Starting a Workflow

Workflows can be started

  1. Manually via agent selections in the workflow assistant
  2. Automatically, on ticket creation, as a result of ticket fields matching workflow start conditions 

Starting Workflows Manually

Workflow Availability

On new tickets, the Workflow Assistant presents a drop-down of available workflows for selection.


The selected workflow chosen will start running when the submit button is clicked to create the ticket. 

Workflows can be defined such that they only become available for selection when certain start conditions on the ticket are satisfied. So, as the agent fills out initial ticket field values, the workflow list may refresh itself to show a greater or fewer number of options. In the above example, neither workflow has preconditions and are thus both workflows are always available for selection.

A third workflow "Change Management" is currently being hidden from the list because it has start conditions that are currently not being met on the ticket.

Now lets imagine the agent changes the value of the Ticket Processing field :


Here we see that Change Management is now appearing a valid workflow selection because its start condition has been satisfied.

Where it is likely that a large number of workflows will be available for selection, it is possible to organise the workflows into groups and sub groups, to form a nested structure (see Grouping Workflows (Nested Selection) for full details):



Selecting a workflow

Once the agent chooses a workflow, the assistant will show the name of the starting activity below the selection. Also the wording of the submit button will change to make it clear that a new workflow will started when the ticket is created


Once the agent chooses a workflow, a number of User Interface changes will occur :

  1. The name of the start activity appears below the workflow selection. (Note, the start activity for a workflow can also change depending on the state of field values on the ticket)
  2. The wording of the submit button changes to indicate that a new workflow will started on ticket creation.
  3. The subject may be filled out with a starting value defined for the workflow.
  4. The description may be filled out with a starting value defined for the workflow


Auto population of Subject and Description fields

With respect to points 3) & 4) above, the automatic value is commonly a template containing placeholders that encourage the agent to fill out the variable information before creating the ticket. If the workflow does not define these then the agent will need to fill out the subject and description as normal. 

When switching between workflow selections the subjects and descriptions may be swapped in and out with those relevant to the latest selection. Any manual changes to the fields are preserved against the current workflow selection, so that the user's changes are never lost.


Start Activities that Automatically set the ticket status

It is possible for the first activity in a  workflow to set the status to a different value from new. If so the wording of the submit button changes slightly to indicate this



Initating the workflow

The selected workflow will automatically be placed on the ticket once it is created. The workflow is created server side so there is usually a short delay whilst this happens with the workflow assistant showing that it is busy.


Then the workflow assistant refreshes to show that the workflow is now running with the start "Change Definition" activity, current. And in this case, the first activity has automatically assigned a group, and set the status to "Open".



Completed Tickets

Running Additional Workflows

Once a workflow has completed on a ticket, it may be possible to run the same workflow (or a different workflow) on the same ticket. If so the workflow selection combo will appear again underneath the details of the previous completed workflow.


The current state of the ticket and the start conditions of the various workflows will determine which workflows are actually available.

Status Controlled Workflows

One special case that governs whether a workflow can run on a completed ticket involves the ticket status and "status controlled" workflows. Status controlled workflows "tie" the Zendesk status of solved to the completion of the workflow such that :

  1. it is not possible to set the ticket status to solved whilst the workflow is running,
  2. and it is only possible to set the ticket status to solved when the workflow completes

This often means it is not possible to immediately re-run the same "status controlled" workflow on a completed ticket, because its current status of solved would violate the rules of "status control". Typically the ticket status would need to be manually changed to something other than solved before the same workflow could be run again. The exception is if the workflow's first activity explicitly sets the ticket status to a value other than solved, (eg open) in which case the workflow might be available to re-run (unless its other start conditions are not currently met.)  See Start Activities that Automatically set the ticket status


Automatic Starting of Workflows

If the user does not explicitly select a workflow via the assistant, it is still possible for a workflow to be started on the ticket at creation.

A Zendesk trigger will call the Cloudset server to determine if any of the active workflows have start conditions that match the ticket field values at creation time. Only workflows with start conditions are considered here, others are ignored.

The first workflow whose start conditions are satisfied by the will be applied to the ticket at creation time.

Note evaluation of the start conditions can be quite complex. It considers not only the start conditions on the workflow but those of all its start transtions and starting activities, including down through levels of decomposition if any of the starting activities are decomposed




Was this article helpful?
0 out of 0 found this helpful



Please sign in to leave a comment.