Approvals that cannot approve themselves
Lessons from building proposal approvals for an architectural consultancy ERP: separation of duties, server-side checks and approver coverage.
Status: Implemented and demonstrated end to end in the client system.
In a consultancy, a fee proposal is a commitment the business will be held to. The ERP we are building for an architectural practice therefore separates who prepares a proposal, who contributes to it and who approves it.
The rules
- The person who prepares a proposal can never approve it.
- Architects can contribute technical scope but cannot price, submit or approve.
- Every API endpoint checks a specific permission on the server; hiding a button is never the only protection.
- Data is additionally scoped by row: staff see the projects they belong to, clients see only their own.
The lesson: rules need coverage
A workflow audit of an earlier build found that a correct rule can still block real work. If only one role may approve and that same person prepared the proposal, the self-approval rule leaves nobody able to approve it. Approvals that are not tied to a project can also disappear from an inbox that is filtered by project. Both were found by testing real scenarios rather than individual rules.
What we do now
Approval rules are designed together with approver coverage — at least one eligible approver must exist for every case — and approval inboxes are tested with the same scenarios users will meet.