This guide is for IT administrators and security teams evaluating Bliro's integration with SAP Sales Cloud (also known as SAP Cloud for Customer or C4C). It covers the authentication model, the configuration required on both the SAP and Bliro sides, how user permissions are enforced, and how Bliro manages tool-level access through its AI agents.

Overview

Bliro connects to SAP Sales Cloud using the OAuth 2.0 SAML Bearer Assertion flow (RFC 7522). An organization administrator configures the connection once at the organization level in Bliro. Bliro then uses this connection to access SAP C4C on behalf of each organization member, with all API requests scoped to the individual user's SAP permissions. Bliro cannot perform any action in SAP that the matched SAP user is not permitted to perform.

Unlike Bliro's Dynamics 365 or Salesforce integrations, SAP Sales Cloud does not use a browser-based per-user OAuth consent flow. Instead, the SAP CRM administrator configures the trust relationship and shares the connection details with Bliro. Once connected at the organization level, all organization members can use the integration without individually signing in to SAP.

The integration works regardless of which Identity Provider (IdP) the customer uses for their SAP system - Microsoft Entra ID, SAP Cloud Identity Services (IAS), Okta, or any other SAML-compatible IdP.

How the Integration Works

When Bliro accesses SAP Sales Cloud on behalf of a user, the following happens:

The Bliro organization administrator configures the SAP connection in Bliro's admin settings by entering the SAP tenant details, OAuth client credentials, OData scopes, and a signing private key.
When a Bliro user triggers an action that requires SAP data (for example, after a meeting ends), Bliro's backend generates a SAML 2.0 assertion. The assertion identifies the user by their email address and is signed with the private key configured in step 1.
Bliro sends the signed SAML assertion to the SAP C4C OAuth token endpoint and exchanges it for a short-lived access token bound to the matched SAP named user.
SAP C4C validates the SAML assertion signature against the trusted Identity Provider configured by the SAP administrator, maps the email address in the assertion to a SAP named user, and issues the access token.
Bliro uses the access token to call the SAP C4C OData API. SAP enforces the matched user's Work Center and View Assignments, Business Roles, and access restrictions on every request.
When the access token expires (typically after one hour), Bliro generates a new SAML assertion and repeats the exchange. This happens automatically in the background without any user interaction.

All SAP requests are scoped to the individual user's SAP identity and permissions. Bliro never uses a shared technical user with elevated access.

Prerequisites

The organization has an active SAP Sales Cloud (C4C) tenant.
A SAP CRM administrator has completed the SAP-side configuration described in the next section (Identity Provider, OAuth client, scopes, and user permissions).
Each Bliro user who should access SAP data must exist as a named Business User in SAP C4C with the same email address as their Bliro account.
The Bliro user who configures the integration must be an organization administrator in Bliro.

Setup Part 1: SAP CRM Administrator Configuration

Before the integration can be enabled in Bliro, a SAP CRM administrator must complete the following steps in the SAP C4C administration backend. These steps establish the trust relationship that allows Bliro to request access tokens on behalf of individual users.

Step 1 - Register the Identity Provider

The SAP system must trust the certificate that Bliro uses to sign SAML assertions.

Navigate to Administrator → General Settings → OAuth 2.0 Identity Provider Configuration.
Create a new Identity Provider.
Enter an Issuer Name (for example, Bliro-API-App). This name must exactly match the issuer value in the SAML assertions Bliro generates. The Bliro organization administrator will enter this same value in Bliro's SAP settings under "Identity provider name."
Upload the public signing certificate (.cer file) provided by your Bliro organization administrator.
Under Name Identifier Formats, enable E-Mail Address. This is how SAP matches the SAML assertion to a named Business User.

Step 2 - Register the OAuth 2.0 Client

This creates the technical API credentials for Bliro.

Navigate to Administrator → General Settings → OAuth 2.0 Client Registration.
Click New to create a new client.
In the SAML Issuer dropdown, select the Identity Provider created in Step 1.
Save the configuration. SAP generates a Client ID (for example, _1829727704O) and a Client Secret. Note both values - the Bliro organization administrator needs them.
Set the Token Lifetime to 3600 seconds (1 hour) or your preferred value.

Step 3 - Define OData Scopes

The OAuth client must know which SAP data areas it is permitted to access. Scopes are defined as Work Center codes.

In the OAuth 2.0 Client Registration, open the client created in Step 2.
Under Registered Scopes, select the Work Centers Bliro should be able to access.

Common scopes for a typical sales integration:

Scope	Description
`UIWC:CODACCOUNTWC`	Corporate Accounts
`UIWC:CODPARTNERWC`	Partners
`UIWC:CODPEOPLE`	People / Contacts
`UIWC:COD_ACTIVITIES`	Activities (visits, calls, tasks)
`UIWC:CC_HOME`	Home (general access)

