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.
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.
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 tab is enabled per instance, not per table: on a table without any workflow it renders empty rather than hiding itself.
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.