Salesforce Admin Best Practices: How to Run an Org That Scales

Salesforce admin best practices are the habits that keep an org secure, clean, documented, and easy to change. They cover seven areas: access, data, automation, releases, integrations, the admin team, and regular health checks.

This guide is for Salesforce admins and platform owners whose org has grown past what one person can hold in their head. Here are the Salesforce administrator best practices that matter most:

• Access: Grant access through permission sets and keep admin rights rare.
• Data: Name an owner for every object and test your backup.
• Automation: Build in Flow and retire what nobody uses.
• Releases: Build in a sandbox, test, then ship with notes.
• Integrations: Give every connected system its own user.
• Team: Run one backlog with clear roles and approvals.
• Health: Check the org every quarter, on a schedule.

Most Salesforce best practices lists assume one admin working alone. This one is written for the team.

Security and Access Best Practices

Access is where a lot of org problems start. People change jobs, projects end, and old permissions stay behind. Good security best practices keep access small, clear, and easy to review. That takes an access model designed at the architecture level, not one patched together request by request.

Lead with Permission Sets, Not Profiles

A profile is the baseline every user must have. Permission sets and permission set groups add access on top of it. Think of the profile as the building pass and permission sets as the keys to each room.

Salesforce once planned to retire permissions on profiles. It has since cancelled that plan “based on customer feedback and remaining feature gaps.” So profiles aren’t going away. Salesforce still recommends a permission set-led model, and so do we.

Here’s the practical rule. Keep defaults like apps, login hours, and password policies on the profile. Put object and field access in permission sets. Then bundle those into permission set groups by job role. That’s least privilege in practice: each person gets what the job needs and nothing more.

Require MFA and Keep the System Administrator Profile Small

Salesforce requires multi-factor authentication (MFA) for all internal users who access production orgs and sandboxes. Check that nobody still has a quiet exemption left over from an old project.

Then count who holds the System Administrator profile. Every extra Salesforce admin account is one more login that can change anything. Keep the list as short as the work allows, and review it every quarter.

Run Security Health Check, and Test Before You Fix

Security Health Check is a built-in Setup page. It scores your security settings from 0 to 100 against a Salesforce baseline, and 100 is the most secure.

Here’s the catch: the “Fix Risks” button changes every flagged setting at once. That can break an integration or lock users out. Try the changes in a sandbox first, then apply them in production.

Data Management Best Practices

An org is only as useful as the data inside it. Reports, automation, and AI all read the same records. Data management best practices come down to two jobs: keep the data clean, and make sure you can get it back. For the bigger picture, we’ve covered what Salesforce’s Informatica deal means for enterprise data management.

Data Quality, Duplicates, and Naming Conventions

Data quality starts with ownership. Name one owner for each object’s data. Then write down ownership and quality rules for enterprise data so the job doesn’t live in one person’s memory.

Stop bad records at the door. Use validation rules to require the fields you need. Use duplicate rules to block duplicates when a record is created. Fixing data at entry takes far less work than cleaning it up later.

Agree on naming conventions for fields, flows, and reports before the org grows. Then make data hygiene a routine, not a rescue project. A monthly look at duplicates and empty fields keeps data quality from sliding.

Poor data quality also gets more expensive over time. Once you pull records from several systems into a single view of each customer, every mismatch has to be matched and merged. We’ve written about why messy data gets expensive once you unify it.

Backups, Recovery, and What Salesforce Keeps

Many teams treat the weekly data export as their backup. It isn’t a full plan. The export runs weekly in Enterprise, Performance, and Unlimited Editions and monthly in others. The zip files are deleted 48 hours after the email goes out, not counting weekends.

So someone has to collect each export and store it somewhere safe. And an export file isn’t a tested restore. A backup you’ve never restored from is a guess. You still need a way to put records back with their relationships intact.

Field history has a limit too. Without the Field Audit Trail add-on, Salesforce keeps field history for up to 18 months, and up to 24 months through the API. If an audit will need older changes, plan for that now.

The best practice is simple. Decide what you must be able to restore and how fast. Pick a backup tool or process that meets that goal. Then test a real restore once a year.

Automation and Customization Best Practices

Automation saves your users time. It also piles up. Every flow, rule, and custom field is something your team has to understand and maintain later. These best practices keep automation useful instead of scary.

Move What Is Left to Flow

Workflow Rules and Process Builder are older automation tools. Salesforce stopped supporting both on December 31, 2025. Your active rules and processes still run. They no longer get customer support or bug fixes.

Flow is the current tool, and Salesforce recommends a plan to migrate active rules and processes to Flow Builder. Start with a list of every active workflow rule and process. Rank them by business risk. Migrate the risky ones first and retire the rest.

