Imagine a checkpoint in a process, like a step in a journey for an item or a person (called an "entity"). In Workflows, this checkpoint is called a Trigger Node. Its job is to check specific conditions, like an entity's Status, Date of Birth, or Pay Rate. Based on these checks, the entity either moves on to the next step or stays where it is.

How Triggers Work in Workflows

In Workflows, there are three main ways to set up these Trigger Nodes to react to changes in an entity's information (called "attributes"):

1. "Specific to Any":
    
   • This trigger activates when a piece of information changes from a specific value to any other value.
   • Example: If an entity's Status changes from "Inactive" to any other status (like "Active" or "Placed").
   • Key Behavior: For this trigger to work, the change must happen after the workflow is active. If it changes before the workflow starts, or if it changes to the same value, the entity will get stuck.
2. "Any to Specific":
    
   • This trigger activates when a piece of information changes from any value to a specific, desired value.
   • Example: If an entity's Status changes from any status (like "Referral Lead") to "Inactive".
   • Key Behavior: This trigger is more flexible. An entity can move forward even if the attribute change happens before the workflow starts, as long as it changes to the specific target value. If it changes to a different value than the specific target, it will get stuck.
3. "Specific to Specific":
    
   • This trigger activates when a piece of information changes from one specific value to another specific value.
   • Example: If an entity's Status changes from "Active" to "Pending".
   • Key Behavior: Similar to "Specific to Any," this trigger generally requires the change to happen after the workflow is active. If it changes before activation, or to the same value, or to a value that isn't the target specific value, the entity will get stuck.

How to Set Up a Trigger Node

To set up one of these checkpoints, you need to:

• Select the piece of information (like Status, DateOfBirth, or PayRate) that you want to watch for changes.
• Choose the type of change you're looking for (Specific to Any, Any to Specific, or Specific to Specific).
• Define the value(s) that should trigger the action.

Important Rules for Entity Movement in Workflows

For an entity to move forward through the workflow via a Trigger Node, two main conditions must be met:

• On the List First: The entity must first meet a "list rule" and be added to a specific list.
• A "New" Change: The trigger rule must be met by a distinct update (a new change from outside) to the entity, and this change must happen after the workflow has been activated. If the trigger rule is met before the workflow is active, the entity will not move forward.

Let's look at different scenarios (cases) for when an entity will or won't move forward:

