Approvals

Approval steps, approval matrices for ERP documents and the Approvals Inbox: who may decide, how stages and quorum work, and delegation.

Approvals Overview

An approval is a request for one named person, or anyone in a group or team, to say yes or no before a process carries on. Approvals come from workflow Approval steps, from approval matrices on ERP documents, and from controlled documents, and they are all decided in the same places under the same rules.

Where to find it

Architect Panel → Automation:

Approvals Inbox — everything waiting for your decision
Approval Matrices — who approves which ERP documents, at what value and in what order
Approval Requests (data) — the raw request records, for looking up and auditing only
Delegations — who is covering for whom, and until when

Admin Panel → Processes:

Approvals Inbox — the same inbox for back-office users

Admin Panel → ERP - Setup:

Approval Matrices — the matrices console for ERP administrators

Where approvals come from

A workflow's Approval step: the run parks until the approver decides, then goes down Approved or Rejected. See Message and People Steps.
An approval matrix: when an ERP document asks for a status that a matrix governs (a requisition asking to be Approved, say), the matrix opens a request for each approver of each stage in turn. See Approval Matrices.
ERP documents with no matrix: a document waiting for a move that a permission allows is listed for the people holding that permission. See Transactional Documents.
Document control: approvals of controlled documents. See Document Control.

Where people decide

The Approvals Inbox, for anyone with back-office access. See The Approvals Inbox.
The "Waiting for my approval" page, for everyone else, opened from the link an Approval step can e-mail.
The record's Processes pane, under Waiting for a decision.
The in-tray (Worklist): each request also puts an item in the approver's in-tray, including requests routed to their group or team.

The rules every decision follows

Only the named approver may decide. Administrative access is not a way round it: an approval someone else could sign for you is not an approval. The exception is a declared delegation on a matrix stage that allows it; see Approvers, Groups and Delegation.
The approver must be able to read the record. A request on a record they cannot open cannot be decided; the inbox says so and suggests asking an administrator for Read access.
Rejecting needs a reason. The person who asked reads it first. Approving takes an optional comment.
A decision cannot be taken back from the inbox. The process carries on straight away.
A rejection with no rejection route drawn in the workflow ends the run.

Withdrawn, not decided

Sometimes a request stops applying. It is then withdrawn: closed with a reason, and nobody's decision is recorded.

The workflow run is cancelled, or the workflow is deleted.
A new version removed the step that asked: trying to decide says the request no longer applies.
An ERP document is cancelled, closed or rejected while its matrix approval is open.

Approval Requests (data)

This tile opens the raw request records for looking up and auditing. Do not decide approvals there: changing a request's state in the grid records nothing about who decided and does not move the workflow on. Use the Approvals Inbox.

Not the same as approving new accounts

The Approve, Revoke, Decline and Change to Approved buttons on external (single sign-on) accounts belong to new-user approval, not to processes. They appear only when the hosting administrator has switched external-user approval on for the installation. See External Accounts.

Worked example

A charity routes grant payments through a workflow Approval step naming group:Trustees, and purchase requisitions through an approval matrix. A trustee opens the Approvals Inbox and sees both kinds side by side: the grant labelled Workflow and the requisition labelled Approval matrix. They approve the grant with a comment and reject the requisition with the reason "No budget code"; the grant workflow carries on to payment and the requisition moves to Rejected.

Recommendations

Decide in the inbox, never by editing Approval Requests (data).
Name approvers precisely, by e-mail address, group or team.
Write rejection reasons the requester can act on.
Draw a rejection route on every Approval step.

The Approvals Inbox

The Approvals Inbox lists everything waiting for your decision in one place: workflow approval steps, approval matrix stages, controlled documents and ERP documents. You approve or reject each one there, and the process it belongs to carries on straight away. People without back-office access use the "Waiting for my approval" page instead.

Where to find it

Admin Panel → Processes:

Approvals Inbox — for every back-office user; the badge counts the requests addressed to you

Architect Panel → Automation:

Approvals Inbox — the same screen for architects

Who sees what

