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 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, and it's ordered the way a review usually goes. First, what this is: how the integration is architected and what third party powers it. Then, how to approve it: the three ways an admin can approve the integration, how to identify and verify the GiveCampus app in Microsoft Entra ID, and what mailboxes you need to provision. Then the weeds: how the "only GC GO emails" limit is actually enforced, what GC GO writes back to the mailbox, and the full list of permissions requested from Microsoft 365 and Google. Skip ahead to whichever part 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 can respond — all in one place.
• Activity becomes record. Gift officers 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 — with one tenant consent up front

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.

One clarification that trips people up. "Delegated, per-user" describes the access model — it does not mean individual users can consent on their own. On Microsoft 365, the mail scopes GC GO requests require tenant admin consent once, before anyone connects. If a gift officer (or a test account) tries to connect first, Microsoft will show a screen saying a Global Administrator or Application Administrator has to approve — that's expected, not a misconfiguration.

The sequence is:

1. A tenant admin consents once — see Admin next steps for the three ways to do this.
2. Each gift officer then connects their own mailbox from their GC GO user settings.

Admin consent authorizes the app in your tenant. It does not convert the integration into app-only access, and it does not connect anyone's mailbox. Only the individuals who complete step 2 have any mail flowing.

2. Nylas as the integration layer

GC GO's email 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.

Admin next steps: three ways to approve the integration

Before your gift officers can connect their inboxes, a Microsoft 365 admin has to approve the integration once. Pick whichever path fits your institution's policy — the end state is identical.

Option 1 — The admin authenticates directly in GC GO (easiest and fastest)

1. Ask your Gift Officer Partner Success Manager at GiveCampus to set up a temporary GC GO account for the admin. It's temporary, so it does not consume a paid seat.
2. The admin logs in and walks through the email authentication steps in the platform with their admin email.
3. That single authentication opens up email authentication for everyone who's been granted email permissions in GC GO — so each of those users can then connect their own mailbox. The temporary account is removed once it's complete.

Option 2 — The admin consents in Microsoft, without ever logging into GC GO

If your policy is to review and approve the app in Entra rather than have an admin sign in to a vendor platform, use Microsoft's tenant admin consent URL. A Cloud Application Administrator or Application Administrator, signed in to the intended tenant, opens:

https://login.microsoftonline.com/<your-tenant>/adminconsent?client_id=c7da248f-f8f6-4102-ac6d-151fadbea590

Replace <your-tenant> with your tenant domain or tenant ID.

Microsoft will display the application and its requested permissions for review before the administrator accepts.

Option 3 — Microsoft's admin consent request queue

If your policy doesn't permit using a direct admin-consent link, use Microsoft's admin consent request workflow instead. A GC GO user requests the app, and an assigned reviewer inspects and approves it entirely within the Entra admin center.

What to verify on the consent screen

Whichever option you choose, confirm all three before accepting:

1. The application is GiveCampus.
2. The publisher is the Microsoft-verified GiveCampus publisher.
3. Every permission is of type Delegated.

After approval

The GiveCampus app appears under Enterprise Applications in your tenant. From there:

• Set User assignment required to Yes and assign only the users or group that should be allowed to connect.
• Have each assigned gift officer complete their own mailbox connection in GC GO.

Tenant-wide admin consent does not give GC GO app-only access to other mailboxes. Every mailbox that syncs is one a specific person connected.

Finding the app in Microsoft Entra ID

Identity teams often go looking for the app before consenting to it, and come up empty. Here's what to expect.

What you're looking for

Why your search comes up empty

Two things are worth separating, because they're easy to conflate:

• The Microsoft Entra application gallery is a catalog of pre-integrated apps. The GiveCampus app is not published there, and gallery publication isn't required for this multitenant OAuth architecture. Searching the gallery will return nothing.
• Enterprise Applications lists the service principals that already exist in your tenant. Before you consent or provision the app, there's nothing to list — so a zero-result search there is also expected.

You don't create a second app registration

GiveCampus owns the app registration in our own Entra tenant. Your institution will not receive or create a second one. When you consent, Microsoft creates a tenant-local Enterprise Application (service principal) for the GiveCampus app inside your tenant. That object is yours: it's what you review, govern, restrict, and can revoke at any time.

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.

What GC GO accesses — and how that limit is enforced

There's an important distinction between what the OAuth scopes permit at the provider level and what GC GO actually pulls into the product:

GC GO ingests only emails that originated in GC GO and the replies to those emails. The purpose is the gift officer's own outbound cultivation and the conversations it generates — not general inbox access.

That's the claim. Here's the mechanism behind it, because "we promise we won't" isn't something a security team should have to take on faith.

The pipeline

