• Activities are broken down into task models
• Task models define data to be captured, conditions that control flow through the task model and outcomes which control onward transitions when the task model has been completed.
• Task models can use a state machine and use control fields to help manage the ticket based on the route taken through the workflow.

Task Models

When you create an Advanced model, activity behaviour is defined by breaking the activity down into a task model.

To break an activity down into a Task Model, open the activity properties panel and select the Task Model option.

To see the definition of the task model that implements the behaviour of the activity, click on the arrow in the top left of the activity shape.

Tasks

A task is a unit of work in which a set of task fields are defined.  The task fields will define information that needs to be gathered from the agent in order to complete the task.  The workflow assistant will display editors to capture the values of each task field associated with tasks.  The task model is traversed from the start displaying all task fields for each task encountered until it comes to a decision where none of the conditions are satisfied.  At this point, the agent should supply values for the task fields.  Once the information supplied satisfies a Decision condition, the workflow assistant will then display task fields for those tasks encountered following the path in the model for the condition satisfied.

Task Fields

Task fields are defined within a task and are used to gather information from the agent processing the ticket.  Task fields fall into four main categories

1. Local task fields that capture information that is only required during the current activity
2. Task fields based on Process Persisted Fields.  These are similar to local task fields, but the data they gather is global and can be accessed from any activity or task flow.  Information gathered in an early activity can influence the behaviour of a later activity.
3. Ticket based task fields that capture information which will be stored against the ticket (in ticket fields).  This is useful when the captured information may be needed by a subsequent activity or for reporting purposes.
4. Comments that can be added to the ticket using templated comment text.  These comments can be applied to the ticket without completing the current activity and transitioning to the next activity.

Adding and Editing Task Fields

Task fields can be created or edited by selecting the 'Add' or 'Edit' button from within the Task properties panel.  The button will be labelled 'Add' if there are no task fields defined for the Task.

Local Task Fields

Local task fields are used to capture data which is needed in order to complete the current activity, but is not needed anywhere else in the workflow.  Flowset supports many types of local task fields

• Drop Down - Select a single value from a list
• Multi Select - Select one or more values from a list
• Yes/No - Yes or No or not set
• Checkbox - Checked or not checked
• Text - Single line text field
• Text Area - Multiline text area
• Integer - Integer numeric field
• Decimal - Real number field
• Currency - Real number field, but with a Currency Symbol
• Regular Expression - Define a regular expression that the input must match
• Date - Date field
• Date Time - Date field plus a time field
• Guidance Message - A short message to be displayed, plus an optional link to useful web page
• Rich Guidance - A longer fully formatted message which can include formatted text, tables, links task field placeholders and images
• Comments - Templated comments that can be dynamically added to the ticket comment field

Guidance Messages

Guidance messages are displayed in the workflow assistant and will show a maximum of 2 lines of text, plus a link to an external web page if specified.  The message is unformatted and useful for giving short succinct instructions.

 

 

Rich Guidance Messages

Rich Guidance messages are displayed in the workflow assistant in a larger scrollable panel and can contain formatted text, tables, links and images.  The message can also contain placeholders for other task fields.  At runtime, when the rich guidance message is displayed, these placeholders will be replaced with the value of the corresponding task field.

 

 

Process Persisted Field based Task Fields

Process Persisted Field based task fields are very similar to local task fields.  The main difference is that the values captured for these fields are available in other activities and can be used to influence later behaviour of the process.  Local task fields will always start off with an empty value, but process persisted based task fields:

• Can be assigned an initial value in the task field definition
• If no initial value is specified, it will have the latest value assigned to the persisted field (previously in the workflow on the ticket)
• Can be made readonly or hidden
• Can be copied to workflows running on parent or child (parallel) tickets

To define a Process Persisted task field, set the task field type to be 'Persisted Field'.  You will be given a list of the Process Persisted Fields defined against the root process to choose from.  Flowset support process persisted fields of the following types

• Drop Down
• Multiselect
• Yes/No
• Checkbox
• Text
• Text Area
• Integer
• Decimal
• Currency
• Regular Expression
• Date
• Date Time

