sf-process-builder-migration

Migrates Salesforce Process Builder processes to record-triggered Flows with criteria and action mapping.

2|Updated Sep 12, 2026
One-click install
npx skills add https://github.com/grzmol/vibe-force --skill sf-process-builder-migration-grzmol
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sf-process-builder-migration
Source: https://github.com/grzmol/vibe-force/tree/main/skills/sf-process-builder-migration
Command: npx skills add https://github.com/grzmol/vibe-force --skill sf-process-builder-migration-grzmol

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Salesforce ended support for Process Builder on 31 December 2025, yet many orgs still run active processes that conflict with flows, write the same fields in undefined order, and cannot be safely edited. This Skill guides the inventory, analysis, conversion, and cutover of those processes into record-triggered Flows without loading tens of thousands of tokens of process XML into context. ## Core Features & Use Cases - Inventory and planning: Query FlowDefinitionView to find every active process, then run the vf-process-to-flow.js plan command to get a per-criteria-node work list without reading the raw XML. - Mechanical conversion: Convert qualifying criteria nodes into before-save flows with $Record assignments, while blocked nodes (prior-value references, cross-object formulas, guarded chains) are reported with reasons instead of guessed. - Semantics-safe cutover: Preserve start-of-process value semantics and reevaluation behavior, map scheduled actions to scheduledPaths, and cut over in two deploys so the org never runs both automations or none. - Use Case: An audit finds an active Case triage process fighting a flow over the Priority field. Use this Skill to plan the migration, convert the field-stamping criteria to a before-save flow, rebuild the email alert as an after-save action, and deactivate the process in a second deploy. ## Quick Start Ask the assistant to migrate the active Process Builder process on Case to a record-triggered Flow, starting with an inventory and a conversion plan.

Frequently Asked Questions about sf-process-builder-migration

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I migrate a Process Builder process to a Flow in Salesforce?

Inventory active processes with a FlowDefinitionView query, then run the vf-process-to-flow.js plan command on the retrieved .flow-meta.xml file. Convert qualifying criteria nodes to before-save flows, rebuild after-save actions by hand, validate with deploy validate, and deactivate the process in a second deploy.

Should I use the Migrate to Flow tool or a converter script?

Use the Setup Migrate to Flow tool for whole processes with mixed actions when you want a working after-save flow quickly. Use the converter for criteria nodes that only stamp fields on the triggering record, since it emits cheaper before-save flows as reviewable source files.

Can invocable or event processes be migrated to flows?

No. The Migrate to Flow tool supports only record-triggered processes with processType Workflow. InvocableProcess and CustomEvent types must be rebuilt by hand as subflows, autolaunched flows, or platform event-triggered flows.

Why can't a process formula be copied directly into a flow?

Process formulas reference [Object].Field or myVariable_current.Field, while flow formulas need {!$Record.Field}. Cross-object references in a process formula cannot migrate at all and require a Get Records element plus a rewritten formula.

What happens to scheduled actions during Process Builder migration?

Scheduled actions become scheduledPaths on an after-save flow, but only when you migrate the single criteria node that owns them. The new flow deletes the process's pending actions at run time and re-queues or cancels them based on criteria.

Why is it risky to keep the process active after deploying the flow?

Both automations write the same field in one save with no guaranteed order, producing nondeterministic results. Cut over in two deploys: deploy and activate the flow first, verify behavior on real records, then deactivate the process.