The Admin Panel entry is given to every back-office security group. A group created later needs the Approvals Inbox item added to its admin panel items; see Admin Panel.
Each person sees the requests that name them, their security group, their worklist team, a list they are on, or a person they are covering for under a delegation.
Requests that name nobody form a shared pool. They are shown to people holding the ERP: Approvals role, and to architects.

The screen

Tiles: Waiting for you (with a breakdown by kind), Oldest waiting, and You decided (last 30 days).
Tabs: Waiting for me, and Decided by me (your decisions over the last 90 days).
Filters: Search (title, record, document number or requester), Kind, and Order (Oldest first, Newest first, Largest amount first).
Buttons: Refresh, and for people with a role on a workflow, My processes and Run History.

Each card shows its kind (Workflow, Approval matrix, Document control, or the ERP document type), how long it has waited, the title, the record or document by name, the workflow or the stage it is asked at, the company, who asked and when, and any amount. The buttons are the decisions you can make, plus Lines (an ERP document's lines, without leaving the inbox), Open (the record) and Processes (the record's Processes page).

Deciding one item

Press Approve or Reject on the card (an ERP document may offer other wording, such as Return for amendment).
For an approval, add a Comment (optional). For a rejection, fill in Why are you rejecting it?: it is required, and the person who asked reads it.
Press Confirm, or Not now to back out.

The card goes from the list and a message says where the process went: moved on to its next step, finished, or stopped.

Approving several at once

Tick the items, or tick Select every item you can approve.
Press Approve selected, add a Comment for all of them (optional), and confirm.

Each item is approved on its own, in turn, exactly as from its card; one that is refused stays in the list saying why. Rejections are always one at a time, because each needs its own reason.

Decisions you cannot make yet

When the server would refuse a decision, its button is shown disabled with the reason under the card rather than failing when pressed. A supplier invoice held by three-way matching shows a Match held pill and a link to open the Invoice Match Queue. A request on a record you cannot read shows a padlock and asks you to get Read access.

Waiting for my approval

An Approval step can e-mail the approver a link. It opens the Waiting for my approval page, available to every signed-in person including customers, partners and staff without back-office access. It has the same Waiting for me and Decided by me tabs, a search box, and Approve and Reject on each request, with a reason required to reject.

What goes wrong

A request I expected is not here. The step named someone else (check the run in Workflow Run History), or it is still on an earlier step.
The badge and the list differ. The badge counts requests addressed to you. A document waiting only for a move your permission allows is listed but not counted.
"That request is no longer waiting for you" on the end-user page: it was decided or withdrawn already.
A warning that one kind could not be read. The rest of the inbox is still shown.

Worked example

On Monday the operations director has eleven items waiting. They sort by Largest amount first, open Lines on a 30,000 purchase order to check what is on it, and approve it with a comment. They tick Select every item you can approve, which leaves out a supplier invoice showing Match held, and approve the rest in one step. Finally they reject a travel request with the reason "Book standard class and resubmit".

Recommendations

Work oldest first unless an amount demands otherwise.
Use Lines before approving an ERP document you have not seen.
Grant ERP: Approvals deliberately: it decides who sees requests that name nobody.
Tick the e-mail link on Approval steps aimed at people outside the back office.

Approval Matrices

An approval matrix decides who approves an ERP document, at what value and in what order. It is a ladder of stages: each stage covers a band of values, names who approves it, and says how many of them must agree. The Approval Matrices console builds the ladder and checks it with the same rules the engine applies, so a stage that resolves to nobody or a gap between value bands shows up before a document gets stuck.

Where to find it

Architect Panel → Automation:

Approval Matrices — every matrix, for architects

Admin Panel → ERP - Setup:

Approval Matrices — ERP document matrices, for people holding the ERP: Administration role

What a matrix governs

A matrix is chosen by what a document is and the status it is asking for. Matrices are applied by the ERP document engine when a document's lifecycle asks for approval; they ship for requisitions (Requisition approval), purchase orders (Purchase order release) and held sales orders (Sales order credit release), all disabled. Until a matrix is enabled, the document type keeps its simpler rule: whoever holds the approving permission may approve. The purchasing and sales specifics are in the ERP documentation; see Transactional Documents.