• Case 1: New Entity, Same List and Trigger Rules, Simultaneous Match
   
  • Scenario: A new entity is created and, at that very moment, it meets both the "list rule" (so it's added to the list) and the "trigger rule" at the same time.
  • Outcome: Yes, the entity will move forward. This is because both rules are met after the workflow is active during its creation.
• Case 2: Existing Entity, Same List and Trigger Rules, Simultaneous Match During Update
   
  • Scenario: An existing entity is updated, and at that very moment, it meets both the "list rule" and the "trigger rule" simultaneously.
  • Outcome: No, the entity will NOT move forward. Even if the entity was already on the list, the trigger rule needs a separate external update to specifically make it true, not just satisfy it as part of a general update that also puts it on the list.
• Case 3: New Entity, Different List and Trigger Rules, Simultaneous Match
   
  • Scenario: A new entity is created and, at that very moment, it meets both the "list rule" and the "trigger rule," even if these rules are different.
  • Outcome: Yes, the entity will move forward. Similar to Case 1, because it's a new creation and the rules are met after workflow activation.
• Case 4: Existing Entity, Different List and Trigger Rules, Simultaneous Match During Update
   
  • Scenario: An existing entity is updated, and at that very moment, it meets both the "list rule" and the "trigger rule," even if these rules are different.
  • Outcome: No, the entity will NOT move forward. Just like Case 2, the trigger rule needs to be satisfied by a separate external update after the entity is already established on the list.
• Case 5: List and Trigger Rules Met via Separate Updates
   
  • Scenario: This is the proper way for an existing entity to move.
    • Step 1: The entity first meets the "list rule" and is added to the list (this could be during creation or an update).
    • Step 2: Later, a separate, distinct update happens that causes the entity to meet the "trigger rule".
  • Outcome: Yes, the entity will move forward. This two-step, sequential process ensures both conditions are met correctly for the entity to progress.

Key Difference Between Journeys and Workflows for "Any to Specific" Triggers

There's an important difference between how older systems (like Journeys) and Workflows handle certain triggers, specifically "Any to Specific" changes, if they happen before the process is active:

• Journeys: If an attribute changes from any value to a specific value before the "journey" (Journeys's process) is activated, nothing will happen. Journeys only pays attention to changes after its journey has started.
• Workflows: Workflows is more forgiving. Even if an attribute changes from any value to a specific value before the "workflow" (Workflows's process) starts, Workflows can still recognize that change and allow the entity to move forward.

Configuring Rule Processing for Workflow Participants

This guide explains how to configure and process rules for individuals in a list before and after a workflow is activated. It clarifies rule behavior for different scenarios so you can accurately manage participant statuses and actions.

Use Case

You may need to process specific rules for people already on a list before workflow activation and for those added later. This flexibility ensures accurate status-based actions and consistent workflow automation.

Acceptance Criteria

Process Rules for Members Added After Workflow Activation

When you enable rule processing for members added after activation, the workflow evaluates participants as they are added.

Any to Any

• The system waits for any update (EU) on the status field before moving the member forward.
• It does not impact whether the member was already in the list or added later.

Any to Active

• Existing members (e.g., 100 already in the list):
  • If status is "Inactive" → The member remains in place.
  • If status is "Active" → The member remains in place.
  • If status changes from any value to "Active" → The member moves forward at that point.
• Newly added members:
  • If status is "Inactive" → The member remains in place.
  • If status is "Active" → The member moves forward immediately.
  • If status changes from any value to "Active" → The member moves forward at that point.

Inactive to Active

• For existing members (similar to keeping the checkbox OFF):
  • If status is "Inactive" → The member stays in place.
  • If status is "Active" → The member stays in place.
  • If status changes from any value to "Active" → The member stays in place.
  • If status changes specifically from "Inactive" to "Active" → The member moves forward at that point.

Active to Any

• Same logic as "Inactive to Active" described above.

Process Rules for Members Already in the List Before Workflow Activation

When you enable rule processing for pre-existing members, the workflow checks and evaluates members as of the moment of activation.

Any to Any

• The system waits for any update on the status field before moving the member forward.

Any to Active

• If status is "Inactive" → The member stays in place.
• If status is "Active" → The member moves forward immediately.
• If status changes from any value to "Active" → The member moves forward at that point.

Inactive to Active

• If status is "Inactive" → The member stays in place.
• If status is "Active" → The member stays in place.
• If status changes from any value to "Active" → The member stays in place.
• If status changes specifically from "Inactive" to "Active" → The member moves forward at that point.

Active to Any

• Same logic as "Inactive to Active" described above.

Trigger Values: "Any to Any"

If you need to trigger actions when a specific entity changes from any value to any other value, use the "Any to Any" configuration.

• You must select the field to monitor (e.g., candidate/status).
• The system qualifies and processes members when a value changes after activation.
• This configuration applies to both:
  • Members already in the list before activation.
  • Members added after workflow activation.

Enhanced Trigger Behavior

Changed

• Trigger Validation Logic: Enhanced trigger rule validation to allow users to specify when rules should be evaluated relative to workflow activation
• List Member Processing: Updated member processing logic to support different validation strategies for pre-existing vs. new list members
• User Interface: Simplified criteria selection interface for better user experience
• Entity Movement Rules: Updated entity movement logic to handle different scenarios for new vs. existing entities

Technical Details

• Default selection: "Consider existing members and new members of the list"
• Affects: Workflow trigger behavior for list-based automations
• Impact: Provides granular control over when trigger rules are evaluated for list members

Key Behavioral Notes

• Entities must first satisfy the list rule and then receive a distinct trigger rule update after workflow activation to move forward.
• New entities can meet both the list and trigger conditions simultaneously during creation.
• Existing entities require separate updates — one for list inclusion and another for trigger activation.
• "Any to Specific" triggers in Workflows are more flexible than in Journeys when handling pre-activation changes.