Sf Flow

sf-flow: Salesforce Flow Creation and Validation (Brite edition)

Use this skill when the user needs Flow design or Flow XML work: record-triggered, screen, autolaunched, scheduled, or platform-event Flows, including validation, architecture choices, and safe deployment sequencing.

Brite Context

Brite's flow stance:

• Apex-first by policy. Brite uses Flows only for (a) Screen Flows (user-facing UI) and (b) simple notifications where Apex would be overkill. Never auto-launched flows for business logic. Source: brite-salesforce/CLAUDE.md §Engineering Standards line 41.
• Screen Flows deploy as Draft regardless of source <status>Active</status>. sf data update record cannot activate flows (fails serializing the complex Metadata field). Activation is a manual Setup-UI step that ships in /revops:post-deploy-runbook Phase 2.
• Post-deploy verification is non-optional. After every deploy that includes flows, verify via Tooling API SOQL: SELECT Status FROM Flow WHERE Definition.DeveloperName = '<Flow_Name>'. Deploy Status: Succeeded is necessary but not sufficient.
• Scratch orgs share the Draft trap. Same activation gap applies to scratch-org CI runs after a deploy preprocess.

See also: sf-apex for the Apex-first automation patterns (trigger handler dispatch, Queueable design); sf-deploy for safe deployment sequencing; sf-lwc when a flow embeds an LWC for richer UI; /revops:post-deploy-runbook for the post-deploy activation walk-through.

Brite Flow Policy

These rules are non-negotiable on brite-salesforce and must surface during flow design, deploy, and post-deploy verification.

1. Flow policy — Apex-first; Flows only for screen flows + simple notifications

Auto-launched flows for business logic are out — use Apex. Record-triggered flows for trivial branching only. Source: §Engineering Standards line 41.

2. Screen Flows deploy as Draft

Even when source XML specifies <status>Active</status>, newly-deployed screen flows land in Draft in the target org. Activate via Setup → Flows → find the flow → click Activate on the version row. Verified during BC-5021 prod deploy (2026-04-16).

3. sf data update record cannot activate flows

It fails serializing the complex Metadata field on the Flow object. Use Setup UI; do not script the activation.

4. Post-deploy SOQL verification — Tooling API

After a flow deploy:

SELECT Status FROM Flow WHERE Definition.DeveloperName = '<Flow_Name>'

Confirm Status = 'Active' before treating the deploy as landed.

5. Scratch org applicability

The Draft trap applies to scratch orgs too; CI deploys that run flows must include the activation step (or skip flow-dependent assertions).

6. Some Screen Flow settings are UI-only

Like the Kanban Group By selection (covered in sf-metadata), some flow runtime configurations live at the Lightning UI layer and aren't deployable. Document any UI-only setup per-org so sandbox refreshes don't lose it.

7. /revops:post-deploy-runbook cross-reference

Phase 2 of the post-deploy runbook walks through Screen Flow activation, diff-driven (only prompts when the deploy includes new/changed flows). Use it as the canonical post-deploy gate.

When This Skill Owns the Task

Use sf-flow when the work involves:

• .flow-meta.xml files
• Flow Builder architecture and XML generation
• record-triggered, screen, scheduled, autolaunched, or platform-event flows
• Flow-specific bulk safety, fault paths, and subflow orchestration

Delegate elsewhere when the user is:

• writing Apex-first automation → sf-apex
• creating objects / fields first → sf-metadata
• deploying metadata → sf-deploy
• seeding post-deploy test data → sf-data

Required Context to Gather First

Ask for or infer:

• flow type
• trigger object / entry conditions
• core business goal
• whether this is new, refactor, or repair
• target org alias if deployment or validation is needed
• whether related objects / fields already exist

Recommended Workflow

1. Choose the right automation tool

Before building, confirm Flow is the right answer rather than:

• formula field
• validation rule
• roll-up summary
• Apex

2. Choose the right Flow type

3. Start from a template

Prefer the provided assets:

• assets/record-triggered-before-save.xml
• assets/record-triggered-after-save.xml
• assets/screen-flow-template.xml
• assets/autolaunched-flow-template.xml
• assets/scheduled-flow-template.xml
• assets/platform-event-flow-template.xml
• assets/ai-decision-template.xml
• assets/subflows/

4. Validate against Flow guardrails

Focus on:

• no DML in loops
• no Get Records inside loops
• proper fault paths
• correct trigger conditions
• safe subflow composition
• AI Decision elements not placed inside loops (credit cost per iteration)
• AI Decision prompts include merge field references for data context

5. Hand off deployment and testing

Use:

• sf-deploy for deploy / dry-run
• sf-data for high-volume test data

High-Signal Rules

Flow architecture

• before-save for same-record field updates
• after-save for related records, emails, and callouts
• do not loop over $Record
• use subflows when logic becomes wide or repetitive

Bulk safety

• no DML in loops
• no Get Records in loops
• test with 251+ records when bulk behavior matters
• prefer Transform when the job is shaping data, not per-record branching

Error handling

• every data-changing path should have fault handling
• avoid self-referencing fault connectors
• deploy Flows as Draft first when activation risk is non-trivial

Output Format

When finishing, report in this order:

1. Flow type and goal
2. Files created or updated
3. Architecture choices
4. Bulk/error-handling notes
5. Deploy/testing next steps

Suggested shape:

Flow: <name>
Type: <flow type>
Files: <paths>
Design: <trigger choice, subflows, key decisions>
Risks: <bulk safety, fault paths, dependencies>
Next step: <dry-run deploy, activate, or test>

Flow Testing (CLI)

Run Flow tests from the command line without VS Code:

# Run all flow tests
sf flow run test --target-org <alias> --json

# Run tests for a specific flow
sf flow run test --class-names MyFlow --target-org <alias> --json

# Get results for an asynchronous run
sf flow get test --test-run-id <id> --target-org <alias> --json

Flow tests execute in the org and can take 1-5 minutes. sf flow run test returns a test run ID for asynchronous runs; use sf flow get test to retrieve results later. Always run with --json and use background execution for longer runs.

Cross-Skill Integration

Reference Map

Start here

• references/flow-best-practices.md
• references/flow-quick-reference.md
• references/orchestration.md
• references/testing-guide.md

Design / orchestration

• references/subflow-library.md
• references/governance-checklist.md
• references/transform-vs-loop-guide.md
• references/orchestration-guide.md
• references/orchestration-parent-child.md
• references/orchestration-sequential.md
• references/orchestration-conditional.md

AI Decision

• references/ai-decision-guide.md

Screen / integration / troubleshooting

• references/form-building-guide.md
• references/integration-patterns.md
• references/lwc-integration-guide.md
• references/agentforce-flow-integration.md
• references/xml-gotchas.md
• references/testing-checklist.md
• references/wait-patterns.md
• assets/

Score Guide