Salesforce

You can configure Salesforce as a source or a target.

To configure the connection details for Salesforce in your Micro-Integration, see Salesforce Connection Parameters.

You must also define at least one Micro-Integration Flow that specifies:

For a listing of available message headers, see Salesforce Message Headers.

If you are deploying the Micro-Integration for Salesforce in a Customer-Controlled Cluster that routes outbound connections through a proxy, no additional configuration is required. The Micro-Integration receives the proxy settings automatically from the environment.

Salesforce Connection Parameters

The following table describes the connection parameters for Salesforce.

Field Description

Pub/Sub API Endpoint

The endpoint used by the Salesforce Pub/Sub API. For example, the Salesforce Global Endpoint is api.pubsub.salesforce.com. For more information, see Pub/Sub API Endpoints in the Salesforce documentation.

Pub/Sub API Port

The port used by the Salesforce Pub/Sub API. Use 443 (recommended) or 7443.

Port 443 is the standard HTTPS port and is less likely to be blocked by corporate proxies or firewalls. Use 7443 only if port 443 is explicitly unavailable in your network.

Login URL

The Salesforce login URL. For example: https://<personal_domain>.my.salesforce.com

Use the base login URL that was provided in your signup email or that appears in your browser before navigating to Setup. Do not copy the URL from the browser while you are inside the Setup tab. When you navigate to Setup, Salesforce appends -setup to the subdomain (for example, my.salesforce-setup.com), which is a different URL and will cause authentication to fail.

Authentication Scheme

The authentication method to use when connecting to Salesforce. Choose one of:

SOAP authentication should be used only for quick local testing. For any Micro-Integration that is expected to run continuously, use either the Client Credentials or JWT Bearer grant type instead.

Salesforce OAuth 2.0 Client Credentials Parameters

The Client Credentials grant type is a machine-to-machine OAuth 2.0 flow that does not depend on user passwords or tokens that require rotation. We recommend this authentication method for any Micro-Integration that runs in a sustained or automated manner.

Field Description

Client ID

The OAuth 2.0 Client ID to authenticate with. The Client ID might appear as "Consumer Key" in Salesforce.

For more information, see Configure a Client Credentials Flow in the Salesforce documentation.

Client Secret

The OAuth 2.0 Client Secret. The Client Secret might appear as "Consumer Secret" in the OAuth Settings in Salesforce.

For more information, see Configure a Client Credentials Flow in the Salesforce documentation.

Validating Client Credentials Before Deploying

Before you configure your Micro-Integration, verify that your OAuth 2.0 Client Credentials work by requesting a token using the following cURL command:

curl -X POST https://<SALESFORCE_LOGIN_URL>/services/oauth2/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=<YOUR_CLIENT_ID>" \
  -d "client_secret=<YOUR_CLIENT_SECRET>"

This test helps you isolate authentication issues from Micro-Integration configuration issues. A successful response returns an access_token. If the request fails, fix the credentials before you configure your Micro-Integration.

If you are unsure which OAuth scopes are required, grant all scopes to the connected app first, verify that the token request succeeds, and then reduce the scopes only after you confirm that the Micro-Integration works end-to-end. If you start with restricted scopes, it's difficult to distinguish a credential misconfiguration from an insufficient-permissions problem.

To confirm that your Salesforce setup is complete before you configure your Micro-Integration, ensure that:

  • A Salesforce Platform Event has been created under Setup > Platform Events.

  • An External Client App has been created under App Manager > External Client App Manager.

  • The Client Credentials Flow is enabled under OAuth Policies for that app.

  • The Run As user has been configured on the Client Credentials policy.

  • The proper OAuth scopes have been granted (start with all scopes; reduce later).

  • The Consumer Key and Consumer Secret have been copied from OAuth Settings.

  • You have verified your credentials by requesting a token using the preceding cURL command.

  • You have verified your login URL to be the base domain URL (not the Setup URL).

Salesforce OAuth 2.0 JWT Bearer Flow Parameters

You must set up a connected app to use JWT. For more information, see Configure a JWT Bearer Flow in the Salesforce documentation.

In addition to following the Salesforce documentation instructions, you must ensure that Plugin Policies are set to Admin approved users are pre-authorized and the user profile/permission set is authorized for the connected app.

