Contrayo
Every contract tool we looked at claims to be “customizable.” Most of what that turns out to mean is: you can reorder a handful of steps in a workflow builder, once, and then every contract that comes through your organization runs that same sequence regardless of what it actually is. A $500 NDA and a $2 million master services agreement get the same three approvers in the same order, because the workflow was configured once, by someone in Legal Ops, months before either contract existed.
That works fine at ten employees. It breaks quietly at two hundred — not with an error message, but with people routing around it. A five-minute NDA that has to go through the same chain as a six-figure vendor contract teaches everyone that the “official” process is something to avoid when possible, which is the opposite of what an approval workflow is supposed to accomplish.
The alternative isn’t a more flexible workflow builder. It’s not treating “the approval workflow” as a single thing an organization has, at all.
The unit is a policy, not a workflow
In Contrayo, what an organization configures is a policy — a versioned set of routing criteria, approval steps, and named people, authored together and applied automatically to every contract that matches. A policy isn’t one sequence of steps; it’s a set of templates, each one scoped to a different situation, evaluated in a defined priority order the first time a contract needs to be routed. The engine walks the templates in that order and uses the first one whose criteria match — contract type, value threshold, jurisdiction, which legal entity is signing, which business unit raised it, whether the counterparty already has an approved parent contract on file. A template narrowed by value doesn’t compete on some abstract “specificity” score against one narrowed by jurisdiction; your organization decides which one should be checked first, explicitly, and that decision is exactly as visible and exactly as changeable as the ordering.
Concretely: a $2,000 NDA and a $2 million MSA can — and in most organizations that grow past a certain size, should — hit different templates, with different approvers, automatically, based on the value on the contract, not on someone remembering to route it differently by hand.
The criteria are also ancestry-aware where it matters. A rule scoped to “the Finance business unit” matches Finance and anything under it, not just contracts tagged with that exact unit — because a real org chart has sub-teams, and a criteria system that only did exact matching would silently under-route the moment a company added a second layer to its structure.
Steps aren’t all the same kind of gate
Within a template, a step is one of three kinds: an approval (someone can accept or reject it), a signoff (required, but there’s no reject path — it’s a checkbox, not a gate someone can veto), or a signature (legal execution). That distinction matters because not every step in a real approval chain is actually a decision point. Some are acknowledgments. Treating all three the same, the way a lot of workflow tools do, either forces a reject option onto something that was never meant to be vetoable, or strips the ability to actually block a contract from the one step where that matters most.
Steps also run in a defined order, but not necessarily one at a time. Two approvals that don’t depend on each other can run in parallel; a signature step that has to wait until both of those clear runs after. A step isn’t just sitting there marked “pending” from the moment a contract is routed — it becomes actually actionable only once everything ahead of it in sequence has cleared, and nobody sees it as “waiting on me” before that point. That’s the mechanical difference between a workflow that looks parallel-and-sequential on a diagram and one that actually behaves that way when real people are trying to figure out whether it’s their turn.
Segregation of duties, enforced, not just documented
By default, the same person who approves a contract’s approval step can’t also be the one who signs it. This is on by default because it’s the sensible default for most organizations, and it’s a real setting an org can turn off — a two-person company where the same person genuinely has to wear both hats is a real, named exception, not an edge case the system pretends doesn’t exist.
Where this is honestly still limited
We’d rather say this directly than let the feature list imply more than it does: the people authorized to act on a step today are specific, named individuals — not a role or a title. There’s no “whoever currently holds VP of Finance” assignment yet; if that person changes, someone has to update the step by hand. What Contrayo does solve is the temporary version of that same problem — someone is out for two weeks, and a time-bound delegation grant makes their approvals available to a named stand-in for exactly that window, without touching the underlying policy at all, and without anyone losing the ability to reconstruct, later, exactly who was authorized to act on a given day. That’s a real, working piece of the puzzle. The permanent version — following a role indefinitely, regardless of who holds it — is a real gap we’re not pretending is solved.
That’s the actual shape of “configurable” here: not a workflow you draw once, but criteria your organization sets, evaluated automatically, contract by contract, against people your organization actually names — with the honest limitations named alongside the parts that work. If that’s a problem you’ve hit before, start a free trial and try it against what your own approval chain actually looks like.