Salesforce Connected App Permissions Best Practices

Salesforce connected app permissions have become an increasingly important part of enterprise Salesforce security. After Salesforce security changes around OAuth governance, delegated access, and connected apps, organizations can no longer assume integrations are secure simply because they work. Salesforce increasingly expects admins to review OAuth-enabled apps, connected app policies, and trust relationships rather than treat them as permanent approvals.

Official Salesforce guidance:

Salesforce Security Changes for Connected Apps

A connected application may access customer records, APIs, automation, reports, or business-critical workflows for years without anyone reviewing whether those permissions are still justified.

This creates an important question:

Does this integration actually need the level of access it currently has?

That question sits at the center of Salesforce connected app permission governance.

In this guide, we explain:

• how Salesforce connected app permissions work;
• common permission mistakes organizations make;
• Salesforce connected app permissions best practices;
• how enterprise teams should review OAuth access;
• how to reduce integration risk without slowing business operations.

What Are Salesforce Connected App Permissions?

Salesforce connected apps use OAuth to access Salesforce data and functionality.

In simple terms:

OAuth determines what an external application is allowed to do inside Salesforce.

Authentication and authorization are not the same thing.

Authentication answers:

Who is accessing Salesforce?

Authorization answers:

What are they allowed to do?

Connected apps integrate external systems with Salesforce APIs and OAuth-based access. As a result, permissions determine what data and capabilities a third-party system receives.

Official Salesforce documentation:

Connected Apps Overview in Salesforce

A connected app may authenticate successfully while still holding permissions far broader than necessary.

For example:

• a reporting platform may only need read access;
• a marketing automation platform may require campaign and lead permissions;
• an ERP integration may need tightly controlled API access;
• a migration tool may temporarily require elevated permissions during implementation.

However, integrations often continue operating with permissions they no longer need.

Over time:

working integrations quietly accumulate unnecessary trust

This is one of the main reasons Salesforce connected app permissions deserve ongoing governance.

Why Connected App Permissions Matter More After Salesforce Security Changes

Historically, integrations were configured once and forgotten.

If the system worked, teams moved on.

Permissions stayed untouched for years.

Meanwhile, OAuth trust relationships accumulated across analytics tools, middleware platforms, customer portals, marketing systems, and internal automation.

Today, that model creates risk.

Salesforce security conversations increasingly focus on:

• OAuth governance;
• delegated trust;
• malicious app approvals;
• risky authorization behavior;
• excessive permissions.

The important shift is simple:

A working integration is not automatically a secure integration.

Recent OAuth-related incidents across SaaS ecosystems highlighted how trusted integrations and delegated access can introduce risk even when the platform itself is not compromised.

Connected apps increasingly become an important part of an organization’s security and governance surface.

Poorly governed permissions may increase:

• customer data exposure;
• compliance risk;
• operational complexity;
• visibility problems;
• unnecessary system access.

Want more context on recent Salesforce OAuth and integration security updates? Read our guide:

What Salesforce Security Changes Mean for Existing Integrations

Therefore:

Salesforce connected app permissions should be intentionally governed rather than passively trusted

Installed vs Authorized Connected Apps

Not all connected apps behave the same way.

Understanding this distinction matters for permission governance.

Installed Connected Apps

Installed connected apps are formally managed inside Salesforce.

Admins can review:

• policies;
• OAuth access;
• permitted users;
• approval settings;
• session behavior.

Because these applications are centrally visible, they are generally easier to govern.

Salesforce also allows admins to review and manage OAuth policies, access behavior, token settings, and connected app permissions.

Official documentation:

Manage Connected Apps in Salesforce

Authorized Connected Apps

Authorized connected apps are different.

In some cases, users may authorize applications through OAuth flows without formal installation.

In practice:

users may grant trust without governance

This matters because enterprise teams often discover integrations that technically work but were never intentionally reviewed.

During a permission review, ask:

• Do we recognize this application?
• Is ownership documented?
• Does it still support an active business process?
• Would we approve this access again today?

If the answer is unclear:

the application deserves review

For additional practical guidance on connected app reviews, see:

A Salesforce Admin’s Guide to Auditing Connected Apps

Common Salesforce Connected App Permission Mistakes

Granting More Access Than Necessary

The most common issue is overpermissioning.

Many vendors request broad Salesforce access because implementation becomes easier.

As a result, teams often approve:

• excessive API permissions;
• unnecessary write access;
• broad object permissions;
• unrestricted OAuth scopes.

For example:

A reporting dashboard rarely needs write access.

Similarly, a customer analytics platform usually does not require permissions across every Salesforce object.

Instead:

permissions should align with business need

This principle is commonly called:

least privilege access

Meaning:

give integrations only the permissions they actually need

Using System Administrator Access for Integrations

Some integrations still run under highly privileged users because:

“That’s how we originally configured it.”

Sometimes vendors request System Administrator access because implementation becomes easier.

However:

easy setup is not a security strategy

Enterprise teams should instead:

• use dedicated integration users;
• separate integrations by business purpose;
• limit object access;
• restrict API permissions;
• avoid administrator-level access unless absolutely necessary.

In practice, a dedicated integration user with minimum permissions is usually safer than broad SysAdmin access.

Keeping Permissions After Projects End

Migration projects frequently create hidden security debt.

A deployment or middleware tool may require elevated access during implementation.

