Integrating Salesforce with MuleSoft: A Practical Guide

Salesforce and MuleSoft integrations are often presented as straightforward connector setups but the real complexity lies in authentication design and access control. This guide walks through a clean, production-ready approach to setting up a secure integration between Salesforce and MuleSoft.

Why This Matters More Than Ever

With recent updates in Salesforce, basic authentication is being deprecated for REST APIs starting from version 65.0. This is not just a version change, it’s a fundamental shift in how integrations are expected to operate.

What this means in practice:

• Username + password (and security token) based authentication is no longer viable
• Integrations relying on legacy auth mechanisms will break or become unsupported
• OAuth 2.0 is no longer optional—it’s the standard

Salesforce Setup

1. Create an Integration User

This user represents your integration layer (MuleSoft) within Salesforce and should be configured explicitly for system-level access, not human usage.

Key Configuration Requirements

When creating the Integration User, ensure the following:

• User License: Set to Salesforce Integration
  This license is purpose-built for API-driven integrations and avoids unnecessary UI capabilities.
• Profile: Use Minimum Access – API Only Integrations (or Salesforce API Only System Integrations, depending on your org)This ensures the user:
  • Cannot log in via UI
  • Is restricted to API-based interactions only
• Permission Set License Assignment: Assign the Salesforce API Integration permission set license to enable API capabilities aligned with the integration use case.

Note: Keep the User’s username handy as that would be required while enabling the client credentials flow.

2. Create and Configure the Permission Set

Once your permission set (i.e., MuleSoft SFDC Integration) is created in Salesforce, the next step is defining the exact level of access your integration requires.

Where to Configure Access

Permissions are primarily configured through:

• Object Settings → Define object-level and field-level access
• System Permissions → Enable API access and other capabilities

The “View Summary” section provides a consolidated view of all assigned permissions and is useful for:

• Verifying access across objects and fields
• Auditing what the integration user can actually do

What to Configure

Focus on three layers of access:

1. Object-Level Permissions

Define CRUD access based on your integration needs:

• Read (for data retrieval)
• Create/Update (for sync or ingestion flows)
• Delete (only if explicitly required)

2. Field-Level Permissions

This is where most integrations silently fail.

Ensure:

• Required fields are visible
• Fields being written to are editable
• Fields that are introduced later are being included and the same goes for the related Object. Such as for Opportunity, one should have access to Account, Contact, OpportunityLineItem, etc.

3. Record-Level Access

Controlled via:

• Organization-wide defaults (OWD)
• Sharing rules (if applicable)

Your integration user must be able to access the actual records, not just the object schema.

3. Assign the Permission Set to the Integration User

After defining the required access in your permission set, the next step is to assign it to the Integration User in Salesforce.

How to Assign

• Navigate to the Integration User
• Go to Permission Set Assignments
• Click Edit Assignments
• Add your permission set (i.e., MuleSoft SFDC Integration)

4. Create an External Client App

This is where most integrations go wrong—not technically, but architecturally.

The only OAuth scopes required for the Integration are the following:

1. Manager user data via APIs (api)
2. Performed requests at any time (refresh_token, offline_access)

Once the External Client App has been created, enable the Client Credentials flow by editing the Policies of the External Client App.

To retrieve the Consumer Key and Secret, browse to the Settings tab and generate it from the OAuth Settings.

You have two authentication options:

Option A: Client Credentials Flow

• No user interaction
• Uses Integration User context
• Token generated via client ID + secret

When to use:

• Backend integrations
• Scheduled jobs
• Event-driven flows

Why it’s better:

• No token refresh complexity
• Fully automated
• Easier to scale

Option B: Authorization Code Flow

• Requires user login
• Uses callback URL
• Generates refresh tokens

When to use:

• User-context integrations
• UI-driven workflows

Tradeoff:

More flexible, but adds lifecycle management (token refresh, expiry handling).

MuleSoft Configuration (Client Credentials Flow)

Once your Connected App is configured in Salesforce using the Client Credentials flow, the next step is to configure the Salesforce Connector in MuleSoft.

Connector Configuration

In MuleSoft, add the Salesforce Connector and configure it with the following:

• Authentication Type: OAuth 2.0 – Client Credentials
• Client ID: From Salesforce Connected App
• Client Secret: From Salesforce Connected App
• Token URL:
  • Sandbox → https://test.salesforce.com/services/oauth2/token
  • Production → https://login.salesforce.com/services/oauth2/token

What Happens Behind the Scenes

When MuleSoft initializes the connection:

1. It sends a request to Salesforce’s token endpoint using:
   • Client ID
   • Client Secret
   • Grant Type = client_credentials
2. Salesforce validates the Connected App configuration
3. An access token is issued in the context of your Integration User
4. MuleSoft uses this token for all subsequent API calls

Critical Configuration Detail

In Salesforce, your Connected App must be configured to:

• Use the Integration User as the Run-As user (for Client Credentials flow)

If this is not set correctly:

• Token generation may succeed
• But API calls will fail due to missing context or permission

To discover similar technical guides and integration patterns, click here.