2 openFlow failed: Opportunity_Update, at Update_Owner
since 09:14
Calder WellbeingFull sandbox
Collection failedConnection needs re-authorising. Showing data from 09:00.
checked 09:30
Brightmoor EnergyProduction
API 84% usedDaily API requests: 84,120 of 100,000
collected 09:30
Ashgrove HousingEmail only
Reported by emailFlow failed: Case_Escalation. Not verified through the API.
email at 09:21
Healthy8 more clients, all checks passed at 09:30
Illustration with demo data, not a live screenshot. In the app, a client with a problem is listed first, and every number shows when it was collected.
Runs inside your own Salesforce org
Checks every client every 30 minutes
Flow error emails become incidents in seconds
Read-only access to client orgs
What it watches
The things that break quietly, for every client at once
Each client org is checked every 30 minutes through a read-only connection. Problems open incidents, and repeats add to the same one.
Flow failures
Failed Flow interviews from every client, with the Flow, the element that failed and the error. Route the client's Flow error emails to us as well, and a failure is an incident within seconds instead of at the next check.
By default, Salesforce sends Flow error emails to whoever last edited the Flow. That might be a developer who moved on months ago. Routing them to MultiOrgMonitor means they reach the team.
API and storage limits
Every limit the org reports, with the one closest to its maximum first, so you see the 84% before the integration stops.
Failed logins
Failed attempts in the last 24 hours, by the reason Salesforce gives and by user, so a locked-out integration user stands out.
Apex and Bulk jobs
Batch, queueable, scheduled and future Apex that failed or reported errors in the last 7 days, and Bulk API jobs that failed or finished with failed rows. Never the records themselves.
Security and Setup
The Health Check score and its high-risk settings, Setup changes in the last 7 days, scheduled jobs, licence use, and locked or inactive users.
Set up once per client, then work incidents, not inboxes
1
Install the app in your own org
A managed package in your consultancy's Salesforce org. Collection, incidents and alerts all run there, under your own security settings.
2
Connect each client
The client admin approves once with their own login, and the app does the setup after listing every change. Prefer not to? Use the script or a Setup checklist. Or skip the connection and just route Flow error emails.
3
Get one incident, not twenty emails
Repeats group into one incident you can acknowledge and resolve. A single failed check doesn't alert anyone. Consultants see the clients assigned to them, and managers see every client.
Honest by design
It tells you what it knows, and how it knows it
Every number has a time
"Collected 4 minutes ago" sits next to the data. When a check fails, you see that in amber, never old data dressed up as healthy.
Observed, not guessed
What Salesforce reported is kept apart from what we infer. An email report stays labelled "Reported by email" until the API confirms it.
Always the right org
If a sandbox refresh changes a client's org ID, collection stops for that client until a manager accepts the new org. You never see another org's data by mistake.
Security
Monitoring runs in your org, not ours
Client data never leaves Salesforce. It goes from your clients' orgs to yours, and not to us or anyone we use.
Flow error emails are the one route that isn't an API call: they travel between Salesforce's mail servers over TLS. Salesforce doesn't say whether they stay on its own network, so the security overview covers that route on its own.
For Flow errors only, no. The client admin makes two Setup changes so that Flow error emails come to you.
For full monitoring, the client org needs an integration user and a small connector app. The client admin can approve once with their own login, and the app sets everything up and lists each change first. A script and a Setup checklist do the same for admins who prefer them.
How much of a client's API allowance does it use?
About 10 API requests per client environment every 30 minutes, which is under 500 a day. When Bulk API jobs have finished since the last check, it reads up to 3 of them for failed rows, at one request each. Flow errors only uses none.
Is it on AppExchange?
Not yet. We're selling directly while we work with pilot consultancies. Salesforce shows a warning when you install a package that hasn't been through its review. The security overview explains what the package does and how to check it yourself.
What happens to our data if we stop?
It's in your Salesforce org, not ours, so it stays yours. Removing a client deletes its monitoring data straight away. Uninstalling the package removes the rest.
Find the next broken Flow before your client does
A 14-day trial covers full monitoring for up to 5 client environments, plus 10 on Flow errors only.