What you are being asked to approve

Your organization uses Mentorloop to run a mentoring program. Calendar Connect lets mentoring partners find times that suit everyone and have meetings placed directly into their calendars.

You can authorize this once, for your whole organization, so that your people have nothing to set up and no consent prompts to answer. That is what this guide covers.

What approving grants, in one sentence — this is the exact wording Mentorloop presents to you:

Allows Mentorloop's scheduling service to see when people in your organisation are busy or free, and to create and manage calendar events for meetings booked through Mentorloop.

If your organization has chosen availability checking only, without meeting creation, the grant is narrower and the sentence is:

Allows Mentorloop's scheduling service to see when people in your organisation are busy or free. It cannot read event titles, attendees, or contents, and it cannot change anything.

What it does not grant, in either case:

• It does not allow Mentorloop to read event titles, descriptions, locations, attendees, or attachments. Mentorloop does not request the permission that would allow this.
• It does not allow Mentorloop to read, modify, or delete any event other than the mentoring meetings created through Mentorloop.
• It does not give Mentorloop any access to mail, files, chat, or any other service.
• It does not create a copy of anyone's calendar. Availability is read at the moment it is needed and discarded.

Before you start

You will need:

• Google Workspace: super administrator access.
• Microsoft 365: an administrator who can grant tenant-wide admin consent (Global Administrator, Privileged Role Administrator, or Cloud Application Administrator).

Your Mentorloop Customer Success Manager (CSM) will send you an approval link, and — for Google Workspace — a Client ID and a list of permissions to check against what appears on screen.

Google Workspace

Mentorloop's scheduling service uses domain-wide delegation, authorized by you for named permissions only.

1. Open the link your Mentorloop CSM sent you, signed in to Google as a super administrator. It lands on the Domain-wide delegation screen with the details pre-filled.

   Manual path, if you would rather navigate there yourself: Admin console → Security → Access and data control → API controls → Domain-wide delegation → Add new.

2. Check the Client ID and OAuth scopes on screen match the values Mentorloop gave you, then click Authorise.

3. Allow around 5 minutes for the change to take effect, then let your Mentorloop CSM know. They will run a check that confirms everything works.

The permissions you are authorizing

If your organization has enabled availability checking only, the second scope is not requested and you will see only the first.

There is no directory scope. Mentorloop cannot list, browse, or look up members of your Google Workspace directory.

Google's own documentation on domain-wide delegation: https://support.google.com/a/answer/162106

Microsoft 365

Mentorloop's scheduling service uses an application registered in Microsoft Entra, consented to by you for your directory only.

1. Open the link your Mentorloop CSM sent you and sign in as an administrator of your Microsoft 365 organization.

   The link addresses your own directory specifically, using one of your verified domains — not a generic consent endpoint. You are consenting for your organization and no other.

2. Review the requested permissions and choose Accept. This consents on behalf of your organization.

3. Allow around 5 minutes for the change to take effect, then let your Mentorloop CSM know. They will run a check that confirms everything works.

The permissions you are consenting to

On User.Read.All: Microsoft Graph requires this permission to match an email address to a mailbox before a calendar can be read. It is a directory read permission, and we would rather you heard that from us than found it yourself. It is not used for any other purpose, and Mentorloop does not store directory data.

Optional: Restrict which mailboxes the application can reach

Microsoft application permissions apply to every mailbox in your tenant unless you restrict them. Mentorloop's own controls limit access to the email domains registered for your organization, but you should hold your own control rather than rely solely on ours.

We recommend applying an Exchange ApplicationAccessPolicy limiting Mentorloop's application to a mail-enabled security group containing only your mentoring program's participants. In Exchange Online PowerShell:

New-ApplicationAccessPolicy `
  -AppId <the application ID Mentorloop gave you> `
  -PolicyScopeGroupId mentoring-participants@yourdomain.com `
  -AccessRight RestrictAccess `
  -Description "Restrict Mentorloop Calendar Connect to mentoring program participants"

Test it before telling us you are done:

Test-ApplicationAccessPolicy -Identity someone@yourdomain.com `
  -AppId <the application ID Mentorloop gave you>

If you apply a policy, make sure every participant in the mentoring program is in the group. Anyone outside it will appear to Mentorloop as unreachable, and their availability will not be shown.

Microsoft's own documentation on granting admin consent: https://learn.microsoft.com/entra/identity/enterprise-apps/grant-admin-consent

How approval is confirmed

There is no notification from Google or Microsoft when you finish, so Mentorloop does not assume anything has happened. Instead, your Mentorloop CSM runs a check that reads availability for one address in your domain. If it succeeds, the connection is marked active. If it does not, the error your provider returned is reported back verbatim, so the cause is visible rather than guessed at.

Until that check passes, nothing in your organization is being read.

Withdrawing access

You can withdraw organization-wide access at any time, in your own console. Mentorloop does not need to be involved, and access ends immediately.

Google Workspace: Admin console → Security → Access and data control → API controls → Domain-wide delegation → remove the Mentorloop Client ID.

Microsoft 365: Entra admin center → Enterprise applications → the Mentorloop application → Properties → Delete, or Permissions → revoke the granted consent.

Two things to know about what withdrawal does and does not affect:

• Meetings already in people's calendars remain. They belong to the people in them. Withdrawal stops future access, it does not retract past events.
• Individual connections are not affected. A participant who connected their own calendar did so themselves, and that grant is theirs to withdraw. It is not covered by your organization's grant and does not end with it.

Questions administrators ask

Can Mentorloop see what our people's meetings are about?

No. The free/busy permission returns periods of time and nothing else — no titles, descriptions, locations, attendees, or attachments. Mentorloop does not request the permission that would return them, so it could not read them even if asked to.

Does Mentorloop keep a copy of our calendars?

No. Availability is read from Google or Microsoft at the moment a participant is scheduling, used to work out which times suit everyone, and discarded. There is no cache and no synchronized copy.

Can this reach people outside our organization?

No. The grant you make applies only to your organization's verified email domains. Mentorloop's scheduling service enforces this on every request, and organizations' grants are isolated from one another.

What about a mentor who is not one of our employees?

They are not covered by your grant, and never can be. If they want their availability taken into account, they connect their own calendar individually, under their own consent. That is theirs, not yours, and you neither authorize nor can revoke it.

One of our people already connected their calendar personally. What happens?

Their own connection takes precedence over the organization grant. This is deliberate: a person's own choice about their own calendar outweighs a default applied on their behalf.

Where is our calendar data processed?

In Mentorloop's own AWS environment, in the same region as the rest of your Mentorloop data — Sydney, London, or Ohio. No third party is involved in the calendar data path.

Can we turn on availability checking without allowing meeting creation?

Yes. Tell your Mentorloop contact before they send your approval link. The grant is then narrower — availability only — and you can enable meeting creation later as a separate decision.

We need this in writing for our security review.

Ask your Mentorloop contact for Mentorloop Calendar Connect — Security and Data Handling, which covers data flows, retention, encryption, access records, and data residency.