Table of Contents
Attention Web Platform
An AWP portal can show and drive the workflows of the items it publishes. Nothing needs to be installed for it — the surfaces are enabled per instance in the AWP configuration in ACC and work as soon as a workflow targets the table the instance works on.
Work List Filter
Adding a filter of type Workflow in Filtering gives the portal user a personal work list: the items of a workflow that are assigned to them or to one of their groups.
| Configuration | |
|---|---|
| Limit to Workflows | The workflows the filter offers. Leave empty to offer every enabled workflow on the collection's table. A selection that names a workflow which was deleted, disabled or re-targeted in the meantime is simply ignored. |
| Show a filter node per workflow state | In addition to the node for the whole workflow, adds one node per state of the workflow, so a user can drill into a single queue. Nodes that match no item are hidden, so a user only ever sees the states they actually have work in. |
The filter is single-select and combines with the other filters like any query filter, which also means the item counts on its nodes are counts within the current search — after picking one queue, the sibling nodes count within that narrowed set.
Information View
The Workflows tab of the Information View is enabled per instance in the tab list. For every workflow that applies to the item it shows:
- The current state, or Not started.
- The deadline, when the state has one.
- The transitions the portal user may apply, each opening a confirmation dialog with a comment field — required or optional depending on the transition.
- Reassign…, when the state allows it and the user may reassign. An empty selection releases the item into the pool.
- Workflow history, a read-only dialog with timestamp, transition, user and comment.
The tab is enabled per instance, not per table: on a table without any workflow it renders empty rather than hiding itself.
Item Actions
The same transitions are offered in the actions menu of a single item, and — as a bulk action — in the actions menu of the collection basket and of the current item selection. As in the Fylr web frontend, a bulk transition is only offered when it applies to every item in the collection, and applying runs per item so one rejection does not abort the rest; the failures are reported afterwards.
Workflow actions are hidden in guest sessions and in PIN-bound collection sessions, which are download-only surfaces.
Notes
- The history dialog needs the workflow's History field on the mask the information view uses. A view set whose mask omits it leaves the dialog empty.
- The menus work out what applies for every item they cover. Transitions with an Only Items Matching restriction make that noticeably slower on a large collection basket — avoid them on workflows exposed in a portal when that matters.