Please check articles under Customer and Staff for a general introduction to working with Approvals and Initiating Workflows. This section deals with setting up workflows.

Approval workflow engine is shared across Incidents, Requests and Change tickets. The good part of this obviously being that any workflow can be initiated from any ticket type!

We take it that you are familiar with the basics of workflows.

As a quick note though, workflows are comprised of a set of approvals from various teams and individuals (usually) in a pre-determined order. the workflow path can take any form with the most popular being Series, Parallel and a mix of these.

Series: Or one after the other workflow. Example, Person 1 then Person 2 and so on.

Parallel: Any one in a group. Example, Person 1 or Person 2.

Mixed: Not uncommon, this mode is often used where a more complex set of users are involved. Person 1 then, either Person 2 or Person 3, then Person 4.

The Approval workflow engine is fairly powerful and can handle most workflow needs for day to day operations of a desk. More complex workflows like Split, Join need a dedicated workflow system.

Start creating a new workflow by clicking the + sign.

This would bring up the creation (or edit if editing an existing workflow) screen.

Enter a suitable name and start defining your workflow.

The example above is of a two step workflow with Step 1 being Series and Step 2 being Parallel, This is an example of  a typical Mixed workflow.

A note on Approval Users/Groups in the graphic above. An individual user is marked with a (U) at the end while a group is marked with a (G). This allows existing groups from within the desk to be added. You can have a mix of a user and a group too. For example, a step could comprise of Purchase group (a group) and CFO (an individual).

Interpretation of the example

Step 1: Since this is defined as Series and Action Required From All is set to Yes, each user in the list would need to take an action one after the other in order to clear this step

Step 2: Defined as Parallel and Action Required From All is set to Yes, all members in this step would need to approve before this step is complete. As an alternate, Action Required From All could be set to No and anyone in the group could approve the step. This can often be the case where workflows stall due to absence of an approver. You could have a Purchase group approval where any person from the department could approve and the workflow could continue to the next step.

Or, anyone could Reject a request and the workflow would stop at that point.

If you are working with Change Approvals, this can provide the flexibility required where you might not want approvals to stall due to non-availability of Change Approval Board.

Provisioning

A typical use case is provisioning request from HR on incoming, outgoing or moving employee.

In this case you might want a mix of groups and users, some who are desk staff and others who only have customer access to the desk. This is no problem as you can add any user to the approval step.

A mix would then be useful for adding Series steps with must approve and parallels to keep HR informed of the progress.

Adding Users

An area which often trips administrators is should I use a named user or a generic alias?

Workflows associate individuals with approval authority. Users come and go, but the responsibility continues to be attached to the position. You may decide for example to use a generic id like HumanResources@YourCompany.com instead of a named user.

It is however possible that this generic alias does not log into the desk to complete an approval causing your approvals to be incomplete. (You can still close tickets with incomplete workflows).

But to keep the data sanitised you could add yourself or a desk staff to be part of a Parallel workflow with setting of Required Approval From All to No and go ahead and close the workflow. This also ensures the work assignment was indeed completed for audit and traceability.