flow-transaction-finalizer-patterns
Use when a Flow needs to do work that must survive the triggering transaction — post-commit notifications, callouts, audit rows, or compensating actions. Covers Flow Transaction Control element, scheduled paths, Platform Event + finalizer escalation, and Apex Queueable finalizer bridging. Does NOT cover general Flow async decisions (see async-selection).
Best use case
flow-transaction-finalizer-patterns is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when a Flow needs to do work that must survive the triggering transaction — post-commit notifications, callouts, audit rows, or compensating actions. Covers Flow Transaction Control element, scheduled paths, Platform Event + finalizer escalation, and Apex Queueable finalizer bridging. Does NOT cover general Flow async decisions (see async-selection).
Teams using flow-transaction-finalizer-patterns should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/flow-transaction-finalizer-patterns/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How flow-transaction-finalizer-patterns Compares
| Feature / Agent | flow-transaction-finalizer-patterns | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when a Flow needs to do work that must survive the triggering transaction — post-commit notifications, callouts, audit rows, or compensating actions. Covers Flow Transaction Control element, scheduled paths, Platform Event + finalizer escalation, and Apex Queueable finalizer bridging. Does NOT cover general Flow async decisions (see async-selection).
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Flow Transaction Finalizer Patterns ## Purpose Salesforce transactions are atomic: either every DML commits or none does. But some work should only run AFTER commit — sending an email, firing a webhook, writing an audit log to an external system, or issuing a compensating action if a callout later fails. Getting this wrong produces two common failures: "email sent but record rolled back," or "record saved but downstream never notified." This skill codifies the patterns Flow designers should use for reliable post-transaction behavior, and when to escalate to Apex Queueable with a Finalizer. ## Recommended Workflow 1. **Classify the step.** Is it pre-commit (validation), in-transaction (DML), or post-commit (notify / callout / external effect)? 2. **Prefer Scheduled Path for simple post-commit work.** A 0-minute scheduled path runs in a new transaction, so effects happen after the trigger commits. 3. **Use Platform Events for fan-out.** Publish-after-commit semantics guarantee the event is not emitted on rollback. 4. **Use Apex Queueable + Finalizer when the work must report success or chain.** A finalizer runs whether the Queueable succeeded or failed — essential for durable notification. 5. **Design idempotency.** Post-commit work may retry; steps must be safe to rerun. 6. **Log every run.** A custom object or Platform Event records that the post-commit step actually fired. ## Available Mechanisms | Mechanism | Runs in | Survives rollback? | Retryable? | |---|---|---|---| | Pre-commit Flow step | Same txn | No (step rolls back with the txn) | N/A | | After-Save Record-Triggered Flow | Same txn | No | N/A | | Scheduled Path (0 min) | New txn | Yes | Via scheduled re-run pattern | | Platform Event (publish-after-commit) | New txn via subscriber | Yes | Via replay / dead-letter | | Queueable + `System.Finalizer` | Async, post-commit | Yes | Yes (finalizer sees outcome) | ## Patterns ### Pattern A: Scheduled Path For Email / Simple Update Record-Triggered Flow triggers an immediate (0 min) Scheduled Path that sends the email or updates a related record. If the parent DML rolls back, the scheduled path does not run. ### Pattern B: Platform Event For Fan-Out Record-Triggered Flow publishes a Platform Event (configured publish-after- commit). Subscribers (Flow or Apex) react in their own transactions. ### Pattern C: Apex Queueable + Finalizer When work is complex (multi-step, requires error handling, must emit an end-to-end result), Flow calls an Invocable Action that enqueues a Queueable. The Queueable registers a Finalizer that logs success/failure and triggers compensating actions on failure. See `templates/apex/` for the repo-canonical `QueueableWithFinalizer` shape. ## Durability Cheatsheet - "Must happen after commit, nice-to-have reliability" → Scheduled Path. - "Must happen after commit, multiple consumers" → Platform Event. - "Must happen after commit, guaranteed acknowledge, able to compensate on failure" → Queueable + Finalizer. ## Anti-Patterns (see references/llm-anti-patterns.md) - Send email directly from a pre-save Flow. - Use an "after-save" Flow for a callout and assume rollback protection. - Catch an exception in Flow and continue as if nothing happened. - Queue work without logging that it ran. ## Official Sources Used - Flow Trigger & Scheduled Paths — https://help.salesforce.com/s/articleView?id=sf.flow_concepts_trigger_schedule.htm - Platform Events Publish Behavior — https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_publish_after_commit.htm - Apex Queueable Finalizer — https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_queueable_finalizer.htm - Salesforce Well-Architected Resilient — https://architect.salesforce.com/docs/architect/well-architected/resilient/resilient
Related Skills
transaction-security-policies
Transaction Security policy creation and configuration: condition builder, enhanced policies, enforcement actions (block, MFA, notification, end session), real-time monitoring mode, and policy troubleshooting. NOT for Event Monitoring log analysis or Shield Event Monitoring setup (use event-monitoring). NOT for Apex testing or debug-log analysis.
mfa-enforcement-patterns
Design MFA enforcement: auto-enablement, Salesforce Authenticator rollout, exceptions, service accounts, API-only users, SSO interop, and audit. Trigger keywords: MFA, multi-factor, two-factor, Salesforce Authenticator, MFA exception, MFA SSO, api-only MFA. Does NOT cover: end-user password policies, device-trust posture, or non-Salesforce IdP configuration.
ip-range-and-login-flow-strategy
Design and implement Salesforce Login Flows (Screen Flows assigned to profiles or Experience Cloud sites) that run post-authentication to enforce conditional MFA, IP-based branching, terms-of-service acceptance, or user data collection. Covers Login Flow creation in Flow Builder, profile/site assignment, IP-aware decision logic, and ConnectedAppPlugin extension points. NOT for static IP allowlisting or profile Login IP Ranges (see network-security-and-trusted-ips), org-wide session policies, or SSO/SAML IdP configuration.
encrypted-field-query-patterns
Design SOQL, filters, reporting, and indexes against Shield Platform Encryption fields. Trigger keywords: Shield Platform Encryption, encrypted field query, probabilistic vs deterministic encryption, encrypted SOQL filter, encrypted field index. Does NOT cover: Classic Encryption (deprecated), field-level security policy, or tenant secret key rotation.
customer-data-request-workflow
Implement GDPR/CCPA data subject rights (access, deletion, rectification) using Salesforce Privacy Center and/or custom workflow. NOT for general backup or org-level data retention policy.
apex-managed-sharing-patterns
Grant row-level access programmatically via __Share records when declarative sharing rules cannot express the policy. NOT for OWD, role hierarchy, or criteria-based sharing rule design.
omnistudio-vs-flow-decision
Use when choosing between OmniStudio (OmniScript / Integration Procedure / FlexCard / DataRaptor) and Flow / Screen Flow / Apex for a given capability. Triggers: 'omnistudio or flow', 'omniscript vs screen flow', 'integration procedure vs subflow', 'flexcard vs lightning page'. NOT for general automation selection across Workflow/Process Builder/Apex (see automation-selection tree).
omnistudio-testing-patterns
Use when testing or validating OmniStudio components — OmniScript preview, Integration Procedure step debugging, DataRaptor field-mapping validation, and end-to-end UTAM-based automation. NOT for Apex unit testing or standard Flow debugging.
omnistudio-error-handling-patterns
Use when designing fault behavior across Integration Procedures, DataRaptors, OmniScripts, and FlexCards — error routing, user-facing messaging, retry semantics, and idempotency. Triggers: 'omnistudio error', 'integration procedure fault', 'dataraptor error handling', 'omniscript retry', 'flexcard action failure'. NOT for general Apex exception design or Flow fault paths.
omnistudio-ci-cd-patterns
Use when designing or implementing CI/CD pipelines for OmniStudio components — DataPack export/import, versioning, environment promotion, and automated deployment. NOT for standard Salesforce metadata CI/CD or Apex-only pipelines.
omniscript-design-patterns
Use when designing or reviewing OmniScripts for guided experiences, step structure, branching, save/resume, and the boundary between OmniScript, Integration Procedures, DataRaptors, and custom LWCs. Triggers: 'omniscript design', 'too many steps in omniscript', 'save and resume omniscript', 'branching in omniscript', 'when should this be an integration procedure'. NOT for deep Integration Procedure or DataRaptor design when the guided interaction layer is not the main concern.
integration-procedure-cacheable-patterns
Use when designing Integration Procedures (IPs) with platform cache to cut latency and callout load. Covers cache key design, TTL selection, per-user vs org-wide partitions, invalidation on data changes, and safe fallback on cache miss/stale. Does NOT cover general IP authoring (see omnistudio-error-handling-patterns) or LWC client-side caching.