Limiting AskCody's access in Exchange Online
Learn what restricting AskCody's access means in the AskCody Platform, what the allowed scope must contain, and what to check before you enforce it
By default, the application permissions granted to AskCody in Exchange Online apply to all mailboxes in your organization. Some organizations prefer to restrict an application's access to a defined scope. Microsoft supports this, and AskCody fully supports running behind such a restriction. This article is written for the IT Admin planning or reviewing that restriction.
What the allowed scope must contain
For the AskCody Platform to work correctly behind a restriction, the allowed scope must contain:
- Every room and desk mailbox connected to AskCody.
- The user mailboxes of everyone who books or attends meetings in those rooms, not only the people who book through the AskCody Platform.
If your organization restricted the earlier EWS application, the simplest rule is: give the Microsoft Graph application the same scope your EWS application had. The platform needs the same reach it had before the upgrade; the restriction just has to be re-created for the new application (see point 4 below).
How the restriction is configured
The restriction is configured and enforced by Microsoft in your tenant, not by AskCody. Microsoft's current mechanism is Role Based Access Control (RBAC) for Applications in Exchange Online, which replaces the earlier Application Access Policies. Because Microsoft owns and evolves this mechanism, we do not document the setup steps here. Follow Microsoft's own documentation:
- Role Based Access Control for Applications in Exchange Online (includes Microsoft's guide for migrating an existing Application Access Policy to RBAC for Applications)
Note: If your integration still has the connection type Exchange Online (Office 365), upgrade to Microsoft Graph before configuring the restriction. Scoping is simpler to set up and verify on the Microsoft Graph integration. See How to upgrade your Exchange Online integration to Microsoft Graph.
What scoping AskCody's access means in the platform
1. AskCody can only see what your restriction allows. If a calendar connected to AskCody is not within the allowed scope, that calendar stops updating in AskCody: rooms appear blank on Displays, bookings no longer sync, and service requests stop following meeting changes. If rooms go blank shortly after a restriction is introduced, check the scope membership first.
2. Include the user mailboxes, not only the room mailboxes. The AskCody Platform does not only work with the room's copy of a meeting. AskCody reads the organizer's calendar to keep a meeting in sync after it is booked and to attribute meetings to rooms in Insights, and it writes to the organizer's calendar when a meeting is booked or managed through the AskCody Platform. This applies to meetings booked in Outlook too, not only to bookings made through AskCody. A scope limited to room mailboxes therefore leaves services, visitor registrations, and utilization data incomplete, even when all booking happens in Outlook, and blocks users outside the scope from booking through AskCody. This is not new with Microsoft Graph: the EWS integration read organizer calendars the same way, which is why re-creating your EWS scope preserves the behavior you had.
Note: A rooms-only scope is not sufficient, even if your users only ever book from Outlook. Include the user mailboxes of everyone who books or attends meetings in the connected rooms. If you are unsure what that covers in your setup, submit a support ticket before enforcing the restriction.
3. The permissions page in AskCody cannot see your restriction. The Microsoft Graph permissions page in the AskCody Management Portal shows whether the permissions are granted in your tenant, not which mailboxes the restriction allows. All permissions show as Granted even when a scope is enforced, and even when the scope is too narrow. A too-narrow scope shows up as the symptoms in points 1 and 2 (blank rooms, calendars that stop updating, incomplete services, visitor registrations, and utilization data) or as per-mailbox errors, never on the permissions page. When troubleshooting a scoped setup, check the scope membership first, not the permissions page.
4. The restriction must target the right application. For the Microsoft Graph integration, the enterprise application in your Microsoft Entra ID (former Azure AD) depends on which regional AskCody platform your organization uses:
- EU platform (you sign in at app.onaskcody.com): the application is named AskCody, Application (client) ID 5a242508-7321-4320-a66a-bd4d65b102db.
- US platform (you sign in at app.goaskcody.com): the application is named GoAskCody, Application (client) ID 1fa56701-1ef6-40cc-9bf9-dff4b0e0af78.
The earlier EWS integration used different enterprise applications (for example AskCody EWS, Application ID e7e4dbfc-046f-4074-9b3b-2ae8f144f59b). A restriction created for one of those does not carry over: after upgrading to Microsoft Graph, re-create it, with the same scope, for the application listed above for your region. Until the new restriction is applied, the integration runs unscoped.
5. Two of the permissions cannot be mailbox-scoped. User.Read.All and GroupMember.Read.All are directory permissions, used to resolve organizers, attendees, and group memberships. They are tenant-wide by Microsoft's design and are not covered by a mailbox scope. They are read-only and carry no access to calendar content, e-mail, or files. The full permission list, with what each permission is used for, is maintained in Permissions used and required connecting AskCody with MS Graph and Entra ID.
6. The scope needs maintenance. When you add new rooms or desks to AskCody, their mailboxes must be added to the allowed scope, or the new calendars will not work. The same applies to people: new employees who book or attend meetings in the connected rooms must be within the scope. We recommend making this part of your standard room creation and user onboarding procedures, together with adding the calendar in the AskCody Management Portal. A dynamic group or an organization-wide scope with exclusions is easier to maintain than a hand-picked list.
7. Changes are not instant. Restrictions can take a while to take effect in Microsoft's systems. After changing the scope, allow time before concluding whether something works, and use Microsoft's test guidance (in the documentation linked above) to verify that an allowed mailbox passes and an excluded mailbox is blocked.
Before you enforce a restriction, check that:
- The allowed scope contains every room and desk mailbox connected to AskCody.
- The allowed scope contains the user mailboxes of everyone who books or attends meetings in those rooms (see point 2 above).
- If you restricted the EWS application before upgrading, the new scope gives the Microsoft Graph application the same reach the EWS application had.
- The restriction targets the current application for your region:
- For EU: AskCody (EU, ID 5a242508-7321-4320-a66a-bd4d65b102db)
- For US: GoAskCody (US, ID 1fa56701-1ef6-40cc-9bf9-dff4b0e0af78)
- You have tested one allowed mailbox and one excluded mailbox following Microsoft's documentation.
If you have questions about scoping AskCody's access, submit a support ticket.