Process Builder and Workflow Rules to Flow
About 25 minute read · 9 steps · Facts checked 21 Oct 2026 · Includes a printable checklist
The honest finding
They still run. Nobody fixes them. Nothing says they run forever.
What Salesforce says
Support ended on 31 December 2025. The tools were not switched off. Salesforce says active ones "continue to run as they did before". It also says the only change is that it "no longer provides customer support or bug fixes". Salesforce itself uses the word "may" about them continuing to work. We found no shut-off date on any Salesforce page we read, and no promise that there will never be one.So the risk is quiet, not loud. A rule that nobody owns keeps changing records. When it breaks, Salesforce support is not there and the bug is not fixed. And it sits on a platform that has moved on to Flow.
What you can and cannot do today
- You can still edit, activate and deactivate the ones you have. Salesforce says so on both help pages.
- You cannot create new ones in a normal org. The Winter '23 release notes block new workflow rules, and the Summer '23 release notes block new processes. Developer orgs are the exception: Salesforce says they still allow creating them to test and build for managed packages.
- Salesforce's own words are mixed. The End of Support article says they were "retired" and, in the same article, that they still run. A planning page still says "pending retirement".
- Salesforce's list of active retirements (updated 16 Oct 2026) does not list either tool. We read the whole table. That is the absence of a date, not a promise.
- Salesforce says the move "may take a significant amount of time and testing", and suggests starting now. It publishes no estimate in hours.
Sources, checked 21 Oct 2026 End of Support article, Workflow Rules help, Process Builder help, release note, new workflow rules blocked, release note, new processes blocked, 2021 Admins plan, Admins blog, Planning your switch, past retirements list, active retirements list
Why a team should care
In one reader survey, admins name tech debt as their biggest challenge. This is the one outside number we use in this guide. The survey is about tech debt in general. It is not about these two tools.
More than half of the admins who answered named tech debt their biggest challenge. Almost none called their org clean.
Say tech debt is their biggest challenge
Say their org is clean and well maintained
Source: Salesforce Ben, 2026 admin survey, 1,134 Salesforce professionals. Checked 21 Oct 2026.
As Salesforce Ben reports them: 56.3% of admins and 2% of respondents. A reader survey about tech debt in general, not about Process Builder or Workflow Rules.
Sources, checked 21 Oct 2026 Salesforce Ben, The State of the Salesforce Admin Role in 2026, Salesforce Ben, survey results
(56.3% and 2%, 3 Jul 2026; 1,134 respondents, 27 May 2026.) We did not check how Salesforce Ben picked its respondents, so read this as "the people who answered", not "all admins".
Step 01
Count what still runs.
You cannot move what you have not counted. Count three things: active processes, active workflow rules, and the flows that already run on the same objects. The Setup lists show names. The queries give you counts, objects and dates for a sheet.
What to do
- Open the Workflow Rules list and the Process Builder list. Sort so the active ones are together.
- Run the queries below. Paste the rows into one sheet: name, tool, object, active, last changed.
- Look at the Flows list and at pending time-based actions. Write down what you see.
Setup path
Workflow Rules:
Process Builder:
Flows:
Pending time-based workflow actions:
Your check
The number of active rules in the Setup list equals the number of rules where Metadata.active is true. The number of active processes in the Setup list equals the rows from query 1. If a count does not match, find out why before you go on.
Good looks like
One sheet. Every active process and rule has a row. Nobody on the team says "I think there is also one on Case".
What can go wrong
- The queries have traps that stop them or hide rows. Read the failure notes below.
- Processes that belong to Marketing Cloud Connect are migrated by Salesforce on its own. Read that notice before you touch them.
- The Tooling API does not return
Metadatafor flows in managed packages, unless they are templates. A packaged process will show no detail.
The queries
We ran these on a developer org on 21 Oct 2026 (API version 68.0). Queries 1 and 5 are normal SOQL. Queries 2, 3, 4 and 6 need the Tooling API. In the Salesforce API a Process Builder process is a flow with ProcessType set to Workflow. Salesforce describes that type as "a process that is invoked when a record is created or edited".
Where to paste them
- The sf CLI. Use the second block below. Add
--use-tooling-apifor Tooling queries. ReplaceMyOrgwith your org alias. - Developer Console. Salesforce says the Query Editor there runs SOQL queries. Use it for queries 1 and 5. Queries 2, 3, 4 and 6 need the Tooling API, so run those with the sf CLI.
The queries as plain SOQL
Query 1. Active Process Builder processes. Normal SOQL.
SELECT Id, ApiName, Label, ProcessType, TriggerType, ActiveVersionId, LastModifiedDate, IsActive FROM FlowDefinitionView WHERE ProcessType = 'Workflow' AND IsActive = true
Query 2. Every version of every process, with its status. Tooling API.
SELECT Id, MasterLabel, DefinitionId, VersionNumber, Status, ProcessType, LastModifiedDate FROM Flow WHERE ProcessType = 'Workflow'
Query 3. Every workflow rule and its object, active or not. Tooling API.
SELECT Id, Name, TableEnumOrId FROM WorkflowRule
Query 4. Is this rule active? One rule per query, using an Id from query 3. Tooling API. Read Metadata.active in the result.
SELECT Id, Metadata FROM WorkflowRule WHERE Id = '01Q000000000000AAA'
Query 5. Active before-save flows already in the org. Normal SOQL.
SELECT COUNT() FROM FlowDefinitionView WHERE ProcessType = 'AutoLaunchedFlow' AND TriggerType = 'RecordBeforeSave' AND IsActive = true
Query 6. The actions workflow rules use. Tooling API. Paste one line at a time.
SELECT Id, Name, SourceTableEnumOrId FROM WorkflowFieldUpdate SELECT Id, DeveloperName, EntityDefinitionId FROM WorkflowAlert SELECT Id, Name, EntityDefinitionId FROM WorkflowOutboundMessage SELECT Id, Subject, EntityDefinitionId FROM WorkflowTask
The same queries in the sf CLI
# 1 sf data query -o MyOrg -q "SELECT Id, ApiName, Label, ProcessType, TriggerType, ActiveVersionId, LastModifiedDate, IsActive FROM FlowDefinitionView WHERE ProcessType = 'Workflow' AND IsActive = true" # 2 sf data query -o MyOrg --use-tooling-api -q "SELECT Id, MasterLabel, DefinitionId, VersionNumber, Status, ProcessType, LastModifiedDate FROM Flow WHERE ProcessType = 'Workflow'" # 3 sf data query -o MyOrg --use-tooling-api -q "SELECT Id, Name, TableEnumOrId FROM WorkflowRule" # 4 (repeat for each rule Id from query 3, then read Metadata.active) sf data query -o MyOrg --use-tooling-api -q "SELECT Id, Metadata FROM WorkflowRule WHERE Id = '01Q000000000000AAA'" # 5 sf data query -o MyOrg -q "SELECT COUNT() FROM FlowDefinitionView WHERE ProcessType = 'AutoLaunchedFlow' AND TriggerType = 'RecordBeforeSave' AND IsActive = true" # 6 sf data query -o MyOrg --use-tooling-api -q "SELECT Id, Name, SourceTableEnumOrId FROM WorkflowFieldUpdate" sf data query -o MyOrg --use-tooling-api -q "SELECT Id, DeveloperName, EntityDefinitionId FROM WorkflowAlert" sf data query -o MyOrg --use-tooling-api -q "SELECT Id, Name, EntityDefinitionId FROM WorkflowOutboundMessage" sf data query -o MyOrg --use-tooling-api -q "SELECT Id, Subject, EntityDefinitionId FROM WorkflowTask"
For query 5, change RecordBeforeSave to RecordAfterSave to count after-save flows. The counts in query 6 are definitions that exist in the org. They do not prove an active rule uses them.
Failure notes
- No GROUP BY on FlowDefinitionView. It fails with "field Id does not support aggregate operator COUNT". Use
COUNT()with a WHERE filter, one query per bucket, or fetch the rows and count them. Grouping did work on the ToolingFlowobject:SELECT ProcessType, Status, COUNT(Id) cnt FROM Flow GROUP BY ProcessType, Status(it counts versions). - Always filter, or add LIMIT 2000. A bare query on FlowDefinitionView can fail with EXCEEDED_ID_LIMIT: "does not support queryMore(), use LIMIT to restrict the results to a single batch". It did in our developer org, which holds thousands of definitions. A large org needs filters such as
ProcessTypeandIsActive. - WorkflowRule has no Active column. The flag lives inside
Metadata, and Salesforce says to query that field only when the result holds no more than one record. So query 4 runs one rule at a time. A cheaper route:sf org list metadata -o MyOrg -m WorkflowRulelists the rule names, andsf project retrieve start -m WorkflowRuleshould give each rule's<active>flag in its XML (we did not run the retrieve). - Versions are not definitions. Query 2 and the Tooling
Flowobject count versions. FlowDefinitionView counts definitions. For plain flows the two numbers can differ in the same org. Report definitions, and say so on the sheet.
Sources, checked 21 Oct 2026 Workflow Rules, Setup path, Process Builder, Setup path, Flows, Setup path, Time-Based Automations, End of Support article, FlowDefinitionView, Tooling API, Flow, Tooling API, WorkflowRule, Marketing Cloud Connect notice, Developer Console Query Editor
Step 02
Catalog by object.
Salesforce's own advice on its planning page is plain: "Organize your automations by Object. Include the Category, Entry Criteria, and Related Actions as you catalog." Do that with the sheet from step 1.
What to do
- Group the sheet by object. One block per object.
- For each item add four things: its category (the kind of work it does: a field update, an email, a task, a call to Apex), its entry criteria (when it starts), its related actions (what it changes), and an owner.
- Add the flows that already run on that object. An object with old and new automation together is where order problems live.
- Add one last column: still needed, yes, no or ask. Write a one-line reason for every "no".
Setup path
Open each item from the same Setup lists as step 1 and read its criteria and actions. The Workflow Rules list and the Process Builder list are where you start.
Your check
For each object, the rows on your sheet add up to the counts from step 1. The sum of all objects equals the total.
Good looks like
One block per object. Every row has an owner, or is marked "no owner". Every "no" has a reason an auditor could read.
What can go wrong
Planning one old item to one new flow. Salesforce says the move "isn't one to one". Plan by object and by behavior, not by item.
How Acme Foods catalogs the Case object
Acme Foods is a made-up food maker. These names, rules and results are invented to show the shape of the sheet. They are not from a real org.
| Item (made up) | Tool | Category | Entry criteria | Related actions | Plan after step 4 |
|---|---|---|---|---|---|
| Case priority on create | Workflow Rule | Field update | Created, Origin is Web | Sets Priority on the same Case | Tool can Only field updates, so a before-save flow |
| Case escalation email | Workflow Rule | Email alert | Edited so Priority is High | Emails the owner's manager | Tool can |
| Case follow-up task | Workflow Rule | Task | Created, Type is Recall | Creates a Task for QA | By hand Create Records on Task |
| Case recall notice | Process | Apex call | Type is Recall | Invokes Apex that notifies the plant | Tool can No extra setup |
| Account last-case date | Process | Related update | Case created | Updates a date on the Account | Check Review by hand after migrating |
| Case SLA reminder | Workflow Rule | Time-based email | Still open after 3 days | Email alert after the wait | Tool can Becomes a scheduled path |
Read it like this: Case has 6 items. The tool can take 4. One needs hand work (the task). One needs a careful look (the related update). Owner and "still needed" are two more columns for Acme's team to fill in. If no other object has fewer items, Case is a good first object.
Sources, checked 21 Oct 2026 Planning your switch, Migrate to Flow considerations, Equivalent features
Step 03
Rank by risk and pick the first object.
Salesforce gives two rules for where to start. First: "Pick the object that has the least number of Workflow Rules and processes associated with it." Second: "Processes that send email alerts or perform same-record field updates are good beginner options for migration."
The risk table below is our rule of thumb, not Salesforce's. Use it to sort the rest.
| If the item... | Risk | So you... |
|---|---|---|
| Only sends an email alert, or only updates fields on its own record | Low | Move it first. Salesforce calls these good beginner options. |
| Uses a time-based or scheduled action, or calls another flow | Medium | Test with realistic dates and records. Time and order matter here. |
| Creates tasks, updates related records, uses related-object criteria, or sits on an object with Apex triggers | High | Plan hand work. Move it last on that object. |
What to do
- Add a risk column to the sheet, using the table above.
- Count the items per object. Sort objects by fewest items, then by lowest risk.
- Pick the first object. Inside each object, move low risk items first.
Setup path
No Setup step. You work on the sheet.
Your check
You can say in one sentence why this object goes first. Example: "Case has 6 items and 4 are low risk."
Good looks like
A numbered list of objects, with the first one small enough to finish and learn from.
What can go wrong
Starting with the busiest object because it hurts most. A first move that fails in front of sales teaches the team to stop. Start where a mistake is cheap.
Sources, checked 21 Oct 2026 Planning your switch
Step 04
Know what Migrate to Flow can and cannot do.
Salesforce's tool will "convert your Process Builder processes and workflow rules into Flow Builder, including scheduled actions". It also supports partial migration of processes for most actions. It does not do everything. Sort your sheet with the picture below before you open the tool.
What to do
- Walk each item on your sheet through Exhibit 2. Write "tool", "partly" or "by hand" in a new column.
- Read the table after the picture. It shows what each old action becomes in Flow.
Setup path
To use it you need Manage Flow for flows, and Customize Application for workflow rules. To activate a process you need Manage Flow, View All Data and Customize Application.
Your check
Every item has a label. The count of "by hand" items is a number you can say out loud.
Good looks like
A short, named list of hand work, each with a note on what to build.
What can go wrong
Reading "the tool supports it" as "it needs no testing". Salesforce warns that "record-triggered flows can behave differently from similar workflow rules". Step 6 covers it.
Does Migrate to Flow handle it? Five questions, from Salesforce's own limits list.
Start with one old process or workflow rule. Ask these five questions in order.
- 1Custom event or invocable process?
- 2Criteria use a related-object field or custom metadata?
- 3Cross-object reference in a formula?
- 4Recursion in the process?
- 5Workflow rule has an item on the cannot-migrate list?
Yes to any question
Build by hand in Flow, or migrate part of it, then finish by hand
Salesforce: the tool supports partial migration of processes for most actions. Recursion is "not fully supported", so expect a partial result.
A workflow rule cannot migrate if it has criteria with no actions, global variable fields, fields on related records, record types, some operators, some formulas, Tasks, relative date values or multiple currencies.
No to all five
Run Migrate to Flow in a sandbox, then test (steps 5 and 6)
Source: Salesforce, "Migrate to Flow Tool Considerations". Checked 21 Oct 2026.
Workflow rules skip questions 1 to 4 and use question 5.
Salesforce says the tool supports only record-triggered processes. For workflow rules it supports field-based criteria, field updates, email alerts, outbound messages and time-dependent actions.
What the old tool did, and what to build in Flow
| The old tool did | In Flow you build | Migrate to Flow | Note from Salesforce |
|---|---|---|---|
| Scheduled actions in a process | A scheduled path in a record-triggered flow | Partly | Migrates only if you select the single criteria that owns the action. They become scheduled paths. |
| Time-dependent workflow actions | A scheduled path | Tool can | Salesforce says: "Use a scheduled path." |
| Invoke Apex | An Apex action | Tool can | No extra setup. |
| Email alert | An Action element | Tool can | No extra setup for processes. Rule email alerts use the Action element. |
| Update the same record | An Update Records element | Tool can | A rule with only field updates becomes a before-save ("fast field update") flow. |
| Update related records | Update Records and Get Records elements | Check | The page says "record update" migrates. It does not say how related-record updates are handled. Criteria on related-object fields are not supported. |
| Invoke another flow | A Subflow element | Partly | It migrates as a subflow, not as an invocable flow action. Callouts and pauses must be redesigned. |
| Invoke another process | No direct tool path | By hand | Salesforce says invocable processes are not supported. The page does not name this action, so check yours. |
| Post to Chatter, quick action, submit for approval, custom notification, live message, surveys, Quip | Flow actions, set up by hand | Partly | They are placed in the flow, but "require additional configuration to function as expected". |
| Outbound message (rule) | An Action element | Tool can | "Use the Action element." |
| Task (rule) | Create Records on the Task object | By hand | Not migrated. Salesforce says to create a record of the Task object. |
Sources, checked 21 Oct 2026 Migrate to Flow tool, Migrate to Flow considerations, Equivalent features, End of Support article
Step 05
Migrate in a sandbox.
Salesforce says: "Before moving your new flows to production, start with migrating and testing in a sandbox environment." Migrate in the same org as the original process, not through a middle org.
What to do
- In the sandbox, open Migrate to Flow and convert the items you labeled "tool" or "partly" for your first object.
- For a process with scheduled actions, select the single criteria that owns the action.
- Build the "by hand" items from your sheet. Use Create Records for a Task.
- Finish the actions that need extra setup, such as a Chatter post or a custom notification.
- Name each flow after what it does. Add a one-line description that points back to the old item.
Setup path
Your check
Open each new flow. Read it against its row on your sheet. Every action on the row appears in the flow, once. Nothing is hard-coded: Salesforce says "Never hard code Salesforce IDs".
Good looks like
A flow for each migrated item, a description on each, and a short list of things you built by hand.
What can go wrong
- Rebuilding by hand in production what you tested in the sandbox. Deploy the flows you tested instead. Salesforce says that by default "active processes and flows are deployed as inactive", so plan to activate them yourself.
- Migrating inside a middle org instead of the org where the process lives.
Sources, checked 21 Oct 2026 Migrate to Flow tool, Planning your switch, Migrate to Flow considerations, Flow best practices
Step 06
Test each flow.
Test the old automation and the new flow on the same records, then compare. Salesforce warns that record-triggered flows can behave differently from similar workflow rules. The reason is where each one runs in the order of execution.
Before-save or after-save
- Before-save flows run "immediately before Apex before triggers". Salesforce says a record-triggered flow can update a record 10 times faster than a record-change process (the page is about before-save flows). Use before-save for field updates on the same record.
- After-save flows are for what needs the saved record: reading its new Id, creating or updating related records, or doing anything beyond updating the record itself.
Where each tool runs
This is the order Salesforce lists, shortened to the parts that matter here.
| Order | What runs |
|---|---|
| 1 | Record-triggered flows set to run before the record is saved (before-save flows) |
| 2 | Apex before triggers |
| 3 | The record is saved (not committed), then Apex after triggers |
| 4 | Workflow rules |
| 5 | Processes built with Process Builder, and flows launched by workflow rules. Not in a guaranteed order. |
| 6 | Record-triggered flows set to run after the record is saved (after-save flows) |
Two things follow. A migrated flow moves to a different place in this list. And after a workflow field update, Salesforce says flows and processes "aren't run again". A process that used to depend on a second pass may now behave differently.
What to do
- Make a short list of test records for the object: one that meets the criteria, one that does not, one edited into the criteria, one edited while already in it, one with blank fields, one owned by a queue, and a small bulk load.
- With the old automation active and the new flow inactive, run the list. Record what changed and what was sent.
- Swap: deactivate the old one, activate the new flow, run fresh copies of the same records.
- Check the flow starts when the old one did: on create only, or on create and edit.
Setup path
Your check
Fill a table with one row per test record: expected result, old result, new result, match yes or no.
Good looks like
Every row matches, or each difference is written down as a decision someone signed.
What can go wrong
- Testing only the easy record.
- Leaving the old automation and the new flow both active during the test, so you cannot tell which one acted.
- An Apex trigger or another flow on the same object that changes the result. Test with them on.
Sources, checked 21 Oct 2026 Before-save flows, Order of execution, Migrate to Flow considerations, Debug Logs
Step 07
Order the flows.
Several flows on one object are fine. Salesforce does not tell you to keep one flow per object: "With this tool, multiple flows per object are manageable." The tool is Flow Trigger Explorer. It "shows all the flows that are associated with a specified object", and it lets you set the order.
What to do
- Open Flow Trigger Explorer for the object.
- Give each flow a trigger order, a number from 1 to 2,000. Salesforce advises spacing the numbers out, for example 10, 20, 30, so you can slot one in later.
- Put field updates that other flows depend on first.
- Write the final order on your sheet.
Setup path
It also opens from inside a record-triggered flow.
Your check
The order shown in the Explorer matches the order on your sheet. Reordering changes the flow's Trigger Order value, so the sheet and the value must agree.
Good looks like
Each active flow on the object has its own trigger order, with gaps between the numbers.
What can go wrong
- You cannot make an after-save flow run before a before-save flow or an Apex trigger.
- Flows made from a flow template do not appear in the Explorer.
- Only flows can be ordered. Processes run "not in a guaranteed order", so Salesforce says to use record-triggered flows if you need control. Salesforce's Admins blog also says to choose one automation tool per object, because mixing Apex triggers, processes and flows can give "unexpected results".
Sources, checked 21 Oct 2026 Flow Trigger Explorer, Release note, Flow Trigger Explorer, Run order of flows, Planning your switch, Admins blog, Flow best practices, Order of execution
Step 08
Switch over, one change at a time.
Switch one pair at a time: one new flow on, its old process or rule off. After each pair, look, and write down what you did.
What to do
- Pick a quiet hour. Tell the people the change touches.
- Look at pending time-based actions and write down what is queued.
- Activate the new flow. If you deployed it, it arrived inactive, so this step is yours.
- Right away, deactivate the old process or rule on the Setup page where you found it.
- Watch the first real record that meets the criteria. Confirm one result, not two.
- Write one line: what, when, who, and how to undo it.
Setup path
Your check
After the switch, one change on a record that meets the criteria gives exactly one set of results: one field update, one email, one task.
Good looks like
The new flow is active, the old item is deactivated (not deleted), and your log has a line for the pair.
What can go wrong
- Both active: the same email goes out twice. Neither active: nothing runs. Keep the gap between the two clicks short.
- The flow was deployed inactive and nobody activated it.
- Permissions. You need Manage Flow to activate a flow, and View All Data and Customize Application as well to activate a process.
The way back
Salesforce says existing workflow rules "continue to run, and you can activate, deactivate, and edit them", and says the same for processes. So the old one can be switched back on. That is why you deactivate it and do not delete it. Keep it deactivated until the new flow has run clean on live records for as long as you decide. This works as Salesforce's pages read on 21 Oct 2026. We found no announced change on those pages, and no promise that there will be none.Sources, checked 21 Oct 2026 Migrate to Flow tool, Workflow Rules help, Process Builder help, Run order of flows, Time-Based Automations, Planning your switch
Step 09
Watch after go-live.
A flow that fails quietly is the same problem you started with. Make failures loud, and make the flow start only when it has to.
What to do
- Add fault paths to every element that can fail. Salesforce: "Modify the default behavior by adding fault paths to all elements that can fail."
- Send an email from each fault path to a named person or a shared inbox. Salesforce recommends configuring fault connectors "so that you always receive an email when a flow fails".
- Set entry conditions. Salesforce says they "prevent automation from running unnecessarily and improve performance".
- Keep database changes out of loops. A Create Records element inside a loop does one database operation per pass.
- Build a report on flow activity. Salesforce points to flow reports and dashboards for this.
Setup path
The Usage tab on a flow in the Automation app shows which orchestrations or approvals use the flow. It does not count how often the flow runs.
Your check
In the sandbox, make one flow fail on purpose, for example with a bad value. Confirm the fault email arrives and names the flow.
Good looks like
Every flow has fault paths and an email. Narrow entry conditions. A first-week review of failures, with a named person.
What can go wrong
- Fault emails go to a person who has left, or to nobody.
- Entry conditions left empty, so the flow runs on every save.
- Looking at the Usage tab for run counts. It does not show them.
Sources, checked 21 Oct 2026 Fault paths, Planning your switch, Bulkification, Flow best practices, Flow Usage tab, Debug Logs
What Clientell AI does for this
Steps 1 to 3 are counting and sorting.
Clientell AI connects to your org, production or sandbox. It lists and maps the old automation it finds, so steps 1 to 3 start from a list and not a blank sheet. For the items you pick, it drafts the fix and shows it to you. Clientell AI asks before it changes anything in production.
The testing, the ordering and the sign-off in steps 5 to 9 stay with your team. They are your calls.
Sources
Salesforce documentation
- Workflow Rules and Process Builder End of Support
- Planning Your Switch to Flow Builder
- Move Processes and Workflows to Flow Builder with the Migrate to Flow Tool
- Migrate to Flow Tool Considerations
- Equivalent Features in Flows and Workflow Rules
- Before-Save Record-Triggered Flows
- Define the Run Order of Record-Triggered Flows for an Object
- Manage Record-Triggered Flows (Flow Trigger Explorer)
- Release note: Block New Workflow Rule Creation
- Release note: New Process Creation Is No Longer Available
- Object Reference: FlowDefinitionView
- Tooling API: WorkflowRule
Last reviewed October 2026.
What next
Print the checklist, then count.
Two A4 pages. Seven groups: count, catalog, rank, migrate in a sandbox, test, switch over, watch. Enter your work email to get it. Then try Clientell AI on your own org free for 14 days. No card.
Guide for Salesforce admin teams. Salesforce facts checked 21 Oct 2026.
Now check the count against your org.
Connect a sandbox or production org and Clientell AI lists your active Process Builder processes and Workflow Rules for you. 14-day free trial, no card.
No card needed