• 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 two main categories

1. Local task fields that capture information that is only required during the current activity
2. 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.

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 message to be displayed, plus an optional link to useful web page

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 values will only be applied to the 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
• Text
• 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.

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.

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

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 Helper 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 then the ticket field will need to be:

1. A ticket based task field that is on the task model flow leading up to this decision.  This will include Readonly and Hidden ticket based task fields.
2. A 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.

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 what 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)