This guide is for IT and security teams evaluating Bliro's integration with Salesforce. It covers the authentication model, the permissions Bliro requests during consent, and how Bliro enforces tool-level permissions through its AI agents.

Overview

Bliro connects to Salesforce using user-delegated OAuth 2.0. Bliro acts on behalf of the signed-in user and cannot perform any action in Salesforce that the user themselves is not permitted to perform. The integration is delivered through Bliro's Salesforce Connected App.

Connected App name: Bliro

How the Integration Works

When a user connects Salesforce in Bliro, the following happens:

Bliro initiates an OAuth 2.0 authorization request against login.salesforce.com.
The user signs in to Salesforce and approves the requested scopes on the Allow Access screen.
Salesforce issues an access token, a refresh token, and the user's instance URL, all bound to the signed-in user.
Bliro uses the access token to call the Salesforce REST API on the user's home org instance URL on behalf of that user.
When the access token expires, Bliro silently refreshes it using the refresh token until the user disconnects or an administrator revokes access.

All Salesforce requests are scoped to the user's own identity and Salesforce permissions. Bliro never holds an integration-user or application-level credential against your Salesforce org.

Prerequisites

The user has a valid Salesforce license with API access (the API Enabled permission on their Profile or via a Permission Set).
Your Salesforce org allows the Bliro Connected App. If the org uses the "Admin approved users are pre-authorized" policy, an administrator must permit the Bliro Connected App for the user's Profile or Permission Set before the user can complete the OAuth flow.
The user is signed in to Bliro.

Setup: Connecting Bliro to Salesforce

In Bliro, open Integrations and select Salesforce.
Click Connect. Bliro redirects you to the Salesforce sign-in page (login.salesforce.com).
Sign in with your Salesforce credentials.
On the Allow Access screen, review the requested permissions and click Allow. The requested permissions are listed in detail in the next section.
Bliro redirects you back to the integration page.
Configure the Tools & Permissions that Bliro is allowed to use on your behalf.

Requested Permissions (OAuth Scopes)

During consent, Bliro requests exactly the following four scopes for the Salesforce integration. Each is listed below with its purpose and justification.

Scope	Justification
openid	Standard OpenID Connect scope. Required to identify the user and link the Salesforce connection to the correct Bliro account.
refresh_token	Same purpose as offline_access; this is the canonical Salesforce scope name for refresh-token issuance and is required to support long-running, non-interactive use. This scope does not grant any additional data access on its own.
api	Required to call the Salesforce REST API on behalf of the signed-in user. This is the scope that lets Bliro read or write Salesforce records, but always strictly within the user's existing Salesforce Profile, Permission Sets, Sharing Rules, and Field-Level Security. Bliro cannot read or change records the user themselves cannot.

Tools and Permissions

Even with the api scope granted, Bliro does not perform any Salesforce operation by default. Each individual action Bliro can take, for example Read Account, Create Contact, or Update Opportunity, is modeled as a tool with its own permission level, configured by an organization administrator.

For Salesforce, administrators can also create custom tools by selecting any Salesforce object; Bliro then automatically generates the corresponding Read, Create, and Update tools for it.

For a full explanation of the tool model, permission levels, the Ask for Permission flow, and how Bliro enforces denied tools, see AI Tools and Permissions.

Security Considerations

User-delegated only. Bliro never holds an integration-user or application-level credential against your Salesforce org. Every API call is authenticated as the user, and Salesforce applies that user's Profile, Permission Sets, Sharing Rules, and Field-Level Security on each request.
Token storage. Refresh tokens are stored encrypted at rest. Access tokens are short-lived and held only for the duration of an operation.
Auditability in Salesforce. Because Bliro acts as the user, every read and write is attributed to that user in Salesforce (Created By / Last Modified By fields, Field History Tracking, Setup Audit Trail, and Event Monitoring where licensed), making activity reviewable through native Salesforce tooling.
Org login and session policies. Any login or session policy your org enforces (Login IP Ranges, MFA, session timeouts, login hours, and Connected App access policies) applies equally to Bliro's calls.

Disconnecting and Revoking Access

Users can disconnect Salesforce at any time from the integration screen in Bliro by clicking Disconnect. This deletes the refresh token from Bliro's side and ends Bliro's ability to call Salesforce on the user's behalf.

In addition, the user can revoke Bliro's access directly in Salesforce under Personal Settings → Advanced User Details → OAuth Connected Apps → Revoke. Administrators can revoke Bliro's access org-wide via Setup → Connected Apps OAuth Usage, where the Bliro Connected App can be blocked or have individual user tokens revoked.