What are conditions?
Conditions are the "if-this-then-that" rules that act as the brain of your workflow. Instead of forcing every recipient, document, and automation to behave the exact same way every time, conditions allow your workflow to dynamically react to the data entered into it. They tell parts of the workflow to turn on, shut off, or change behavior based on real-time inputs.
What are they used for?
Conditions are used to transform rigid, one-size-fits-all processes into smart, adaptable workflows. You should use them when you want to:
Personalize the experience: Show only the fields, documents, or steps that are relevant to a specific recipient.
Save time: Skip approvals, signers, or automations that don't apply to the current scenario.
Create logical branches: Run different automations based on outcomes (e.g., triggering different actions for "Approved" vs. "Declined" statuses).
Reduce errors: Minimize manual decision-making and make the recipient's journey shorter, clearer, and harder to mess up.
Type | Where you set it up | What it controls | Default behavior (if no condition) |
Field-level | Web form editor → Conditions | A single field's visibility or requirement status. | The field behaves exactly as originally set up. |
Step-level | Recipient step setup → Conditions | Whether a specific workflow step happens at all. | The step always happens. |
Bot-level | Any bot's setup → Conditions | Whether a bot executes when its trigger fires. | The bot runs every time it's triggered. |
Document-level | Show conditional document bot → Conditions | Whether a whole document is visible to recipients. | Hidden forever (if marked conditional but no bot is set). |
Breakdown of сondition types
Field-level conditions
What it is: Rules built inside a web form that dynamically show, hide, require, or disable a single field based on what the user has entered in other fields within that same form.
The benefit: Creates adaptive, progressively revealed forms. Recipients only see what is relevant to them, making the form look cleaner, feel shorter, and reducing data entry errors.
Use сase example: A signup form asks for Email, Phone, and Discount Notifications. You don’t want to ask about discounts until they provide a contact method.
Rule: Show Discount Notifications IF Email is not empty OR Phone is not empty. The discount question remains hidden until a contact field is filled.
Find detailed information on the field conditions in the corresponding articles for Web-forms and PDF-documents.
Step-level conditions
What it is: A rule placed on a recipient step that dictates whether that specific step actually occurs. If the conditions aren't met, the workflow skips the recipient entirely and moves to the next phase.
Condition types you can use on a step.
Type | What it checks | Example use |
When document field | A value entered in a field of any document filled in an earlier step | Run the step only if Amount in the Budget approval form is greater than $500 |
When the recipient | Attributes of the previous recipient — email, first name, last name, access level, or current step | Run the manager review step only if the requester's access level is "Fill and Share" |
When the date | The current date or a custom date / time / recurrence | Run a quarterly review step only in the first week of each quarter |
When the previous step | The state of the step immediately before this one | Run the escalation step only if the previous step was declined |
When document data | Document metadata — revision status, tags | Run the next step only if the document's status is "Completed" |
When the number of filled fields in | How many fillable fields have been filled in a chosen document | Run the QA review step only if all required fields in the contract are filled |
See Bot execution conditions article for the full operator reference.
The benefit: Eliminates workflow bottlenecks. Approvers are only pinged when their input is strictly necessary, allowing routine or low-stakes cases to pass through automatically.
Use case: A purchase request workflow goes: Requester → Manager Approval → Finance. For requests under $500, a manager's approval is a waste of time.
Rule on Manager Step: The step occurs when Amount > 500. Smaller requests will automatically bypass the Manager and land straight on Finance's desk.
Bot-level conditions
What it is: Rules attached to individual bots that determine if the bot should actually perform its task when its standard trigger fires.
The benefit: Enables highly selective automation. You can use one unified workflow that branches out and runs entirely different automations based on the data provided, without duplicating workflow templates.
Use case: You have a bot that exports completed contracts to Salesforce. You only want signed contracts exported, not ones the client declined.
Rule on Export Bot: Run when Revision status is equal to "Completed". Declined contracts safely stay out of your CRM.
Learn more about bot setup conditions in this article.
Document-level conditions
What it is: A specialized two-step setup that hides an entire document from recipients until specific criteria are met, utilizing the Show conditional document bot.
The benefit: Creates highly adaptive document packages. Recipients only see the paperwork that legally or practically applies to them, avoiding massive packets full of "N/A" fields.
Use сase: A new-hire onboarding packet includes a Relocation Agreement. This only matters if the employee is actually moving.
Setup: Mark the Relocation Agreement as conditional. Configure the bot to show it ONLY WHEN the Are you relocating? field in the primary onboarding form equals "Yes". Local hires will never even know the relocation document exists.
Chaining conditional documents
When one document's visibility depends on data from another, or several documents form a sequential gate, you build it by referencing fields from more than one document inside the Show conditional document bot's conditions. There is no separate "cross-document" feature — it's the same bot, just with conditions that look at multiple documents.
Example: A workflow has three documents:
Document 2 appears only if a field in Document 1 equals "Yes".
Document 3 appears only if a field in Document 2 equals "Approved".
Note: If the recipient opens Document 2, then Document 3, then goes back and changes Document 1 in a way that should hide Document 2 — Document 3 stays visible. It does not disappear automatically.
The fix: Set Document 3's conditions to depend on both Document 1 and Document 2. An upstream change will then collapse the whole chain correctly.
See Show conditional document bot for additional advanced scenarios.
Best practices
Use one field as the source of truth. If the same answer controls several things — a field, a document, a step, a bot — store it in a single field and point every condition at that one field. Much easier to update later.
Always require data to be present for bots to run. Include at least one Is not empty condition on every bot. Without it, a bot can fire on incomplete information.
Use specific fields, not "All Fields" or "All Required Fields". Specific fields behave more predictably and are easier to debug.
Test from the recipient's view, not just the builder's. Admins see every document regardless of conditions. A workflow that looks correct in the builder may look different to a recipient.
Name controlling fields clearly. If a field drives conditional logic elsewhere, name it so that's obvious — for example, is_relocating instead of Question 3.
Apply the condition at the narrowest level that solves the problem. A field-level rule is cheaper to change than a bot. A single bot is cheaper than rearranging steps or document chains.