1. Change notifications, not mailbox crawling. To keep a gift officer's threads current, GC GO subscribes to change notifications from the connected mailbox. GC GO doesn't sweep or query the mailbox at large.
2. An isolated store. Notifications arrive over an encrypted channel into an isolated store that no user-facing surface, API, report, AI component, or product feature can read.
3. One automated process, one test. A single automated process reads that store. It extracts a message into GC GO only if the message belongs to a thread GC GO originated. Anything else is never read beyond that match check.
4. Automatic purge. The store purges itself automatically after one month.

The practical effect: only emails that originated in GC GO, and their replies, are ever available in the product.

What the match actually keys on

Not the subject line. Subjects aren't unique and recipients can edit them, so they're not used for correlation.

• When GC GO sends the original email, Nylas returns both a message ID and an account-scoped thread_id. GC GO stores both.
• Incoming Nylas webhooks include the incoming message ID and its thread_id. GC GO identifies the connected mailbox from the relevant account, then accepts the message only when its thread_id exactly matches an existing GC GO conversation owned by that mailbox.
• The subject is stored for display, never for matching.

On Microsoft accounts specifically: Nylas maps Outlook's native ConversationId to its thread_id. Outlook and Nylas rely on the provider's conversation metadata and standard reply-chain headers — Message-ID, In-Reply-To, References — not on the subject.

If a recipient edits the subject but Outlook preserves the conversation, the reply stays associated with the thread. If Outlook treats it as a brand-new conversation, GC GO will not merge it into the original thread just because the subjects match. The design fails toward missing a match rather than making a false one.

What GC GO writes to the mailbox

It would be easier to call this integration read-only. It isn't, quite, and you should have the precise answer.

The one write: read-status synchronization. When a gift officer opens an inbound reply in GC GO, we update that specific Outlook message to unread: false, so it shows as read in Outlook too. Microsoft requires delegated Mail.ReadWrite to update a message; there is no narrower Microsoft permission scoped to read/unread state alone. That's why the scope appears on the consent screen even though Mail.Send already covers sending.

What GiveCampus does not do with that permission:

• Create or edit drafts
• Move or delete messages
• Modify flags or categories
• Reorganize mailbox folders

GC GO does list the Drafts folder so draft events can be excluded from GiveCampus — but listing is a read operation.

One more reason the scope is present. GC GO enables Nylas tracking for opens, link clicks, and thread replies. Nylas documents both Mail.ReadWrite and Mail.Send as required Microsoft scopes for its message-tracking and sending functionality. That's a Nylas platform requirement, not additional GiveCampus code that moves, deletes, or edits mailbox content.

The honest framing. These are delegated permissions for the user who connects their mailbox — not an application permission that independently reaches every mailbox in your tenant. Within that one connected mailbox, though, Mail.ReadWrite is a broad permission. The narrower GC GO behavior is enforced by the GiveCampus application controls described above, and we'd rather tell you that directly than describe the scope as something it isn't.

The 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. Note that the calendar difference some people expect isn't about user type (students vs. staff); it's about the provider: GC GO requests calendar scopes from Microsoft, but not from Google.

Worth knowing about the Microsoft calendar, room, and meeting scopes: GC GO requests them today but does not currently use them. They date to the original integration design, when a calendar feature was planned; that feature hasn't been built. Nylas documents Place.Read.All as supporting meeting-room and resource lookup, and it's included for that planned capability. No calendar, room, or meeting data is synced or acted on — and we'd rather say so plainly than describe those scopes as necessary.

Microsoft 365 (Outlook / Exchange)

Core sign-in / identity

Offline access (refresh tokens)

Mail (read / write / send)

Calendar (read / write) — requested, not currently used

Locations / meeting rooms — requested, not currently used

Online meetings — requested, not currently used

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:

On gmail.modify: This 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.

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 GiveCampus Enterprise Application (it appears in your tenant after consent — see above).
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.

At a glance for security reviewers

• Access model: Delegated, per-user OAuth — never tenant-wide application access to mailboxes. One tenant admin consent is required up front; it authorizes the app, it doesn't connect mailboxes.
• Entra app identity: Name GiveCampus, Application (client) ID c7da248f-f8f6-4102-ac6d-151fadbea590, Microsoft-verified GiveCampus publisher. Not published in the Entra app gallery; your tenant-local Enterprise Application is created on consent.
• 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: Only emails that originated in GC GO and the replies to them. Enforced by exact thread_id matching (Outlook ConversationId on Microsoft accounts) inside an isolated store that no product surface, API, report, or AI component can read, purged automatically after one month. Subject lines are never used for matching.
• Scope of access: Only the individual who connects their own account.
• Mailbox writes: Exactly one — marking a message read in Outlook when the gift officer reads it in GC GO. No draft creation or editing, no moving or deleting, no flags or categories, no folder changes.
• Microsoft 365 scopes: Sign-in/identity, refresh tokens, and mail (read/write/send, including shared). Mail.ReadWrite is required because Microsoft offers no narrower permission for read-status updates, and because Nylas requires it for message tracking. 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.
• Admin control: Restrict the enterprise app to assigned users/groups via User assignment required. Consent is revocable in Entra at any time.
• 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.