Months later:

the project ends, but permissions remain

This creates:

• stale OAuth trust;
• abandoned integrations;
• excessive permissions;
• unclear ownership.

Ask:

• Does this integration still support an active workflow?
• Does it still require elevated permissions?
• Is ownership documented?
• Would we still approve this level of access today?

If the answer is unclear:

permissions should be reviewed

Assuming MFA Solves Connected App Security

MFA strengthens authentication.

However:

MFA does not govern OAuth permissions

Organizations may enforce MFA successfully while still exposing unnecessary connected app access.

Secure login does not automatically equal secure integration governance.

Salesforce Connected App Permissions Best Practices

1. Follow Least Privilege Access

The strongest recommendation is simple:

Grant the minimum access necessary

Ask:

• Is write access required?
• Does this integration really need broad API access?
• Are requested OAuth scopes justified?
• Could permissions be reduced?

Over time, permissions naturally expand.

Therefore, governance should intentionally reduce unnecessary access.

2. Review OAuth Scopes Regularly

Connected app permissions should not be reviewed once and forgotten.

Organizations should periodically review:

• OAuth scopes;
• API permissions;
• authorization history;
• ownership;
• business purpose;
• session settings.

Recurring reviews frequently uncover:

• duplicate tooling;
• stale OAuth access;
• abandoned integrations;
• excessive permissions.

This is one of the simplest ways to improve Salesforce security without major implementation effort.

If you want a practical step-by-step audit process, see:

How to Audit Salesforce Connected Apps After Security Changes

3. Use Admin Approved Users for Sensitive Integrations

In Salesforce, organizations commonly choose between:

• All Users May Self-Authorize
• Admin Approved Users Are Pre-Authorized

For sensitive or business-critical systems, enterprise teams often prefer:

Admin Approved Users Are Pre-Authorized

because it limits uncontrolled access and improves governance.

Meanwhile, lower-risk internal tools may justify controlled self-authorization.

The objective is simple:

govern trust intentionally

4. Review Connected App Policies — Not Just Permissions

Permissions alone are not enough.

Enterprise teams should also review:

• approval settings;
• OAuth policies;
• access restrictions;
• session controls;
• authorization history.

Go to:

Setup → Connected Apps OAuth Usage

and

Setup → App Manager → Connected Apps

Official Salesforce documentation:

Salesforce Connected Apps Management Documentation

Then ask:

Would we approve this access again today?

If the answer is no:

permissions should change

5. Consider API Access Control and Permission Boundaries

Enterprise teams should also evaluate API access boundaries for sensitive integrations.

Not every connected app requires the same level of access.

For example:

A finance or ERP integration deserves stricter governance than a lightweight internal reporting tool.

Organizations should review whether integrations require:

• unrestricted API access;
• write permissions across multiple objects;
• refresh tokens and persistent access;
• broad object visibility.

In many cases, access can be constrained through:

• permission sets;
• profiles;
• connected app policies;
• dedicated integration users;
• scoped OAuth permissions.

Additional OAuth security recommendations:

How to Secure Connected Apps and OAuth Connections in Salesforce

Salesforce Connected Apps: Security Risks and Best Practices

In practice:

governance should match business risk

What Permissions Should Be Reviewed?

A connected app permission review should go beyond asking whether an integration still works.

Teams should review:

• API access;
• read and write permissions;
• OAuth scopes;
• refresh token access;
• offline access requirements;
• session settings;
• ownership;
• business purpose;
• authorization history.

Helpful questions include:

• Does this integration still support a real business workflow?
• Could permissions be reduced?
• Is write access truly required?
• Does this application still need long-term token access?
• Would we approve this level of access again today?

Often, the biggest risk is not malicious behavior.

Instead:

it is forgotten trust

For a practical governance framework, explore:

Salesforce Connected App Security Audit Checklist for Enterprise Teams

Quick Salesforce Connected App Permission Checklist

During every review, ask:

Even lightweight reviews frequently uncover:

hidden security debt

When Connected App Governance Becomes Difficult

Governance becomes harder as Salesforce environments grow.

Organizations often struggle with:

• dozens of integrations;
• unclear ownership;
• duplicate tooling;
• stale OAuth access;
• excessive permissions;
• business-critical API dependencies.

Questions quickly appear:

• Why does this integration still exist?
• Who owns it?
• Why does it have this level of access?
• Are permissions excessive?
• Which integrations create unnecessary risk?

At Success Craft, we help organizations review Salesforce connected app permissions, audit OAuth access, improve integration governance, and design secure Salesforce integration architectures that scale as ecosystems grow.

This becomes especially valuable when enterprise teams manage:

• multiple vendors;
• middleware platforms;
• customer-facing integrations;
• large API ecosystems;
• business-critical automation.

Learn more about Salesforce connected app security:

Salesforce Connected Apps Security: What Enterprise Teams Should Know

Final Thoughts

Salesforce connected app permissions should never be treated as permanent trust.

Instead, permissions should be:

• reviewed;
• justified;
• periodically reduced where possible;
• intentionally governed.

The strongest Salesforce organizations follow three principles:

least privilege + visibility + recurring governance

Secure integrations are rarely accidental.

They result from deliberate access control, recurring permission reviews, and thoughtful governance decisions.

Because every integration represents trust:

and trust should be reviewed