Table of Contents
Transitions
A transition is a named step a user or a job applies to an item. It defines where the item may come from, where it goes, who may apply it, who it is assigned to afterwards and what runs while it is applied.
General
| Configuration | |
|---|---|
| Name | The localised name of the transition. It is the menu entry users click and the text written into the history. |
| Starts the Workflow | Marks the transition as initial: it applies to items that are not in this workflow yet and starts them. Its source states are ignored. A workflow needs at least one initial transition, and may have several with different destinations, which lets the user pick the entry point. |
| Source States | The states an item may be in for this transition to be offered. Ignored for an initial transition. |
| Destination State | Where the item ends up. Exactly one state is required. |
Restrictions
Everything on this tab is an inbound condition: it decides whether the transition is offered and whether applying it is accepted. A user interface hides what does not apply, and the conditions are enforced again when the transition is actually applied.
| Configuration | |
|---|---|
| Only Items Matching | A Fylr query the item must match for the transition to apply. It is usually the answer to “why is this step offered on one item but not on the next”. Evaluating it is more expensive than the other conditions, which is noticeable when menus are built for many items at once. |
| Restrict Assigned Items to Their Assignees | When the item is assigned, only its assignees may apply the transition. On by default. An unassigned item is considered to be in the pool and passes, so a workflow that does not use assignments at all is unaffected. Never evaluated for an initial transition — nobody can be assigned before the workflow starts. This is what makes an “assigned to me” work list a real queue. |
| Require a Comment | The transition can only be applied together with a comment, which is recorded in the history. Off by default. A caller that cannot collect a comment — the autostart job, for instance — is rejected. |
| Restrict to Users or Groups | Limits the transition to the listed users and groups. Ticking the box with an empty list means no user can apply the transition at all, and the validation reports it. |
The Restrict to Users or Groups and Restrict Assigned Items to Their Assignees conditions describe who may act in a user interface, and do not apply to a transition applied by a scheduler job. Only Items Matching and Require a Comment always apply.
Do not use Fylr's system groups (All Users, Public, …) in a restriction or assignment list. Membership in a system group cannot be resolved, so such an entry does not work: the transition is offered but rejected when applied, and an item assigned to a system group can no longer be acted on.
Assignments
The outbound effect: who the item belongs to once it has arrived in the destination state.
| Configuration | |
|---|---|
| Assignment Mode | Keep Current Assignments leaves the assignment untouched. Clear Assignments releases the item back into the pool. Assign to Fixed Users or Groups hands it to the list configured below. Assign to User Applying the Transition hands it to whoever clicked. |
| (owner list) | The users and groups the item is assigned to. Only used by Assign to Fixed Users or Groups; an empty list assigns the item to nobody, and the validation reports the mismatch. |
| Notify Assignees by E-Mail | Sends the assignment e-mail, see E-Mail Notifications. Only available for Keep Current Assignments and Assign to Fixed Users or Groups — clearing an assignment has nobody to notify, and assigning to the acting user would notify somebody about their own click. |
| E-Mail Template | Which template to send. Only shown when more than one AWE assignment template exists; with exactly one it is used automatically. |
| Also Notify the Members of an Assigned Group | Expands an assigned group to its members. Off by default. |
Actions
The work that runs when the transition is applied, in the configured order. If any action fails, the item is not moved and nothing the actions wrote is saved — which is how a “these fields must be filled in first” gate produces a readable message instead of a step that silently disappears from the menu.
| Configuration | |
|---|---|
| Enabled | Disabled rows are kept in the configuration but skipped at runtime. |
| Action | The action to run. It is chosen when the row is added and cannot be changed afterwards — remove the row and add a new one instead. Properties… opens the action's own configuration. |
The buttons beside the table move the selected action within the list; the order in the table is the order the actions run in.
The available actions and how to add more are described in Transition Actions.