Manage customers day to day

Approval rules

Route a purchase to the right approver — what you can configure today, and what is still coming.

The purchasing manager at a customer tells you that her technicians may order consumables up to €500 on their own, and anything above that needs her signature. That is an approval rule: this person may spend up to this much, and above it somebody else has to sign. In the Revenue Cloud it is expressed with two fields on a contact.

Before you start: read How procurement governance works. The rules you are configuring are the customer's internal policy, so ask them what it is rather than inventing one.

Read this before you promise anything. The model carries who may approve and up to what amount, and the Orders app can create an order that has not been placed. There is no approval queue in the Cockpit yet that an approver works through, and no automatic routing or notification. Configure the policy now, because the fields are real and the permissions are enforced at the point of ordering. Do not sell a customer a running approval workflow today.

The two fields

Field	On	What it says
`role`	The contact	Whether this person places orders, requests them, or signs them off
`order_approval_limit`	The contact	How far their signature reaches, in the market's currency

The role is the grant. The limit is an amount: on somebody whose role cannot approve, it has nothing to act on. Empty means no ceiling.

Behind the roles are three permission keys, and the distinction between the first two is the whole mechanism:

orders.create — place the order directly.
orders.request — submit the order for approval instead of placing it.
orders.approve — approve a submitted order, up to order_approval_limit.

Design the policy

Write it down as a table before you touch a screen. A workable shape for a mid-sized customer:

Person	Role	Limit
Apprentice, technician	`viewer`	—
Anyone who needs a signature	`requester`	—
Workshop manager	`buyer`	—
Site manager	`approver`	5000
Managing director	`approver`	empty (no ceiling)
Their shop administrator	`admin`	as appropriate

Two things people get wrong at this point:

A buyer has no limit to set. They place orders directly; the ceiling concept belongs to approval. If you want a buyer capped, they are a requester.
Somebody has to have no ceiling. A policy where every approver has a limit and the largest order exceeds all of them is a policy with no exit. Leave the top approver's limit empty.

Configure it

For each person at the customer:

Go to CRM › Contacts and open the contact.
Select Edit.
Set the Role from the table you wrote.
Set the Order approval limit where the role approves.
Save.

Then confirm the roles grant what your policy assumes:

Go to CRM › Roles. If the list is empty, select Load the built-in roles. Until a tenant has its own rows there is nothing to edit, and loading them changes nobody's access.
Open each role and check its permission list. Use the Permissions row action to change it; it replaces the whole set, so anything left unticked is revoked.

Limits of the model today

Be precise with customers about these:

No routing. Nothing decides which approver a request goes to. With one approver per site that is not a problem; with a matrix it is.
No queue, no reminder. There is no screen an approver opens to see what is waiting, and nothing chases an unapproved request.
No multi-step chains. "Over €10,000 needs two signatures" is not expressible.
No per-market roles. "Buyer in DE, viewer in AT" is one role today.
Only ordering enforces permissions. The Orders app gates placing an order on orders.create versus orders.request. Other apps declare nothing yet, so their grants are advisory. Do not use a role as a security boundary for anything except ordering.

The alternative worth offering

For a customer with a real, complex approval matrix, the honest answer is often not to reproduce it. If they run SAP Ariba, Coupa or Onventis, their workflow already exists there, and connecting to it means you never have to rebuild it. See Punchout explained and Set up punchout.

What to check

Open a contact and look at the Role & permissions section. It shows the grants that person holds right now, whether they may act on them, and their approval ceiling.
A contact who is blocked or whose registration is pending keeps their role and cannot act on it. That is correct.
Have the customer's requester try to order. They should not be able to place one directly.

Cost centres and budgets — the other half of procurement governance.
The order lifecycle — where an order goes once it is placed.

Edit this page

Block a customer

Three different blocks, three different consequences — pick the right one.

Cost centres and budgets

Carry the customer's accounting bucket through to the order line — and what a budget would need beyond that.