All 23 fixes, in the order we would do them
1 integration user will stop connecting unless updated. Salesforce blocks SOAP login() without the Use Any API Auth permission from 1 December 2026.
- What to do
- Assign Use Any API Auth to each integration user whose license allows it, through a permission set, before 1 December 2026. Then run Salesforce's test in Release Updates: it applies the rule to the whole org, so start it only after every integration user holds the permission.
- Check it yourself
- Setup, Login History, create a view with Login Type equals Other Apex API or Partner Product and add the Login Subtype and API Version columns. Then open Setup, Release Updates, and read "Assign Use Any API Auth Permission for SOAP login()" to see what it changes. Run its test in a sandbox first; in production it applies to the whole org.
- Who can do it
- Your admin
| User ID | Logins | Last seen | API versions | Application |
|---|
| 005000000000005 | 2100 | 2026-09-14 | 58.0 | N/A |
1 integration user still logs in this way. Salesforce retires this login method on 20 February 2027.
- What to do
- Move server-to-server jobs to the client credentials flow, and apps that people sign in to onto the web server flow with PKCE. For apps you did not build, ask the vendor for a version that no longer uses this flow.
- Check it yourself
- Setup, Login History, create a view with Login Type equals Remote Access 2.0 and add the Login Subtype and API Version columns. Then open Setup, Release Updates, and read "Retirement of OAuth 2.0 Username-Password Flow for Connected Apps" to see what it changes. Run its test in a sandbox first; in production it applies to the whole org.
- Who can do it
- Your admin, with the app's developer
| User ID | Logins | Last seen | API versions | Application |
|---|
| 005000000000007 | 300 | 2026-09-13 | N/A | Acme Billing Sync |
1 integration user on API version 58.0. Salesforce retires SOAP login() on API 31.0 to 64.0 in Summer '27, and later API versions do not offer it.
- What to do
- Move each integration to sign in through an external client app, as Salesforce asks, or confirm the vendor has a build that does. The Release Updates test switches off SOAP login() for the whole org, so try it in a sandbox, not production.
- Check it yourself
- Setup, Login History, create a view with Login Type equals Other Apex API or Partner Product and add the Login Subtype and API Version columns. Rows with an API Version from 31.0 to 64.0 are the ones Salesforce retires.
- Who can do it
- The integration's developer or vendor
| User ID | Logins | Last seen | API versions | Application |
|---|
| 005000000000005 | 2100 | 2026-09-14 | 58.0 | N/A |
3 outside apps can reach your data. 2 not used since 19 Mar 2026, 1 never approved by an admin. Stored app access was the route in the 2025 Salesloft Drift incident.
- What to do
- For apps still in use, install the app, give its users access through a permission set, and only then set it to admin-approved users; switching before that cuts everyone off. For idle apps, confirm with each app's business owner, then revoke their tokens rather than blocking the app, because some integrations run only once a quarter or once a year.
- Check it yourself
- Setup, Quick Find "OAuth", Connected Apps OAuth Usage. Count the rows. An Install button in the Action column means no admin ever installed that app. Click the User Count number to see last-used dates.
- Who can do it
- Your admin, with each app's business owner
| App | Type | Installed | Users | Last used | Use count |
|---|
| Mailer Pro | Third-party | Yes | 1 | Not recorded | 0 |
| Workbench | Third-party | Yes | 1 | 2024-07-25 | 1 |
| Acme Billing Sync | Third-party | No | 2 | 2025-01-10 | 432 |
| Salesforce CLI | Salesforce | No | 1 | 2026-09-14 | 186 |
8 admin-level users, and passkeys are switched off. Salesforce has required a passkey of admin-level users since 20 July 2026, and blocks direct password logins without one.
- What to do
- In Setup, Identity Verification, allow users to verify their identity with a physical security key and with a built-in authenticator. Ask each admin-level user to register one in Personal Settings, Advanced User Details, plus a second as a backup, and agree how an admin gets back in if one is lost. Where admins sign in through single sign-on, also confirm with your IT team that the identity provider tells Salesforce when a passkey was used.
- Check it yourself
- Setup, Identity Verification: look for the settings that let users verify their identity with a physical security key and with a built-in authenticator.
- Who can do it
- Your admin, with your IT team
| User ID | Admin-level permissions | Profile | Permission sets | API only |
|---|
| 005000000000A01 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
| 005000000000A02 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
| 005000000000A03 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
| 005000000000A04 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
| 005000000000A05 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
Plus 3 more rows, listed in the appendix.Plus 3 more rows in the full report, available from partners@meethemind.com.
2 guest profiles on 2 public sites. 1 can read people's records. 1 has API access on. Salesforce's March 2026 security advisory warns that attackers target permissive guest settings.
- What to do
- In each guest profile listed, switch off API Enabled and remove read and create access on every object the site does not need. Then check the guest sharing rules on contacts, leads and accounts, and the other settings Salesforce's advisory lists, such as self-registration and user visibility.
- Check it yourself
- Setup, Sites, or Digital Experiences, All Sites: open a site and its Public Access Settings to see the guest profile's object access and API Enabled.
- Who can do it
- Your admin, with each site's owner
| Guest profile | API access | Can read | Can create |
|---|
| Admissions Site Profile | On | Lead, Contact, Application__c | Lead, Application__c |
| Events Site Profile | Off | Campaign, Event_Registration__c | Event_Registration__c |
4 people hold automation together, and 1 of those logins is already switched off. When one of them is deactivated, the alerts, queues, dashboards and jobs attached to them stop, with no error.
- What to do
- Do this before the next person leaves, not after. Address alerts and tasks to a queue or public group rather than a person, add a second member to any queue or group that has one, move dashboards onto a running user who will stay, and reschedule jobs under an integration user. Anything listed against a login that is already switched off has stopped, so it needs a new owner now or deleting.
- Check it yourself
- Setup, Email Alerts: open one and look at its recipients. Setup, Queues shows each queue's members, and Setup, Scheduled Jobs shows who scheduled each job.
- Who can do it
- Your admin, with each team lead
| User ID | Alerts and tasks | Only member of | Dashboards | Scheduled jobs | Login |
|---|
| 005Nw00000RegistrarB | 1 | 1 | 0 | 1 | Switched off |
| 005Nw00000RegistrarA | 4 | 1 | 2 | 1 | Active |
| 005Nw00000FinanceC | 1 | 0 | 1 | 0 | Active |
| 005Nw00000ITSupportD | 0 | 0 | 0 | 1 | Active |
5 settings below Salesforce's standard, 2 of them high risk. Scored 58 of 100, which Salesforce rates Poor.
- What to do
- Change the high-risk settings first, then the medium ones, and re-open Health Check to confirm the score moved. Try the ones that can break pages or lock people out in a sandbox first: login attempts.
- Check it yourself
- Setup, Health Check. Read the score, the grade next to it and the High Risk section.
- Who can do it
- Your admin
| Setting | Your value | Standard | Risk |
|---|
| Lock sessions to the domain in which they were first used | Disabled | Enabled | High |
| Minimum password length | 8 | 12 | High |
| Let users verify their identity by text (SMS) | Enabled | Disabled | Medium |
| Maximum invalid login attempts | 10 | 5 | Medium |
| Obscure secret answer for password resets | Disabled | Enabled | Low |
1 user logged in this way in 6 months. Salesforce restricts this login method from 30 November 2026.
- What to do
- Confirm each app still needs the device flow and review the release update in Setup.
- Check it yourself
- Setup, Login History, create a view with Login Type equals Remote Access 2.0 and add the Login Subtype and API Version columns. Then open Setup, Release Updates, and find the one for the OAuth device flow to see what it changes. Run its test in a sandbox first; in production it applies to the whole org.
- Who can do it
- Your admin
| User ID | Logins | Last seen | API versions | Application |
|---|
| 005000000000008 | 14 | 2026-08-30 | N/A | Kiosk App |
1 user still logs in this way. Salesforce retires these login methods on 20 February 2027.
- What to do
- Ask each app's developer to move it to the web server flow with PKCE. Where the app is one of Salesforce's own mobile apps, make sure people use the latest version; there is nothing to change in Setup.
- Check it yourself
- Setup, Login History, create a view with Login Type equals Remote Access 2.0 and add the Login Subtype and API Version columns. Then open Setup, Release Updates, and find the one for the OAuth user-agent and hybrid flows to see what it changes. Run its test in a sandbox first; in production it applies to the whole org.
- Who can do it
- Each app's developer; for Salesforce's own apps, the people using them
| User ID | Logins | Last seen | API versions | Application |
|---|
| 005000000000009 | 5 | 2026-07-01 | N/A | Legacy Portal |
3 connected apps you built to migrate, 1 with no sign of use. 1 app for its publisher to move. 3 apps on a sign-in that stops sooner. Salesforce stops supporting connected apps in Summer '27, and switches off password and user-agent sign-in on 20 February 2027.
- What to do
- Work down the table from the earliest date. Move the apps that stop sooner off password, user-agent and device sign-in first. Then migrate the connected apps you built with the Migrate button, deleting the ones with no sign of use instead, and ask each publisher for their plan. Local External Client Apps are not copied to sandboxes on refresh, so recreate them after each refresh, or package them.
- Check it yourself
- Setup, App Manager: a connected app you can move shows Migrate to External Client App in its row menu. Setup, Release Updates lists "Migrate All Connected Apps to External Client Apps" with its date.
- Who can do it
- Your admin, with each app's owner or publisher
| App | Whose | Sign-in seen | Users | Last used | First date | What to do |
|---|
| Kiosk App | Another org's | Device | 1 | 30 Aug 2026 | Stops 30 Nov 2026 | Ask its owner now |
| Acme Billing Sync | Yours | Password | 3 | 13 Sep 2026 | Stops 20 Feb 2027 | Move off this sign-in, then migrate |
| Legacy Portal | Yours | User-agent | 1 | 1 Jul 2026 | Stops 20 Feb 2027 | Move off this sign-in, then migrate |
| Alumni Survey Connector | Yours | None in 6 months | 0 | | Support ends Summer '27 | No sign of use: delete, or migrate if needed |
| Mailer Pro | Packaged | None in 6 months | 1 | | Support ends Summer '27 | Ask the publisher for their plan |
Plus 2 more rows, listed in the appendix.Plus 2 more rows in the full report, available from partners@meethemind.com.
1 of 4 managed packages shows no sign of use. 3 package seats sit on deactivated users. Packages nobody uses still add code, objects and sometimes paid seats.
- What to do
- Check whether each package still holds data: Setup, Storage Usage shows storage by object. For packages nobody uses, take back their seats, revoke their app access and hide them from users. Uninstall only after the owner confirms the data is not needed, the data is exported and kept outside Salesforce, and the uninstall has been tested in a sandbox, because uninstalling permanently deletes the package's objects and data.
- Check it yourself
- Setup, Storage Usage shows how much data each object holds; objects whose names start with the package's namespace prefix belong to it. Then Setup, Installed Packages, open the package and choose View Components, and check Apex Jobs and Scheduled Jobs for the same prefix.
- Who can do it
- Your admin, with the business owner
| Package | Seats on active users | Seats on deactivated users | License | Signs of use |
|---|
| Old Survey Tool | 0 | 0 | Free | None found |
| Seat Tool | 2 | 3 | Active | seats |
2 of 3 background automations have steps with no error handling. When these fail, the change can roll back with only a generic error.
- What to do
- In each flow listed, add a fault path to every element that lacks one, and have it log the error and notify an admin.
- Check it yourself
- Open any flow listed below, click an Update Records or Create Records element, and look for a red Fault connector. No connector means no fault path.
- Who can do it
- A Salesforce developer or an experienced admin
| Flow | Trigger | Elements without a fault path |
|---|
| Nightly_Cleanup | Scheduled | 1 |
| Opportunity_After_Save | Record change, after save | 3 |
9 paid users with no login in 90 days. About $18,900 to $21,060 a year at list price.
- What to do
- Confirm each user with their manager, and check they do not own scheduled reports or jobs, run a flow or integration, or sit in an approval step. Freeze them first, which can be undone, then deactivate and reassign the license before your renewal date.
- Check it yourself
- Setup, Users. Create a list view with Active equals True and Last Login before a date 90 days ago, then a second view for a blank Last Login. Compare with Setup, Company Information, User Licenses.
- Who can do it
- Your admin, with each manager
| License | Idle users |
|---|
| Salesforce | 9 |
| Salesforce Platform | 2 |
9 users (23% of active internal users) hold admin-level permissions. Salesforce requires a passkey of each admin who signs in, and AI assistants act with the permissions of the person using them.
- What to do
- Review the list with each user's manager. Remove admin-level permissions nobody needs day to day, starting with View All Data on profiles that are not for admins. Grant what remains through permission sets rather than profiles, with an expiry date where the need is temporary, and keep integration users to the permissions each integration uses.
- Check it yourself
- Setup, Permission Sets and Profiles: open each one named below and check its System Permissions for Modify All Data, View All Data, Customize Application and Author Apex.
- Who can do it
- Your admin, with each user's manager
| User ID | Admin-level permissions | Profile | Permission sets | API only |
|---|
| 005000000000A06 | View All Data | Admissions Manager | | No |
| 005000000000A07 | View All Data | Admissions Manager | | No |
| 005000000000A08 | Customize Application | Standard User | Report Builder | No |
| 005000000000A09 | View All Data | Integration Profile | | Yes |
| 005000000000A01 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
Plus 4 more rows, listed in the appendix.Plus 4 more rows in the full report, available from partners@meethemind.com.
3 active rules on 3 objects. Salesforce stopped fixing bugs in Workflow Rules on 31 December 2025.
- What to do
- Rebuild each active rule as a record-triggered flow, starting with the ones that send outbound messages or use time triggers. Salesforce's Migrate to Flow tool in Setup converts many simple rules. Before deactivating a rule with time triggers, check Setup, Time-Based Workflow for actions still queued.
- Check it yourself
- Setup, Workflow Rules, sort by Active and count.
- Who can do it
- A Salesforce developer or an experienced admin
| Object | Rule | Time triggers | Actions |
|---|
| Account | Set Account Tier | 0 | Field update |
| Contact | Sync Flag | 0 | Outbound message |
| Opportunity | Closed Won Alert | 1 | Email alert, Task |
2 automations with problems the scanner rates as errors. Updates and queries inside loops fail as data grows.
- What to do
- Move record updates and queries out of loops first, since they hit Salesforce limits as data grows. Replace record IDs and web addresses typed into flows with custom metadata, custom labels or a Get Records lookup.
- Check it yourself
- Setup, Flows: open each flow listed and look for record IDs or web addresses typed straight into its elements, and for Create, Update or Get Records elements inside a Loop.
- Who can do it
- A Salesforce developer
| Flow | Problems |
|---|
| Nightly_Cleanup | DML inside a loop |
| Opportunity_After_Save | hardcoded record IDs |
Of 4 managed packages, 1 runs a deprecated version and 1 has not been upgraded in over 5 years. Publishers no longer support deprecated versions, and a managed package upgrade cannot be rolled back.
- What to do
- Upgrade deprecated packages in a full sandbox first, after reading the publisher's release notes, because a managed package upgrade cannot be rolled back. For packages that have not changed in years, ask each publisher whether a newer version exists.
- Check it yourself
- Setup, Installed Packages. Note each package's Version Number and Install Date, then compare with the version on the publisher's AppExchange listing or release notes.
- Who can do it
- Your admin, with each publisher
| Package | Version | Why listed | Installed |
|---|
| Old Survey Tool | 2.4.0.1 | Deprecated | 2014 |
| Legacy Docs | 1.0.0.3 | Never upgraded | 2016 |
Free up data storage before it runs out
Data storage is 88% full
0.9 of 1.0 GB of data storage in use. Extra storage is a paid add-on.
- What to do
- See which objects use the most space in Setup, Storage Usage. Archive or delete old records nobody needs, check that no automation or integration creates records in bulk, and plan for extra storage if the org keeps growing.
- Check it yourself
- Setup, Storage Usage: compare Used with Limit, and read which objects use the most.
- Who can do it
- Your admin, with the data's owners
2 active processes built in your org. Salesforce stopped fixing bugs in Process Builder on 31 December 2025.
- What to do
- Rebuild each process as a record-triggered flow and deactivate the process in the same deployment.
- Check it yourself
- Setup, Process Builder, sort by Status and count the Active rows. 1 of them belong to installed packages.
- Who can do it
- A Salesforce developer or an experienced admin
| Process |
|---|
| Case_Escalation |
| Opportunity_Stage_Updates |
3 updates past their due date. 3 more due in Spring '27 and Summer '27. Salesforce can switch them on with a coming release, and some change how code behaves.
- What to do
- Open each overdue update in Setup, Release Updates, read what it changes, and run its test in a sandbox. Turn it on in production once the sandbox shows no problems, oldest first, then do the same for the ones due next. Some need a developer, because they change how Apex, Aura or Visualforce code behaves.
- Check it yourself
- Setup, Release Updates: each update shows its due date and whether it is complete.
- Who can do it
- Your admin, with a developer for code changes
| Release Update | Release | State |
|---|
| Restrict User Access to Run Flows | Winter '26 | Overdue |
| Enable Profile Filtering | Winter '27 | Overdue |
| Update Instanced URLs in API Traffic | Winter '27 | Overdue |
| Update Apex Code and Flows for Changed Sharing Recalculation Behavior | Spring '27 | Due |
| Conceal Personal Information Fields from Guest Users | Spring '27 | Due |
Plus 1 more row, listed in the appendix.Plus 1 more row in the full report, available from partners@meethemind.com.
1 of 4 managed packages is not marked as having passed the AppExchange security review. The flag is also false for some Salesforce and private packages, so this is a prompt to confirm who built each one.
- What to do
- Confirm the publisher of each package and that it is still needed, and prefer a security-reviewed version where the publisher offers one.
- Check it yourself
- Setup, View Setup Audit Trail, and look for entries saying a managed package that has not been security reviewed was installed.
- Who can do it
- Your admin
| Package | Version |
|---|
| Legacy Docs | 1.0.0.3 |
Decide what AI agents may see and do
1 AI agent is active
Generative AI is on. 2 agents, 1 active. 3 users can build agents. Agents act with a user's permissions, and Salesforce is switching the Agentforce platform on for eligible orgs.
- What to do
- Agree who may build and switch on agents, and keep that group small. Give each agent user only the objects and fields its agent needs, never admin-level permissions. Cut back admin-level permissions before assistants reach everyone, because an assistant can reach whatever its user can.
- Check it yourself
- Setup, Einstein Setup: see whether generative AI is on. Then Setup, Agentforce Agents: open each agent and see which user it runs as.
- Who can do it
- Your admin, with whoever owns your AI plans
| Agent | Type | Active |
|---|
| Student Help Agent | Service agent | Yes |
| Staff Assistant | Employee agent | No |
The steps for each Medium and Low fix, what each check read, what it cannot tell you, and the full lists are in the full report, available from partners@meethemind.com.
Appendix: how this check worked
We read metadata and setup data only: automation definitions, the apps that can sign in and how, sign-in history grouped by user ID, who holds admin-level permissions, security and AI settings, AI agent setup, Release Updates, what public site guests can reach, what depends on one person, installed packages, license and storage counts, Health Check settings and org limits. We also read the name, username, email address, user ID and time zone of the person who approved this check, and the company details on Company Information, so we can send this report and follow up. We did not query any customer record, token value, or any other user's name or email address. We revoked our access token at 10:01 UTC on 15 September 2026, and Salesforce confirmed it (HTTP 200).
Every finding below names what we read and what it cannot tell you, so you can judge it yourself or hand it to whoever does your Salesforce work.
1. Give integrations the permission they need to keep logging in
Integrations that need Use Any API Auth by 1 December 2026 · Salesforce date: 1 Dec 2026 · Source
We found 1 integration user that signed in with the SOAP API login() call in the last six months without holding the Use Any API Auth permission. Salesforce requires that permission for SOAP login() in every org from 1 December 2026.
What we read. Login type, login subtype, API type, API version, application and status from Login History for the last six months, grouped by Salesforce user ID. We did not read user names or emails.
What this check cannot tell you. We only see six months of Login History, so an integration that runs less often is invisible. SOAP logins show the application as N/A by design, so we can name a user ID and an API version but not the product.
| User ID | Logins | Last seen | API versions | Application |
|---|
| 005000000000005 | 2100 | 2026-09-14 | 58.0 | N/A |
2. Move integrations off password-based login
Connected apps using the OAuth username-password flow · Salesforce date: 20 Feb 2027 · Source
We found 1 user signing in through the OAuth username-password flow, from Acme Billing Sync. Salesforce retires that flow for connected apps on 20 February 2027.
What we read. Login type, login subtype, API type, API version, application and status from Login History for the last six months, grouped by Salesforce user ID. We did not read user names or emails.
What this check cannot tell you. We only see six months of Login History, so an integration that runs less often is invisible. We see which app signed in and as which user ID, not who owns the app or what it does.
| User ID | Logins | Last seen | API versions | Application |
|---|
| 005000000000007 | 300 | 2026-09-13 | N/A | Acme Billing Sync |
3. Move SOAP integrations off login() before Summer '27
Integrations on SOAP login() versions Salesforce retires in Summer '27 · Salesforce date: Summer '27 · Source
We found 1 integration user signing in with SOAP login() on API version 58.0. Salesforce retires SOAP login() on API versions 31.0 to 64.0 in Summer '27, and later API versions do not offer it.
What we read. Login type, login subtype, API type, API version, application and status from Login History for the last six months, grouped by Salesforce user ID. We did not read user names or emails.
What this check cannot tell you. We only see six months of Login History, so an integration that runs less often is invisible. SOAP logins show the application as N/A by design, so we can name a user ID and an API version but not the product.
| User ID | Logins | Last seen | API versions | Application |
|---|
| 005000000000005 | 2100 | 2026-09-14 | 58.0 | N/A |
4. Review outside apps that can access your Salesforce
Connected apps holding OAuth tokens
We found 4 connected apps holding OAuth tokens in this org, used by 4 distinct users: 3 third-party apps and 1 of Salesforce's own. 2 third-party apps have not been used by anyone since before 19 March 2026. 1 was authorized by a user and never installed by an admin, so no admin has reviewed it. Salesforce's own apps are marked Salesforce in the list and are not counted as idle or unapproved.
What we read. App name, installed state, last-used date, use count and user ID on OauthToken, aggregated per app. We did not read token values, user names or emails.
What this check cannot tell you. A blank last-used date means Salesforce did not record one, not that the app was never used. We cannot tell whether a token still works, only when it was last used. Integrations that sign in with SOAP login() or a password flow hold no tokens like these; we check them separately in Login History. We list an app as Salesforce's own only when its name exactly matches one of Salesforce's apps.
| App | Type | Installed | Users | Last used | Use count |
|---|
| Mailer Pro | Third-party | Yes | 1 | Not recorded | 0 |
| Workbench | Third-party | Yes | 1 | 2024-07-25 | 1 |
| Acme Billing Sync | Third-party | No | 2 | 2025-01-10 | 432 |
| Salesforce CLI | Salesforce | No | 1 | 2026-09-14 | 186 |
5. Switch on passkeys for admins
Passkeys are switched off for the admins who now need them · Salesforce date: in force since 20 Jul 2026 · Source
Salesforce now requires users with admin-level permissions to verify their identity with a passkey: a security key, or a built-in authenticator such as Touch ID or Windows Hello. Since July 2026, anyone who logs in directly with a Salesforce password is blocked until they register one, and people who sign in through single sign-on meet it through their identity provider. Both kinds of passkey are switched off in this org's Identity Verification settings, so nobody can register one in Salesforce, and we found 8 active users with admin-level permissions who sign in to Salesforce. 1 more is an API-only integration user, which this rule does not cover.
What we read. Which active internal users hold Modify All Data, View All Data, Customize Application or Author Apex, and the profile or permission set that grants it, by Salesforce user ID. We did not read user names or emails. From the Security settings, whether security keys and built-in authenticators are allowed.
What this check cannot tell you. We cannot see which sign-in methods each person has registered, or whether they sign in through single sign-on, so we cannot tell who is blocked today and who only sees reminders.
| User ID | Admin-level permissions | Profile | Permission sets | API only |
|---|
| 005000000000A01 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
| 005000000000A02 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
| 005000000000A03 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
| 005000000000A04 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
| 005000000000A05 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
| 005000000000A06 | View All Data | Admissions Manager | | No |
| 005000000000A07 | View All Data | Admissions Manager | | No |
| 005000000000A08 | Customize Application | Standard User | Report Builder | No |
6. Limit what visitors to your public sites can reach
Visitors without a login can reach records through 2 public sites
We found 2 active public sites with 2 guest profiles, the access a visitor gets without logging in. 1 profile can read Lead and Contact records. 2 profiles can create records. 1 profile has API access switched on, which Salesforce's March 2026 security advisory says to turn off. Visitors only see existing records that a guest sharing rule shares with them, so these settings are the upper limit of what they can reach, not proof that data is exposed.
What we read. Active public sites, the profiles of active guest users, and each guest profile's object read and create access and API Enabled permission. Salesforce's advisory: https://status.salesforce.com/generalmessages/20000244.
What this check cannot tell you. We read profile permissions, not guest sharing rules or field-level security, so we cannot tell which records a visitor can actually see.
| Guest profile | API access | Can read | Can create |
|---|
| Admissions Site Profile | On | Lead, Contact, Application__c | Lead, Application__c |
| Events Site Profile | Off | Campaign, Event_Registration__c | Event_Registration__c |
7. Take individual people out of the middle of your automation
1 person whose login is switched off is still wired into automation
We found 4 people that automation runs through: alerts and tasks addressed to them by name, queues or groups where they are the only member, dashboards that refresh as them, and jobs they scheduled. Deactivating one of them stops those quietly, with no error and no warning to anyone. 1 of them has already been switched off, so whatever is listed against that name has stopped working. 4 alerts also send to an email address typed into the alert, which belongs to nobody in Salesforce and is worth checking at the same time.
What we read. Email alert and task recipients from the Workflow metadata, queue and public group membership, the running user of each dashboard, and the owner of each scheduled job. Recipients are named by username in the metadata, so we matched them to Salesforce user IDs while the scan ran and kept the IDs, never the usernames.
What this check cannot tell you. We do not see user IDs written into Apex, flow assignments, approval steps or managed packages, so this is what can be read from setup data, not the whole list.
| User ID | Alerts and tasks | Only member of | Dashboards | Scheduled jobs | Login |
|---|
| 005Nw00000RegistrarB | 1 | 1 | 0 | 1 | Switched off |
| 005Nw00000RegistrarA | 4 | 1 | 2 | 1 | Active |
| 005Nw00000FinanceC | 1 | 0 | 1 | 0 | Active |
| 005Nw00000ITSupportD | 0 | 0 | 0 | 1 | Active |
8. Raise your Security Health Check score
Security Health Check settings below Salesforce's standard
We found a Security Health Check score of 58, which Salesforce's grade table labels Poor. 5 settings do not meet Salesforce's standard, 2 of them in the high-risk category. Each is listed below with your value and the standard value. Salesforce can change the score when it adds or removes settings from the calculation.
What we read. The Health Check score and each setting's value from the Tooling API SecurityHealthCheck and SecurityHealthCheckRisks objects.
What this check cannot tell you. Health Check scores settings against Salesforce's baseline. It does not look at who has access to what data.
| Setting | Your value | Standard | Risk |
|---|
| Lock sessions to the domain in which they were first used | Disabled | Enabled | High |
| Minimum password length | 8 | 12 | High |
| Let users verify their identity by text (SMS) | Enabled | Disabled | Medium |
| Maximum invalid login attempts | 10 | 5 | Medium |
| Obscure secret answer for password resets | Disabled | Enabled | Low |
9. Review apps that use device login
Connected apps using the OAuth device flow · Salesforce date: 30 Nov 2026 · Source
We found 1 user signing in through the OAuth device flow, from Kiosk App. Salesforce restricts the device flow for connected apps from 30 November 2026.
What we read. Login type, login subtype, API type, API version, application and status from Login History for the last six months, grouped by Salesforce user ID. We did not read user names or emails.
What this check cannot tell you. We only see six months of Login History, so an integration that runs less often is invisible. We see which app signed in and as which user ID, not who owns the app or what it does.
| User ID | Logins | Last seen | API versions | Application |
|---|
| 005000000000008 | 14 | 2026-08-30 | N/A | Kiosk App |
10. Update apps that use a retiring browser login method
Connected apps using the OAuth user-agent or hybrid flows · Salesforce date: 20 Feb 2027 · Source
We found 1 user signing in through the OAuth user-agent or hybrid app flows, from Legacy Portal. Salesforce retires those flows for connected apps on 20 February 2027.
What we read. Login type, login subtype, API type, API version, application and status from Login History for the last six months, grouped by Salesforce user ID. We did not read user names or emails.
What this check cannot tell you. We only see six months of Login History, so an integration that runs less often is invisible. We see which app signed in and as which user ID, not who owns the app or what it does.
| User ID | Logins | Last seen | API versions | Application |
|---|
| 005000000000009 | 5 | 2026-07-01 | N/A | Legacy Portal |
11. Move every integration before Salesforce's dates reach it
3 connected apps you built must move to External Client Apps before Summer '27 · Salesforce date: Summer '27 · Source
We listed every app that can sign in to this org: 7 apps, with the first Salesforce date that reaches each one. 3 connected apps were built in this org. Salesforce stops supporting connected apps in Summer '27; they keep working, but get no fixes, and its Migrate button moves them one at a time. 1 of them shows no sign of use in six months, so deleting it is quicker than migrating. 1 app comes from an installed package, so only its publisher can move it. 3 apps signed in with a method Salesforce switches off sooner, on 30 November 2026 or 20 February 2027, so they come first. 1 app belongs to another org, so only its owner can move it. 1 External Client App is local to this org, and a sandbox refresh does not copy local External Client Apps, so it has to be recreated after every refresh.
What we read. The apps installed in this org (App Menu items for connected apps and External Client Apps, with their package namespace), app tokens by app and Salesforce user ID, and six months of API sign-ins grouped by app and sign-in method. We did not read consumer keys, secrets or callback addresses.
What this check cannot tell you. Salesforce's Migrate button cannot move an app that uses Canvas, an Apex handler, SAML with Triple DES, user provisioning or dynamic client registration; we do not read those settings, so App Manager has the final word. SOAP sign-ins carry no app name and are listed in the SOAP findings instead. We see six months of sign-ins.
| App | Whose | Sign-in seen | Users | Last used | First date | What to do |
|---|
| Kiosk App | Another org's | Device | 1 | 30 Aug 2026 | Stops 30 Nov 2026 | Ask its owner now |
| Acme Billing Sync | Yours | Password | 3 | 13 Sep 2026 | Stops 20 Feb 2027 | Move off this sign-in, then migrate |
| Legacy Portal | Yours | User-agent | 1 | 1 Jul 2026 | Stops 20 Feb 2027 | Move off this sign-in, then migrate |
| Alumni Survey Connector | Yours | None in 6 months | 0 | | Support ends Summer '27 | No sign of use: delete, or migrate if needed |
| Mailer Pro | Packaged | None in 6 months | 1 | | Support ends Summer '27 | Ask the publisher for their plan |
| Salesforce CLI | Salesforce | Refresh token, Web server | 1 | 14 Sep 2026 | | Nothing: Salesforce moves it |
| Timetable Feed | External Client App | None in 6 months | 0 | | | Already moved; recreate in sandboxes after refresh |
12. Review packages with no sign of use and reclaim package seats
Installed packages with no sign of use, and package seats or licenses to review
We found 1 installed managed package with no sign of use in the setup data we read: no seats on active users, no Apex jobs in the last 7 days, no scheduled jobs, no app tokens used in 180 days, no users whose last app belongs to it, and no active triggers or flows. These are candidates for review, not confirmed unused packages. We leave out packages installed in the last 90 days, which have had no time to leave those traces. 3 package seats are still assigned to deactivated users, across 1 package.
What we read. Package licenses and seat counts, namespaced Apex jobs and scheduled jobs, active namespaced triggers and flows, package app tokens and last-used apps, all counted by namespace. We did not read any business records or user names.
What this check cannot tell you. We cannot see use through Lightning components on pages, Visualforce pages, Apex called from your own code, outside systems, or data held in the package's objects, because we read no records.
| Package | Seats on active users | Seats on deactivated users | License | Signs of use |
|---|
| Old Survey Tool | 0 | 0 | Free | None found |
| Seat Tool | 2 | 3 | Active | seats |
13. Add error handling to automations
Flows without fault paths
We found 2 of 3 active record-triggered or autolaunched flows with 4 elements that have no fault path. If one of those elements fails, the flow stops, the record change that started it can be rolled back, and Salesforce sends only a generic flow error email.
What we read. Flow definitions from a Metadata API retrieve, scanned in memory with the open-source Lightning Flow Scanner.
What this check cannot tell you. We scan the version of each flow that is active today (for up to 200 flows that also have a newer draft). We read no run history, so we cannot say a flow has ever failed.
| Flow | Trigger | Elements without a fault path |
|---|
| Nightly_Cleanup | Scheduled | 1 |
| Opportunity_After_Save | Record change, after save | 3 |
14. Reclaim paid licenses nobody is using
Paid licenses with no login in 90 days
We found 9 full Salesforce licenses assigned to active users who have not logged in for 90 days or more. At Salesforce list price for Enterprise Edition that is an estimated $18,900 to $21,060 a year. Your contract price is probably lower. These users are candidates for review, not a deactivation list. We also found 2 idle users on other paid license types, listed as counts.
What we read. User counts grouped by license type and user type, for active users created more than 30 days ago with no login in 90 days. We did not read names, usernames or emails.
What this check cannot tell you. List price is not your contract price, and most contracts only allow reductions at renewal. We cannot see your renewal date or discounts. Salesforce's own feature and agent users, and free Chatter licenses, are left out.
| License | Idle users |
|---|
| Salesforce | 9 |
| Salesforce Platform | 2 |
15. Cut back who holds admin-level permissions
9 users hold admin-level permissions
We found 9 active users, 23% of active internal users, holding at least one permission Salesforce treats as admin-level: 5 with Modify All Data and 8 with View All Data, and 1 with only Customize Application or Author Apex. Salesforce now requires each of them who signs in to use a passkey, or an equivalent check through single sign-on, and AI assistants such as Agentforce Coworker act with the permissions of the person using them, so every extra admin widens what a mistake or a stolen login can reach.
What we read. Which active internal users hold Modify All Data, View All Data, Customize Application or Author Apex, and the profile or permission set that grants it, by Salesforce user ID. We did not read user names or emails.
What this check cannot tell you. We see who holds these permissions, not how each person uses them, and some people need them for their job.
| User ID | Admin-level permissions | Profile | Permission sets | API only |
|---|
| 005000000000A06 | View All Data | Admissions Manager | | No |
| 005000000000A07 | View All Data | Admissions Manager | | No |
| 005000000000A08 | Customize Application | Standard User | Report Builder | No |
| 005000000000A09 | View All Data | Integration Profile | | Yes |
| 005000000000A01 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
| 005000000000A02 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
| 005000000000A03 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
| 005000000000A04 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
| 005000000000A05 | Modify All Data, View All Data, Customize Application, Author Apex | System Administrator | | No |
16. Rebuild Workflow Rules as Flows
Workflow Rules still running · Salesforce date: support ended 31 Dec 2025 · Source
We found 3 active Workflow Rules on 3 objects, plus 1 inactive one. Salesforce ended support for Workflow Rules on 31 December 2025. They keep running, but Salesforce no longer fixes bugs in them and has not published a shutdown date. 1 of the active rules uses time triggers and 1 sends outbound messages, which take the most care to rebuild in Flow.
What we read. Workflow Rule definitions, active flags, time triggers and action types from a Metadata API retrieve. Rules that belong to installed packages are not included; they are the vendor's to migrate.
What this check cannot tell you. We read definitions, not execution logs, so we cannot say whether a rule still fires or is still wanted.
| Object | Rule | Time triggers | Actions |
|---|
| Account | Set Account Tier | 0 | Field update |
| Contact | Sync Flag | 0 | Outbound message |
| Opportunity | Closed Won Alert | 1 | Email alert, Task |
17. Fix automation design problems
Other Flow problems the scanner found
We found 2 active flows with problems Lightning Flow Scanner rates as errors: 1 with DML inside a loop, 1 with hardcoded record IDs.
What we read. Flow definitions from a Metadata API retrieve, scanned in memory with the open-source Lightning Flow Scanner.
What this check cannot tell you. We scan the version of each flow that is active today (for up to 200 flows that also have a newer draft). We read no run history, so we cannot say a flow has ever failed.
| Flow | Problems |
|---|
| Nightly_Cleanup | DML inside a loop |
| Opportunity_After_Save | hardcoded record IDs |
18. Upgrade deprecated installed packages
Installed packages on deprecated or beta versions
We found 1 managed package whose installed version the publisher has marked deprecated. Salesforce does not allow the newest version of a first-generation package to be deprecated, so a later version exists for it. We also found 1 managed package still on the version first installed in this org more than 5 years ago, the oldest installed in 2016. We cannot tell whether newer versions exist, so these are listed for a check, not quoted as upgrades. In the 178 days Setup Audit Trail covers, we found 1 package install and 2 package upgrades.
What we read. Installed package versions with their deprecated, beta and first-installed-version flags from the Tooling API, license install dates, and counts of package installs and upgrades from Setup Audit Trail. We did not read any business records.
What this check cannot tell you. Salesforce does not tell an org whether a newer version of a package exists, so we cannot name the latest version. Install dates come from each package license, which only managed packages have.
| Package | Version | Why listed | Installed |
|---|
| Old Survey Tool | 2.4.0.1 | Deprecated | 2014 |
| Legacy Docs | 1.0.0.3 | Never upgraded | 2016 |
19. Free up data storage before it runs out
Data storage is 88% full
We found 0.9 of 1.0 GB of data storage is in use (88%). Extra storage is a paid add-on, so it is worth knowing what fills it before it runs out.
What we read. The storage totals Salesforce reports in the org limits. We did not read any business records.
What this check cannot tell you. We read the totals, not which records fill them, because we read no records. Salesforce updates storage figures with a delay after large imports.
20. Rebuild Process Builder processes as Flows
Process Builder processes still running · Salesforce date: support ended 31 Dec 2025 · Source
We found 2 active Process Builder processes of your own. Salesforce ended support for Process Builder on 31 December 2025. Processes keep running, but Salesforce no longer fixes bugs in them and has not published a shutdown date. 1 more belongs to installed packages and is left out of this count; they are the vendor's to migrate.
What we read. Active Process Builder versions from the Tooling API Flow object, by process type.
What this check cannot tell you. We read definitions, not execution logs, so we cannot say whether a process still fires or is still wanted.
| Process |
|---|
| Case_Escalation |
| Opportunity_Stage_Updates |
21. Test and turn on overdue Release Updates
3 Release Updates are past their due date
We found 3 Release Updates past the date Salesforce set and not finished in this org, the oldest from Winter '26. Salesforce can switch an overdue update on for this org with a coming release, so it is safer to test it first. A further 3 updates are due in Spring '27 and Summer '27 and not yet turned on.
What we read. The title, release, due date and status of each Release Update, from the Tooling API ReleaseUpdate object.
What this check cannot tell you. We see each update's status, not whether your code or automation relies on the old behavior; its test in a sandbox shows that.
| Release Update | Release | State |
|---|
| Restrict User Access to Run Flows | Winter '26 | Overdue |
| Enable Profile Filtering | Winter '27 | Overdue |
| Update Instanced URLs in API Traffic | Winter '27 | Overdue |
| Update Apex Code and Flows for Changed Sharing Recalculation Behavior | Spring '27 | Due |
| Conceal Personal Information Fields from Guest Users | Spring '27 | Due |
| Block Apex Anonymous Code Execution from Managed Packages | Summer '27 | Due |
22. Confirm who built packages without a security review
Installed packages not marked as security reviewed
We found 1 managed package not marked as having passed the AppExchange security review. The flag is also false for some packages Salesforce publishes and for private packages built for one org, so this is a prompt to confirm who built each one, not evidence of a flaw. In the 178 days Setup Audit Trail covers, it recorded 1 install or upgrade of packages like this.
What we read. The security review flag on each installed package version from the Tooling API, and a count of Setup Audit Trail entries for installs of packages that were not security reviewed.
What this check cannot tell you. We cannot tell whether a package is safe, what data it can reach, or why it was never reviewed.
| Package | Version |
|---|
| Legacy Docs | 1.0.0.3 |
23. Decide what AI agents may see and do
1 AI agent is active
We found generative AI switched on and 2 agents set up (1 active). 3 users can create or change agents. Agents act with a user's permissions: assistants such as Agentforce Coworker use those of the person asking, and service agents run as their own agent user (1 here). Salesforce began switching the Agentforce platform on for orgs on eligible editions in September 2026.
What we read. Whether Einstein generative AI is on, the name, type and active status of each agent, how many active users can create or change agents, and which users are on an agent license. We did not read agent topics, actions, prompts or conversations.
What this check cannot tell you. We read which agents exist and who can build them, not what each agent is allowed to do, and not which outside AI tools connect to the org.
| Agent | Type | Active |
|---|
| Student Help Agent | Service agent | Yes |
| Staff Assistant | Employee agent | No |
