LEARN. PRACTICE. GROW.Concept and mechanism
A flow starts when its trigger is satisfied and receives data appropriate to that trigger. Type, table, conditions, session, and repetition policy are part of its design. An update trigger running for every change can create repeated work when the flow updates the record again. For approvals, official guidance recommends one initial trigger execution and explicit logic when approval must be requested again. A saved trigger supports reusing a published definition, but later changes and consumer-specific options still need impact analysis. Scope and execution identity also determine which data can be accessed.
Guided application
In a fictional example, a restart request waits for approval before creating APS work. Adding a note should not open a second approval chain. Use specific conditions and inspect execution context. Scheduling defines timing intent, but asynchronous processing can introduce delay; it does not guarantee second-exact execution during financial closing. Virtual Agent can guide users and transfer conversations to human support depending on configuration and availability. An indication that agents are online does not prove suitable skills for every issue. Define an alternative when support is unavailable, preserve the necessary context, and do not present a failed transfer as resolution. This example teaches the decision without installing real automation.
Updating a note should not duplicate restart approval.
Common pitfalls
Overbroad trigger; queue treated as immediate execution; availability treated as expertise.
Related topics: Instance, navigation, and context · Configuration, access, and interfaces · Records, collaboration, and analytics
Design conditions, identity, repetition, and exceptions together.
Reference: Workflow Studio flow trigger types · CSA blueprint January 2026