For the complete documentation index, see llms.txt. This page is also available as Markdown.

Salesforce

Integrating Salesforce with ThreatDefence allows you to securely ingest audit, user, and application activity into the ThreatDefence platform for centralized monitoring and incident response. The following steps guide you through configuring authentication, creating an integration user, and providing the necessary API credentials.

This integration authenticates using the OAuth 2.0 Client Credentials Flow — a server-to-server flow that requires no username or password and no interactive login. Instead, the integration presents a Connected App's Client ID and Client Secret to Salesforce, and Salesforce returns an access token that runs as a designated integration user.


Prerequisites

Before you begin, confirm the following. If they are not in place, the integration will authenticate successfully but collect little or no data — most queries return zero records without raising an error.

  • Event Monitoring (Salesforce Shield or the Event Monitoring add-on) — required for the core data this integration collects (login, logout, URI, permission-update, report, and list-view activity). Without it, these objects return no records.

  • Einstein Threat Detection — required only for threat-detection events (report anomaly, API anomaly, credential stuffing, session hijacking). If absent, these specific events stay empty.

  • A Salesforce user licence that includes API access for the integration user (see Step 1). The Salesforce Integration licence is recommended; API-only or standard licences with API access are also suitable.

If you are unsure whether your org has Event Monitoring, search for Event Monitoring under Setup or check with your Salesforce account team. Standard editions without Shield will not return log data.


Step 1. Create a Dedicated Integration User

The Client Credentials Flow issues tokens that act on behalf of a single Run-As user. Create a dedicated user for this purpose so activity is clearly attributable and easy to audit.

  1. Log in to Salesforce as a System Administrator.

  2. In Setup, search for Users in the Quick Find box and open Users.

  3. Click New User.

  4. Complete the user creation form (name, email, profile/role). Where available, assign the Salesforce Integration user licence with the Minimum Access – API Only Integrations profile.

  5. Save changes.

Salesforce New User

If licence limits prevent creating a new user, you may reuse an existing user with sufficient permissions.

No password is required for this integration — the Client Credentials Flow never uses the integration user's login credentials. You do, however, need this user's permissions (Step 2) and it must be selected as the Run-As user (Step 5).


Step 2. Assign Required Permissions to the Integration User

The integration user must be granted the following permissions, either directly through its Profile or — recommended — through a dedicated Permission Set that you create and assign. These permissions are mandatory: without them the integration cannot read events or enrich usernames.

Permission
Why it is needed

API Enabled

Allows the user to authenticate and call the Salesforce REST API. Without it, all requests are rejected.

View Event Log Files

Required to read login, logout, URI, and permission-update event log files.

View Real-Time Event Monitoring Data

Required to read report, list-view, and threat-detection events.

View All Users

Required so the integration can resolve user IDs to usernames. Without it, events are still collected but usernames may be missing.

View Setup and Configuration

Only needed if Setup Audit Trail collection is enabled. Optional otherwise.

To create a Permission Set:

  1. In Setup, search for Permission Sets and click New.

  2. Give it a name (e.g. ThreatDefence Integration) and save.

  3. Open System Permissions, click Edit, enable the permissions listed above, and save.

  4. Click Manage Assignments → Add Assignment, select the integration user, and assign.

If you reused an existing user (per Step 1), confirm it already carries these permissions.


Step 3. Create a New Connected App

  1. In Setup, search for Apps.

  2. Go to App Manager → New Connected App (top-right corner).

Salesforce App Manager
Salesforce OAuth Settings
  1. Complete the required fields — Connected App Name, API Name, and Contact Email (you may use any valid email).

Salesforce App Details

Step 4. Enable OAuth and the Client Credentials Flow

  1. In the Connected App, check Enable OAuth Settings.

  2. Enter any valid Callback URL (e.g. https://login.salesforce.com/services/oauth2/callback). It is not used by the Client Credentials Flow but the form requires a value.

  3. Under Selected OAuth Scopes, add at a minimum Manage user data via APIs (api). If you also want long-lived tokens, add Perform requests at any time (refresh_token, offline_access). The other scopes (Data Cloud cdp_*, Pardot, etc.) are not required and can be left unselected.

Salesforce OAuth Scopes
  1. Check Enable Client Credentials Flow. Acknowledge the confirmation prompt that warns access tokens will run as the Run-As user you assign in Step 5.

  2. Leave Require Proof Key for Code Exchange (PKCE) and the username–password options unchecked — they do not apply to this flow.

  3. Save changes, then wait a few minutes for the app to propagate (Salesforce may show a "changes can take up to 10 minutes" notice).


Step 5. Set the Run-As User and Relax IP Restrictions

The Client Credentials Flow has no interactive user, so Salesforce must know which user's context and permissions to apply to the issued token. This is the integration user from Step 1. Relaxing IP restrictions on the app avoids token requests being blocked by login-IP policies.

  1. In Setup, search for Apps → Connected Apps → Manage Connected Apps.

  2. Locate the Connected App you created and click its name.

Salesforce Manage Connected Apps
  1. Select Edit Policies.

  2. Under Client Credentials Flow, set Run-As to the integration user you created in Step 1.

  3. In the OAuth Policies section, set Permitted Users to Admin approved users are pre-authorized (then ensure the integration user is granted access via its Profile or Permission Set), and set IP Relaxation to Relax IP restrictions.

  4. Save changes.

Salesforce OAuth Policy Edit

Step 6. Obtain the App's Client ID and Client Secret

  1. In Setup, go to Apps → App Manager.

  2. Find the Connected App you created for ThreatDefence integration.

  3. From the row menu (dropdown on the right), select View.

Salesforce App Manager View
  1. In the API section, click Manage Consumer Details (requires a verification code sent to the admin email).

Salesforce Consumer Details Verification
  1. On the Consumer Details page, copy the following values:

    • Consumer Key (Client ID)

    • Consumer Secret (Client Secret)

Salesforce Consumer Key and Secret

Anyone with the Consumer Key and Consumer Secret can obtain an access token that runs as your integration user. Store these values securely and rotate the Consumer Secret periodically.


Step 7. Obtain Your Salesforce Domain

  1. In Setup, search for Domain.

  2. Go to Company Settings → My Domain.

  3. In the My Domain Details section, copy the Current My Domain URL.

Salesforce My Domain Settings

Final Step. Provide Credentials to ThreatDefence

Share the following values with your ThreatDefence representative at support@threatdefence.com:

  1. Client ID — Consumer Key from the Connected App

  2. Client Secret — Consumer Secret from the Connected App

  3. Domain URL — Current My Domain URL from My Domain settings

ThreatDefence will configure ingestion using these details. Once configured, audit, user, and application activity from your Salesforce org will begin flowing into the ThreatDefence platform. If no data appears, the most common cause is a missing Event Monitoring licence or one of the permissions in Step 2 — review the Prerequisites and Step 2 above. If authentication fails, confirm the Client Credentials Flow is enabled on the app (Step 4) and that a Run-As user is assigned (Step 5).

Last updated