Microsoft Graph permissions Tekst requests and how to restrict them

To connect Outlook, Tekst requests a small set of Microsoft Graph permissions. These permissions are available by default in Microsoft 365, but many organizations restrict them as they tighten their security policies. If yours does, an administrator needs to grant them in Azure Active Directory (AAD) before the connection will work.

This article lists the permissions Tekst requests for each account type, and shows how an administrator narrows what Tekst may do in your mailboxes by revoking the permissions you do not want it to have.

Tekst will never delete emails.

The exact permissions depend on which account type you connect. See Outlook integration: personal vs organization-wide accounts if you are not sure which one applies to you.

Personal accounts (delegated permissions)

A personal account signs in as an individual user, so Tekst requests delegated permissions - access on behalf of that signed-in user:

• user.read - verify the connected user and mailbox.
• mailboxsettings.read - read and apply Outlook categories.
• mail.readwrite - read incoming emails (the read part) and add category labels or move emails into folders (the write part).
• mail.send - forward emails, when an automation is configured to do so.

To also connect shared mailboxes that the user can access, Tekst additionally requests:

• mail.readwrite.shared - read and process emails in a shared mailbox, and apply labels or move them into folders.
• mail.send.shared - forward emails from a shared mailbox, when configured.

A personal account is limited to the permissions its signed-in user consented to, so you choose its access at the moment you connect it. The restrictions later in this article apply to organization-wide accounts only.

Minimal permissions

During setup, a personal account can enable "Ask for minimal permissions". This requests only the smallest set of permissions needed to read and process emails. Choose this if your security policy requires the narrowest possible access; note that some features (such as applying categories) rely on the broader set.

Organization-wide accounts (application permissions)

An organization-wide account does not sign in as a user. Instead, a Microsoft 365 administrator grants Tekst application permissions once, and Tekst uses application-level access to reach mailboxes across the tenant. There are no .shared permissions in this model - application access already spans the mailboxes the policy allows.

Granting admin consent gives Tekst these application permissions:

To see exactly what your organization granted, open Enterprise applications > Outlook x Tekst (service account) > Permissions > Admin consent. Each permission can be revoked on its own, which is how you narrow what Tekst can do.

Your Admin consent tab may also list User.Read as a delegated permission. An organization-wide connection does not use it, so revoking it changes nothing.

If your connection was set up some time ago, MailboxSettings.Read may not appear in the Admin consent tab, because Tekst did not always request it. An administrator has to grant consent again to add it, and doing so also restores any permission you revoked earlier, so re-check the tab afterwards.

Because this access can reach every mailbox in the tenant by default, we strongly recommend scoping it to only the mailboxes Tekst should process. See Restrict Tekst to specific mailboxes.

Granting these permissions in Azure

If your organization has restricted the permissions above, an administrator can grant them on the Tekst enterprise application in Azure. See Configure Outlook access in Azure.

Restrict what Tekst can do in your mailboxes

An organization-wide Outlook account gives Tekst application-level access to the mailboxes it reaches. An administrator narrows what Tekst may do there by revoking permissions on the Tekst application in Microsoft Entra ID.

This is the companion to Restrict Tekst to specific mailboxes. That guide limits which mailboxes Tekst can reach; the steps below limit what Tekst may do in them. The two work together, and we recommend applying both.

Choose the narrowest option that still supports what you use Tekst for. If you are unsure which automations would be affected, ask your Tekst contact before you apply a restriction.

Why this is done in Microsoft Entra ID

What Tekst is allowed to do is decided by the permissions consented to the Tekst application. Revoking one there is the only thing that takes it away.

It is worth knowing what the Exchange Online options do not do, because it is easy to assume otherwise:

• An application access policy limits which mailboxes an application can reach. It does not change what the application may do in the mailboxes it still reaches.
• RBAC for Applications grants an application permissions, optionally limited to a set of mailboxes. Microsoft describes those grants as a union with the ones consented in Entra ID, so an Exchange role assignment only ever adds access. It cannot hold Tekst below a permission it already has.

Neither is a substitute for revoking the permission.

Prerequisites

• An administrator who can revoke consented permissions in Microsoft Entra ID (Cloud Application Administrator or Application Administrator).
• The Application (client) ID of the Tekst Outlook application, to confirm you are looking at the right one: b2094c09-0651-49c4-b2c2-ed3b739e2a8c.

Step 1: Revoke the permissions you do not want

1. In the Microsoft Entra admin center, go to Enterprise applications > All applications.
2. Open Outlook x Tekst (service account).
3. Select Permissions, then the Admin consent tab. This lists every permission your organization has granted Tekst.
4. Select the ... control next to the permission you want to remove, then select Revoke permission.
5. Repeat for each permission you do not want Tekst to have, and confirm the remaining list matches what you intend to allow.

Nothing has to be reconnected in Tekst. Tekst asks Microsoft for whatever is still granted, so it picks up the reduced set by itself.

Expect a delay before the change takes effect. Revoking a permission does not cancel a token Microsoft has already issued, and Tekst keeps using that token until it expires. Microsoft issues these tokens with a lifetime of 60 to 90 minutes, so allow up to 90 minutes, or longer if your organization has configured a longer access token lifetime.

You can do the same with PowerShell using Remove-MgServicePrincipalAppRoleAssignment, which is useful when you want the change recorded in a script.

Important: granting consent again restores what you revoked. Revoking a permission does not stop Tekst from requesting it again. Connecting an organization-wide account sends an administrator to Microsoft's consent screen, which asks for the full set of permissions Tekst requests, and granting consent there restores everything you revoked here.

If someone reconnects the account, or grants consent again while troubleshooting, repeat this step afterwards and confirm the Admin consent tab still shows only the permissions you intend to allow.

Step 2: Confirm the restriction

The Admin consent tab is the record of what Tekst can do. After the change, it should list only the permissions you decided to keep.

If you want to confirm the effect rather than the configuration, ask your Tekst contact to check the integration. An automation that needs a revoked permission fails with an access error from Microsoft, which is the expected result rather than a fault.

Changing the restriction later

Widening or narrowing what Tekst can do is a change to the consented permissions, not a change to the connection in Tekst. Nothing has to be reconnected, no mailboxes have to be added again, and the folder settings and history on the integration are all preserved.

To restore a permission, you have two options:

• Grant admin consent on the same page grants the full set Tekst requests, so any other restriction you had in place has to be applied again afterwards.
• Granting back a single permission is possible with the Microsoft Graph API or the Graph PowerShell SDK, which leaves your other restrictions untouched. See Microsoft's guide to granting and revoking API permissions programmatically.

Troubleshooting

Tekst still writes to mailboxes after I restricted it

Check the Admin consent tab. A permission still listed there applies to every mailbox Tekst can reach, and no Exchange Online setting removes it. This is the most common reason a restriction appears to have no effect.

Tekst can write again after I restricted it

Someone granted consent again, most likely by reconnecting the account in Tekst. The consent screen asks for the full set of permissions Tekst requests, so it restores anything you revoked. Revoke the permissions again and check the Admin consent tab.

Tekst reports mailboxes as unhealthy

Tekst reports a mailbox as unhealthy when it cannot read email there, which is what revoking Mail.ReadWrite causes. Restore that permission if the mailboxes should keep syncing.

The change does not seem to have taken effect

Allow up to 90 minutes for the token Microsoft already issued to expire. Until then, Tekst still uses the access it had when that token was issued, and a write that you expected to fail can still succeed. Do not grant consent again to force the change through: that restores every permission you revoked.

Reference

This guide is based on Microsoft's documentation on reviewing permissions granted to enterprise applications.