Microsoft 365 integrations (rA Meetings)
The rA Meetings app runs in SharePoint and Teams — in your employees’ browsers, with no server of its own. For it to transfer a decided outcome to roleALPHA or ask a governance question, roleALPHA has to accept the sign-in that already exists there: the Microsoft sign-in of the person sitting in the meeting.
For your employees that means: no second sign-in, no consent dialog, no address to type. The draft appears in roleALPHA under their name, with exactly their permissions, in the right tenant.
What you set up
Section titled “What you set up”Two fields, once, under AI settings → Microsoft 365 integrations:
| Field | What goes in |
|---|---|
| Directory ID | The Directory (tenant) ID of your Microsoft 365 directory. You find it in the Entra portal under Overview. |
| Allowed addresses | The addresses access may come from — your SharePoint address, plus https://teams.microsoft.com for Teams. One per line. |
The External AI applications switch above is a prerequisite. With it off, this connection is off too.
Empty field = switched off. Without a directory ID roleALPHA refuses every request, no matter how valid the Microsoft token presented is.
There is one step on the Microsoft side, done by your Microsoft 365 administration: approving the permission for roleALPHA (API access in the SharePoint admin center). rA Meetings ships the instructions for it.
The values for rA Meetings
Section titled “The values for rA Meetings”As soon as a directory ID is in the field, a block with four values appears below it. These are exactly the four the rA Meetings setup wizard asks for in step 4 (“Set up connections”). They appear nowhere else — before this, you had to ask for them.
| Field in rA Meetings | What it is |
|---|---|
| roleALPHA MCP address | The address the app talks to. |
| Resource (Application ID URI of the service) | How roleALPHA identifies itself to Microsoft as an API. It applies to the whole installation and is maintained by platform administration, not by you. |
| Delegated permission (scope) | The scope the Microsoft token has to carry — usually access_as_user. |
| roleALPHA tenant ID | Your tenant in roleALPHA. Not to be confused with the directory ID above: that one belongs to Microsoft, this one to roleALPHA. Both look alike. |
The MCP address is the central sign-in address — even if you otherwise use roleALPHA via your own company domain. That is not an oversight: the Microsoft token is exchanged on the sign-in domain, and the result is valid for exactly the address named there. Enter your company domain and every request is refused — with a message that does not name the address. So copy the address from the block instead of typing it.
Below the values there is a short list, “What else has to be true”. It shows for each point whether it is done: the switch for external applications, the saved directory ID, at least one allowed address, the Application ID URI and the central sign-in domain. Only platform administration can set the last two; while either is open, the connection is off regardless of what you enter.
One condition cannot be shown there, and it is still the most common cause: every person must have signed in to roleALPHA via Microsoft at least once (see below).
How the sign-in works technically
Section titled “How the sign-in works technically”The notable part is what does not happen: roleALPHA does not pass the Microsoft token on as a ticket. It verifies it and exchanges it for its own short-lived roleALPHA token.
- The app holds the signed-in person’s Microsoft token.
- It exchanges that at roleALPHA for a roleALPHA token (valid one hour).
- With that token it talks to the roleALPHA endpoint.
During the exchange roleALPHA checks five things, and any of them can end the request:
- The signature really comes from Microsoft — from your directory.
- The token was issued for roleALPHA, not for some other application.
- It is a token for a person. Tokens an application obtains without a person (“service account”) are rejected.
- The person is known in roleALPHA (see below).
- The tenant has the feature switched on.
Permissions never come from the Microsoft token. roleALPHA looks them up fresh, exactly as for a sign-in through the web interface. Whatever someone may not see or change in roleALPHA, they cannot see or change through the app either.
Why a person must sign in to roleALPHA via Microsoft once
Section titled “Why a person must sign in to roleALPHA via Microsoft once”The mapping runs on the object ID from your directory — not on the email address. roleALPHA remembers that ID when the person signs in via Microsoft. While it is missing, the exchange answers with a note to sign in to roleALPHA via Microsoft once; after that the app works permanently.
There is a reason for the detour: an email address changes, the object ID does not. See Single Sign-On (SSO).
What to know before switching it on
Section titled “What to know before switching it on”The approval applies to your whole directory, not just rA Meetings. Microsoft grants SharePoint extensions their permissions through a shared principal of the tenant. Technically any SharePoint extension in your directory can therefore use this connection — bounded by each person’s permissions in roleALPHA, but not limited to a single app. If you do not want that, restrict how extensions are distributed in SharePoint.
No wildcards in addresses. https://*.sharepoint.com would give every SharePoint site of
every Microsoft customer access. The field rejects such entries.
Guest accounts from other directories are not mapped unless they have an account of their own in roleALPHA.
When it does not work
Section titled “When it does not work”| Message or symptom | Cause |
|---|---|
| “No Entra directory is configured for this tenant” | The directory ID is missing. |
| “External applications are … not enabled” | The switch above is off. |
| “This account is … not linked to the directory” | The person has never signed in to roleALPHA via Microsoft. |
| “The token presented was not accepted” | Wrong directory, missing approval in Entra, or a token without a person. The exact reason is in the log. |
| The app reports a network error while roleALPHA logs nothing | The app’s address is not under Allowed addresses. |
| The block with the four values does not appear | The Directory ID field is empty or holds something that is not a valid GUID. |
| The block says the Application ID URI is not configured | That is a platform setting, not your tenant’s. While it is missing, every Microsoft token is refused — please contact platform administration. |
| All four values are entered and it still does not work | Usually the MCP address: your own company domain does not work there (see above). |
Seeing and ending connections
Section titled “Seeing and ending connections”Every connection appears under Connected applications — one row per person. It can be ended there individually; whoever was ended gets no new access until the connection is set up again for the tenant.
The fastest way to end everything is to clear the directory ID or switch off external applications. Both take effect immediately and also end running sessions.
Related
Section titled “Related”- Single Sign-On (SSO) — the Microsoft sign-in that makes the mapping possible in the first place
- Sign-in methods — which sign-in methods a tenant permits