Setting up the matrix

Open the console. Matrices lists each one with its Company, Bands in, Governs, Status sought, number of Stages and whether it is Enabled. Press Open on one, or fill in Add a matrix.
Company: Every company, or one company. A company's own matrix wins over the one for every company.
Value bands are in: a currency, or Each document's own currency. A document in another currency is converted at the spot rate on its date before its band is chosen; with no rate it is refused rather than banded at face value.
Name and Key: the key is what a document type routes to, unique per company.
Governs and Governs what: doctype and the document type's key, such as preq, po, pinv or so.
Value basis: which figure of the document the bands compare against; blank means the gross total.
Status sought: the status the document enters when it is sent for approval (Submitted, for a requisition). Status when approved: the status it may enter only once every stage has approved. Status when rejected: where a rejection sends it.
Tick Enabled when the stages are ready, then Save.

Adding stages

Under Add a stage, give a Name and a Stage number. Stages run in number order.
Set the value band, From and To. A To of 0 means no upper limit. A document whose value is outside a stage's band skips that stage.
Choose Who approves: A named person, Anyone in a security group, Anyone in a worklist team, Whoever is named in a field on the record, The owner of the cost centre being spent, or Back to whoever raised it.
Fill in Which one for the kinds that name somebody: a person's e-mail address, a security group's name or ID (as in the Security Group Manager), a team key, or a field name.
Choose the Quorum: Any one of them, All of them, or A set number of them (with How many). It counts distinct people.
Optionally set SLA (hours), and tick Allow self-approval or Allow delegation.
Press Add stage. Use the arrows to reorder, Edit to change and × to remove.

The checks

Under the matrix form the console says either "Every enabled stage resolves to somebody, and the value bands cover every amount with no gap", or what is wrong:

A stage names nobody, so it blocks every run that reaches it. Saving such a stage is refused, as is a security group that does not exist.
A gap between bands at one stage number: a document in that range skips the stage rather than being refused.
No band covers the top: set the highest band's To to 0.
Two stages share a number, or the matrix has no enabled stage.

Recent approvals lists the last 50 runs (Document, Value, State, Stage, Raised by, Raised, Settled), read-only.

What goes wrong

A shipped matrix blocks every document once enabled. Its group stages name no group yet. Fill in Which one first.
"There is already a '…' matrix for …": one key per company.
A matrix cannot be removed while approvals are in progress through it; finish or cancel them first.
An ERP administrator cannot change a matrix. They need write access to its company, or to every company for an Every company matrix, and may manage document matrices only.

Worked example

A group with UK and US companies wants one requisition ladder in pounds. The finance systems lead opens Requisition approval, sets Value bands are in to GBP and keeps Company as Every company. Stage 1, Budget holder, covers 0 to 0 (everything) with All of them. Stage 2, Second approval over 10,000, covers 10,000.01 to 0, Anyone in a security group, Which one "Finance Directors", Any one of them, SLA 72 hours. The checks turn green, they tick Enabled and save. A US requisition for 14,000 dollars is converted at the day's rate and, at roughly 11,000 pounds, reaches both stages.

Recommendations

Read the checks before enabling a matrix.
End the ladder with a To of 0 so no value escapes it.
Set a currency for any matrix used by companies in different currencies.
Prefer groups and cost-centre owners to named people, who leave.
Enable one matrix at a time and watch its first documents.

How an Approval Matrix Runs

Once a matrix is enabled, every document sent for approval opens an approval run that walks the matrix's stages in order. This page follows one run from start to finish: who is asked, how a stage is settled, what happens if nobody answers, and why an edited document can need approving again.

Where to find it

Architect Panel → Automation:

Approval Matrices — Recent approvals shows each run's state and stage
Approvals Inbox — where each stage's approvers decide

Admin Panel → ERP - Setup:

Approval Matrices — the same console for ERP administrators

From submission to approval

