sf-flowlisted

<!-- Adapted from Jaganpro/sf-skills@ff1ab74 (MIT). This file layers Brite conventions from brite-salesforce/CLAUDE.md §Engineering Standards (line 41, Apex-first flow policy) + §Apex & Automation (line 189, Screen-Flow-deploy-as-Draft trap). --> # 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-ap