This is the seventh post in our Essential SOPs for Salesforce Admins series, based on my session at Texas Dreamin'. Part 1 made the case for routine maintenance, Part 2 covered user management, Part 3 covered backup and recovery, Part 4 tackled duplicates, Part 5 covered rotational field audits, and Part 6 covered training material audits. Last week was about the people using your org. This week is about the systems using it.
I was in the middle of rolling out a statewide change when I tripped over something I hadn't planned for.
We were updating user emails. Simple enough. Except there was a tool users reached through a button in Salesforce, and it logged them in using the email tied to their Salesforce login. It didn't show up in Connected Apps. It wasn't in anyone's documentation. I only found it because things stopped working.
So instead of wrapping up the rollout, I spent the day updating every one of those logins by hand.
Not a disaster. But it was a good reminder: you can't safely change what you don't know is connected.
Your Org Has More Doors Than You Think
When I take over an org, I can usually spot the obvious integrations fast: the marketing platform, the email sync, the e-signature tool. What takes longer is everything else:
Apps someone tried once. A free trial from two years ago that still has an active token.
Integrations built by a former admin or a vendor. Often with custom code and no documentation of how data moves between the two systems, or when.
Tools connected by individual users. A rep authorized a browser extension or a dialer with their own login, and now it can see whatever they can see.
Integration users with too much access. Set up as a System Administrator "just to get it working" and never dialed back.
Each one is a key to your data. Most of them were handed out with good intentions. Very few get checked again.
Why It's an SOP
If you need a reason beyond tidiness: in August 2025, attackers stole OAuth tokens from a widely used sales chat integration and used them to pull data out of hundreds of Salesforce orgs. They didn't break into Salesforce. They walked in through a door a connected app had already opened.
That's why connected apps reviews are on my core SOP list: twice a year at minimum, quarterly if you have a lot of integrations or handle sensitive data.
It's also a governance issue. When you have integrations, you need governance. Full stop. A field request here, a mapping change there, and eventually you have fields to nowhere and two systems arguing over which one is the source of truth. (Your data dictionary from Part 5 helps a lot here.)
You Don't Have to Be a Developer
I'll be honest: I know very little about custom code. For a long time I assumed that meant integrations weren't my lane. They are. You don't need to read Apex to build an inventory. Here's where to look in Setup:
Connected Apps OAuth Usage. Shows which apps have been authorized, how many users are connected to each, and lets you revoke access. If you only check one place, start here. (Thanks to Mike Reynolds for this one.)
Manage Connected Apps and External Client Apps. The apps configured in your org and their access policies. Salesforce has been moving new integrations toward External Client Apps, so check both.
Installed Packages. Everything from AppExchange. Note what's unused, expired, or owned by nobody.
Remote Site Settings and Named Credentials. The outside endpoints your org is allowed to call. These are often the breadcrumbs left behind by custom integrations.
Users with "API Enabled." Run a report on your integration users. Who are they, what profile do they have, and when did they last log in?
Login History. Filter for API and OAuth logins to see what's actually connecting, and how often.
And for the stuff that doesn't show up anywhere (like my button-based login), ask. Talk to the teams that use the system. "What else do you log into from Salesforce?" surfaces more than you'd expect.
The Twice-a-Year Review
Build the inventory. For every integration, capture: what it is, what it does, who owns it (business side and technical side), which user it runs as, and what data it reads or writes.
Check for activity. No logins in 90 days? Flag it. No one can tell you what it does? Flag it louder.
Right-size the access. Integration users should have only the permissions they need. Use a dedicated integration user and permission sets, not a recycled admin login.
Tighten the policies. For apps you keep, set them to "Admin approved users are pre-authorized" so only the people (or permission sets) you choose can use them.
Decide: keep, fix, or revoke. Same as fields, same as training. If nobody claims it and nothing breaks when you turn it off in a sandbox, it's time to let it go.
Document the flow. Even a simple diagram of what moves between systems, which direction, and when will save the next person (or future you) a very long day.
A Word on Cheap Integrations
I've watched this one play out more than once: someone goes with the lowest bid, gets an integration built for $5K by a team with no Salesforce experience, and then pays $6K to have it fixed. Usually the code works, sort of. What's missing is any documentation of how the data moves.
The review won't prevent a bad build. But it will tell you much sooner that you have one.
Where to Start
If connected apps is the pillar you're picking up first, here's the single move: open Connected Apps OAuth Usage today and write down every app on the list. Next to each one, put a name. Anything you can't put a name next to is your first conversation.
What's Next
Next post, we'll look at security reviews: permission sets, profiles, and the "View All Data" and "Modify All Data" checkboxes that tend to multiply when no one's watching.