The document is sent for approval. As it enters the matrix's Status sought, the engine finds the matrix: a company's own matrix first, then the one for every company. No enabled matrix means no approval run.
Its value is banded. The value basis is read and, if the matrix has a currency, converted at the spot rate on the document's date. If a stage cannot be resolved or there is no rate, the move is refused and the document stays where it was.
The first stage opens. Its approvers are worked out now and recorded, and one request is raised for each person, in their Approvals Inbox and in-tray.
The stage is settled when its quorum is reached: any one, all, or a set number of distinct people. The others' requests are withdrawn.
The next stage whose band includes the value opens, and so on. Stages whose band excludes the value are skipped.
When the last stage is granted the run is granted and the record's activity notes "Approved: all stages granted." Deciding from the Approvals Inbox then moves the document to Status when approved.

A rejection at any stage settles the whole run at once: the remaining requests are withdrawn and, from the inbox, the document moves to Status when rejected.

Who is asked

Approvers are fixed when the stage opens. Joining a security group after a request was raised does not make you its approver, and an auditor can see who was actually asked.
A stage that resolves to nobody fails closed. It never becomes "anyone may decide"; the document does not move.
The cost-centre owner kind asks the owner of every cost centre the document's lines are charged to; two cost centres with two owners means two approvers.
The person who raised the document is left out of a stage's approvers unless that stage has Allow self-approval ticked. If they were its only approver, the stage cannot open. (The matrix's own "Nobody may approve what they raised themselves" box is stored with the matrix; on this version the stage setting is what the engine applies.)
Delegation: on a stage with Allow delegation, someone covering for an approver under a current delegation may decide; see Approvers, Groups and Delegation.

Deadlines, reminders and escalation

A stage's SLA (hours) records when its requests are due, so a late stage can be seen in the run's record.
Reminders and escalation are driven by the matrix's Reminder After (Hours) and Escalate After (Hours) and the stage's Escalate To Kind and Escalate To. These are fields of the Approval Matrices and Approval Matrix Stages records; the console does not show them. A reminder is noted in the record's activity.
Escalation opens a new stage instance, marked "(escalated)", for the escalation target, so the history reads "asked A, A did not answer, asked B".
Nothing is ever approved by silence. A stage past its time with no escalation target stays open.
All of this runs from the task Approval Matrix, every 15 minutes, which is installed switched off and in preview mode. An architect turns it on from the Tasks screen; see Tasks.

When the document changes

An approval belongs to the document as it was when it was submitted. If the document is edited afterwards, moving it to the approved status checks whether the change matters. With the default rule (Re-approve On Change: material) it needs approving again when its value moved past the matrix's material-change thresholds, or when any line was re-coded to a different cost centre, however small. The old run is superseded and the move says "This has changed since it was approved and needs approving again."

When the document is cancelled

A document that reaches a dead-end status (Cancelled, Closed, Rejected) while its run is open has the run withdrawn and its pending requests closed, never decided. The Approval Matrix task also sweeps up any older runs left open this way.

What goes wrong

"Stage '…' resolved to nobody": check the person, group, team, field or cost-centre owner it names.
"There is no … to … exchange rate": add the rate, then submit again.
Nobody chases late approvals. The Approval Matrix task is off, or no reminder or escalation hours are set.

Worked example

A requisition for 12,500 is submitted. Stage 1 asks the owners of its two cost centres, and both must approve. Stage 2, over 10,000, asks the Finance Directors group. One director is on leave and a colleague covering under a delegation approves. Before the order is raised, the requester changes a line's cost centre: the next move is refused as needing approval again, and a new run starts.

Recommendations

Turn on the Approval Matrix task before relying on SLAs or escalation.
Set an escalation target on stages where silence would hold up the business.
Leave Allow self-approval off except where segregation is not required.
Keep cost-centre owners up to date; a missing owner blocks the stage.

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.

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.
While the delegation is current, the delegate sees the delegator's matrix requests in their Approvals Inbox and may decide them.
The decision records that it was made through a delegation, and for whom, beside the name of the person who pressed the button.
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.