Teneo makes it easy to start creating new flows as soon as you've created your environment. Before you get started, however, it is best to plan ahead in order to make it easier to manage larger projects as they continue to expand. Standardizing everything from naming conventions to the quality and quantity of trigger example inputs will help ensure the highest possible quality of a solution, making it not only effective, but also easy to understand and troubleshoot. As there are a lot of things to keep in mind when designing flows, we have compiled the following checklist which can be used to quickly verify that your newly built flow meets the highest standard.
Every flow has its own properties; these are important to acknowledge as they can act differently depending on the Match Requirements set inside the flow. Here are some questions to consider when working on flows that may help you.
Is the flow stored in the relevant folder?
Does your flow have a descriptive name?
Is the flow name consistent with other flow names in the solution?
If this is a special type of flow (e.g. Prompt flow or Sub-Flow), does the flow name reflect that?
Triggers inside the flows can work in different ways depending on the Match Requirement set on the trigger. The usual things to choose from are classes and conditions. As they both differ from each other it is important to consider the following questions:
Does each trigger in the flow have a name that describes its purpose?
Do the condition (non-programmatic) triggers have 3 - 5 positive example inputs?
Are the example inputs of the same degree of exactness?
Are they not too 'fluffy'?
Is none of them a subset of another?
Check the language conditions of the condition match requirement; make sure they are not too wide.
Does the class match requirement have at least 10 learning examples?
Are the flow’s triggers in the right trigger order group(s)?
Flow nodes are found inside a flow. They are used for different functionalities and are described everywhere around Teneo Developers. Here are some things to think about when working on flow nodes:
Do the nodes in the flow have names that describe the purpose of that node?
Should output nodes be revisitable, and if so, how often?
In most cases, you will want output nodes to be revisitable if they are followed by a 'Get input' transition.
Do transitions that 'Get input before continuing' have match requirement(s)?
In most cases, transitions of type 'Get input before continuing' must have a match requirement.
If your flow contains an integration, is there a fallback answer after the integration in case the integration is down or returns an unexpected result?
Does the flow contain parts that can be re-used in other flows? If so, should you create a Sub-Flow for it?
Testing the flow
Testing can be done in various different ways around Teneo. First and foremost, we have our own Auto-Test inside the studio. On top of that we have our own developed Dialog Tester and a partnership with Botium on testing your Teneo solution there.
After building a flow, test what you have implemented, but don’t restrict your tests to the inputs that you built the flow on.
Is your flow triggering? If not, it is probably a coding problem or an ordering problem; check the condition and trigger ordering.
Is your flow stealing inputs from other flows? Should it trigger on keywords only? Run a solution wide Auto-test to see if your new flow is stealing inputs from other flows.
What happens if you don't follow the 'happy path'? What happens if a user says something unexpected?
Try out every path and try to discover weak points in your solution. For example, when someone answers in an unexpected way, it is important to reply in a fashion that makes sense. While in the middle of a booking a flight, you should answer appropriately when the 'happy path' is not followed instead of giving the standard Safetynet answer.