From Workflows to Flows: Modernizing Your Process Automation

Introduction

This is where the rubber meets the road.

You've cleaned up your org. You've removed unused objects and dead code. You've assessed your readiness for modernization. Now comes the most impactful change most Salesforce organizations will make: migrating from Workflows and Process Builder to Flows.

This isn't just a technical upgrade. It's a shift in how you approach process automation. Workflows and Process Builder feel like configuration—point and click, straightforward, simple. Flows feel like programming—more powerful, more flexible, but also requiring more thought.

That's actually the point. Modern process automation requires intentionality. When you migrate to Flows, you're not just switching tools. You're building better, more maintainable, more powerful automation. You're also creating the foundation for future capabilities you haven't even imagined yet.

This post is a comprehensive guide to making that transition successfully. We'll cover the differences, the migration paths, the common pitfalls, and the governance model that prevents new technical debt from accumulating.

Why Flows Are The Future

Salesforce has been clear for years: Flows are the platform. Workflows and Process Builder still work, but they're deprecated. New developers joining your team may not even know how to read Process Builder. Managed packages are increasingly built on Flows.

More importantly, Flows are better.

The Power of Flows

Visibility and Debugging:

• Process Builder workflows are black boxes. When something goes wrong, you get a cryptic error message
• Flows provide detailed execution logs. You can see exactly where the flow executed, what decisions were made, what actions were taken
• You can debug flows in sandbox with actual test data

Conditional Logic:

• Workflows support only simple field-based triggers
• Process Builder supports more complex conditions, but the UI quickly becomes unwieldy
• Flows support complex nested conditions, loops, and sub-flows. If you can think of it, you can probably build it

Asynchronous Processing:

• Workflows and Process Builder run synchronously, which creates performance issues at scale
• Flows can run asynchronously, improving performance and preventing governor limit issues
• Scheduled flows let you queue actions to run at specific times

Reusability:

• Each workflow or process builder is self-contained
• Flows can be called from other flows (sub-flows), reducing duplication
• You can build a library of reusable flows for common patterns

Version Control:

• Workflows and Process Builder don't play well with source control
• Flows export cleanly to XML, making them suitable for version control and CI/CD pipelines
• You can track changes, do code reviews, and safely manage deployments

Maintainability:

• After 3-4 years, a complex Process Builder is hard for anyone but the original creator to understand
• Flows have clearer visual logic. Someone new to the org can understand the flow by reading it
• Flows encourage documentation (you can annotate flow elements)

A Real Example

Let's imagine you have a Process Builder that:

1. Watches for Opportunities that reach 80% probability
2. Triggers an email to the account executive
3. Creates a task for the account team
4. Updates a custom field to mark the stage
5. If the account is above $1M ARR, also creates a case for customer success

This works in Process Builder, but debugging is hard. When something fails, you're hunting through logs trying to understand where it failed. The UI is crowded with decision trees. If you need to reuse part of this (e.g., the email logic) in another automation, you have to rebuild it.

In Flows, the same automation:

• Runs asynchronously, so it doesn't impact the user's experience
• Has clear visual logic. Anyone can read and understand it
• Has detailed logs showing exactly what happened at each step
• Can reference sub-flows (e.g., a sub-flow that handles "notify opportunity team")
• Can be version controlled and reviewed before deployment
• Can be called from other processes, eliminating duplication

That's a meaningful difference.

Understanding Flow Types

Not all Flows are the same. Each type serves a different purpose. Understanding which type to use is the foundation of good automation design.

Record-Triggered Flows

Purpose: Trigger automation when a record is created or updated

Replaces: Workflow rules and most Process Builder processes

When to use:

• Field updates based on record changes
• Email alerts
• Task creation
• Related record updates
• Data validation beyond formula fields

Example: When an Opportunity closes/won, send email to account executive, create task for account team, update Account renewal date

Scheduled Flows

Purpose: Run automation on a schedule

Replaces: Scheduled workflow rules, batch processes that run on timer

When to use:

• Daily/weekly/monthly batch operations
• Cleanup tasks
• Data reconciliation
• Recurring notifications

Example: Every Monday morning at 9am, send activity summary email to all sales managers

Cloud Flows

Purpose: Flows triggered by external events (API, webhook, or integration)

