ContrayoAn approval matrix your org defines, not one we impose
Every contract that comes through Contrayo is checked against your org's own routing rules — contract type, value, jurisdiction, which legal entity and business unit it sits under — and the engine decides who has to approve it and how it gets signed. Change the rules and the next contract routes differently. The ones already in flight keep running under the rules that were live when they started.
Versioned by design
A policy isn't a single mutable workflow — it's a versioned snapshot: every template, every routing rule, every step, every named actor, authored together as one policy version. Editing a policy means cloning the current version forward into a new one and publishing it. The old version doesn't disappear or get overwritten; a contract already routed under it keeps running under those exact rules. That's what lets you answer "why was this contract routed that way in March" months after the policy has since changed.
How a contract finds its template
A policy version holds multiple workflow templates, each ranked by priority. Templates are checked in that order, and the first one that matches wins — evaluated against the real, current shape of the contract, not a guess.
Contract type & value
Match on contract type and on a value threshold with its currency. There's no cross-currency conversion yet — a threshold set in USD only evaluates against contracts valued in USD.
Jurisdiction
A straightforward criterion any template can require.
Business unit & legal entity, ancestry-aware
Both are independently-varying, arbitrary-depth hierarchies your org models for itself. A rule written against a parent business unit or entity matches everything under it too, not just an exact node — so one rule covers a whole division without listing every sub-unit by hand.
Approved parent contract
A contract can inherit routing treatment from an already-approved parent — an SOW under a governing MSA, for example — instead of being routed as if it stood alone.
Within a template, multiple criteria rows are OR'd together, and every field set on a single row must match — a field left blank on that row is a wildcard. No matching template is a real, visible outcome the engine reports, not a contract that silently falls through.
Sequenced steps, run in parallel or in order
Steps run in ascending sequence order. Steps that share a sequence number run in parallel — two parallel approvals, then a sequential sign-off, then parallel signatures, expressed with a sequence number per step and nothing more elaborate.
Approval
An actor can accept or reject.
Sign-off
Required completion, with no reject path.
Signature
Legal execution — an actor signs or rejects.
A step clears once its actor requirement is met: "any" clears on the first affirmative decision from an eligible actor, "all" needs every eligible actor to act. A single reject ends the step outright.
Controls that run automatically, not by review
Sequential gating, checked twice
A step isn't actionable just because it exists — every step ahead of it in sequence has to clear first. That's enforced both if someone tries to act on a step early, and in the "what's waiting on me" list, which only ever shows steps that are reachable right now.
Segregation of duties
On by default: the same person who approved a contract's approval step can't also be the one who signs its signature step, within that routing. Checked automatically, not left to a manual review.
Delegation-aware eligibility
Grant a delegation for a date range and anyone standing in becomes eligible to act on the absent person's steps for that window, with no change to the underlying policy. Grants are corrected by superseding, never edited in place, so who was authorized to act on a given day stays reconstructable later.
Resubmission after rejection
A rejected contract can resubmit back into the same routing — only the affected steps reset — or, if your org configures it that way, get freshly re-routed from scratch against the current policy, which can land on a different template if the rules have changed since.
Know before you commit
The same engine can run a dry-run evaluation against a hypothetical contract's shape — no document, no workflow started — and tell you who would have to approve it and how it would be signed, before the contract even exists.
A real builder, not a support ticket
Org admins author and edit policies through an actual in-app builder — stages and steps as a structured list, not a support request to a vendor to change how approvals work.
What the engine connects to
Contract records
What a contract carries — type, status, entity and business unit, value, dates — is what the engine matches against.
E-signature routing
The same policy that routes approvals also decides how the contract gets signed.
Notifications
The moment a step becomes actionable, whoever's eligible — including a delegate — finds out.
The engine is included, every tier
The delegation-of-authority engine ships on every plan. See the per-seat price for each one.