Loading

Approvers, Groups and Delegation

Who may decide an approval depends on how the approver is written. A request can name one person, a security group, a worklist team or a short list of these, and on approval matrix stages a colleague covering under a delegation may decide too. Getting the approver right is what makes a request reach the right inbox.

Where to find it

Architect Panel → Automation:

  • Workflow Builder — the Approver box on an Approval step
  • Teams — worklist teams, whose members can be approvers
  • Delegations — who is covering for whom, and until when
  • Approval Matrices — Who approves and Allow delegation on each stage

Writing the approver on an Approval step

  • An e-mail address: that person.
  • group:id or name, such as group:Finance or group:12: anyone in that security group.
  • team:key: anyone in that worklist team.
  • A list: several of the above separated by commas, such as group:Finance, ops.manager@example.org. Any one of them may decide.
  • A placeholder such as {{manager_email}}, holding any of the above.

Anything else is read as one person's identity: a user ID, e-mail, username or display name. A comma does not make a list unless every entry is an e-mail address, group: or team:, so "Smith, John" is one person called Smith, John, never two people. As you type, a hint under the box says how the entry will be read, such as "Any one of these 3 may decide" or "Read as ONE person's name ('Smith, John'), not a list".

Groups and teams are a shared queue

For a workflow Approval step, membership is checked when the decision is made, as in a shared in-tray: whoever is in the Finance group today may decide Finance's requests. The record notes which group or team the decision came through as well as the person who pressed the button.

An approval matrix works the other way: a stage's approvers are fixed when the stage opens and one request is raised per person, so later changes to a group do not change who was asked. See How an Approval Matrix Runs.

Requests that name nobody

If the approver comes out empty (a {{field}} that is blank, say), the request names nobody. Anyone who can read the record may then decide it from the record's Processes pane, where it shows as for "anyone who can see this record". In the Approvals Inbox such requests form a shared pool, shown only to people holding the ERP: Approvals role and to architects. Approval matrices never do this: a matrix stage that resolves to nobody stops instead.

Delegation

A delegation is a dated, recorded hand-over: one person covers another's work for a period. Set one up under Delegations with the Delegator (the person away), the Delegate (the person covering), the Scope, a Reason, and From and To dates. See Teams, Allocation & Delegation for how delegations work across the worklist.

  1. Delegation applies to approvals only on an approval matrix stage with Allow delegation ticked. A plain workflow Approval step is never decided by delegation; use a group or a list there instead.
  2. While the delegation is current, the delegate sees the delegator's matrix requests in their Approvals Inbox and may decide them.
  3. The decision records that it was made through a delegation, and for whom, beside the name of the person who pressed the button.
  4. Quorum counts distinct people: someone deciding for themselves and for a delegator on the same stage is one approval, not two.

Give every delegation a To date. A delegation without one is the one people forget.

What goes wrong

  • Nobody can decide a request. The approver was a display name that matches no user, or a group name that does not exist in this tenant. Use an e-mail address or group:ID.
  • "This step is for … to approve." Someone else tried to decide. Administrative access does not override the named approver.
  • A covering colleague cannot see a request. It is a workflow step rather than a matrix stage, the stage does not allow delegation, or the delegation's dates have passed.

Worked example

A council's grants workflow first named its approver as "Patel, Asha", which the hint showed would be read as one person's name. The architect changed it to group:Grants Panel, asha.patel@example.gov.uk, so either the panel or Asha may decide. When Asha goes on leave, a delegation to a colleague covers Asha's approval matrix requests on purchase orders, and the panel continues to handle the grants.

Recommendations

  • Prefer groups and teams to named people.
  • Use e-mail addresses when you must name individuals.
  • Read the hint under the Approver box before saving.
  • Allow delegation on matrix stages where cover is normal, and date every delegation.