Someone at your organization wants to connect a shared mailbox, for example ar@yourcompany.com, to Kolleno. This page is for whoever administers your Microsoft 365 tenant. It takes about five minutes.

You will be scoping Kolleno's access to that one mailbox using Exchange RBAC for Applications. Kolleno reads replies from the mailbox and sends from it, and cannot touch anything else.

If you open Kolleno's app in the Microsoft Entra admin center, you may be tempted to grant Mail.ReadWrite or Mail.Send there. Please do not. Those are tenant-wide, and they would let Kolleno reach every mailbox you have. The effective permission is the union of the Entra grant and the RBAC scope, so an Entra grant cancels out the restriction you are about to set up.

The role assignments below are all Kolleno needs.

You need:

Both are GUIDs and they are easy to mix up, so it is worth being clear before you start.

If a command fails saying an object cannot be found, check you have not swapped the two.

One warning about module order. If you load the Exchange module first, Connect-MgGraph can fail with Method not found: ... WithLogging, because Exchange brings an older authentication library with it. Connect to Graph first, or use a separate PowerShell window for each.

If you administer more than one tenant, confirm the TenantId is the one that owns the mailbox before going further. To switch, run Disconnect-ExchangeOnline -Confirm:$false and connect again. If the browser keeps signing you in as the wrong account, use Connect-ExchangeOnline -Device and pick the account at the code prompt.

If Kolleno's app has already been consented to in your tenant, you will get a row like this:

Copy the value in the Id column. That is your <SP_OBJECT_ID>. Note it is not the AppId in the third column, which is the same value for every Kolleno instance.

If nothing comes back, create it. This creates an identity only, and grants no access to anything:

Copy the Id from that output, the same way. You can retrieve it again at any time by re-running the Get-MgServicePrincipal command above, so there is no harm in losing it.

Exchange keeps its own record of the service principal, separate from Entra, so this step is needed even when step 2 found one. Replace <SP_OBJECT_ID> with the Id from step 2:

This is the part that limits Kolleno to one mailbox. Use the real address:

To allow several mailboxes, put them in a mail-enabled security group and filter on MemberOfGroup instead of naming each address.

If you get The ... management scope has the same RecipientRoot, RecipientFilter, ServerFilter, ScopeRestrictionType or Exclusive property values that you specified, a scope with that exact filter already exists. Use it instead of creating another, and skip to step 5 with its name.

<SP_OBJECT_ID> is again the Id from step 2, not the application ID:

Kolleno needs Mail.ReadWrite to read incoming replies and mark them as read, and Mail.Send to send from the mailbox. Both are Exchange roles limited to the scope you just created. They are not the tenant-wide Entra permissions of the same name.

This command takes the application ID, not the object ID:

You should see two rows, both InScope : True. Now run it again against a mailbox you did not scope:

InScope : False is the result you want. That second command is the one that proves the restriction works, so it is worth running rather than assuming.

Then tell your Kolleno user the mailbox address. They enter it in Kolleno themselves.

Allow a few minutes before expecting the change to take effect. Exchange permission changes propagate on a delay, in both directions, so a connection that fails immediately after these steps may simply need another go.

On a tenant where this has never been done, New-ManagementScope and New-ManagementRoleAssignment both fail. Run this once, then repeat the step:

Your session is holding a token issued before you created the service principal. Reconnect and try again:

Get-ManagementScope "Kolleno mailboxes" | Select RecipientRestrictionFilter returns a blank column, which looks alarming. Exchange stores what you passed in a property called RecipientFilter. Use this instead:

Order matters. Remove the role assignments first, then the scope, then the service principal. Removing the service principal while assignments still point at it leaves them orphaned.

Get-ManagementRoleAssignment has no -App parameter, so list by role and find yours by its RoleAssignee, which is the object ID from step 2:

Two kinds of row show up. Remove only the ones whose RoleAssignee is Kolleno's service principal object ID and whose CustomResourceScope is your scope. Leave the rows ending in -Delegating alone. Those belong to Organization Management and are what allows these assignments to be created at all.

The confirmation prompt defaults to yes, so pressing Enter removes it.

Once both assignments are gone:

Two things you may notice. Remove-ManagementScope fails while any assignment still references the scope, which is the check that you removed them in the right order. And Remove-ServicePrincipal warns about removing an Active Directory user object. That wording is generic Exchange boilerplate. It removes Exchange's record of the application, not a person, and not the app in Entra.

Kolleno notices withdrawn access on its next attempt and flags the mailbox as needing attention, so your user will see it in the product.

Microsoft's documentation for this feature: Role Based Access Control for Applications in Exchange Online.