Workflow Enactment Permission Concepts

Flowset specifically uses the term Enactment Permissions to add emphasis to the ability to grant role-based permissions to enact either a transition or the ability to work on an activity. 

Typical use cases are workflow processes that include the notion of approvals, as ultimately implemented by people fulfilling roles. To maintain a level of abstraction, Flowset assigns roles to permission enactments. Currently, roles are just scoped to Zendesk Groups, but this is being expanded to integrate with the Systemset Roles Engine.

Note: The omission of the ability to define specific agents within Flowset configurations is purposefully excluded as it makes the workflow process more brittle and increases the burden on maintaining volatile operational data in semi-static configuration design. The Systemset Roles Engine provides the ability to more widely delegate who fulfills roles to agents who are not necessarily Zendesk admins i.e. at a business operations level.

There are two enactment points where permissions can be applied:

1. On transitions - only defined roles can transition between specific activities
2. On activities - only defined roles can update ticket data on specific workflow process activities

This provides flexibility on how best to apply for different types of process approaches.

Using transitions permissions can be thought of as a guard that protects against unauthorised movement between activities. Transition labels presented to agents can be used to incorporate terms like approved. If an agent does not have the correct permissions they will see the transition tab colored red.

By placing permissions on the activity, this affords more direct modeling of the act of approval step or the locking of an activity from those who don't have the role or responsibility to implement. However, much like Zendesk Light Agents, all non-permission agents would still be able to add private comments, but would not able to process the ticket data beyond this.