Chaining Record-Triggered Flows with Touch Fields

Salesforce does not allow one Record-Triggered Flow to directly invoke another Record-Triggered Flow on a different object. When you need an automation on a child record to trigger an evaluation on the parent record, the "touch field" pattern provides a clean, declarative solution.

Why You Cannot Call One Flow From Another Directly

Record-Triggered Flows fire based on DML events (insert, update, delete) on a specific object. There is no "Call Flow" element that invokes another Record-Triggered Flow. While Subflows exist, they invoke Screen Flows or Autolaunched Flows, not Record-Triggered Flows.

The touch field pattern works around this limitation by using DML as the communication mechanism: Flow 1 updates a field on the parent record, which triggers Flow 2's entry condition on that same parent object.

Designing the Touch Field

A touch field is a purpose-built field whose sole job is to signal that an event occurred. DateTime is the best data type for this purpose.

Why DateTime is better than Checkbox:

Data Type	Behavior	Problem
Checkbox	Toggled from false to true	If already true, setting it to true again is not a change. Flow 2 does not fire.
DateTime	Set to NOW()	Always produces a new, unique value. Every update is detected as a change.

Field Definition Example

<fields>
    <fullName>Evaluation_Trigger_Stamp__c</fullName>
    <label>Evaluation Trigger Stamp</label>
    <type>DateTime</type>
    <required>false</required>
    <externalId>false</externalId>
    <description>
        Touch field used to trigger parent-level automation
        when child records change. Do not set manually.
    </description>
</fields>

Mark this field as hidden on page layouts and set FLS to read-only for non-admin profiles. It is a system field, not a user-facing field.

The Two-Flow Architecture

Flow 1: Child Record Trigger (Sender)

• Object: Child record (e.g., QuoteLineItem)
• Trigger: After Update (or After Create, depending on use case)
• Entry Condition: Detects the relevant change on the child record (e.g., Status__c changed to "Approved")
• Action: Update Records element targeting the parent record, setting Evaluation_Trigger_Stamp__c = {!$Flow.CurrentDateTime}

Flow 2: Parent Record Trigger (Receiver)

• Object: Parent record (e.g., Quote)
• Trigger: After Update
• Entry Condition: ISCHANGED({!$Record.Evaluation_Trigger_Stamp__c}) evaluates to true
• Action: Performs the parent-level evaluation logic (e.g., checks whether all child records meet approval criteria, then updates the parent status)

The key is that Flow 2's entry condition uses ISCHANGED on the touch field. This ensures Flow 2 only fires when the touch field is actually updated, not on every parent record update.

Practical Example: Approval Resubmission

Consider a scenario where a Quote requires re-approval after any Quote Line Item changes:

1. A user modifies a QuoteLineItem's quantity or price.
2. Flow 1 (on QuoteLineItem, After Update) detects the field change and sets Quote.Reapproval_Trigger_Stamp__c = NOW().
3. Flow 2 (on Quote, After Update) detects ISCHANGED on Reapproval_Trigger_Stamp__c, evaluates whether the Quote's current approval status should be reset, and updates ApprovalStatus__c to "Pending Reapproval."
4. A Platform Event or notification alerts the approver.

Without the touch field, you would need either a single monolithic Flow that handles both child and parent logic (which becomes unmaintainable), or custom Apex to bridge the two objects.

Common Pitfalls

Circular triggers: If Flow 2 updates a field on the parent that Flow 1 also monitors, you can create an infinite loop. Always ensure that the touch field update in Flow 1 and the entry condition in Flow 2 do not create a cycle. Use entry conditions that explicitly exclude touch-field-only updates.

Entry condition timing: In Flow 2, use ISCHANGED rather than checking for a non-null value. A non-null check fires on every update to the parent record once the field has been set, which produces unintended executions.

Multiple child updates in one transaction: If a bulk operation updates 50 child records simultaneously, Flow 1 may attempt to update the same parent record 50 times. Use a Before-Save Flow or Apex trigger with deduplication logic to consolidate the parent update into a single DML operation.

Key Takeaway

The touch field pattern is a reliable, declarative way to coordinate automation across parent-child object boundaries. Using a DateTime field ensures every signal is unique and detectable. The pattern keeps each Flow focused on a single object, maintains separation of concerns, and avoids the complexity of custom Apex for straightforward chaining scenarios.