Entra App Registration

Once the extension is installed, sign in to Business Central with a user that has SUPER permission and open the Elevate Approvals Setup page from the search bar. From there you complete a one-off registration step before the connector can talk to the portal.

Why you need an app registration

The connector needs a Microsoft Entra app registration in your own tenant that it can use to obtain an access token for the Elevate API. The token must carry the application role that the API exposes for BC connectors; without that role the portal rejects the call and nothing will sync.

You create this app registration once. The same registration covers both the push direction (lookups, master data) and the pull direction (approved requests). Equerra's own API app registration needs nothing from you: it never calls into BC.

Who needs to do this

The person performing the setup must be a Cloud Application Administrator or Application Administrator in your Entra tenant. The final consent step requires a Global Administrator, because it grants an application permission tenant-wide.

Create the registration

1. Sign in to the Microsoft Entra admin centre at https://entra.microsoft.com.
2. Go to Identity > Applications > App registrations and choose New registration.
3. Name: pick something recognisable, for example Elevate Approvals BC Connector.
4. Supported account types: choose Accounts in this organizational directory only (single tenant). The connector only ever runs inside your own tenant.
5. Redirect URI: leave blank. Client credentials flow does not use a redirect URI.
6. Choose Register.
7. From the Overview blade, copy and save the Application (client) ID and the Directory (tenant) ID.

Add a client secret

1. Open Certificates & secrets > Client secrets > New client secret.
2. Give it a description (for example BC connector secret) and an expiry. Pick the longest expiry your security policy allows, since rotating means a small outage on the connector while the new secret propagates.
3. Choose Add, then immediately copy the Value column. Microsoft does not show this value again. The Secret ID column is not the secret; do not use it.
4. Store the secret in your secrets manager. Treat it like a password.

If you would rather use a certificate, the Certificates tab supports that with the same role assignment. Equerra recommends a client secret for simplicity unless your policy mandates certificates.

Request the connector role on Equerra's API

The Elevate API exposes an application role for BC connectors. Your app registration needs it.

1. Open API permissions > Add a permission.
2. Choose APIs my organization uses, then search for and select Equerra Elevate API. Equerra confirms the exact name during onboarding.
3. Choose Application permissions (not Delegated).
4. Tick the connector role and choose Add permissions.
5. Back on the API permissions list, choose Grant admin consent for <your tenant>. This step requires Global Administrator and applies tenant-wide.
6. Confirm the consent dialog. The status column should change to a green tick.

The portal checks every incoming request for this role and rejects app-only tokens that do not carry it, so the sync will not work until it is granted.

If you are also testing against a non-production Elevate environment alongside your production one, note that each environment has its own, separate Equerra app registration, each exposing its own connector role. Admin consent granted against one does not cover the other: you need a separate permission grant and consent per environment you point BC at.

Hand the credentials to BC

This step is the most common source of setup errors, because it involves two different app registrations and it is easy to put a value from one into the field meant for the other. Keep them straight:

• Your own app registration (created above, living in your Entra tenant) supplies the values that say who is calling.
• Equerra's "Elevate API" app registration (living in Equerra's tenant) supplies the value that says what you are calling. You never authenticate as this app and you never create a secret for it: you only need its Application ID URI.

Plug these into the Elevate Approvals Setup page. There is no separate endpoint record to create; these fields live directly on this page:

Field on Elevate Approvals Setup	Value	Comes from
OAuth Client ID	Application (client) ID	Your own app registration
Client Secret	The secret Value (not the Secret ID)	Your own app registration
OAuth Token Endpoint URL	https://login.microsoftonline.com/{your-tenant-id}/oauth2/v2.0/token, using your own Directory (tenant) ID	Your own tenant, always, even against Equerra's Elevate API
OAuth Scope	Equerra's Elevate API Application ID URI plus /.default, for example api://<equerra-app-id>/.default. Ask Equerra to confirm it for your target environment	Equerra's app registration, never yours
Base URL	The Elevate API's base URL for your environment. Equerra provides this during onboarding	Equerra provides this
Endpoint Code	Any label you like (for example PROD)	Not a lookup value, you choose it

A quick sanity check before moving on: the Token Endpoint URL should contain your tenant ID, never Equerra's. The Scope should contain Equerra's app ID, never yours. Putting your own Client ID into the Scope field, or Equerra's app ID into the Client ID field, is the single most common mistake here and it will fail Test Connection. See Troubleshooting if that happens.

Rotation

Client secrets expire. Set a calendar reminder for two weeks before the expiry date so you can issue a replacement, plug it into the Client Secret field on Elevate Approvals Setup, and confirm Test Connection still passes before the old secret expires. There is no automatic rotation today.

What the portal sees

When BC calls the portal with this token, the portal:

• Reads the tenant claim and looks up your tenant in its registry. If your tenant is not registered the call is rejected and no data is read.
• Confirms the connector role is present in the token. If not, the call is rejected.
• Treats the call as a service-account action. The audit trail records the calling app alongside any data change so you can always tell BC pushes apart from human actions.

App-only tokens are also explicitly blocked from actions that require a human actor (approve, reject, comment, change personal preferences). You do not need to configure anything for this; it is enforced by the portal itself.