# Office365 Graph Role-Based Access Control (RBAC)

This is a variant of the [Office 365 Graph service account](/developers/authorization/enterprise-connect/service-account/index.md) connection for customers whose security policy forbids granting Cronofy a tenant-wide application permission. Instead of consenting to `Calendars.ReadWrite` across the whole tenant, the administrator authorizes Cronofy on identity alone and then scopes its access to a chosen set of mailboxes with Exchange Online Role-Based Access Control (RBAC).

You deep-link an administrator into this path. The administrator's side of the setup is documented in the [calendar admin RBAC guide](/calendar-admins/enterprise-connect-office365-graph/restrict-data-access-by-rbac-without-tenant-wide-permissions/index.md); share that link with them.

## Deep-linking to the RBAC path
Start from the [Enterprise Connect authorization request](/developers/api/enterprise-connect/request-authorization/index.md) you already use to onboard service accounts. Pre-select the Office 365 provider with [`provider_name=office365`](/developers/api/authorization/request-authorization/index.md) and add `provider_connection_variant=rbac`:

```
https://app.cronofy.com/enterprise_connect/oauth/authorize
    ?response_type=code
    &client_id={CLIENT_ID}
    &redirect_uri={REDIRECT_URI}
    &scope={SCOPE}
    &delegated_scope={DELEGATED_SCOPE}
    &provider_name=office365
    &provider_connection_variant=rbac
    &state={STATE}
```

##### `data_center_app_url` *(required)*

The URL for the data center you want to communicate with. Possible choices are:

- `app-au.cronofy.com` - Australia
- `app-ca.cronofy.com` - Canada
- `app-de.cronofy.com` - Germany
- `app-sg.cronofy.com` - Singapore
- `app-uk.cronofy.com` - United Kingdom
- `app.cronofy.com` - United States

Find out more about [Cronofy's data centers](/developers/data-centers/index.md).
##### `provider_connection_variant` *(optional)*

All other parameters are exactly as documented for the [Enterprise Connect authorization request](/developers/api/enterprise-connect/request-authorization/index.md).

## What the administrator experiences
- They must sign in as a **Global Administrator** of the Microsoft 365 tenant. Any other account is rejected with an `access_denied` error, and they are returned to your `redirect_uri` with that error rather than a `code`.

- Microsoft's admin-consent screen is **not** shown, because no tenant-wide permission is requested.

- They are returned to your application as with any other successful Enterprise Connect authorization, and separately complete an Exchange Online role assignment out of band to grant Cronofy access to the mailboxes they choose.

## What to expect on your side
- **The service account is created before any calendar access is proven.** This connection skips the directory read that normally confirms access, so a connection exists as soon as the administrator returns. Cronofy cannot read any calendar until the administrator's Exchange role assignment has propagated and the first sync succeeds.

- [Requesting delegated access](/developers/api/enterprise-connect/delegated-access/index.md) to a user's calendar before the role assignment is in place, or for a mailbox outside the administrator's scope, will fail with `impersonation_denied`.

- Aside from resource listing (see below), the connection otherwise behaves like any other Graph service account: you request [delegated access](/developers/api/enterprise-connect/delegated-access/index.md) to a user or resource in the same way.

## Resources must be authorized as accounts
An RBAC connection is granted a scoped calendar role, not the tenant-wide `Place.Read.All` permission that lets Cronofy read the directory's room and resource lists. As a result, [the List Resources endpoint](/developers/api/enterprise-connect/list-resources/index.md) returns an **empty list** for an RBAC connection, the same as it does for a [Free/Busy](/developers/authorization/access-modes/free-busy/index.md) connection. You cannot discover a customer's rooms and resources through Cronofy on this connection.

Instead, authorize each resource or room the same way you authorize a user: request [delegated access](/developers/api/enterprise-connect/delegated-access/index.md) using the resource's email address. The administrator must include those resource mailboxes in the RBAC management scope so that Cronofy can reach them, exactly as they do for user mailboxes.

## Microsoft caching
Exchange Online does not evaluate the RBAC role assignment on every request; it caches the authorization result for a mailbox. The cache can persist anywhere between 30 minutes to 2 hours. Microsoft documents this limitation [here](https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac#limitations) This means:

- **A newly scoped mailbox may not be reachable immediately.** After the administrator adds a mailbox (user or resource) to the management scope, there may be a delay before Cronofy can access it. Delegated access requested inside that window may fail until Microsoft's cache refreshes.

- **Removing a mailbox from scope may not be immediate either.** Access can persist briefly after the administrator removes a mailbox from the scope, until the cached decision expires.

If a mailbox that should be in scope is not syncing, ask the administrator to re-run the `Test-ServicePrincipalAuthorization` check in the [RBAC guide](/calendar-admins/enterprise-connect-office365-graph/restrict-data-access-by-rbac-without-tenant-wide-permissions/index.md); an `InScope : True` result that still will not sync usually means the cache has not yet caught up.


---
[Read in HTML](/developers/authorization/enterprise-connect/office365-graph-rbac-without-tenant-wide-permissions/)