Conditional Routing in eSignature: How to Design Rules That Work

Conditional routing sends a document to different signers or approvers depending on what is in it: a field value, a dollar amount, a checkbox, or an earlier signer’s answer. Instead of building one fixed signing order and fixing exceptions by hand, you write the rules once and the workflow picks the path. This guide explains how the logic works, which rules are worth building, where they break, and what to log so you can prove who signed and why.

TL;DR

• Conditional routing is an if/then rule attached to a signing workflow: if a value meets a condition, add, skip or reorder recipients.
• The most common limits come from who knows the answer. A rule can only use data that exists before the step it controls.
• Start with one rule that removes a real manual hand-off, such as a discount approval, and test every branch before launch.
• Log the input value, the rule that matched, the recipient assigned and what happened next. That is what makes a routed document defensible later.
• Per-envelope pricing can make branching workflows expensive. Flat-rate plans keep the cost of testing and extra branches predictable.

Table of Contents

• What conditional routing actually does
• Routing versus conditional fields
• Where the data for a rule comes from
• Five rule patterns worth building
• A worked example: vendor agreements
• How to build and test a routing rule
• Common ways routing rules fail
• What to record for every routed document
• Routing in common team workflows
• Our perspective on conditional routing
• Run routed workflows with BeeSign
• FAQ
• Sources

What conditional routing actually does

A standard signing workflow is a list: signer one, signer two, signer three. Everyone on the list gets the document in order, whether or not they are needed.

Conditional routing replaces that list with a decision. The system looks at a value and chooses the next recipient. Three things can change:

• Who receives the document (a manager, a legal reviewer, a spouse, a guardian).
• Whether a step happens at all (skip the second signer if the amount is small).
• In what order steps happen (send to finance before legal when the contract is international).

A simple example: a sales contract has a field for contract value. Under $10,000, the sales manager signs. Between $10,000 and $50,000, a director also signs. Above $50,000, legal and finance review before anyone signs. The sender never decides. The value does.

The questions people post in community forums show where the pain is. They ask how to show spouse fields only when a signer is married, how to handle a document that sometimes has one signer and sometimes two, and how to make a field on one recipient’s page depend on another recipient’s answer. All three are routing or conditional-display problems, and all three have the same root cause: the rule needs information that nobody has yet at the time the document is sent.

Routing versus conditional fields

These two features are easy to confuse, and mixing them up causes most failed setups.

You often need both. A tenant fills in a form, a checkbox reveals extra fields, and the answer decides whether a co-signer gets a copy. Design them separately, then connect them.

Where the data for a rule comes from

Every rule needs an input. There are four realistic sources, and choosing the right one decides whether the rule works.

1. The sender, at send time. The person sending the document fills in a value, such as deal size or employee level. This is the simplest and most reliable source.
2. A form filled by the first signer. The first recipient answers a question, and the next step depends on it. This works only if the first signer is the one who knows the answer.
3. A template default. The template carries a fixed value, for example “department = Finance”, so routing is the same every time.
4. Your own system through an API. Your CRM, HRIS or order system passes values when it creates the document. Nobody retypes anything.

The forum question about a document that conditionally has one or two signers is a good test. If the only person who knows whether a second signer is needed is the first signer, then you need source two: ask that signer directly, in a required field, and let the answer add the second recipient. If the sender knows, use source one. If your system knows, use source four.

Five rule patterns worth building

Do not start by mapping every exception. Start with patterns that remove a repeated human decision.

1. Threshold approvals

Route by amount: purchase orders, discounts, refunds, vendor contracts. Define bands, not single cutoffs, and decide what happens exactly at the boundary. “Over $10,000” and “$10,000 or more” produce different paths for a $10,000 contract.

2. Role or department routing

Use a dropdown to send an HR change form to the right department head, or a service request to the right regional manager. This replaces a shared inbox where someone forwards messages by hand.

3. Optional signers

Add a co-signer, guardian, spouse or witness only when a condition is true. Education administrators use this for enrollment: a student under 18 needs a parent or guardian signature, an adult student does not. Real estate teams use it when a property has more than one owner.

4. Risk or verification gates

Add an extra step when risk is higher. A high-value agreement might require identity verification with a government ID check before signing, while a low-value one does not. Making that check conditional keeps friction low for routine documents.

5. Fallback and escalation

If the assigned approver does not respond in a set time, route to a backup. This is routing by time rather than by value, and it prevents a document from stalling because one person is on vacation.

A worked example: vendor agreements

Take an e-commerce company onboarding vendors. Here is the rule set, written the way you would document it before building it.

A few details make this robust:

• Make inputs required. If annual spend is blank, no rule can match. A blank field should block sending, not fall through to the cheapest path.
• Set a default. Decide what happens when nothing matches. The safest default is the strictest path, not the lightest.
• Evaluate rules in a stated order. When two rules apply, as with a $60,000 contract that also involves customer data, the document should collect both reviewers, not pick one.
• Put the vendor last. External signers should receive the document only after internal reviewers approve, so you never ask a vendor to sign a draft that internal review will change.

How to build and test a routing rule

This sequence works in any tool that supports branching, and it is how we suggest teams pilot it.

