Loading

Who Can Use a Workflow

Architects can do everything with every workflow. Anyone else can be given a role on one workflow at a time, so a process owner (the financial controller who owns the month-end close, say) can see its runs, test it, change it or publish it without becoming an architect. Owners can also be alerted when a run fails.

Where to find it

Architect Panel → Automation:

  • Workflow Builder — open a workflow, then More → Who can use it…
  • Workflow Run History — shows people with a role the runs of their workflows, read-only

Admin Panel → Processes:

  • Approvals Inbox — its My processes and Run History buttons take people with a role to their workflows

The four roles

  • Viewer: sees the workflow (a read-only canvas), its versions and its runs.
  • Run only: also simulates it and test-runs its live version on a record.
  • Editor: also changes and saves the draft, and tests the draft. Cannot publish.
  • Owner: also publishes, activates or disables it, runs its schedule now, decides who has which role, and is alerted when a run fails.

Some things stay with architects whatever the role: creating, importing, duplicating, deleting and restoring workflows, and cancelling, retrying or skipping runs in Workflow Run History.

Giving someone a role

  1. Open the workflow and choose More → Who can use it…. The dialog lists the roles already given.
  2. Under Add someone, choose Who: A group or A person.
  3. Pick the Group, or type a name or e-mail in Person and pick from the list.
  4. Choose the Role and press Add.
  5. Tick Alert the owners when a run fails if owners should hear about failures.
  6. Press Save roles.

Only an architect or an owner of the workflow can change roles; everyone else sees the list read-only. In the library, an architect sees a badge with the number of roles given on each workflow.

What an editor may not add

A workflow runs with the engine's rights, not its editor's. So an editor cannot add or change a PHP function, Extension step or Webhook; an architect does that. A Sub-workflow step an editor draws may start only a workflow the editor could run themselves (Run only or above), chosen from the list rather than given by a placeholder.

Failure alerts

With alerts on, when a run fails every owner (a person, or each member of an owner group) gets an item in their in-tray naming the workflow, the record and why, with links to the run in Workflow Run History and to the record's Processes page. There is at most one alert per workflow per hour. Test runs, sub-workflow runs (the parent alerts instead) and before-save checks that refuse a save do not alert.

How people with a role find their workflows

  • The Workflow Builder lists only the workflows they have a role on, each with "Your role".
  • Workflow Run History shows only those workflows' runs, read-only.
  • The Approvals Inbox shows My processes and Run History buttons to anyone with a role, so back-office users without the Architect Panel can reach both.
  • A failure alert links straight to the run.

What goes wrong

  • "The Workflow Builder is for architects and for people given a role on a workflow." The person has no role on any workflow. Give them one.
  • Test… is missing. They are a Viewer; Run only or above can test.
  • "A Sub-workflow step can only start a workflow you may run yourself": give the editor Run only on the called workflow too, or ask an architect.
  • No alert arrived. Alerts are off, the failure was a test run, or an alert was already sent in the last hour.

Worked example

An architect builds a month-end close workflow from the template. They open Who can use it…, add the Finance group as Viewer and the financial controller as Owner, and tick Alert the owners when a run fails. The controller opens the Approvals Inbox, presses My processes, sees the workflow with "Your role: Owner", simulates it against last month's period and publishes a small change to the wording of the final notice. When a run fails at month end, the alert in their in-tray takes them straight to the failed step.

Recommendations

  • Give every important workflow an owner outside the architect team.
  • Grant roles to groups rather than individuals where you can.
  • Turn on failure alerts for anything customers or finance depend on.
  • Use Editor for people who refine wording; keep Owner for whoever answers for the process.