Task access and validation

​

Verify task access

When configuring a workflow, assign each task transition to the intended user groups and test with accounts inside and outside those groups. Check both the decision form and the resulting instance history. This page describes the behavior to validate before enabling the process. Tasks can also be requested for the document open in an Office add-in. The person must be able to view that document as well as meet the task’s audience rules. Access to a task lookup does not bypass document permissions.

​

Who sees a task

Two settings on a task transition in the designer decide who sees the task and can complete it: Visible to groups and Visible to the person who started the workflow. Below the switch, the designer states who sees the task with the current settings. The person who started the workflow is the run’s owner, shown as Owner on the instance under Workflow Instances. It is the person who chose a workflow document action, started the run by hand, or chose Run now on a schedule. For a trigger, it is the user whose action raised the event, such as the person who stored the document, so to ask the person who uploaded a document to check it, switch on Visible to the person who started the workflow and leave the groups empty. A run another workflow starts has that run’s owner, and a run a schedule starts has none; see the owner of a run. When a service account stores the document, as the Mailbox Importer and API clients do, that service account is the run’s owner, and no person signs in as it. An owner-only task on such a run reaches no one, so select a group as well when documents stored this way can start the workflow. A run without an owner shows an owner-only task to no one. A run a schedule starts never has one, so on a system workflow with a schedule the switch stays unavailable until you select a group, and the designer warns when it is already on without one. On a system workflow without a schedule, the designer notes that a run another workflow starts gets the owner of the run that started it, so a chain that began with a schedule has none. Publishing also warns about an owner-only task in a system workflow.

​

The Tasks page

When a workflow parks at a node with task transitions, those tasks appear in the Tasks page in the main navigation — the inbox for everything the signed-in user is allowed to act on. Each task is listed only for the people allowed to see it. The page follows the familiar three-panel search layout: Everywhere in the Tasks page, workflows and steps appear by their display names — internal identifiers never surface to end users.

​

Completing a task

A task is a button configured by the workflow author — with a label, a color (primary, neutral, or critical), and optionally an icon.

• One-click tasks open a short confirmation dialog.
• Form tasks open a dialog with the fields the author defined — text, number, checkbox, or date — with required fields marked. Validation errors appear inline under the matching field.

Completing the task fires the workflow’s transition: any transition actions run and the instance moves to the next step. The task then disappears from everyone’s list. If two people act on the same task at the same time, the first completion wins; the second user is told the task was already completed and the list refreshes.

​

Tasks on the document or Caseflow object

A task can also be offered where the work is. Switch on Also show on the document or object on the task transition, and the task is offered on the page of the document or Caseflow object the workflow runs on, as well as on the Tasks page.

• On a document, a Tasks button with the number of tasks appears next to the Notes button when the document has tasks for you. It opens a panel with one group per workflow, showing the step it is on and its task buttons. The button is on the document’s own page, not in a preview pane, such as the one on the Search, Folders, or Tasks page.
• On a Caseflow object, the template decides where the tasks go. The WorkflowTasks element shows a button with the count that opens the same panel, or the list in place. A template without the element shows no tasks. After a task completes, the object’s values are reloaded; if you have unsaved changes, they are kept and you are asked to save and reload.

Completing a task there works as on the Tasks page, with the same dialog, inputs, and validation. Who sees the task does not change: the same groups and owner rule apply, and the person must also be able to open the document or the object. The setting applies to runs started after you publish the version that has it. Runs already going keep the version they started on, so their tasks stay on the Tasks page only. A system workflow has no document or object, so its tasks are only ever offered on the Tasks page.

​

Workflow badges in search results

Documents and Caseflow objects that are currently in a running workflow carry a small badge on their icon in search results (with a count when the item is in several workflows). Hovering shows, for each workflow, the workflow name and the step the item is currently on — so a caseworker can tell at a glance whether a document is already being handled, and where it is in the process.

​

Where to read next