AB Projects asks for permissions in two places. Your administrator sees a Microsoft consent screen once for the whole organization, and a team owner accepts a short list of team permissions when the app is added to a team or updated. Every entry maps to a feature you can see in the product, and most of it is delegated access, meaning the app acts as you and can never do more than you already can.
What is Microsoft Graph, and what do the permissions power?
Microsoft Graph is Microsoft 365's built-in API — the official doorway apps use to work with Teams, Outlook, and your profile. AB Projects uses it for four things:
Channel linking & roster sync
Connecting a project to the right Teams channel and automatically adding channel members to the project — see Adding or Removing Members.
Task cards & comment sync
Posting task cards and comments into the channel thread, and syncing replies in that thread back to the task — see Commenting with Mentions in Channels.
Calendar scheduling
Creating an Outlook calendar event for a task when you choose to time-block it, and scheduling meetings.
Sign-in (SSO)
Password-free sign-in with your Microsoft 365 account — see SSO and Microsoft Login.
Organization-wide permissions
These are the ones your administrator consents to once, in Microsoft Entra ID. Delegated = the app acts as the signed-in user, limited to what that user can already do. Application = used by AB Projects without a signed-in user, for background work like keeping a project’s members in step with its channel.
| Permission | Type | Why AB Projects needs it |
|---|---|---|
User.Read | Delegated | Sign-in and reading your basic Microsoft 365 profile. Required by any app that uses Microsoft sign-in. |
openid, profile, email | Delegated | Standard sign-in scopes: authenticate you, and read your name, avatar, and email address so tasks and comments are attributed to the right person. |
offline_access | Delegated | Lets the app refresh its access in the background (e.g. calendar sync) without asking you to sign in again every time a token expires. |
Team.ReadBasic.All | Delegated | Reads the names of the Teams teams you belong to, so a project can be linked to the correct team. |
Channel.ReadBasic.All | Delegated | Reads basic channel names so the right channel can be picked during tab setup and shown correctly. |
Group.Read.All | Delegated | Reads the Microsoft 365 groups behind your teams — used for project ↔ channel linking and the automatic roster sync that adds channel members to the project. |
ChannelMessage.Send | Delegated | Posts to the linked channel as you when you change a task or add a comment (including @mentions of members you pick). |
ChannelMessage.ReadWrite | Delegated | Reads and posts channel messages so task comments and updates land in the task's own Teams thread. |
ChannelMessage.Read.All | Delegated | Reads messages in channels where the app is used, to relate thread activity to the corresponding task. |
Calendars.ReadWrite | Delegated | Creates and updates an Outlook calendar event for a task when you choose to sync it (time-blocking). Requested at sign-in so no extra consent prompt appears later. |
Schedule.Read.All | Delegated | Reads Teams Shifts schedules you can already see. Listed on the consent screen; no current AB Projects feature uses it. |
TeamMember.Read.All | Application | Reads who is in a team, so the project’s member list follows the linked channel even when nobody is signed in. |
ChannelMember.Read.All | Application | Reads who is in a private or shared channel, whose members can differ from the team’s, so those projects get the channel’s members rather than the whole team. |
Team permissions (accepted by a team owner)
A few permissions apply to one team only. Microsoft calls them resource-specific consent: instead of an administrator granting access across the organization, a team owner accepts them when AB Projects is added to the team, or when an update adds a new one. They give the app nothing outside that team, and removing AB Projects from the team takes them away.
| Permission | Type | Why AB Projects needs it |
|---|---|---|
TeamMember.Read.Group | Team | Reads this team’s member list for roster sync. |
ChannelMessage.Read.Group | Team | Lets the bot receive replies in this team’s channels without being @mentioned, which is how a plain reply under a task card becomes a comment on the task. Added in AB Projects 2.4.0. AB Projects files only replies in threads under its own task and document cards. |
ChannelMessage.Read.Group takes effect. Until then, only replies that @mention AB Projects sync. See Commenting with Mentions in Channels.Notes for administrators
- Delegated access can't exceed the user. Most rows above act as the signed-in person — if they can't see a channel, neither can the app.
- Application permissions are for roster sync. They let AB Projects keep a project’s members in step with its channel when no one is signed in. They read membership only, not messages.
- Reply sync uses a team permission, not an organization-wide one.
ChannelMessage.Read.Groupis accepted per team by a team owner, so it never covers a team that hasn’t accepted it. - Calendar writes are opt-in per task. The app only touches your calendar when you explicitly sync a task or schedule a meeting from one.
- You stay in control. Organization-wide permissions can be reviewed or revoked at any time in Microsoft Entra ID; consent may be required once per organization at first sign-in (see SSO and Microsoft Login). Team permissions end when AB Projects is removed from the team.
In short: the permissions exist so tasks, Teams channels, and your calendar stay in sync — nothing here reads your mail or files, and the consent screens are always the definitive list.