Additional scopes can be added depending on the use case. Only grant scopes required for your business process.

Step 4 - Verify Business User Permissions

The OAuth access token uses the identity of a real SAP Business User. This user must exist in SAP C4C and have the appropriate read and write permissions.

Navigate to Administrator → User Management → Business Users.
Search for the user whose email address matches the Bliro user's account (for example, [email protected]).
Open the user's Access Rights.
Under the Work Center and View Assignments tab, verify that the required Work Centers are assigned to the user (for example, CODACCOUNTWC for Account access).

Repeat this for each user who will use the Bliro integration. Users whose email address does not match a SAP Business User, or whose Business User lacks the required Work Center assignments, will receive an error when Bliro attempts to access SAP on their behalf.

Setup Part 2: Bliro Organization Administrator Configuration

Once the SAP CRM administrator has completed the steps above, the Bliro organization administrator configures the connection in Bliro.

In Bliro, open Integrations and select SAP.
Enter the following values provided by the SAP CRM administrator:

Field	Description
Tenant	The SAP C4C tenant subdomain (for example, `my370045-sso`).
Identity provider name	The Issuer Name configured in the SAP Identity Provider (Step 1). Must match exactly.
Client ID	The OAuth Client ID generated in Step 2 (for example, `_1829727704O`).
OData scopes	The Work Center scope codes configured in Step 3, space-separated (for example, `UIWC:CODACCOUNTWC UIWC:CODPARTNERWC UIWC:CODPEOPLE UIWC:CC_HOME`).
Client secret	The OAuth Client Secret from Step 2.
Signing private key (PEM)	The PEM-encoded private key corresponding to the public certificate uploaded to SAP in Step 1.

Click Save Configuration. Bliro validates the connection by attempting a test token exchange.
Once connected, the integration is propagated to all organization members. Configure the Tools & Permissions that Bliro is allowed to use (see below).

Account Matching

Bliro matches each organization member to their SAP Business User based on their email address. When Bliro generates a SAML assertion for a user, it sets the assertion's Subject (NameID) to the user's Bliro email address. SAP C4C then looks up the Business User with the matching email.

This means:

Every Bliro user who should have SAP access must have a corresponding SAP Business User with the same email address.
If a Bliro user's email does not match any SAP Business User, SAP will reject the token request and the user will see an error in Bliro.
Organization administrators should only enable the SAP integration for users who have active SAP accounts. Users without SAP access will not be able to use SAP-related tools in Bliro.

Tools and Permissions

Even with a valid SAP connection, Bliro does not perform any SAP operation by default. Each individual action Bliro can take - for example Read Account, Create Visit Report, or Update Contact - is modeled as a tool with its own permission level, configured by an organization administrator.

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.

To go beyond individual tool calls and define repeatable, multi-step workflows for your team (for example, automatically composing a visit report in a specific format after every meeting), see AI Skills.

Security Considerations

User-scoped access. Every SAP API call is made in the context of the individual user's SAP identity. SAP C4C enforces that user's Work Center and View Assignments, Business Roles, and access restrictions on every request. Bliro cannot access records or perform actions that the matched SAP user cannot.
No shared technical user. Bliro does not use a single technical integration user with broad permissions. Each API call is authenticated as the individual named Business User, preserving per-user data scoping.
IdP-independent. The integration works regardless of which Identity Provider the customer uses for their SAP system (Microsoft Entra ID, SAP Cloud Identity Services, Okta, or others). The SAML assertion is signed by Bliro and validated by SAP directly - the customer's IdP is not in the runtime path.
Credential storage. The client secret and signing private key are stored encrypted at rest in Bliro's backend. Access tokens are short-lived (typically one hour) and cached only for the duration of their validity. Bliro does not store SAP user passwords.
Auditability in SAP. Because Bliro acts as the individual named user, every read and write is attributed to that user in SAP C4C's change and audit logs, making activity reviewable through native SAP tooling.
Principle of least privilege. The OData scopes configured on the OAuth client define the maximum data areas the integration can access. Within those scopes, each user's access is further restricted by their individual Work Center and View Assignments. Organization administrators should only grant the scopes required for their business process.

Disconnecting and Revoking Access

From Bliro: The Bliro organization administrator can disconnect the SAP integration at any time from the SAP integration page by clicking Disconnect. This removes the stored credentials (client secret and signing private key) from Bliro and ends Bliro's ability to access SAP for all organization members.

From SAP: The SAP CRM administrator can revoke Bliro's access at any time by either:

Deleting or deactivating the OAuth 2.0 Client in Administrator → General Settings → OAuth 2.0 Client Registration.
Removing or deactivating the Identity Provider in Administrator → General Settings → OAuth 2.0 Identity Provider Configuration.
Removing individual users' Work Center assignments to restrict access on a per-user basis.