Conditional routing: workflows that adapt to the answers

Most real approval processes have branches. A purchase under ten thousand needs one signature; over that it needs two. A contractor in one region needs an extra tax form. Until now, modelling that in SignTheDoc meant maintaining a separate template per branch and training people to pick the right one.

Conditional routing lets a single template contain the branches. The document decides where to go based on what has actually been filled in.

How a condition is built

A condition is a rule attached to a recipient or a field group. It reads a value from an earlier field and decides whether the step applies.

• Numeric comparisons — amount is greater than, less than, or between values
• Text matching — equals, contains, or is one of a set
• Checkbox state — checked or unchecked
• Dropdown selection — matches one or more options
• Emptiness — a field was left blank

Conditions combine with AND and OR. We deliberately stopped short of arbitrary nesting. If a workflow needs more logic than this expresses, it usually needs to be two workflows, and forcing that conversation produces better processes than letting people build something unreadable.

Conditional recipients

The most common use. Add a second approver whose step only activates when the contract value exceeds a threshold. On a small deal that recipient never receives anything and never appears in the audit trail. On a large one they are inserted into the sequence automatically.

Conditional fields and pages

Fields can show or hide based on earlier answers within the same signing session. Select "Yes" on a disclosure question and the follow-up detail box appears; select "No" and it stays hidden and is not required.

Whole page sections can be conditional too. A contractor agreement can include a region-specific tax appendix that only renders for signers who selected that region, so nobody wades through six pages that do not apply to them.

Testing before you send

Every template with conditions gets a simulation mode. Enter hypothetical values and see exactly which recipients activate, in what order, and which fields render. It runs the real evaluation engine, not an approximation.

We made this mandatory before a conditional template can be published. It adds thirty seconds and catches the inverted comparison operator that would otherwise route every large contract past the person who was supposed to approve it.

Keeping conditions understandable

The risk with any rules engine is that it becomes write-only — a configuration nobody but its author can read. Three things push against that.

• Conditions render as plain sentences: "Show this recipient when Contract value is greater than 10,000"
• Every condition requires a description explaining the business reason, not just the mechanics
• The template overview lists every condition in one place rather than hiding them per-field

The description requirement generates mild irritation during setup and repays it entirely the first time someone inherits a template and needs to know why a threshold is 10,000 rather than 25,000.

Common patterns

Four that cover most of what teams build. Value-based approval, where a second approver activates above a threshold. Jurisdiction-based appendices, where a region selection controls which pages render. Exception documentation, where selecting a non-standard term reveals a justification field. And role-based sections, where a contractor sees different terms from an employee on the same base document.

All four replace what used to be multiple near-identical templates, which is where the real benefit lies — not in the branching itself but in having one document to maintain instead of six that drift apart.

Availability

Conditional routing is available on Business plans. Existing templates are unaffected; conditions are opt-in per template and a template with no conditions behaves exactly as it did before.

What we are not building

Two requests we have declined, with reasons, because the reasoning may be more useful than the features.

Conditions based on external data — routing on a value pulled live from a CRM at signing time — introduces a dependency that can fail midway through a legal process. If the lookup fails, the document either stalls or routes on stale data, and neither is acceptable for something that produces a binding agreement. Prefill the value at send time instead, so what the condition evaluates is fixed and recorded.

Conditions that modify clause text based on answers are the second. That sounds appealing and it means the document a signer agreed to was assembled at runtime from fragments, which makes proving what they saw considerably harder. Conditional page sections are supported precisely because whole sections can be recorded as included or excluded; conditional sentences within a clause cannot be evidenced as cleanly.