In native Zendesk, conditions are a core concept for Triggers and Automations, for given data patterns, triggers will fire and implement the defined actions. As such, the business logic is tightly coupled and critically linked to a ticket update, specifically against the ticket persisted data store.
Flowset conditions are both more flexible and can be loosely coupled or not coupled at all. Flexibility is achieved by making conditions configurable is several places using different types:
- Activity Pre-conditions - activity can't start until defined data requirements are present
- Activity Completion conditions - activity can't complete until defined data requirements are present
- Transition conditions - transitions between activities can't occur until defined data requirements are present
While it is possible that Pre, Completion, and Transition conditions can be blended together, it's more likely that only one method would be applied at a time.
| Type | Concept | Scenario Description |
| Pre | These are the requirement needed to start this activity. | As either the only transition into an activity or if they are multiple incoming transitions that share all the same condition start parameters, it's especially efficient to define in one place |
| Completion | These are the requirements that need to be satisfied to consider this activity complete in its own right. | This is akin to stating the activities deliverables. These may naturally align with the pre-conditions on the next activity. As such, either a completion condition on the current activity is used or a pre-condition of the next activity. However, Completion conditions are particularly suited to where the deliverables of the current activity may be consumed later on in the workflow process. |
| Transition | The requirements of this specific transition to move between activities. |
Two opposite use cases are supported: (1) The simplest universal point to define the conditions needed to move from one activity to another in a simple sequence. (2) The ability to be very granular, specifying different conditions depending on where the transition is coming from. Note: These granular transitions could be used as supplements to Pre-conditions i.e extra requirements depending on where they come from. |
The choice of which to use for which situation is just a preference and perhaps one of consistency or efficiency, but by offering such choices it's not prescriptive or restrictive.
Where condition types are combined, they are additive in the case of Transition and Pre-conditions and experienced by the agent as a composite set guarding the ability to transition.
Completion conditions are subtly different as they are implemented independently of the choice of the next transition, indeed the next transition will not even get offered until the Completion condition(s) are met. The results of the activity may well govern the available choices as a way to make and surface data-driven decisions.
A very important and distinguishing aspect of Flowset flexible conditions is that they can be visibly interactive without the need to submit the ticket. The business logic will detect the setting of fields or selection of transitions in real-time, the logic is not hidden, rather the logic can guide the agent. No data is changed until the ticket submits.
A further example of enhanced visual business logic and interactivity is the exposure of choices as defined conditions, not just a binary assessment. A transition or pre-condition of the next selected activity can offer the choice of the parameters of a condition e.g. pick from a restricted set of Groups for the next activity. This can cut down on the number of activities required if it's basically the same activity.
Any associated actions like setting comments or fields are defined separately as part of either the transition, an accelerator, or on initialization on arriving at the next activity. This decoupling makes for a much more powerful process-orientated approach to what an activity requires, what context it needs to create for itself to implement the activity, and what it delivers.
It's also entirely valid to not need to use any conditions to implement a workflow process. The workflow can simply be a series of logical steps and/or alternative paths to take.
Comments
Please sign in to leave a comment.