Email in GC GO — Security, Setup, and Permissions

Email is where most cultivation happens, so GC GO sends and receives it from each user’s real inbox — not a generic system address. That design gives gift officers (and students) a natural workflow, and it gives your IT and security teams a set of fair questions: How does the connection work? Who can access what? Where does data live? What exactly are we consenting to?

This guide answers those questions. It’s written for the people who review and approve the integration: GiveCampus admins and the campus IT / identity / security teams they work with. It covers how the email integration is architected, the third party that powers it, how credentials and data are handled, the full list of permissions GC GO requests from Microsoft 365 and Google, how access is scoped, and the boundaries of the integration (like shared mailboxes). If you’re an IT reviewer signing off, this has what you need.

What the integration does

Connecting an email account unlocks the workflow gift officers rely on:

• Sent mail lands where it should. Emails sent through GC GO appear in the Sent folder of the user’s Exchange (Outlook) or Gmail account.
• Real conversations, threaded. Constituent replies thread back into GC GO, where the gift officer (or student(  can respond — all in one place.
• Activity becomes record. Gift officers and students can create contact reports from outbound emails, inbound emails, and replies.
• Engagement you can measure. Deliverability, open rate, and click rate are available per email (including individual messages within a thread) and in aggregate.

How the integration works

Two things power the email connection, and both matter to a security review.

1. Delegated, per-user OAuth

GC GO uses delegated, per-user OAuth. In plain terms:

• Each GC GO user authenticates their own Outlook or Gmail account to enable a bi-directional sync of email.
• GC GO acts on behalf of that individual user — the same way any app you’d grant access to your own inbox does.
• There is no application permission that lets GC GO reach into everyone’s mailboxes at once. Access is always tied to the specific person who connected their account.

This is the single most important point for a security review: GC GO is not requesting tenant-wide, app-level access to your mail environment. It requests delegated access, one user at a time, and only for the users who choose to connect.

2. Nylas as the integration layer

GC GO’s email and calendar sync is powered by Nylas, an industry-standard provider of integrations between software platforms and email/calendar providers (Outlook/Exchange and Gmail). Nylas is used by many companies for email integration, including Salesloft.

How credentials and tokens are handled:

• Login credentials (username and password) are never stored by GiveCampus or by Nylas.
• After a user authenticates directly with their email provider, the provider issues an authentication token. That token is sent to Nylas, which stores it securely.
• The token — not the user’s password — is what maintains the ongoing connection.

Nylas security and compliance posture:

• SOC 2 Type II certified
• ISO 27001 compliant
• GDPR compliant
• HIPAA compliant

Nylas publishes its approach to enterprise privacy — covering security, data encryption, and SOC 2 compliance — and GiveCampus can share that documentation with your security team on request.

What GC GO actually accesses

There’s an important distinction between what the OAuth scopes permit at the provider level and how GC GO uses the connection in practice:

In practice, GC GO uses the Nylas connection only to access emails sent from the GiveCampus platform (i.e., from a gift officer to a specific constituent) or messages sent in response to those emails. The purpose is the gift officer’s own outbound cultivation and the replies it generates — not general inbox surveillance.

The sections below list the scopes requested at connection time so your identity team has the complete picture.

The Microsoft 365 permissions GC GO requests

GC GO connects through two providers — Microsoft 365 (Outlook/Exchange) and Google (Gmail) — and the scopes it requests differ by provider. The calendar difference isn't about user type (students vs. staff); it's about the provider: GC GO requests calendar scopes from Microsoft, but not from Google.

Microsoft 365 (Outlook / Exchange)

Core sign-in / identity

Offline access (refresh tokens)

Mail (read / write / send)

Microsoft calendar & meeting scopes — requested, not currently used

GC GO also requests these calendar, location, and online-meeting scopes from Microsoft, but does not currently use them — they date to a planned calendar feature that hasn't been built to date.

Calendar (read / write)

Locations / meeting rooms

Online meetings

Why the .Shared scopes? They let a user work with mailboxes and calendars that have been explicitly shared with them — for example, a gift officer covering a shared team inbox. They do not grant access to mailboxes the user hasn’t been given rights to.

Google (Gmail)

For the Gmail OAuth flow via Nylas, GC GO requests a deliberately narrow set of scopes — and no calendar access: openid (sign the user in), userinfo.email (read the user’s email address), userinfo.profile (read basic profile info), and gmail.modify (read, modify, and send — all read/write except permanent deletion). gmail.modify is Gmail’s “modify” scope — all read/write operations — reading, modifying (labels and drafts), and sending messages — except the immediate, permanent deletion of messages and threads (bypassing Trash). It's broader than gmail.readonly (read-only), but narrower than full mailbox access at https://mail.google.com/, which also permits permanent deletion. No calendar scopes are requested for Google.

Scoping who can connect: Role-Based Access Control

A common question from identity teams is whether GC GO supports scoping via Role-Based Access Control (RBAC) in Exchange Online.

The honest answer comes down to the delegated model:

• Exchange Online RBAC and Application Access Policies are primarily built to scope application permissions — the “an app can access everyone’s mailboxes” kind — down to a subset of mailboxes.
• GC GO doesn’t use that kind of permission. There’s no app-wide mailbox access to scope down.
• So in practice, access is already scoped to only the individual who connects their own account. Application Access Policies don’t apply the same way, because the thing they’re designed to constrain isn’t in play.

What you can do on the M365 side

The lever that matters is controlling who is allowed to authorize and use the enterprise app in the first place:

1. In Microsoft Entra ID, open the GC GO Enterprise Application.
2. Set User assignment required to Yes (Properties tab).
3. Under Users and groups, assign only the specific users — or a group — who should be able to connect GC GO.

With that in place, only the people you’ve explicitly assigned can complete the OAuth connection. Everyone else is blocked at the door, regardless of the scopes the app requests.

Can GC GO Students use a shared mailbox?

Not at this time. GC GO requires a distinct mailbox per user. A single shared mailbox connected across multiple student accounts isn’t supported.

If your goal is to keep tight control over student email rather than hand each student a full, independent mailbox, admins commonly do one of the following:

• Forward to a master mailbox. Give each student their own distinct mailbox, but forward all of it to a supervising mailbox (such as the program manager’s) so activity stays visible in one place.
• Withhold direct account access. Provision the distinct mailbox for the connection, but don’t give the student direct sign-in access to that underlying account.

Both approaches satisfy the “distinct mailbox per user” requirement while keeping oversight where you want it.

Setup checklist for admins and IT

4. Confirm the email provider. Microsoft 365 (Outlook/Exchange) and Google (Gmail) request different scopes — see the permissions section above.
5. Provision distinct mailboxes. One mailbox per user — no shared mailboxes for student connections.
6. Restrict the enterprise app. Set User assignment required and assign only the users or groups who should be able to connect.
7. Decide your oversight model. If you want centralized visibility into student email, set up forwarding to a master mailbox or withhold direct account access.
8. Have users connect their accounts. Each user authenticates directly with Microsoft (or Google) from their GC GO user settings and consents for their own mailbox and calendar.

At a glance for security reviewers

• Access model: Delegated, per-user OAuth — never tenant-wide application access to mailboxes.
• Integration layer: Powered by Nylas (SOC 2 Type II, ISO 27001, GDPR, and HIPAA compliant).
• Credentials: Usernames and passwords are never stored by GiveCampus or Nylas. Nylas securely stores the provider-issued authentication token.
• Scope of use: In practice, GC GO accesses only emails sent from the platform and the replies to those emails.
• Scope of access: Only the individual who connects their own account.
• Microsoft 365 scopes: Sign-in/identity, refresh tokens, and mail (read/write/send, including shared). Calendar, meeting-room, and online-meeting scopes are also requested but not currently used.
• Google (Gmail) scopes: openid, userinfo.email, userinfo.profile, and gmail.modify — all read/write (read, modify, send) except permanent deletion bypassing Trash. No calendar scopes requested.All of the above plus calendar (read/write, including shared), meeting rooms, and online meetings.
• Admin control: Restrict the enterprise app to assigned users/groups via User assignment required.
• Shared mailboxes: Not supported — distinct mailbox required per user.
• Exchange RBAC / Application Access Policies: Don’t apply in the usual way, because there’s no app-level mailbox permission to constrain.

Need a hand?

If your IT or security team has questions this guide doesn’t answer — or you’d like Nylas’s enterprise privacy and compliance documentation — the GiveCampus team is glad to help you get the integration reviewed and configured securely. Reach out and we’ll work through it with you.