# Workflow Best Practices
The following information was provided by Aisera Service Engineers as Best Practices for creating Workflows.
### Writing Good Titles and Descriptions
Workflow **Titles** and **Descriptions** are the key information used by the system to search and validate the relevancy of a flow to a user's Request. If they are not set up correctly, the system will not retrieve them nor validate them.
For **Titles**, use a general representation of what the workflow does.
In order to generate a correct flow description, follow these rules:
1. Describe exactly what the flow is doing. Clearly state the core use case addressed by the flow. Describe the key actions in the workflow, such as upgrade a license, troubleshoot a PC, or remove electronic access, so that the search engine can easily match the relevant keywords.
2. Provide clear, concise, and consistent information for all the expected scenarios that are covered. Avoid unnecessary details or broad statements.
3. Include relevant examples **only when necessary**, such as to highlight edge cases or customer-specific terms. This will help enhance both search and validation logic.
4. Avoid using personal names, such as, “this flow removes electronic access, for example, disable mark smith user”. Instead, use keywords like co-worker or employee.
**Example Flow**
> **Title:** MS projects and Visio provisioning
>
> **Description:** This flow addresses requests specifically for the applications Microsoft Project and/or Microsoft Visio, requests for access (or access rights/license) or upgrading/activating/reactivating a user's application's access/account/license/subscription and users' requests to download, install, reinstall and/or set up those applications OR assistance in troubleshooting the aforementioned actions. The device, if mentioned, is a computer or phone.
The description here is an amalgamation of all the phrases mentioned in the original intent. In cases where multiple scenarios are all covered by a flow, the more thorough the description, the better performance the system will provide.
**Example flow with examples**
> **Title:** Hardware Troubleshooting
>
> **Description:** This flow addresses any issue related to hardware equipment (PC, phone, PC/phone accessory/peripheral) malfunctioning or not working to the requestor's liking/convenience (such as, device not turning on, screen issues, unresponsive peripherals).
If no description is provided, the workflow will not be available in the **Intentless Flow Search**. By leaving descriptions for subflows empty, you can exclude them from the detection process. If you update the description of a prompt, you need to re-index your data, so the revised version of the prompt can be passed to the system.
### Workflow Best Practices
The best practices for Workflow creation include:
1. Always create an output variable if the JavaScript node function returns a result that affects the flow or the flow sequence. Example: for a use case where you update session variables, always declare an output variable such as `sessionVars,` as the output variable for the JavaScript node.
2. Do not use **botId** for the variable name in the flow, since this is a reserved word and may unexpectedly change the variable value in the flow runtime execution.
3. Repeated and reusable functionality should be included at a separated subflow. With this approach, your flow is more readable and you have the ability to re-use the subflow as needed.
4. Values that are used often within the flow, should be included as a separate flow variable and should be initialized at the beginning of the flow. Use the pre-built Set Variable node in this case. Some examples include base URLs and integration specific tokens.
5. Each action that contains a `success` output variable (indication of whether the operation was successful) should be followed by a decision node based on the above `success` or `failure` result. In the case of failure, use the appropriate message node to display the error details. The following screenshot displays an example:
6. When building flows that invoke Ticket Management operations, use the pre-built ticket management actions. Review screenshots for these actions below:
1. *Create Action Node*
*b. Update Ticket Action*
*c. Get Ticket Detail*
*d. Add Attachment Action*
*e. List Tickets*
7. If an HTTP Request should be executed within the flow, this operation is more preferable to be made by an *ExecuteRestCallAction* node. Unlike HTTP Request node, this option offers a better handling on the debugging side (logging). For this purpose:
8. A test integration should be created, that will work only as placeholder for the HTTP Request such as *Zabbix.* The integration can be configured with Test / dummy variables: 
9. Any authorization details should be provided within the headers. An example of headers definition is provided below:
```
var headersMap = new java.util.HashMap();
headersMap.put("Authorization", "Bearer " + bearerToken);
return headersMap;
```
10. For the **User Input** node, if there is already a variable with same name defined in previous nodes, or if the **User Input** node is the leaf node, then the **User Input** node will be skipped. One exception is the **GOTO** node, which will skip the variable check logic and will ask for input variables with the same name.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.aisera.com/workflow-best-practices/workflow-best-practices.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