Keep each flow readable. Aim for one clear entry point per object where you can. Give every flow a description and an owner. We’ve also recommended a Flow health audit for automation debt and failing flows as a regular habit.

Avoid Over-Customizing, and Track Your Technical Debt

Technical debt is configuration and code that nobody uses, nobody understands, or nobody dares to touch. It builds up one quick fix at a time.

Salesforce’s own cleanup checklist points to two signs of tech debt. One is outdated API versions on Apex classes, triggers, and Visualforce pages. The other is permission sets with very few people assigned.

Before you add a field or a flow, check whether a standard feature already does the job. And know when a requirement needs code instead of one more flow. One tidy piece of code beats ten tangled flows.

Change and Release Management Best Practices

A change that skips testing is the fastest way to break an org. Change management and release management best practices give every change the same path: build, test, announce, ship, and write it down.

Build and Test in the Right Sandbox

Never build in production. Build in a sandbox, test there, and promote the change when it passes. Salesforce offers four sandbox types, and each one fits a different job.

Sandbox type	Refresh interval	What it copies	Use it for
Developer	1 day	Metadata only	Building and unit testing
Developer Pro	1 day	Metadata only	Larger builds and integration work
Partial Copy	5 days	Metadata and sample data	User testing and training
Full	29 days	Metadata and all data	Performance tests and final rehearsal

The first three columns come from Salesforce. The last column is our guidance. Don’t run user testing in a Developer sandbox. It has no data, so your users can’t test real work.

Stay Release-Ready and Document as You Go

Salesforce ships new features three times a year: Spring, Summer, and Winter. The first sandbox upgrades happen four to six weeks before a release reaches production. Use that window to test your key processes.

Open Release Updates in Setup before each release. It lists the changes Salesforce will enforce and when. Put each one on your backlog with a date.

Change management is about people too. Tell users what’s changing and why before it ships. A short note and a two-minute video beat a surprise.

Good documentation survives a resignation. Add a description to every custom field and flow. Keep a change log and a short data dictionary. For documentation on a complex build, see the same release discipline applied to quote-to-cash.

Salesforce Admin Best Practices for an Integrated Org

Once Salesforce talks to other systems, your changes travel. A renamed field can stop an order sync. Most admin guides skip this part. If your team is connecting Salesforce to ERP, commerce, and data platforms, these best practices matter as much as security.

Give Every Integration Its Own User

Salesforce recommends one user for every integration. Its Salesforce Integration user license limits that user to API-only access. The license is available in Enterprise, Unlimited, Performance, and Developer Editions.

Here’s why an integration user matters. You can see which system changed a record. You can switch one integration off without breaking the others. And no integration runs with a person’s admin rights.

Watch API Limits, and Agree Who Owns a Failure

Every org has a daily API allowance. In Enterprise Edition, the formula starts at 100,000 calls per 24 hours and adds 1,000 for each Salesforce license. Unlimited and Performance Editions add 5,000 per license. Salesforce allows some overage and tells you not to rely on it.

API limits turn into a design question as you add systems. Point-to-point links each make their own calls. A shared layer built on reusable APIs instead of point-to-point connections lets systems share the same calls. One of our published case studies, a loyalty platform rebuild, reports a drop from 300 APIs to 40.

Before you rename, retype, or delete a field, check whether another system reads or writes it. Keep a simple list of which fields feed which integration. A missing list is one of the signs your integrations have outgrown their design.

Then agree who gets the alert when an integration fails: the Salesforce admin or the integration team. Write it down. If you run an integration layer with its own monitoring, decide who watches that dashboard as well.

Governance: Best Practices for the Admin Team

Governance sounds heavy. It’s a simple idea: who decides what changes, and who does the work. Salesforce admin best practices only stick when someone owns them. Without governance, every request to a Salesforce admin is urgent and the loudest voice wins.

How Many Salesforce Admins Do You Need?

Salesforce publishes its own guidance. It says one common approach is to base the number of administrators on the number of users.

Number of users	Administration resources
1 to 30	Less than 1 full-time administrator
31 to 74	1 or more full-time administrators
75 to 149	1 senior administrator and 1 junior administrator
140 to 499	1 business analyst and 2 to 4 administrators
500 to 750	1 to 2 business analysts and 2 to 4 administrators
More than 750	Depends on a variety of factors

Two honest notes on this table. The ranges overlap in the middle, and above 750 users Salesforce says it depends. Salesforce also says the answer turns on the size of your business, the complexity of your setup, and the volume of user requests.

In our view, complexity matters more than headcount. When you ask how many Salesforce admins you need, count integrations, business units, and regulated data too. A 300-user org in a regulated industry like banking with six connected systems can need more hands than a simple 600-user org.

Roles, a Backlog, and a Lightweight Center of Excellence