Replaces: Process Builder triggered by platform events

When to use:

• Integration triggering Salesforce updates
• External systems triggering Salesforce automation
• Webhook-based workflows

Example: When a customer signs up on the website, create Lead in Salesforce via webhook

Screen Flows

Purpose: Interactive flows that guide users through processes

Not replacing anything: This is new functionality. Workflows and Process Builder couldn't do this

When to use:

• Multi-step wizards
• Guided processes
• Forms
• Data entry screens

Example: "Book Demo" flow that captures prospect information and creates Lead + Opportunity

The Migration Decision Tree

Not every Workflow and Process Builder should be migrated to Flows. Some should be retired entirely.

For each Workflow or Process Builder process:

1. Is it active?

→ No: Delete it

→ Yes: Continue

2. Does it actually run?

(Check logs - has it executed in the last 6 months?)

→ No: Delete it

→ Yes: Continue

3. Is it critical to operations?

(Would business be impacted if it failed?)

→ No: Consider deleting or consolidating

→ Yes: Continue

4. Is it simpler than what a Flow would be?

(Single field update triggered by a simple condition)

→ Yes: Consider leaving it OR migrate if you want consistency

→ No: Continue

5. Does it conflict with other automation?

(Could this and another automation create loops?)

→ Yes: Consolidate into a single Flow before deploying

→ No: Continue

6. Migrate to Flow

→ Choose: Record-triggered, Scheduled, or Cloud Flow

→ Build flow

→ Test thoroughly

→ Run in parallel temporarily

→ Deactivate old automation

→ Monitor

→ Delete old automation after 30 days

Migration Playbook: By Workflow Type

Type 1: Simple Field Update Workflows

Example: "When Opportunity Stage = Closed Won, update Account field Active Opportunities Count = Active Opportunities Count - 1"

Difficulty: Very easy Estimated time: 2-3 hours (including testing)

Steps:

1. Create Record-triggered Flow on Opportunity
2. Add trigger: When record is created or updated
3. Add filter: Stage = "Closed Won"
4. Add action: Update record on Account
5. Test with dummy data
6. Deploy to production
7. Run both in parallel for 1 week
8. Deactivate workflow
9. Monitor for 1 week
10. Delete workflow

Testing checklist:

• Create new Opportunity and move to Closed Won - updates correct Account field
• Edit existing Opportunity to Closed Won - updates correct Account field
• Bulk update Opportunities to Closed Won - all updates trigger correctly
• Update Opportunity to different stage - does NOT trigger flow

Type 2: Workflow with Field Updates and Actions

Example: "When Lead Status = Marketing Qualified Lead, send email to Sales Manager AND create task for Sales Rep AND update field Last MQL Date"

Difficulty: Easy Estimated time: 3-5 hours

Steps:

1. Create Record-triggered Flow on Lead
2. Add trigger: When record is created or updated
3. Add filter: Status = "Marketing Qualified Lead"
4. Add action: Send email (to lookup Sales Manager)
5. Add action: Create task
6. Add action: Update record
7. Test thoroughly
8. Deploy to production
9. Run in parallel for 1-2 weeks
10. Deactivate workflow
11. Monitor and delete

Key consideration: In a workflow, you might have multiple separate tasks for different actions. In a Flow, they're all in one visual diagram. This is actually better—it's easier to see all actions at once. But it requires thinking about the automation differently.

Testing checklist:

• Email goes to correct Sales Manager based on Lead assignment
• Task is created with correct description
• Last MQL Date field updates correctly
• Bulk updates trigger for all records
• Existing records with status already = MQL don't trigger (only new changes)

Type 3: Complex Process Builder with Conditions

Example: "When Opportunity probability > 80%, decide:

• If Account annual revenue > $1M: Create case for Customer Success + send email to Exec
• If Account annual revenue < $1M: Just send email to Sales Manager
• Always: Update custom Opportunity field = Current State"

Difficulty: Medium Estimated time: 6-8 hours

Steps:

1. Create Record-triggered Flow on Opportunity
2. Add trigger: When record is created or updated
3. Add filter: Probability > 80%
4. Add Decision element: Check Account annual revenue
5. Branch A (> $1M):
• Get Account details (lookup)
• Create Case
• Send email to Executive
• Update Opportunity field
6. Branch B (< $1M):
• Send email to Sales Manager
• Update Opportunity field
7. Thorough testing in sandbox with realistic data
8. Deploy to production
9. Run in parallel for 2-3 weeks (longer due to complexity)
10. Deactivate Process Builder
11. Monitor for issues before deleting

