Creating Intentless Workflows
This topic describes how to create Intentless Workflows and Hyperflows, using mostly Workflow examples. Workflows can be included within Hyperflows. Hyperflows use Prompts, and Workflows use Titles and Descriptions. Variables within workflows also have descriptions. To see specifics about Hyperflow creation, see Hyperflow Studio.
After you have a Conversational 2.0 bot set up,
Create a list of workflows and the input required for each workflow.
For each workflow:
Develop the workflow. Include a detailed description (see the Flow Descriptions section) to be used by your LLM application/bot.
Incorporate the necessary input variables (see the build Input Variables section) and add description for each variable.
Ask your Aisera team to make sure that the Fulfillment variable is set to Flows with No Intent (Intentless) in the Advanced tab of your Bot configuration.
Execute the workflow indexing process (job).
Validate the trigger for all workflows using test phrases in AILens.
General Rules for Conversational AI 2.0 Workflows
You can only create workflows or hyperflows at the bot level.
Avoid catch-all workflows.
There is a tendency for people to generate massive catch-all flows for massive topics like “software troubleshooting”, “hardware troubleshooting”. This should be avoided in general because it doesn't allow the systems to categorize or analyze the data to determine the real intention of the user. It is nearly impossible for a flow to support all possible troubleshooting scenarios. The only scenario where that would make sense is if literally all scenarios are supported by creating a ticket to IT support.
The following example describes how this can destroy the bot experience.
Assume a flow named “Report issue” with the description, “This workflow creates a ticket to the support agents for issues”. If the bot user enters, “I have issue with X”, where X could be literally everything, from KB supported answers to service catalog items, then the workflow is considered valid. Therefore, possibly 90% of the requests would hit this flow, since workflows take the highest priority in the responses. This is how huge umbrella flows can overshadow the rest of the available responses if they are too generic.
The general guideline is to separate the sub-flows into smaller workflows, especially if the topic is also connected to other fulfillment types. If there is a catch-all workflow and workflows that have sub-cases, such as, “hardware troubleshooting” and “fixing the printer”, then the description of the catch-all workflow needs to explicitly exclude the printing issues.
Workflow 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:
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.
Provide clear, concise, and consistent information for all the expected scenarios that are covered. Avoid unnecessary details or broad statements.
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.
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.
Input variables
Intentless Flow Search can now support conversational input variables that are not part of the workflow.
Currently, for each input variable only one value can be supported in each user request.
Currently, information from the user profile is not used..
Variable types
Input variable types supported:
String
Int
Bool
Enum
Entity class
Multi-value support
There are two ways to support a list of constraint values:
Enum
Entity class
For most simple use cases, you can use Enums, since they are more versatile.
Entity classes should be used on two key scenarios:
There is a large number of possible values for the input variable (Such as >10-20). These cases have not been extensively tested and will possibly be harder for the llm to keep track of.
When there is a lot of internal company language/abbreviations and it is impossible to add it to the description of the variable. For example, if there are 4 different ways to talk about the same thing, and the possible synonyms are difficult for the prompt to interpret.
Entity classes are based on exact matching, so you cannot make an error on the spelling. All possible synonyms need to be included in the Ontology (this is not required for Enums).
Date support
Dates can be supported as strings in the system.
The following screenshot displays an example date input variable.
It is important to include in the description of the date variable the exact format expected as output. The system can output any format requested no matter the format the user will use in their requests. In order to support more generic requests like “Show me PRs created in Dec 2024” you need to provide explicit instructions in the description of the input variable like “The user might provide a relative time frame like "January 2023". The starting date then is "01/01/2023"”.
Required vs non-required input variables
The system treats required and non-required input variables differently.
For required slots:
A value must be given by the user in order to trigger the flow
The slot extraction system will ask for three turns until we get a valid value
If a valid value is not given, the system will go to fallback
For non-required slots:
A value is not required
The slot extraction system will ask for 1 turn to get a valid value
If a valid value is not given, the system will trigger the flow
If there is a mix of required and non-required, the non-required slots will only be asked in the first follow-up question and then ignored.
Variable description
The variable description needs to abide to the following rules:
Describe exactly what the variable is doing
Provide as much information as possible for all the expected scenarios that are covered
If the value needs to follow a specific format this format needs to be provided
Avoid too many input variables
The system should be able to handle at least 4 input variables per flow, but has not been tested for more. In general too many variables will lead to very large prompts during value extraction which will lead to worse performance. Therefore it is strongly recommended that the number of input variables is kept to a reasonable level.
If a flow has more than that number of variables, the admin should possibly think how the flow can be separated into multiple different flows that cover subcases.
Process for confirmation
There might be use cases where confirmation of the values extracted is required for the user. For this to be available currently, one can use an existing feature within flows that is called “Input Form”. There, the input variables will be mapped to Input Fields of the node and the values already extracted will be showcased to the user for a final review before triggering the flow. In the example below, Input Form Label Email is mapped to the email input variable of the flow.
Backup input nodes
Input nodes can also be used as backups within the flow. In the seldom case that the conversational aspect of the slot filling is unable to handle a specific use case, input nodes can be used instead of particular input variables.
Acknowledgement or Confirmation of user input
If the customer desires to have a confirmation dialog showing user input and allow corrections before processing flow then they have to create a specific form node in the action workflow which will display all input fields pre-filled and present a chance for user to modify before continuing. This is existing form functionality within action flow and the information will be presented in a form UI and not conversationally. In future phases of this project we plan to change this to conversational acknowledgement.
Last updated