Four roles keep an org healthy. The Salesforce admin configures and maintains. The developer writes code. The architect designs how systems fit together. The business analyst turns requests into clear requirements.

In a small org, one person does all four jobs. That’s the point where Salesforce best practices start to slip. Even if one person wears every hat, name the hats so nothing gets dropped.

Run one intake queue and one backlog. Agree who approves a change before work starts. A center of excellence doesn’t need a big budget. It can be three people who meet twice a month to rank requests, set standards, and keep documentation current.

Good governance also needs a shared yardstick. The Salesforce Well-Architected Framework names pillars that include Trust, Reliability, and Operational Excellence. It also helps to see how a platform review weighs data, governance, and architecture together.

Getting Your Org Ready for AI Agents

AI agents inherit whatever your org gives them. Loose permissions become agent permissions. Messy records become wrong answers, which is why agents need a unified data layer they can trust. So the Salesforce admin best practices above are also your agent prep.

Salesforce’s security guidance for Agentforce is plain. It says to grant agents the minimum user permissions their tasks require and to monitor access logs regularly for suspicious activity. That’s least privilege again, applied to AI agents.

Here are four jobs to finish before any agent goes live:

• Tighten permissions. Give each agent its own narrow permission sets.
• Fix the data agents will read. Start data hygiene with the objects in your first use case.
• Retire dead automation. Clear out old rules before AI agents start updating records.
• Write field descriptions. Our advice: clear descriptions help people and agents understand a field.

For a quick self-check, try a 12-question check of whether your org is ready for agents. If you’re picking a first project, see which agent use cases are proving out this year. And if a rollout is already planned, our Agentforce team focuses on building agents with governance from day one.

A Quarterly Org Health Routine

First, a quick clarification. Security Health Check is one feature that scores security settings. An org health check is the whole routine: security, data, automation, technical debt, and license use. People say “Salesforce health check” for both.

The tools have changed too. Salesforce Optimizer, the old built-in report, was scheduled for retirement in the Winter ’26 release. Salesforce’s admin team now points to Org Check, a free Salesforce Labs tool on AppExchange that helps you drill into your metadata.

We recommend running the routine below every quarter. That’s our advice, not a Salesforce rule. It lines up with the three yearly releases and leaves one extra pass for cleanup.

Check	Where to look	What to look for
Security settings	Security Health Check in Setup	A falling score, or new high-risk settings
Metadata and technical debt	Org Check (Salesforce Labs)	Fields, automation, and code that nobody uses or owns
Old automation	Workflow Rules and Process Builder in Setup	Anything still active after end of support
Upcoming enforced changes	Release Updates in Setup	Updates with an enforcement date in the next release
Storage	Storage Usage in Setup	Data or file storage close to its limit
Access sprawl	Permission sets and System Administrator assignments	Sets with very few people assigned, and too many admins
API and integration health	API usage and integration user logins	Usage climbing toward the daily allowance, and failed calls

A routine your Salesforce admin runs every quarter catches drift early. When the list of findings is longer than your team can clear, bring in an outside review of tech debt, license use, and AI readiness. You can also estimate what unused licenses and tech debt are costing you before you ask for budget.

When to Bring In Help: In-House, Fractional, or Managed Services

Four signals tell you the workload has outgrown your Salesforce admin team. The backlog only grows. Releases get skipped. One person holds all the knowledge. And the quarterly org health check stops happening.

You have three options:

• Add in-house capacity. Best when the work is steady and specific to your business.
• Use a fractional or outsourced Salesforce admin. Good for day-to-day requests when a full hire is too much.
• Use managed services. Fits when you also need architecture, integration, and release support.

Our hiring guide covers when a freelancer, a boutique, or a full partner makes sense. If integrations are the pain, read about the traits that separate a strong integration consultant from a weak one. And if you want a team behind you after launch, we offer ongoing support after go-live.

How Incepta Helps Salesforce Admin Teams

We work with Salesforce admin teams that have more org than hours. Here’s where we help:

• Assess the org. Our Salesforce Platform Assessment covers tech debt, license optimization, and AI readiness. It starts with a complimentary two-hour discovery session.
• Fix the integration layer. We design and build the connections between Salesforce and your other systems.
• Prepare for AI agents. We get permissions, data, and automation ready before an agent goes live.
• Provide ongoing support. We back up your Salesforce admin team after go-live.

The deep analysis step of an assessment combines automated scanning, manual review, a data quality assessment, a security audit, and an AI readiness evaluation.

To see the kind of work we do, browse the enterprise projects we’ve published.

Find Out Where Your Org Stands

You can’t fix what you haven’t measured. Salesforce admin best practices work best when you know your starting point. If your quarterly list is longer than your team can clear, we’ll help you sort it. To get that baseline, book a discovery session with our team.

Frequently Asked Questions