Key considerations:

• Decision logic is much clearer in Flows than Process Builder
• You can test each branch independently
• Debugging failed executions is infinitely easier

Testing checklist:

• High-value account > 80% probability → creates case + sends email to exec
• Low-value account > 80% probability → sends email to sales manager only
• Custom field updates in all scenarios
• Account lookups resolve correctly
• Emails send to correct recipients
• Edge cases: What if Account doesn't exist? What if Account is null? Test those

Type 4: Scheduled Workflows (Daily/Weekly Tasks)

Example: "Every Monday at 9am, send activity summary email to all Sales Managers"

Replaces: Scheduled workflow rule or scheduled Apex job

Difficulty: Easy to medium Estimated time: 4-6 hours

Steps:

1. Create Scheduled Flow
2. Set schedule: Weekly, Monday, 9:00 AM
3. Add batch retrieval: Get all Sales Managers
4. Add loop: For each Sales Manager
5. Inside loop: Build email content (query their team's activities), send email
6. Test: Run flow manually with test data
7. Deploy to production
8. Monitor execution in logs
9. Deactivate old scheduled workflow
10. Delete old scheduled workflow after confirming new one runs correctly

Key consideration: Scheduled Flows use Salesforce's scheduler (same as scheduled Apex jobs). They can run up to 50 in parallel, but typically you'll only need a few.

Testing checklist:

• Manual run executes correctly
• Scheduled run executes at correct time
• Emails contain correct data
• All Sales Managers receive emails
• If a Sales Manager has no team, handle gracefully

Type 5: Workflow with Outbound Messages (Integration)

Example: "When Contract status = Signed, send HTTP callout to ERP system with contract details"

Difficulty: Medium to hard (depends on API complexity) Estimated time: 8-10 hours

Steps:

1. Create Record-triggered Flow on Contract
2. Add trigger: When record is created or updated
3. Add filter: Status = "Signed"
4. Add action: HTTP Callout
5. Configure:
• URL: Your ERP endpoint
• Method: POST
• Headers: Authentication headers
• Body: JSON with contract data
6. Add error handling: If callout fails, log the error or queue for retry
7. Test in sandbox with mock API
8. Test in production with staging ERP environment if possible
9. Deploy to production with monitoring
10. Run in parallel with outbound message for 2 weeks
11. Deactivate outbound message
12. Monitor callout logs for errors
13. Delete outbound message after confirming no issues

Key consideration: API integrations are critical. Failing silently is bad. Add error handling: If the callout fails, your flow should either retry, log the error, or alert someone.

Testing checklist:

• Callout fires when Contract status = Signed
• Correct data sent to API
• Error handling works (what happens if API is down?)
• Retry logic works (if needed)
• API response is handled correctly

Consolidation: Killing Automation Sprawl

Many organizations have multiple automations doing similar things. Migration is an opportunity to consolidate.

Before consolidation:

• Workflow A: When Opportunity > $10k, send email
• Workflow B: When Opportunity > $50k, send different email + create task
• Process Builder C: When Opportunity > $100k, create case + send alert
• Manual process: VP manually monitors high-value opportunities

Result: Confusing, hard to maintain, inconsistent logic

After consolidation:

• Single Record-triggered Flow on Opportunity:
• If Amount > $100k: Create case, send VP alert, update field
• Else if Amount > $50k: Send director email, create task
• Else if Amount > $10k: Send manager email
• Update "Monitored" field for all
• Complete in one visual flow

Result: Clear logic, easy to maintain, single source of truth

Consolidation process:

1. Identify overlapping automations
2. Document what each one does
3. Design new consolidated Flow
4. Build and test comprehensively (this is complex)
5. Deploy new Flow
6. Run new Flow in parallel with old ones for 2-3 weeks
7. Deactivate old automations
8. Monitor and delete

Governance: Preventing New Technical Debt

Migration is your opportunity to establish better governance.

Flow Governance Framework

Naming Convention

• Format: [Trigger]_[Object]_[Action]
• Examples:
• RecordUpdate_Opportunity_SendHighValueAlert
• Scheduled_Daily_SalesActivitySummary
• CloudFlow_WebhookEvent_CreateLead

Documentation

• Every Flow has a description: "Triggers when Opportunity probability > 80%, notifies Account Executive and creates Customer Success case for deals > $1M ARR"
• Complex Flows have design documents explaining the logic
• Flows are tagged by business area (Sales, Marketing, Success, etc.)

Ownership

• Every Flow has a named owner
• Owners are responsible for:
• Monitoring performance
• Responding to errors
• Updating documentation when changes are made
• Planning deprecation if the Flow is no longer needed

Approval Process

• Significant new Flows require:
• Business justification (what problem are we solving?)
• Impact assessment (will this affect other flows?)
• Design review (is this the best approach?)
• Security review (if handling sensitive data)

Monitoring

• Monthly review of Flow execution logs
• Identification of frequently failing Flows
• Measurement of performance metrics
• Consolidation of redundant Flows

Deprecation

• When a Flow is no longer needed, mark it as "Deprecated - Scheduled for deletion [date]"
• Deactivate the Flow
• Wait 30 days
• Verify no issues, then delete
• Document what replaced it

Common Pitfalls and How to Avoid Them

Pitfall 1: Over-engineered Flows

Problem: You build a Flow that does everything, handles every edge case, and is 50 elements long. It becomes unmaintainable.

Solution:

• Keep individual Flows focused. One Flow should do one thing well
• Use sub-flows to break complex logic into smaller, testable pieces
• If you're documenting complicated logic, break it into simpler flows

Good design: Multiple focused flows called in sequence

Bad design: One massive flow trying to handle everything

Pitfall 2: Missing Error Handling

Problem: Your Flow calls an API. The API fails. Your Flow silently fails, and data gets out of sync.

Solution:

• Every external action (API call, DML) should have error handling
• Options:
• Retry logic: Try the action again if it fails
• Fallback: If the action fails, do something else (e.g., create a task for manual review)
• Logging: Always log failures so you know something went wrong

Example:

HTTP Callout: Send data to ERP

If callout fails:

- Log the error

- Create task for Integration team: "ERP callout failed for Opportunity [ID], check logs"

- Return error to caller

Pitfall 3: Not Testing Edge Cases

Problem: Your Flow works perfectly for the happy path but fails on edge cases:

• What if the lookup field is null?
• What if the value is negative?
• What if there are 10,000 records?

Solution: Test thoroughly:

• Happy path: Normal scenario
• Empty values: What if a lookup field is null?
• Boundary conditions: What if Amount = exactly $50k (the threshold)?
• Bulk operations: Does it work if 10,000 records match?
• Error scenarios: What if the API is down?

Pitfall 4: Ignoring Governor Limits

Problem: Your Flow loops through 10,000 records and makes 5 DML operations each. You hit governor limits.

Solution:

• Be aware of limits:
• 10,000 DML operations per transaction
• 20,000 records in a single query
• 5,000 records per DML operation
• For bulk operations:
• Use batch Flows that process in chunks
• Use async Flows to avoid hitting limits
• Consider traditional Batch Apex if you need to process huge volumes

Pitfall 5: Creating Recursive Loops

Problem: Flow A updates a record, which triggers Flow B, which updates a record, which triggers Flow A again. Infinite loop.

Solution:

• Diagram your automation dependencies
• Use flow control to prevent recursion:
• Track "source" of updates using custom fields
• Only trigger automation for external changes, not internal updates
• Use a "prevent recursion" flag
• Example:

If LastModifiedBy = Automation OR IsRecursionFlag = true:

STOP (don't run automation)

Else:

Set IsRecursionFlag = true

Run automation

Migration Timeline and Phasing

Here's a realistic migration schedule for a typical mid-sized org with 30-50 active Workflows/Process Builder:

Month 1: Discovery and Planning

• Week 1-2: Inventory all Workflows and Process Builder
• Week 3-4: Categorize by complexity and criticality
• Decision: Which to migrate, which to consolidate, which to retire

Month 2-3: Simple Migrations

• Weeks 1-4: Migrate simple field-update workflows
• Weeks 5-8: Migrate simple email/task creation workflows
• All thoroughly tested in sandbox before production deployment

Month 4-5: Complex Migrations

• Weeks 1-4: Design and build complex Flows
• Weeks 5-8: Test extensively, including parallel runs with old automation

Month 6: Cleanup

• Deactivate old Workflows and Process Builder
• Monitor for issues
• Delete after 30-day grace period

Month 7+: Optimization

• Monitor Flows for performance
• Look for consolidation opportunities
• Establish governance processes

Total: 6-7 months for complete migration. Aggressive but achievable.

Real Migration Example: From Start to Finish

Let's walk through a complete migration of a Process Builder process:

Original Process: "When Contract Status = Signed"

1. Update Account field "Last Signed Contract Date"
2. Send email to Account Manager with contract details
3. If contract amount > $100k, create Case for Customer Success
4. If contract company = previously won customer, send special acknowledgment email to VP

Step 1: Design the Flow

• Record-triggered Flow on Contract object
• Trigger: When created or updated
• Filter: Status = "Signed"
• Actions:
  • Yes: Create Case for Customer Success
  • No: Skip
  • Yes: Send VP email
  • No: Send standard Account Manager email
• Get Account record (to check company and send to Account Manager)
• Update Account Last_Signed_Contract_Date
• Decision: Contract Amount > $100k?
• Decision: Is customer in VIP list?

Step 2: Build in Sandbox

• Create the Flow diagram
• Configure each element
• Add error handling for lookups and DML
• Document the logic

Step 3: Test Thoroughly Test scenarios:

• Create new signed contract < $100k: Updates Account, sends Account Manager email
• Create new signed contract > $100k: Updates Account, creates Case, sends Account Manager email
• VIP customer signed contract: Sends VP email instead of Account Manager
• Bulk update 100 contracts to signed: All process correctly
• Edit existing signed contract (change amount): Does it trigger again? (it shouldn't, due to filter—test it)
• Account Manager is null: Flow handles gracefully, logs error
• Case creation fails: Flow catches error, logs it, sends alert

Step 4: Deploy to Production

• Deactivate original Process Builder (but keep it in case)
• Activate new Flow
• Monitor logs

Step 5: Run in Parallel

• Run both old Process Builder and new Flow for 2 weeks
• Compare results: Did the Flow do the same thing?
• Are emails going to the right people?
• Are Cases being created?
• Are there any errors?

Step 6: Cutover

• After 2 weeks of parallel running, if everything looks good:
• Deactivate Process Builder
• Monitor Flow logs for 1 week
• If no issues, delete Process Builder
• Keep Flow active and monitored

Step 7: Optimize

• Month 1: Monitor for performance issues
• Month 2-3: Look for consolidation opportunities (can other Flows call this?)
• Ongoing: Update documentation, refresh if business rules change

Measuring Success

Track these metrics to confirm migration success:

Technical Metrics:

• All automations trigger correctly (compare old vs. new logs)
• No orphaned actions (fields update, emails send, tasks create)
• Error rate is acceptable (< 0.5%)
• Performance is good (no slow executions)

Operational Metrics:

• Time to debug issues: Reduced from hours to minutes
• Maintenance time: Reduced from X hours/month to Y hours/month
• New team member ramp time: Faster because Flows are easier to understand
• Automation consistency: Fewer duplicate/overlapping automations

Business Metrics:

• Adoption of Flows by admins: increasing over time
• New automations built in Flows: not Workflows or Process Builder
• System stability: Fewer unexpected automation errors

Next Steps: Embracing Modern Automation

By completing this migration, your org is ready for the next wave of innovation: reporting modernization, integration architecture evolution, and emerging capabilities like Einstein features.

But you can't do everything at once. Focus on executing this migration well. The discipline and governance you establish here enables everything that follows.

Part 5 will look at the broader modernization landscape: what comes after Flows, and how to build a sustainable culture of continuous improvement.

Reflection

The migration from Workflows and Process Builder to Flows isn't just a technical upgrade. It's a cultural shift toward better automation practices: more deliberate, more testable, more maintainable.

Do you have an old Process Builder that's been running for 5+ years? That's your first migration candidate. Start with it. You'll be surprised at how much clearer Flows make the logic.

Share your migration experiences in the comments. What was hardest? What surprised you? We'd love to hear your stories.