Table of Contents
Attention Workflow Engine
Attention Workflow Engine (AWE) brings Fylr items under managed workflow. A workflow is a state machine over exactly one Fylr table: every item it covers sits in exactly one state, and transitions are the named steps that move it on. Who may apply a step, who the item is assigned to afterwards, when it becomes overdue and what is written along the way are all part of the workflow definition.
Workflows are authored once in the ACC Workflow Engine module and executed everywhere the items are used: in the Fylr web frontend, in an AWP portal and unattended through the Attention Scheduler.
An overview presentation introduces the product and its feature set in short form — the same ground as the rest of this namespace, for showing AWE to somebody who has not seen it before.
Concepts
| Term | Meaning |
|---|---|
| Workflow | A state machine bound to one target table. Enabled or disabled as a whole; a disabled workflow disappears from every user interface and no transition of it can be applied. |
| State | Where an item currently is. An item is in at most one state per workflow. A state can be marked terminal (an end state) and can carry a due period. |
| Transition | A named step from one or more source states to exactly one destination state. An initial transition ignores its source states and starts the workflow on an item that has no state yet. |
| Restriction | An inbound condition that decides whether a transition may be applied at all: a user/group restriction, an item query, an assignment requirement or a required comment. |
| Assignment | The users and groups an item is handed to when it arrives in a state. Assignments are what makes a personal work list (“assigned to me”) possible. |
| Reassignment | Handing an assigned item over to somebody else without moving it to another state. Allowed per state and per user. |
| Due date | An absolute deadline stamped onto the item when it enters a state that has a due period configured. |
| History | An append-only audit trail: every applied transition and every reassignment is recorded with timestamp, user and comment. |
| Action | A pluggable piece of work run when a transition is applied. If an action fails the item is not moved. |
What a workflow adds to the data model
A workflow keeps its data in ordinary Fylr fields on its target table, created automatically when the workflow is saved in ACC:
| Field | Content |
|---|---|
| (a tag group per workflow) | The workflow's states. Only one of its tags can be set at a time, so an item is never in two states of the same workflow. |
| Assignments (workflow) | The users and groups the item is currently assigned to. |
| History (workflow) | The audit trail of everything ever applied to the item. |
| Due Date (workflow) | The deadline of the state the item is in. Stays empty for workflows that do not use due dates. |
The fields are created when a workflow is saved. Data left behind by deleted or re-targeted workflows is removed with the Cleanup action described in Workflows.
Where workflows are used
- ACC — the Workflow Engine module: author workflows, validate them, view them as a diagram and read the workflow statistics.
- Fylr web frontend — a Workflows entry in the object context menu and in the detail sidebar, a My Workflow Assignments tool in the main search, plus history and reassignment dialogs.
- AWP — a work-list filter, a Workflows tab in the information view, and apply/reassign actions on single items and on whole collections.
- Attention Scheduler — three unattended jobs: Workflow Autostart, Workflow Automation and Workflow Due Dates.
Licensing
AWE requires a license which needs to be installed with the License Manager. Without a valid license the ACC module, the scheduler jobs and the workflow menus in the web frontend refuse to work.