Workflow Conditions

Conditions allow you to add decision logic to your workflows. Instead of executing the same actions for every lead, you can create branching paths that execute different actions depending on the lead's data.

How Conditions Work

A condition node sits between a trigger and its action nodes. When the trigger fires:

1. The system evaluates the condition against the lead's data.
2. If the condition is true, the workflow follows the "Yes" path.
3. If the condition is false, the workflow follows the "No" path (if one exists).

This creates an if/else branching pattern:

Trigger: Stage Enter ("Interview")
  → Condition: Program = "Primary School"
    → Yes: Send Email (Primary Welcome)
    → No: Send Email (Secondary Welcome)

Trigger-Level Conditions

The simplest form of conditions is built into trigger nodes. When configuring a trigger, you can add filters that narrow when it fires:

Stage-Specific Triggers

Configure a "Stage Enter" trigger to only fire for a specific stage:

• Without condition: Fires when a lead enters any stage.
• With condition: Fires only when a lead enters the "Interview Scheduled" stage.

Form-Specific Triggers

Configure a "Form Submitted" trigger to only fire for a specific form:

• Without condition: Fires for any form submission.
• With condition: Fires only when the "Primary Application Form" is submitted.

Status-Specific Triggers

Configure a "Status Enter" trigger to only fire for a specific status:

• Without condition: Fires for any status change.
• With condition: Fires only when the status changes to "Accepted."

Trigger Matching Logic

The triggerMatches method evaluates whether a trigger's conditions match the current context:

• Stage triggers: Compare the stage_id in the event context with the trigger's configured stage.
• Status triggers: Compare the status value in the event context with the trigger's configured status.
• Form triggers: Compare the form_id in the event context with the trigger's configured form.
• Checklist triggers: Compare the checklist_id with the trigger's configured checklist.
• Engagement triggers: Compare the engagement_level with the trigger's configured level.

If no conditions are set on the trigger, it matches all events of that type within the pipeline.

Building Conditional Workflows

Example 1: Different Emails by Program

Goal: Send different welcome emails depending on the applicant's program.

Trigger: Lead Created
  → Condition: Program = "Kindergarten"
    → Yes: Send Email (Kindergarten Welcome)
    → No: Send Email (General Welcome)

Example 2: Auto-Assignment by Campus

Goal: Assign different admissions officers based on the applicant's campus.

Trigger: Form Submitted
  → Condition: Campus = "Main Campus"
    → Yes: Assign Owner (John Smith)
    → No:
      → Condition: Campus = "North Campus"
        → Yes: Assign Owner (Jane Doe)
        → No: Assign Owner (Default Team)

Example 3: Conditional Status Change

Goal: Automatically accept applicants who complete all required checklists, but only if they are in the "Documents Complete" stage.

Trigger: Checklist Completed
  → Condition: Stage = "Documents Complete"
    → Yes: Set Status (Accepted)
    → No: (do nothing)

Best Practices for Conditions

TIP

1. Keep conditions simple -- each condition should test one thing. Use multiple connected conditions for complex logic rather than trying to evaluate everything in one node.

2. Consider all paths -- always think about what happens when a condition is false. If no "No" path is defined, the workflow simply stops for leads that do not meet the condition.

3. Test with different leads -- before activating, mentally walk through the workflow with different types of leads to ensure all paths produce the desired results.

4. Document your logic -- use descriptive names for workflow nodes so the logic is clear when reviewing later.

Condition Limitations

WARNING

• Conditions evaluate at the time the trigger fires. If a lead's data changes after the trigger but before delayed actions execute, the actions use the original data.
• Complex nested conditions (more than 3-4 levels deep) can be difficult to maintain. Consider splitting into multiple simpler workflows.
• Rate limiting applies across all workflows -- if multiple workflows trigger rapid cascading changes, some executions may be rate-limited.

Was this helpful?