The problem it solves
A yes is asked for in a message and then forgotten: nobody knows whose desk the request is on or who agreed to it in the first place, and months later nobody can say why it was refused. What is needed is a request with known steps, each answered by the person it belongs to, and a decision and a reason that stay readable.
Who it is for
- Managers and decision-makers
- Purchasing and operations teams
- All teams
Available today
Nobody approves their own request
Whoever raised it does not decide it, not even the owner. The rule is checked before anything else, so neither rank nor permission gets round it, and a type that names the person raising it as its approver is refused at sending rather than left pending for ever.
A step names a role, or it names one person
A step naming a role is answered by anybody at least that senior, which is how “a manager approves it” is written. A step naming a person is answered by that person and nobody else — not their manager, and not the owner — because seniority is not the same as being asked.
What was sent is frozen
Sending copies the type’s steps onto the request itself and stamps them with a round. Editing the type afterwards changes the next request and nothing about one already out, and a refused request is put right and sent as a new round while the first round’s answers stay on the record.
No is not said without a reason
A refusal needs a written reason, which reaches the person who raised it so they can put it right and send it again; pulling a request back is the author’s alone, and only while it is still being asked.
An amount recorded, not an amount spent
A request may carry an amount in whole minor units beside its own currency, because somebody has to approve a number. Saying yes to a purchase is not the purchase: nothing in this app writes an entry in the ledger.
Attachments that are checked, and moves that are written down
An attachment’s type is read from its bytes rather than its name, and nothing may be added once the request has left the author’s hands. Every move is written onto the request’s own record in both languages and into the audit log.
Frequently asked questions
Can the owner approve their own request?
No. Whoever raised it does not decide it, whatever their rank, and the rule is checked before anything else, so no permission and no seniority gets round it. If a type names the person raising it as its approver, sending is refused rather than leaving the request pending for ever.
Who answers a step?
A step naming a role is answered by anybody at least that senior, which is how “a manager approves it” is written. A step naming a person is answered by that person and nobody else — not their manager, and not the owner. Holding the approvals permission lets you take part; it does not let you answer a step that names somebody else.
What happens if I edit a request type after sending?
Nothing happens to a request already out: its steps were copied onto it the moment it was sent and stamped with a round. The change affects the next request only, and a refused request is put right and sent as a new round while the first round’s answers stay on the record.
Does approving an amount post it to the accounts?
No. A request carries an amount in whole minor units beside its currency so the approver can read it, and saying yes to a purchase is not the purchase: nothing in this app writes an entry in the ledger. Six steps is the limit on one request; more than that is a process, not an approval.