Workflow Best Practices

The following information was provided by Aisera Service Engineers as Best Practices for Workflow Creation.

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:

1. When building flows that invoke Ticket Management operations, use the pre-built ticket management actions. Review screenshots for these actions below:

   1. Create Ticket Action

   2. Update Ticket Action

   3. Get Ticket Detail

   4. Add Attachment Action

   5. List Tickets

2. 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:

   1. 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:

   2. 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;

1. 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.