The Task Field Name is the name displayed in the workflow assistant.  Typically it would be the same as the persisted field name, but does not have to be.  When you select the persisted field, the Task Field Name is automatically changed to be the same.  You can change this if you wish.

For all available persisted field types (except for Date and Date Time), you can specify an initial value to assign to the field when the task is encountered during the task model flow.  When entering an initial value for a Regex (Regular Expression) field, the value entered will be checked against the field regular expression when the task fields are saved.  If the entered initial value does not match the regular expression then it will not be saved.

If the persisted field selected is of type 'Drop-down', then you are given the option to restrict which of the field option values should be available for selection when performing this task.  This allows you to configure task fields to show only the valid options based on previous information supplied.

If you leave the Restrict options to selection empty, then all option values will be available.  Select the option values you wish to restrict the field value to.  When restrictions are defined, the Initialise value to drop down will only show options from the restricted list.

At runtime, the Workflow Assistant will only allow the agent to choose from the restricted list of value.

There are further additional properties associated with persisted based task fields.

Readonly 

The persisted field will be displayed in the workflow assistant, but will be readonly.  The value of this field will not be editable from the workflow assistant.  Instead, the value displayed will be either

1. The initial value supplied in the configuration data
2. The current persisted value of the field

Hide

The persisted field will not be displayed in the workflow assistant, but the assistant will track the value.  Hidden fields are useful when you need to be able to control the behaviour of the task model depending on the value of a persisted field, but without exposing the value to the agent.  The value will be either 

1. The initial value supplied in the configuration data
2. The current persisted value of the field

Copy to parent ticket

  When the current activity finishes (when you transition to the next activity), persist the value to any parent workflow that may exist. See Parallel Process Pattern

Copy to child tickets

  When the current activity finishes (when you transition to the next activity), persist the value to any child (parallel) workflow that may exist. See Parallel Process Pattern

It might be useful, when copying persisted data to parent or child tickets to include a comment to make it more obvious to the agent dealing with the ticket that an update has occurred and they should respond to it.  See Parent and Child Comments for details of how to define these comments.

 

Ticket based Task Fields

Ticket based task fields are fields that will be presented to the agent in the Workflow Assistant (as per Local Task Fields), but these fields correspond to Zendesk ticket fields. When enacting a task in the agent workflow assistant interface, the agent will be able to enter values for ticket based task fields.  The assistant will keep track of any values supplied, but the task field values will only be applied to the Zendesk ticket fields when the activity task flow is completed and you transition on to the next activity.

Set the task field type to 'Ticket Field'.  You will the be given a list of the Zendesk ticket fields defined from which to choose.  Flowset supports Ticket based task fields for the following Zendesk ticket field types

• Tagger - Single valued drop down fields
• Multi-select
• Text
• Text Area
• Regex
• Integer
• Decimal
• Checkbox
• Date
• Plus the system fields priority, type, status and ticket form

The Task Field Name is the name displayed in the workflow assistant.  Typically it would be the same as the ticket field name, but does not have to be.  When you select the Zendesk ticket field, the Task Field Name is automatically changed to be the same as the Zendesk ticket field name.  You can change this if you wish.

For all available Zendesk field types (except for Date), you can specify an initial value to assign to the ticket field when the task is encountered during the task model flow.  When entering an initial value for a Regex (Regular Expression) field, the value entered will be checked against the field regular expression when the task fields are saved.  If the entered initial value does not match the regular expression then it will not be saved.

If the Zendesk ticket field selected is of type 'Drop-down', then you are given the option to restrict which of the ticket field option values should be available for selection when performing this task.  This allows you to configure task fields to show only the valid options based on previous information supplied.

If you leave the restrict option to selection empty, then all option values will be available.  Select the option values you wish to restrict the field value to.  When restrictions are defined, the initialise value to drop down will only show options from the restricted list.

At runtime, the Workflow Assistant will only allow the agent to choose from the restricted list of value.

There are further additional properties associated with ticket based task fields.

Readonly

  The Zendesk ticket field will be displayed in the workflow assistant, but will be readonly.  The value of this field will not be editable from the workflow assistant.  Instead, the value displayed will be either