1. Pick one document. Choose a document where people currently forward emails to decide who signs next.
2. Write the rule on paper. List the input, each condition, each outcome and the default. If you cannot fit it in a small table, the rule is too complicated for a first version.
3. Identify the data source. Name who or what supplies each input and when. If the answer is “the signer, after the step that needs it”, redesign.
4. Build it in a template. Rules belong in a reusable template so every sender gets the same logic. Our guide to setting up approval workflows walks through the approval side.
5. Test every branch. Send a test document for each path using real email addresses you control, including the default path and an empty-input case.
6. Pilot with a small group. Run the workflow with a few senders for a couple of weeks, then compare time to completion and the number of manual corrections. Our team pilot guide covers how to run one.
7. Document the rule. Keep the rule table where an auditor or new employee can find it. A rule nobody can explain is a liability.

Common ways routing rules fail

The rule needs data from a later step. A field on signer two’s page cannot decide whether signer one is needed. Order the workflow so decisions come after the data exists.

Templates drift. Someone edits a copy instead of the template, and the rule no longer matches your table. Lock templates and control who can edit them.

Recipient lists are hard-coded. A rule that routes to a named person breaks when they leave. Route to a role or shared group address that you maintain.

Too many branches. Every extra condition multiplies test cases. Three independent yes/no rules produce eight possible paths. If a rule set grows past what you can test in an afternoon, split it into separate templates.

Nobody owns the rules. Name one person responsible for changes, and keep a change log.

What to record for every routed document

Routing makes the audit trail more important, not less. When a document takes a different path each time, a reviewer will eventually ask why this one went to legal and that one did not.

For each routed document, record:

• The input value that triggered the rule, and who or what supplied it.
• The rule that matched, by name or version.
• The recipient assigned and the time of assignment.
• Each later action: viewed, signed, declined, reassigned.
• Any identity verification result tied to the signer.

Regulated industries show why. In an interpretive letter from FINRA, the regulator addressed an electronic workflow in a broker-dealer setting, and the letter’s focus is on making records and audit trails accessible, identifying the employees who processed or reviewed records, and keeping authorized-user information available for examination. That is a financial-industry context, not a rule for every eSignature, so apply the idea in proportion to your own records and industry requirements. The practical lesson holds broadly: a final signed PDF alone cannot reconstruct who reviewed a record and what access they had.

If you want the detail of what a good trail contains, read our explainers on how an audit trail works, electronic signatures with an audit trail and tamper-evident audit trails. If a dispute or investigation starts, the guide on holds that protect audit trails explains what to preserve first.

Routing in common team workflows

HR onboarding. Route by employment type or location: a contractor gets a different agreement and approver than a full-time employee, and a state-specific notice is added only for employees in that state. See the offer letter workflow and the guide to eSignature in HR workflows.

Real estate. Add a second seller or buyer when the property has multiple owners, and route addenda to a broker only when the price changes. For deals with several parties, our piece on multi-signer contract workflows covers ordering and reminders.

Education. Add a guardian for minors, route financial aid forms to the aid office only when the student selects aid, and send international students’ forms to the right advisor.

Service businesses. Route change orders by job size, so small changes go to the site lead and large ones to the owner. Our page for service businesses shows how signing connects to daily operations.

Our perspective on conditional routing

We see the same pattern in many teams. They buy a signing tool, then discover that their real process has exceptions the tool does not handle, so people go back to email. The cause is rarely the signature itself. It is the hand-off logic around it.

That is why we build BeeSign around the workflow rather than the envelope. Contracts, templates, identity verification and approvals sit in one platform, so a routing decision can use the same data the rest of the process uses. When your rules depend on your own systems, the API lets you pass values in at creation time, so nobody retypes a deal size into a form. We also build and maintain integrations for customers, so your team does not have to manage every API connection alone.

We also think pricing shapes behavior. If every extra envelope costs money, teams avoid testing branches and avoid sending test documents, and their rules go live untested. We use flat-rate pricing without per-envelope fees so you can test every path before launch. And because routed documents need to be explainable, we pair routing with complete audit trails and optional blockchain timestamp proof, with white-label and bring-your-own-cloud options for teams that need records to stay inside their own infrastructure.

Our advice is the same for a startup and an enterprise: automate one decision at a time, write it down, test it, and make the trail readable by someone who was not there.

— Mustafa Abusharkh

Run routed workflows with BeeSign

If you want to build approval paths, reusable templates and identity checks in one place, start with BeeSign electronic signatures. Add identity verification for the higher-risk branches. Plans and the 7-day free trial are on the pricing page, where the Individual plan is $9.99 per month and Enterprise and customized integrations are available for larger needs. Teams that must run signing under their own brand and storage can look at white label and bring-your-own-cloud.

FAQ

Can a rule depend on another signer’s answer?

Yes, as long as that answer exists before the step the rule controls. Place the signer who knows the answer earlier in the order, make the field required, and let the next step depend on it. A field on a later page cannot change an earlier step.

What should happen if no rule matches?

Use a default path, and make it the strictest one. A blank required input should stop the document from being sent. Silent fall-through to the lightest approval is how exceptions slip past review.

How many conditions are too many?

When you cannot test every path in one sitting, split the workflow. Three independent yes/no conditions already create eight paths. Separate templates for distinct document types are easier to test and explain than one template with a dozen branches.

Does conditional routing change the legal validity of a signature?

Routing decides who signs, not whether a signature is valid. Validity depends on consent, intent to sign, record retention and the rules that apply to your document type and industry. For regulated records or high-stakes agreements, ask your counsel or compliance officer which controls to add.

Sources

• FINRA interpretive letter to Laura Moret, American Express Financial Corporation

Recommended

• Court Proven Real Estate ESIGN Workflow That Maps Recorder Rules
• 8 Steps for Admins to Fix Hidden Required Fields in Conditional eSign
• How to Route Documents for Approval Fast
• Practical Setup in Beesign: Sequential, Parallel, and Hybrid Signing