WorkflowRule returns zero rows in the Tooling API

Your migration checklist says "disable workflow rules." Your query returns nothing. Before you conclude the org is clean, work out which of three very different things just happened — because two of them mean automation is still armed.

Salesforce · Workflow Rules · Tooling API · Industries / Vlocity

Do not read zero as "clean"

This is the whole point of the page. A count of zero can mean any of the following, and they demand opposite responses:

A tool that renders all three as "0" is actively dangerous during a migration, because it tells you automation is off when it may be running. If you are writing one, keep the empty case and the error case separate all the way to the UI.

Cause 1: the org migrated, and this is now normal

Salesforce ended support for Workflow Rules and Process Builder on 31 December 2025, with a long-signalled push toward Flow. Existing rules generally keep running, but no new investment is going into them and Salesforce's guidance is to migrate.

The practical consequence for anyone writing migration tooling in 2026: an empty workflow rule result is increasingly the correct answer. Plenty of orgs finished their migration and have genuinely none left. If your checklist still treats "zero workflow rules" as suspicious, the checklist is out of date.

Confirm it the boring way — Setup → Process Automation → Workflow Rules. If Setup shows an empty list too, the org is clean and your query was right.

Cause 2: the query, not the org

A plain query is the right diagnostic. Add no filters at all first:

Then narrow. Two filter mistakes account for most false empties:

• Filtering on Active = true while the rules exist but are already inactive. That is a legitimate zero for "active rules" and a misleading zero for "rules exist."
• Filtering TableEnumOrId by object label rather than API name. It holds the API name for custom objects and an enum for standard ones, so a label-based filter silently matches nothing.

Run the unfiltered version once. If it returns rows, your filter was the problem and you now know exactly which one.

Cause 3: the call failed and you never saw it

This is the one that bites, and it is usually your own code's fault rather than Salesforce's. If the object isn't queryable in that org's configuration, or the composite request was malformed, Salesforce returns a non-200 with a real message — INVALID_TYPE, a malformed query, or an insufficient-access error. Any of these is informative. But a client that wraps the call in a broad try/catch and falls back to an empty array converts a useful error into a confident, wrong zero.

Then render the two states differently: "0 workflow rules" versus "couldn't read workflow rules — reason." The second is honest and lets the user decide.

Why Industries and Vlocity orgs surface this most

Anecdotally this is where the empty-or-erroring result shows up most often. Those orgs carry very large managed packages, a distinct feature mix, and frequently a different automation history from a standard CRM org.

The engineering conclusion is not to special-case the org type. Detecting "is this a Vlocity org" is fragile and will drift. Handle the three outcomes — rows, empty, error — distinctly on every org, and Industries orgs stop being a special case at all.

Frequently asked