1. The current value of the field from the ticket if no initial value was supplied in the configuration data
2. The initial value supplied in the configuration data

Hide

  The Zendesk ticket field will not be displayed in the workflow assistant, but the assistant will track the value.  Hidden fields are useful when you need to be able to control the behaviour of the task model depending on the value of a ticket field, but without exposing the value to the agent.  The value will be either 

1. The current value of the field from the ticket if no initial value was supplied in the configuration data
2. The initial value supplied in the configuration data

Copy to parent ticket

  When this value is committed to the ticket (when the activity is finished and you transition to the next activity), copy the value to any parent ticket that may exist. See Parallel Process Pattern

Copy to child tickets

  When this value is committed to the ticket (when the activity is finished and you transition to the next activity), copy the value to any child ticket that may exist. See Parallel Process Pattern

It might be useful, when copying field values to parent or child tickets to include a comment to make it more obvious to the agent dealing with the ticket that an update has occurred and they should respond to it.  See Parent and Child Comments for details of how to define these comments.

Comments

Comment task fields allow the workflow designer to define templated comment text that can be applied to the ticket by the agent at runtime.  The workflow assistant will show a list of all comments defined for the task and the agent can select one to apply to the ticket.  When selected, the configured comment text is added to the ticket comment.  This facility allow the workflow definition to define standard ticket comment responses that can be used at appropriate points in the workflow.

 

To define a comment task field, set the task field type to 'Comment' (1).  The name (2) will be displayed by the workflow assistant and should indicate the nature of the comment that will be added.  The description (2) is used as a tooltip in the workflow assistant.  Select whether the comment should be public or private (3) and then fill in the comment text (4).  The comment editor will provide a drop down menu from which placeholders can be selected.  These placeholders correspond to task fields define in this task or any preceding tasks and will be replaced with the value of the task field when the comment is inserted onto the ticket.  The comment editor supports formatted text, tables, links, images and task field placeholders.  For more details on using these features see Transition Comments

To save the comment against the ticket, the ticket will need to be submitted.  The agent will be able to modify the template comment text that has been inserted by the workflow assistant prior to submitting the ticket.

 

Display Separators

The workflow assistant will display task fields for all tasks that it encounters when navigating the model.  When data has been entered for some task fields, further tasks may be enabled and their task fields will be displayed.  To help with understanding which task fields correspond to which tasks, there is a configuration option which instructs the workflow assistant to display the task fields for a task within a collapsible section whose heading will be the name of the Task.

 

In (1) we see how the workflow assistant displays the task fields without grouping them in a section based on the task name (Group Task Fields switched off).  In (2) we see the same task fields displayed but in a section named after the task name (Offer Letter and Contract) (Group Task Fields switched on).  Clicking on the chevron (3) will collapse the section to make it easier to see other task fields or sections.

Including Task Fields in Transition Comments

When a task model has completed and the workflow will now transition to another activity, Flowset allows Task Field information captured in the Task Model to be saved on the ticket as a comment.  The Task Field data can be applied to the current ticket (as a record of information supplied for local task fields) and/or can be used as the initial description of any parallel tickets that might be created when the workflow transitions onwards.  See Transition Comments for details.

Decisions

A decision is used to define a set of conditions based on the task field data gathered so far in the task model.  Each condition, when satisfied, will expose further tasks.  Each condition will proceed along a different path through the task model. If you define three conditions in a Decision, then there must be three separate paths leaving the decision which will be labelled with the condition satisfied.

 

 

 

The example shows a decision in which 2 conditions are defined (Accepted and Not Accepted).  If the Accepted condition is satisfied, then the workflow assistant will display the task fields associated with the Offer Accepted task.  If the Not Accepted condition is satisfied, then the task fields associated with the Debrief task will be displayed.

Adding and Editing Decision Conditions

Decision conditions can be created or edited by selecting the 'Add' or 'Edit' button from within the Decision properties panel.  The button will be labelled 'Add' if there are no conditions defined for the Decision.

Create a decision and give it a name.  You can then edit the condition associated with the decision.  The condition will be defined in terms of task fields that will have been encountered in the task model up to the point the decision has been defined.  You will not see task fields for tasks that follow the decision.

