- Define process persisted fields whose scope is the entire workflow which can be used to share information between activities without the need to use ticket fields.
- Nominate a ticket custom field or process persisted field which will represent the state of the workflow
- Nominate helper fields which can be used to help guide the progress of the process as well as record details about what has been done so far
- Use Process State field and Helper fields in task models (in Decisions) to control the process.
- Enable Process State field and Helper fields to be set/updated as part of the normal running of the process to record what has happened so far and potentially influence future behaviour
- Nominate Controlled ticket fields whose values will be controlled by the workflow assistant and therefore disabled in the Zendesk left hand panel.
Process Persisted Fields
A workflow definition will usually consist of activities to be carried out on a ticket. These activities represent a set of tasks that need to be performed before moving on to the next activity. To perform the tasks, data may need to be gathered from the agent and used to make decisions about how to proceed. Typically this tasks data is local to the activity being performed and will not be known about in later activities.
Process Persisted Fields allow task data to be collected, but held in such a way that is it accessible to subsequent activities. This allows a workflow to be designed to gather information early in the process, which can then be used later without having to ask the same question again. For example, in an employee onboarding process we capture whether someone will be a home worker early on, but may need to use this information later in the process to decide whether they will need a desk allocated.
Process Persisted Fields are available if the Persist Activity Task Data option is enabled for the root level process definition. See Workflow Options for details of enabling Persisted Activity Task Data.
Generally, Process Persisted Fields can be used wherever you can currently use task fields which are based on Zendesk Ticket Fields. Process Persisted Fields are given names, descriptions and are typed. The types which are supported for Process Persisted Fields is as follows
- Drop Down - Specify the available option values
- Multiselect - Specify the available option values
- Yes/No - Similar to check box, but has 3 values - Yes, No & Not set
- Checkbox
- Text
- Text Area
- Integer
- Decimal
- Currency - Specify the currency symbol to use (e.g. $)
- Regular Expression - Specify a regular expression pattern that needs to be matched
- Date
- Date Time
Process Persisted Field values are scoped to the ticket where their value was defined. If you define a process which creates child (parallel) tickets, these child tickets will have their own copy of the process persisted field values. When a child ticket is created, you can specify ticket field values to copy from the parent ticket to the child ticket. You can also specify process persisted field values to copy from the parent to the child. By default, the process persisted field values for a child will be empty unless you copy values from the parent.
You can define task fields based on process persisted fields and mark them to be copied to parent or child workflows when their values are changed and committed. See Parent/Child Field Sync (Advanced Only) for details.
Defining Process Persisted Fields
When the Persist Activity Task Data option is enabled for the root process, you will be able to define process persisted fields.
Double click the root process shape on the topmost process definition. Select Add or Edit option to define process persisted fields.
Define the fields of the appropriate type which will capture data needed by the process. Typically you will only need this where the data is to be used in many activities.
Once process persisted fields are defined, they will be available to be used in
- Process State and Helper fields (see below)
- Task fields in a task flow (see Activity Task Modeling)
- Activity Pre Conditions (see Activity Pre-conditions)
- Parent Child Task Field Syncing (see Parent/Child Field Sync)
Process State
Advanced Models are able to nominate a custom ticket field or process persisted field whose values can be used to represent the state of the workflow running on a ticket. This can be used, for example, to identify that the ticket has been escalated in importance. Task models can be designed to behave differently if the Process State is escalated.
When defined, task model decisions will be able to define conditions which use the process state field. Hence you can define different paths through the task model based on the process state field.
Defining the Process State Field
Each Advanced workflow definition can nominate a process state field.
Double click the process shape on the topmost process definition. Select the Add or Edit option to nominate the Process State Field.
Find the field in the list that you want to use as the Process State field and select the checkbox then click Save. You can select only one Process State Field. You can choose from any defined Process Persisted Fields or Ticket Fields. In this example, the Process State Persisted Field is being used.
Helper Fields
Process Helper fields can be used to hold useful information about the process that is running on the ticket which may be used later to control the path taken through a task model. For example, you may have an activity that can be run multiple times within the lifecycle of the ticket, but the behaviour of the activity task model may need to differ after the first time the activity is run. A Helper field can be used to indicate that the activity has been run before and govern the behaviour.
When defined, task model decisions will be able to define conditions which use the helper fields. Hence you can define different paths through the task model based on these helper fields.
Defining Helper Fields
Each Advanced workflow definition can nominate process helper fields.
Double click the process shape on the topmost process definition. Select the Add or Edit option to nominate the Process Helper Fields.
Find the fields in the list that you want to use as Helper Fields and select the checkbox then click Save. You can nominate as many Helper Fields as you wish. In this example, Next Review is a Process Persisted Field and Candidate Name is a ticket field.
Using State and Helper Fields
Controlling Flow Models
Having defined Process State and Helper fields, these fields are presented when editing Decision conditions in the task models within the process definition. The conditions can be based on task fields from the task model plus any Process State and Helper fields that have been defined.
When defining a condition in a Task Model Decision, the drop down listing the fields to choose from shows any task fields defined in the Task Model, but will also include the Helper fields and State field. Helper and State fields will be suffixed with (T) if they are ticket field based or with (P) if they are process persisted field based.
Setting Process State or Helper Fields
The completion of a task model is indicated by a flow that goes to a Stop shape. Essentially the task model is complete, the flow will typically have an outcome associated with it (which can help control which activity you can transition to next). When you are using Process State or Helper fields, you can set their values in the Stop shape. Essentially now that the task model is complete, some of the data associated with the Process State or Helper fields may need updating. Using the Stop shape to update these fields means that they can be manipulated without exposing them to the agent running the process on the ticket.
Double click the stop shape in the task model. Select the Add or Edit option to nominate the Process Helper Fields. Bear in mind that if you have multiple stop shapes in your task model, each stop shape can be configured to set different State or Helper field values.
Add an entry for each State and Helper field that should be set. Select the Field (This drop down shows only the Process State and Helper Fields) and then define the value to be assigned when the task model completes. In this case, when the task model completes, the Next Review field will be set to Month 1.
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).
To define which background events the Task Model should respond to, click the Background Events button.
This background model has identified that it will respond to the custom1 and custom2 background events. For custom1, this will produce an outcome of BG Auto 1. For custom2, the outcome is conditional based on conditions defined in the Outcome Decision. The conditions in the Outcome Decision can be defined in terms of the Process State field and any Helper fields. In this case, there are 2 possible outcomes (Normal and Escalated).
There are four background event types which are
- Pending Open - the ticket has been changed from Pending to Open due to the requester responding to a pending ticket.
- Custom 1, 2, 3 - These are 3 custom events that are triggered when the ticket is updated and specific tags have been added to the ticket.
In the stop shapes, you can set Process State or Helper field values (in the same way as in the Task Model - See Above). By setting different values of Process State or Helper fields, you are able to control the behaviour in later Activities.
Consuming Background Event Outcomes
In the Parent Workflow, as well as normal transitions controlled by Task Model outcomes, you can defined Automatic Transitions which are controlled by outcomes created by Background events.
Here we see the Last Minute Activity has 2 transitions that are controlled by background event outcomes. These are shown with dashed lines. When BG Auto1 or Normal background outcomes occur, it will transition to Review Progress. When the Escalated background outcome occurs, it will transition to Handle Escalation.
When background event outcomes are defined for a Task model, when you edit the properties of the transition, a drop down will allow you to select the Auto Transition Type. This has 2 possible values
- Manual Transitions - normal transitions based on Task model outcomes
- Automatic Transitions - based on background event outcomes.
When you select Automatic Transition type, the available list of Activity Outcomes will list only the background event outcomes to select from. When it is set to Manual, you will see the Task Model outcomes.
Controlled Fields
When running an Advanced Workflow on a ticket, the workflow assistant takes on responsibility to present and manage those ticket fields that are used to enable the process to run. These fields fall into 3 main categories
- Process State Field - Typically used and updated by the workflow but not exposed to the agent
- Helper Fields - Typically used and updated by the workflow but not exposed to the agent
- Ticket based Task Fields - Part of the workflow definition and often will be presented to the agent in the workflow assistant to fill in as appropriate
Since Flowset is responsible for managing the values of these fields, it is undesirable for these ticket fields to be manipulated directly on the Zendesk ticket in the left hand ticket field panel. This could result in the agent setting values in these fields that are inappropriate for the workflow. To prevent this from happening, the workflow assistant will disable all Process State and Helper fields so they cannot be edited by the agent.
Ticket based Task Fields will also be disabled in the left hand panel, but there is a choice about how this is applied. You can
- Disable all ticket fields that are used in any task model in any activity in the workflow (this is the default behaviour)
- Disable all ticket fields that are used in the task model running in the current activity on the ticket
To select option (2)
If you choose to controlled fields at the activity level, then as you progress from Activity to Activity in the workflow, a different set of fields may be involved in each Activity and hence a different set of fields will be disabled. If there are some fields that you wish to always be disabled regardless of which activity is running on the ticket, you can specify these as Process Controlled Fields
Double click the process shape on the topmost process definition. Select the Add or Edit option to nominate the Process Controlled Fields.
From the list of presented fields, select those fields that should always be disabled in the left hand ticket field panel. In this case, Full Details will always be disabled regardless of which activity is running on the ticket.
Once the workflow on the ticket has completed, all ticket fields that were disabled whilst the workflow was running will re-enabled.
For examples of how the Workflow Assistant disables fields see Disabling Ticket Fields (for Advanced)
Comments
Please sign in to leave a comment.