Workflow Zendesk Integration

Workflow Activity Field

Every published workflow has a custom dropdown ticket field generated whose values represent each of the activities in the workflow.  There is a drop down value in the field that corresponds to each activity defined in the workflow.  The generated field will be named '[Flowset] <Workflow Name>', where <Workflow Name> is the name given to the workflow.  For example, a workflow named 'Change Management', will have a custom field named '[Flowset] Change Management' generated.

When the workflow runs on a ticket, the generated workflow field will be set to the name of the activity currently running on the ticket.  Using this field, you can build Zendesk views to track the progress of tickets through the various workflows you have defined.

Each activity in the workflow is represented by a drop down value in the field.  The option value label will be the name of the activity, the tag will be a value generated based on the internal id of the activity shape in the workflow definition.  If you edit a workflow definition and change the name of an activity, the corresponding label of the drop down option will change, but the tag will remain the same and everything should continue to work fine.  If you delete an activity and replace it, the new activity will have a new id even if you name it the same as the previously deleted one.  This may result in the field value disappearing from tickets that were on the now deleted activity.

Any running workflow that is affected in this way by changes to the workflow definition will recognise that it is inconsistent with the new workflow definition and offer the agent ways to rectify this.

Blocked Activities & Unblock Notifications

It is sometimes necessary to split some of the activities in a workflow onto separate tickets.  This may be because the agents responsible for this part of the workflow are different than the primary activity and these split activities can occur at the same time as the primary activities.

In the example above, the process splits after the first activity completes. Two split tickets are created which implement the 'Systems & Facilities Provision' and 'New Employee Liaison' activities while the primary ticket will transition on to 'Managers Preparation'.  Next we see that the two split activities rejoin the primary activity.  In this case, the primary activity cannot transition on to 'Team Introductions' until both of the split activities are completed.  The main ticket workflow is blocked by these two split tickets.

When defining your workflow you can configure it to mark a ticket when the workflow running on it is blocked by split parallel tickets.  A ticket field called '[Flowset] Activity Block' will be set when processing the workflow.  It has the values Not Blocked, Partially Blocked and Blocked to indicate the extent of split activity blocking that is occurring. 

You can incorporate this field into Zendesk views to help understand which workflows are able to proceed and those that cannot.

Furthermore, you can also enable another configuration option which will email the ticket assignee when it changes from blocked to not blocked.

Auto Transitions

When designing your workflow, you may wish to include in the design places where ticket requester interactions are expected.  Usually, the agent will set the ticket status to pending and await the requester to make a comment on the ticket, at which point the status is changed to open automatically by Zendesk.  Another use case is when the agent sets the ticket status to solved.  If the requester adds a further comment, Zendesk will re-open the ticket.

When designing your workflow, you can define auto transitions which will be performed in response to the requester reopening the ticket from pending or solved.

In the above example, when the workflow is running the activity 'Awaiting Requester Response', if the requester adds a comment to the ticket and hence changes the status from pending to open, then the workflow will automatically transition to activity 'Action Requester Response'.  The transition is drawn with a dashed line so it is easily identifiable.

In this example, a solve reopen automatic transition is drawn (marked with a dot-dash line) from the last activity that would have run on the ticket prior to the workflow stopping (and the ticket being solved).  In this case the Recommend activity.  If the ticket is reopened by the requester adding a further comment to the ticket then the workflow will automatically transition back to the 'Diagnose' activity.