Extending a Workflow¶
Introduction¶
The workflow is what defines the paths a case can move on from start to finish. Depending on how the workflow is designed there can be more than one path. It consists of states and transitions.
State¶
States are the stations or steps a case can go through. Every case usually starts with an entry state, which usually is a draft, and ends with a final state, e.g. approved. In between there can be as many states as necessary. All of these states in between can, but don’t have to, be entered on the way to a final state. The order in which the states are moved through is defined by the workflow's transitions.
Transition¶
Transitions are the connections between states. Each transition acts like a gate that allow a user to enter from one state to another state. This way it can be clearly steered which state a user can enter next.
Adding new Steps to a Workflow¶
When a workflow needs an extra station to go through a new state needs to be added to it. Adding an extra state starts as usual with giving it a key and a name.
It can then further be decided if a state should be a final state and if it should be shown in the progress bar or not. If a workflow has state that is only entered in rare cases it makes sense to not show it in the overview of the workflow. A good practice is to only show these states in the progress bar that are part of the ‘happy flow’, the ideal flow for a case. This way, a user knows what to expect. States in the progress bar appear in the order specified in the configuration, meaning they can be reordered in any way needed.
For every individual state it can be defined which permissions each user role has, so who is allowed to edit information, upload files, delete uploaded PDFs, etc.
Adding Transitions between Workflow States¶
A transition has a key and a name as well. It also has a state it transitions from and a destination state where it transitions to. Also, it can be stated which user role has permission to execute the transition. In a draft case, a configurator can execute every transition regardless of these permissions.
Additionally, a transition can have a condition that defines when it can be executed. This is useful in case a state should only be entered if a specific condition is met, e.g. a special approval is required because the client is a US-citizen. In that case a transition's condition could look like this:
Showing a Transition that cannot be Executed¶
Info
New in Atfinity 18.
A transition the user cannot execute is hidden from the case, whether their role lacks permission or its condition is not met. The user then cannot tell a transition that does not exist from one they are not allowed to use yet.
Set Show button even if disabled and the button stays in the case header in both cases, greyed out. Add Show tooltip with a Tooltip if disabled to explain why, for example which information is still missing. The button then carries an information icon, and hovering it shows the tooltip. The tooltip is translated like the button title, and it is only shown while the button is disabled.
The setting applies only to a transition offered as a button. A transition that runs on its own, for example once all information is provided, is never shown to a user whose role may not execute it.
A greyed-out button counts towards the buttons in the case header, so with more than three, the first ones move into the menu next to them.
Requiring Several Approvals for a Transition¶
Info
New in Atfinity 18.
A button transition can wait for several users to approve it before it moves the case. Set Multiple votes required for transition and the Number of votes required, between 2 and 16.
The button then shows the approvals so far, for example 1/3. Every user allowed to execute the transition can approve once and revoke their own approval. Approvals stay in place when the case changes, but only count while their user may still execute the transition. When the condition of the transition is no longer met, its approvals are cleared and the activity log records it. The last approval runs the transition and clears all approvals, the activity log records each approval and revoke. With Show who voted, the button opens a dialog listing who approved and when.
The API and the MCP server refuse such a transition. A transition action of a rule moves the case without approvals and clears those given so far.