Configuration
Every setting in Approval Matrix Pro, and what each one changes.
Everything lives under Approvals → Matrices. A matrix is one rule: what it applies to, and who has to say yes.
The matrix
| Setting | What it changes |
|---|---|
| Name | What appears on the request. Write it for the approver, not for you: Orders over 50k beats Matrix 3. |
| Model | Sales Order or Customer Invoice. These are the two models the module governs; see Compatibility for why. |
| Priority | Which matrix wins when more than one matches. Lower number first. |
| Active | Unticking it stops new requests. Requests already in flight are unaffected. |
| Allow self-approval | Off by default. See below. |
| Lock during approval | Whether the record freezes while a decision is pending. |
| Allow override | Whether an Approval Administrator may force the outcome. |
Priority is explicit on purpose. If precedence depended on which matrix was created first, adding a stricter rule later would quietly not apply, and you would not find out until something expensive went through unapproved.
Conditions
A condition is a field, an operator and a value. Three parts, chosen from dropdowns. There is no expression box, and that is a security decision rather than a simplification: letting an administrator type Python would be a remote-code-execution hole wearing a business-rules costume.
Operators: is at least, is more than, is at most, is less than, equals, does not equal, is one of, is not one of.
Dotted paths work, so you can reach through relations:
amount_total is at least 50000
partner_id.country_id.code is one of EG,SA,AE
user_id does not equal <a named salesperson>Conditions are ANDed. Every one must match. For either A or B, make two matrices and give them different priorities.
A matrix with no conditions matches every record of its model. That is occasionally what you want and usually not, so it is worth a second look.
Levels
Levels are approved in order, one at a time. Each level has:
| Setting | What it changes |
|---|---|
| Name | Shown to the approver — Department head, Finance. |
| Sequence | The order levels are climbed in. |
| Approvers | Named users, a group, or both. |
| Rule | Any one approver is enough, or every approver must sign. |
| Deadline (days) | 0 means none. |
| Escalate to | Who hears about it when the deadline passes. |
Name a group rather than a person wherever you can. There is no delegation feature, so an individually-named approver on holiday is a stuck request, while a group covers itself.
Deadlines escalate; they never approve
When a deadline passes, the named person is notified and the request is flagged overdue. It is not approved. Approving something because nobody looked at it is the opposite of an approval, and a deadline that auto-approves is a deadline that teaches people to ignore approvals.
The escalation contact does not gain approval rights by being notified. If you want them able to decide, add them to the level.
Self-approval
Off by default: the person who raised the request cannot be the one who grants it. Turning it on is legitimate for a small team where the alternative is nobody being able to work, but it does remove the control the matrix exists to provide, so it is a per-matrix switch and not a global one.
Locking
With Lock during approval on, a pending record cannot be edited. Chatter, activities and followers stay writable — locking those makes the workflow unusable without making it any safer.
An approval on a 500 order is worthless if the requester can multiply it afterwards, which is what this setting is for. To edit a locked record, withdraw the request, change it, and raise it again — which is visible in the history, as it should be.
Override
Approval Administrator only, and only where the matrix allows it. An override is recorded as its own entry with its reason and approves the whole request rather than advancing it one level.
Designing the rules and forcing a decision past them are different powers. One person holding both quietly removes the control, which is why the administrator group is separate from the manager group rather than a superset of it.