You can build and sign a JWT using the template on jwt.io. Change the default text to your client ID and username e-mail, then add your private key to sign the token.

To test your JWT before using it in the Micro-Integration, issue the following POST request:

POST <YOUR_LOGIN_URL>/services/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
							
grant_type= urn:ietf:params:oauth:grant-type:jwt-bearer&
assertion=eyJpc3MiOiAiM01WRz...[omitted for brevity]...ZT
Field Description

Issuer

The OAuth client_id or the connected app for which you registered the certificate. Corresponds to the iss JWT claim.

Audience

The authorization server that is the intended audience. Corresponds to the aud JWT claim. Allowed values are:

  • https://login.salesforce.com (Default value)

  • https://test.salesforce.com

  • https://site.force.com/customers (if this Micro-Integration is authenticating with a Salesforce Experience Cloud site)

Subject

The Salesforce user name to use for authentication. Corresponds to the sub JWT claim.

Private Key

The private key file used to sign the JWT. Both unencrypted and encrypted (PKCS #8 and OpenSSL/PEM) private keys are supported.

Private Key Password

The password for the private key if it is encrypted.

Salesforce Legacy SOAP Parameters

Legacy SOAP authentication relies on a username, password, and security token. Salesforce periodically enforces password rotation, which also invalidates the security token. If a running Micro-Integration is using SOAP authentication and the credentials are rotated, the Micro-Integration will fail without any configuration change on the event broker side.

For any Micro-Integration that is expected to run continuously, use either the Client Credentials or JWT Bearer grant type instead.

Field Description

Username

The Salesforce username to authenticate with.

Password

The password that corresponds to the Salesforce username.

Security Token

The security token generated by Salesforce. If you don't have a security token, click your avatar in Salesforce, then click Settings > Reset My Security Token. A new token is emailed to you.

Micro-Integration Flow Parameters

You must configure the endpoint parameters for each Flow. Each Flow can have different settings, but they all share the connection details of the parent Micro-Integration. These parameters differ depending on whether Salesforce is configured as a source or a target.

Salesforce Source Parameters

The following table describes the parameters for configuring Salesforce as a source.

Field Description

Last Value Queue

The name of the Last Value Queue (LVQ) on the Solace event broker to use for checkpointing. The Salesforce Micro-Integration stores the last successful Salesforce Replay ID in the LVQ. The LVQ must exist on the same event broker and VPN as the target destination.

LVQ Provision Mode

The provision mode for Last Value Queue (LVQ). Allowed values are:

  • CREATE_IF_NOT_EXISTS—Create the LVQ if it does not exist.
  • NONE—Do not create the LVQ.

Destination

The source of events from Salesforce. For example, Change Data Capture events (/data/ChangeEvents and /data/<OBJECT_NAME>ChangeEvents) or Custom Events (/event/<CUSTOM_EVENT_NAME>__e).

Salesforce Target Parameters

The following table describes the parameters for configuring Salesforce as a target.

Field Description

Destination

The target destination. This must be a Custom Platform Event (for example, /event/<CUSTOM_EVENT_NAME>__e). Alternatively, you can set a Smart Topic Destination on the Mapping step, which will override this destination.

Platform Event Schema and Payload Format

When you configure Salesforce as a target, the messages you publish must match the schema of the Salesforce Platform Event. A payload mismatch is a common cause of 400 errors.

Naming Conventions

  • The API name for any custom Platform Event always ends with __e. For example, a Platform Event named TestEvent has the API name TestEvent__e.
  • The destination path follows the pattern /event/<EVENT_NAME>__e.
  • Custom fields always end with __c. For example, a field named message becomes message__c in the schema.

Standard Fields

Every Platform Event schema automatically includes the following fields regardless of what custom fields you add:

  • CreatedDate—a Unix timestamp in milliseconds (not seconds).
  • CreatedById—a non-empty string identifying the publisher. Must be a valid Salesforce user or entity ID string.

If a required field is missing from the payload, Salesforce rejects the event. This includes CreatedDate and CreatedById. If a custom field is optional (nullable), you can omit it or set it to null.

Payload Examples

The following examples show the format for some common payloads:

  • Platform Event with No Custom Fields

    {
      "CreatedDate": 1700000000550,
      "CreatedById": "05xx000001Sv6A"
    }
  • Platform Event with a Custom Text Field (message__c)

    {
      "CreatedDate": 1700000000550,
      "CreatedById": "05xx000001Sv6A",
      "message__c": "Hello World!"
    }

Retrieving the Schema for Your Platform Event

To confirm the exact schema for your event, use the Salesforce Platform Events REST API. For more information, see Get Event Schemas in the Salesforce documentation.

Testing the Target Micro-Integration

When you use a Salesforce Target Micro-Integration to publish Platform Events from your event broker service to Salesforce, don't rely solely on the triggering of Salesforce flows to verify that the Micro-Integration is working. If a Salesforce flow doesn't trigger, you won't know whether the problem is in the Micro-Integration or in the Salesforce flow configuration.

Instead, deploy a Salesforce Source Micro-Integration subscribed to the same Platform Event topic you are publishing to. When you publish a message through the Target Micro-Integration, the Source Micro-Integration receives it on the event broker service side. This approach:

  • Confirms that the message was received and accepted by Salesforce (not just sent by your event broker service)
  • Confirms that the payload matches the Platform Event schema
  • Eliminates Salesforce flow configuration as a variable in the test
  • Is easier to verify than inspecting internal Salesforce flow execution logs

Debug any issues with Salesforce flows not triggering only after you confirm that the round-trip works (Target Micro-IntegrationSalesforce → Source Micro-Integrationevent broker service).

Troubleshooting

The following troubleshooting tips might help you to resolve issues with this Micro-Integration. If problems persist, contact Solace.

Failed to Create Call Credentials

If you see the following error in the logs:

Failed to instantiate [com.solace.connector.core.io.sfdc.SFDCPubSub]:
Factory method 'sfdcPubSub' threw exception with message: Failed to create call credentials

Check for the following issues:

  • The Client ID or Client Secret is incorrect. Validate using the curl token request described in Salesforce OAuth 2.0 Client Credentials Parameters.
  • The Login URL points to the Setup URL (for example, my.salesforce-setup.com) instead of the base login URL.
  • The Client Credentials Flow is not enabled on the connected app in Salesforce.
  • The Run As user is not configured on the Client Credentials OAuth Policy.
  • Required OAuth scopes are missing. Try enabling all scopes to rule this out.
Salesforce REST API Error Codes

When the Micro-Integration logs contain HTTP error responses from Salesforce, refer to the Salesforce REST API Error Codes reference. The following table lists some common codes in this context:

HTTP Status Meaning Common Cause in Micro-Integration Context

400 Bad Request

Malformed request or schema mismatch

Payload does not match the Platform Event schema.

401 Unauthorized

Invalid or expired token

Credentials are wrong, scopes are insufficient, or token has expired.

403 Forbidden

Insufficient permissions

The Run As user does not have permission to publish or subscribe to the event.

404 Not Found

Resource not found

The Platform Event API name is incorrect. Ensure the __e suffix is present.

429 Too Many Requests

Rate limit exceeded

Publishing volume exceeds Salesforce Platform Event limits.

500 Internal Server Error

Salesforce-side error

Check Salesforce service status.

Micro-Integration Stops Working After Running Correctly

If a previously working Micro-Integration suddenly stops without any configuration change:

  • Check Salesforce service status at status.salesforce.com for any active incidents or maintenance windows affecting your instance or region.
  • Verify that the connected app in Salesforce has not been modified. For example, check whether the OAuth policy has been disabled or the Run As user deactivated.
  • For SOAP specifically: if the Salesforce account password was rotated, both the password and the security token will have changed. Update the Micro-Integration credentials. This is one of the primary reasons SOAP is not recommended for long-running Micro-Integrations.
Messages Published to Salesforce Are Not Triggering Flows

If the Micro-Integration is running without errors but Salesforce flows are not being triggered, perform the following steps:

  1. Confirm that the Platform Event is actually reaching Salesforce by deploying a Source Micro-Integration subscribed to the same event (see Testing the Target Micro-Integration). This separates the Micro-Integration layer from the Salesforce flow layer.

  2. If the Source Micro-Integration does receive the event, the Micro-Integration is working correctly—the issue is in the Salesforce flow configuration.

  3. Verify whether the Salesforce flow:

    • has the correct trigger event name
    • has entry conditions that may be filtering out the event
    • is activated