Fault paths required
HighReliabilityrecordUpdates element Update_Account has no faultConnector defined.
Why it matters, how to fix it and where the rule comes from: FL-005 in Rules applied
Every flow was checked when it was built, and rarely since. The org has grown, the platform has moved on, and "still working" has been standing in for "still sound". Chalky reads every flow against thirty-six published rules and shows you, with evidence from your own org, which are fine and which are cost waiting to land.
Each rule names the Salesforce documentation or practitioner guidance it comes from, and the rules stay public whether or not you buy anything. A rule we are still testing runs too, marked as beta in the report and left out of the price.
The failures that surface months later: DML with no fault path, queries whose empty result is never checked, update triggers that fire on every save because nothing gates them on a real change.
Queries and actions inside loops, record-triggered flows with no entry criteria running on every save of every record, unfiltered queries that work in a sandbox and fail at real data volumes.
Flows elevated to system context without sharing where nothing justifies it, and credential material sitting in plain sight in assignments, formulas or action inputs.
Hardcoded record Ids and business values, missing descriptions, unreachable elements left behind by an unfinished change, and automation with no way to switch it off during a data load.
Twelve flows were tested against 36 published rules. 94 checks applied, and 18 of them failed. 3 high severity failures sit in the group that causes production incidents: unhandled faults, missing null checks, automation with no entry criteria. A further 11 medium severity findings affect how safely the org can be changed later, and 4 low severity findings are recorded for completeness.
This scan evaluated 12 of the 126 flows found in the org, so every number below describes those 12 and no others.
recordUpdates element Update_Account has no faultConnector defined.
Why it matters, how to fix it and where the rule comes from: FL-005 in Rules applied
Without a fault path, any runtime error produces a generic unhandled exception visible to the end user, and sends no notification to administrators.
Add a fault path to every record and Apex action element, routing to a screen with a message the user can act on, or an email alert for autolaunched flows.
Not "this rule exists". The element, the value, and where it sits, so your admin can open the flow and see the same thing we did.
What breaks if it is left, written in business terms, then the remediation and a link to the published source the rule came from.
A plain-English read of each flow rather than a list of codes, so the report is usable by someone who did not build it.
Flows found, flows evaluated, and any we could not read are all stated. Rules that did not apply are named as such, because a rule that did not apply is not a pass.
Alongside the audit, Chalky counts the clutter: obsolete flow versions, drafts that were never activated, flows with no active version at all, and interviews left paused waiting on something that never came.
On a real org that meant over nine hundred obsolete versions across three hundred flows, and several hundred paused interviews, the oldest by some months. None of it was doing harm that day. All of it was noise between an admin and the flow they needed to change.
Create a minimal integration user in your sandbox, log in once with Salesforce’s own CLI, and paste the connection URL into the connect page. About ten minutes.
Chalky counts the flows and elements in the org and prices the scan from the count. The quote is shown before anything is charged.
Card checkout for the quoted amount.
Every flow is evaluated against all 36 rules, and against anything we have in beta. Most scans finish within the hour; the work is queued, so a busy period can stretch that. You get a link when the report is ready rather than waiting on the page.
The report covers every flow, worst first, with a contents index. Each finding carries the evidence, the impact and the fix.
Nothing is priced per seat or per user. Chalky counts the flows and the elements in them, and the count decides the band. Charities pay half: evidence of Nonprofit Cloud or the Nonprofit Success Pack in the org halves every price, applied automatically at the quote.
40 hours, near enough 5.3 working days, at £95 an hour. Reviewing what is there — not fixing any of it.
That is the price if you unlock the full report within 7 days of the scan, which is what credits the scan fee against it. Miss the window and the two stand separately at £584.
The quote is counted from your own org rather than estimated, and you see it before anything is charged.
On your numbers that is £3,315 of review time you do not spend, and you get the evidence, the impact and the fix written down rather than held in somebody’s head.
A year of Monitor is £1,746. Buying the same scan and report one-off every month for a year would be £5,820, with the scan fee credited each time. Both plus VAT.
Subscriptions are not on the self-serve checkout yet — the one-off scan is. Ask us and we will set one up.
Indicative. The price you pay is counted from your own org, not from the numbers you typed here, and it is shown before anything is charged. All prices exclude VAT. Orgs running the Nonprofit Success Pack or Nonprofit Cloud pay half. 1% of every purchase goes to removing CO₂ from the atmosphere, through Stripe Climate — the checkout states it on the order.
These move on their own. They include the runs we do on our own orgs while building and testing, because the number is what the engine has evaluated, not what we have invoiced.
One connection, one scan of the org, three reports. If you run Revenue Cloud Advanced, the same sandbox connection reads your pricing procedures, decision tables, product catalog and constraint model against twenty-one further checks.
Prices written into procedure logic where nobody managing the catalog can see them. Decision tables answering from whenever they were last refreshed. Tables referenced by live pricing elements and holding no rows at all — which returns a blank, not an error.
Products carrying no description, near-duplicates where an attribute belonged, component relations with nothing bounding them in either the model or the master data, and constraint models not synced since the products beneath them changed.
One connection, one scan of the org, three reports. If you run Agentforce, the same sandbox connection reads your agents, topics, actions, instructions and prompt templates against thirty further checks.
An action pointed at a corpus that is not enabled, or at an object holding no records, returns nothing — and nothing is not an error. The model carries on, answers from whatever else is in context, and is no less fluent for having had no material.
Actions that write, send, refund or cancel, reachable by the planner with no confirmation and no human in the loop. Planners retry and users repeat themselves, so where the action moves money the second run is a second real-world effect.
No. Chalky reads flow metadata and changes nothing, and it points at a sandbox — there is no production option to choose. What the connection can reach is bounded by the user you connect it with, and removing that user’s access in your own Setup ends ours without asking us.
Use it. It is a good open-source plugin, built by developers for developers: it runs from the CLI and the deployment pipeline, and it speaks to the person who builds flows. If your team runs a pipeline, it belongs there. Chalky reports to the people accountable for the org: heads of CRM, architects, analysts and admins. Every flow evaluated to one standard, evidence from your own org against published sources, and the impact on the business written so the reader can act without having built the flow. Nothing to install, no pipeline to build.
Whether automation can be switched off during a data load. Unfiltered Get Records that pass in a sandbox and fail at production volumes. Wait elements and synchronous callouts in record-triggered flows. Error messages a user could actually act on. Decision defaults that were chosen rather than inherited. Last checked against the scanner’s default ruleset on 30 August 2026, when we also adopted one of its checks we had been missing and wrote down why we declined another.
That we believe it and have not yet watched it hold up across enough real orgs to charge for it. It still runs, anything it finds is in your report marked as beta, and it is not in your price — the price is counted from flows and elements, so what we are testing costs you nothing either way. Today that is one rule alongside the thirty-six. We would rather show you what we are working on than quietly bill for it, and if a beta rule is wrong about your org there is a button on the finding to tell us so.
Chalky evaluates every Flow in your org against 36 published rules. Save days of effort and ensure your Flows are fit for purpose on demand.