By job
Who has to say yes, and did they?
An approval is a gate: someone can't proceed until a decision is made. stepbase decides who that someone is from the request itself, holds the work at the gate until they act, and keeps the decision on record afterwards.
Approval by email is a decision with no home
The rule is usually clear enough: under a thousand, your manager; over twenty-five, an exec. What's unclear is whether it was followed. The thread forked, two people replied "fine by me", one of them wasn't the right approver, and the request went ahead anyway. Then finance queries it at month end and the only proof anyone can produce is a forwarded thread containing two different answers.
Today
- The threshold rule lives in a policy doc, and people apply it from memory
- Approval is a reply-all that forks into two threads with different answers
- A request stalls for a week because the approver is on leave and nobody knew
- "Can you add the budget code?" becomes a thread, not a step
- Small purchases get an exec signature, large ones skip one
- "Who approved this and when?" means searching mail archives
On stepbase
- The threshold is a condition on the submitted amount, applied every time
- One approval at a time, in order, with the request held until it's decided
- Approvals land in a team or role queue, so a single person being away doesn't stall it
- Send-back is an action with a path, not a request buried in a reply
- Each level of sign-off is triggered by the request itself, never by who noticed
- "Who approved this and when?" is a timestamped line on the instance
How it works
Capture what the approver needs to decide
Build the request form around the decision: amount, budget code, justification, evidence. The approver opens one screen with everything on it instead of asking for the missing half.
Set the threshold as a rule
A condition block reads the submitted data and picks the path. The bands are yours: an amount, a number of days, a risk score. Paths are checked in the order you set them and the first match wins, so "over $10,000" and "over $10,000 and off-contract" can be two different routes.
Chain the sign-offs
Put each approver on their own stage so they act in sequence, or assign one stage to several people and require all of them, any two, or a percentage before it moves on.
Give rejection and send-back real paths
Approve, Reject and Request Changes each point somewhere. A send-back returns the request to the person who raised it, who revises and resubmits down the same chain.
Keep the decision
Every approval, rejection and comment is recorded with the person, the timestamp, the stage and where it went next. Nothing to switch on, nothing to remember to log.
Start from a template
Every template is fully editable: change the stages, forms, and routing to match how you work.
Employee Requests
Leave, letters and equipment, asked for in one place, each with the approval it needs behind it, and a balance that says what is left.
View templatePurchasing
Purchase requisitions routed by spend threshold through department, finance and executive approval, then tracked as purchase orders against a register of approved vendors.
View templatePolicy Exception
Escalations for exceptions with documentation and approvals.
View templateFAQ