The screen shot shows defining a Decision Condition.  The conditions provide a list of all Task Fields plus any defined Process State and Process Helper Fields.  Those fields suffixed with (T) are based on Zendesk ticket fields, those suffixed (P) are based on process persisted fields.  These fields can be used in the conditions.  If you want to have a condition based on the value of a Zendesk ticket field or a process persisted field,  then there will need to be:

1. A ticket or persisted field based task field that is on the task model flow leading up to this decision.  This will include Readonly and Hidden ticket or persisted based task fields.
2. A Process State or Process Helper Field defined for the process (See Process State, Helper and Control Fields)

Each condition defined in the Decision shape is evaluated in order.  Once a condition is satisfied, the path defined for that condition is followed by the workflow assistant.  If there is the possibility that more than one Decision condition might be satisfied, the first one will be chosen.  For this reason, you can change the order of the decision conditions within the Decision shape.

Outcomes

When a task model completes, it will typically produce an outcome.  If the task model has many decisions and hence many paths through the model, each path through the model can produce a different outcome.  These outcomes can then be used at the parent activity level to control which transitions are available when moving on.

Outcomes can be conditional or unconditional.  Unconditional outcomes are when there is a path through the task model which reaches a stop shape and on the link connecting the last task to the stop, you can define the outcome (say Not Hired).  When the workflow is run on a ticket, if the data and decisions mean that this path is followed through the task model, then the outcome will be Not Hired.

Conditional outcomes are when the outcome is dependent on data that has been captured as part of the task model.  An Outcome Decision shape is used to define the conditions and each condition will define a separate outcome.

Outcomes are defined on the flows that join to Stop shapes.  Essentially the task model has completed and the flow defines the outcome that has resulted.

Unconditional Outcomes

When the last flow comes from a task to a stop shape, you can edit the flow properties and define the outcome that should be produced when following this path through the model.

Double click the flow and then enter an outcome name.  The outcome message will be displayed in the workflow assistant when the outcome is satisfied to indicate the outcome that will be produced.

Conditional Outcomes

When the outcome is dependent on the data that has been supplied by the agent, we use an Outcome Decision shape to define which outcomes are satisfied under which conditions.

Define conditions from the outcome decision properties sheet.  The names of the Outcome Decisions correspond to the outcomes assigned to the flows.

Edit the properties of the flows from the Outcome Decision to the stop shapes and select the outcome that the flow corresponds to.  You will be presented with a drop down list based on the names defined in the Outcome Decision.

The model should have a flow for each outcome defined in the Outcome Decision.

Outcome Comments

Outcomes can be used to control where you can transition to when the current activity completes.  If a task model produces many outcomes, it is possible that an onward transition may be available for multiple outcomes.  You can configure this by selecting multiple outcomes on the transition link.  The  transition can have a comment associated with it which will be applied to the ticket when the transition is selected by the agent.  However, this comment will be applied regardless of which outcome caused the transition to become available.

You can use outcome comments to associate a comment with a specific outcome.  This will allow the comment to be specific to the outcome that allowed the transition to occur rathe than the transition itself.

If and outcome comment and a transition comment are defined, then the outcome comment will be chosen over the transition comment.

Double click the outcome flow (1) and click the Add or Edit button (2) to edit the comment text.  A comment editor will be presented to capture details of the comment to be added to the ticket when this outcome is satisfied.  See Transition Comments for details of how to use the comment editor.

Background Events

There are a number of background events that can occur on a ticket which are not part of the normal flow of the ticket through the workflow defined on it.  An example is when a ticket has been set to pending awaiting a response from the requester and the requester provides the response.  In this case, the ticket status will change automatically to open.  It would be difficult to model the behaviour you would expect when such a background event occurs, since you can never really be sure when it might occur.

Flowset allows you to define for a Task Model, which background events it should respond to and what is the impact of the background event on the State and Helper fields (which govern how the Task Model should behave).

A full description of how to define the handling of Background Events in Task Models can be found in Process State, Helper and Control Fields (for Advanced)