Finish a Working CRM Shared Inbox: Lean Setup and Safe Permissions

Most small support teams do better with a native CRM inbox, and higher-volume or collaboration-heavy teams do better with a dedicated shared inbox connector. Before choosing either, confirm your provider supports OAuth or Microsoft Graph and can send email from the shared address, not just log it. That single check determines whether agents can actually reply from the CRM.

TL;DR:

• Native CRM inboxes are suitable for small teams with simple workflows, but they lack advanced routing and SLA management needed by larger or high-volume teams.
• Connecting Gmail or Microsoft 365 via OAuth or Graph API requires careful setup of permissions, with Gmail limited to 100 users per OAuth profile and strict consent management.
• Effective message routing involves using keyword, department, or workload-based rules, and proper attachment to contact or deal records is essential for accurate reporting.
• Limiting permissions to necessary scopes, enabling audit logs, and establishing retention policies improve security, compliance, and ease of future audits.
• Teams approaching SLA misses or managing multiple agents should consider switching from native inboxes to dedicated shared inbox connectors to streamline workflows and reduce manual re-routing.

Table of Contents

• CRM-native inbox or a dedicated shared-inbox connector?
• Gmail integration: OAuth 2.0 checklist and setup steps
• Microsoft 365 integration: Entra permissions and Graph API scopes
• Routing, assignment, and how messages attach to CRM records
• Permissions, security, and compliance: a go-live checklist
• Troubleshooting and scaling: when to change your setup
• A lean path to a working shared inbox
• Try SendSync: a shared inbox without the setup overhead
• Sources
• FAQ

CRM-native inbox or a dedicated shared-inbox connector?

A CRM-native inbox lives inside your existing CRM, pulling email into the same screen as contacts and deals. A dedicated shared-inbox connector is a separate tool built specifically for team email, then linked back to the CRM through an integration.

The trade-offs show up fast once a team grows. Native inboxes keep data unified in one place but often lack deep routing, and admins spend more time reconciling two systems when they eventually add a specialist tool. Best-of-breed connectors tend to offer stronger routing and SLA management but require an extra integration layer and its own permission setup.

• Small teams generally do fine with a native inbox and unified reporting.
• Growing teams with multiple queues or departments start feeling the limits of native routing.
• High-volume teams need SLA tracking, workload balancing, and audit trails that most native inboxes were not built for.

The decision often comes down to maturity rather than headcount alone: a five-person team handling complex multi-channel support may need a dedicated tool sooner than a twenty-person team with simple, repetitive requests.

Gmail integration: OAuth 2.0 checklist and setup steps

Connecting Gmail to a CRM runs through OAuth 2.0, not a simple username and password. The setup touches Google’s developer console before it ever reaches your CRM’s mailbox settings.

1. Create a project in the Google API Console and enable the Gmail API for that project.
2. Configure the OAuth consent screen and set the redirect URIs your CRM requires.
3. Generate a client ID and client secret from that project.
4. In your CRM’s mailbox configuration, select Gmail OAuth as the authentication type and enter the client ID and secret.
5. Sign in to the Gmail account to grant delegated consent, authorizing server-side synchronization for incoming and outgoing mail.
6. Confirm the mailbox can both read and send, not just log messages for visibility.

Gmail OAuth email server profiles are documented to work for up to 100 users per profile, so teams beyond that count need to create additional OAuth profiles rather than trying to stretch one profile across the whole organization.

Pro Tip: Build a short internal runbook for token refresh failures and consent errors before launch, so a non-developer admin can fix common auth breaks without escalating to engineering.

Watch for expired tokens after password changes, consent screens that fail silently when scopes are misconfigured, and send-as errors that trace back to DNS records rather than the OAuth setup itself.

Microsoft 365 integration: Entra permissions and Graph API scopes

Microsoft 365 integration runs through an Entra app registration and the Graph API, and the permission model matters more here than with Gmail because shared mailboxes introduce an extra consent layer.

• Create or reuse an Entra app registration and add delegated permissions including Mail.ReadWrite.Shared and Mail.Send.Shared for shared mailbox scenarios.
• Shared mailbox scenarios typically require a tenant admin to grant consent, since individual users cannot approve access to a mailbox they do not own.
• Add User.ReadBasic.All when the integration needs to resolve another user’s mailbox identity for delegated access.
• Reserve application-level access for service accounts or service-to-service scenarios: it skips the sign-in step but needs its own registration and admin approval, and it is not a substitute for delegated permissions in most support workflows.
• Some CRMs run a hybrid setup, syncing email through Graph while calendar data still relies on older EWS calls. Verify each channel separately during testing.

Getting the permission scopes right the first time avoids the most common failure mode: an integration that reads mail fine but throws access errors the moment an agent tries to send.

Routing, assignment, and how messages attach to CRM records

A working inbox needs rules for who sees what and how each message ties back to a customer record. Routing generally falls into a few patterns, and most teams end up combining more than one.

• Keyword or topic routing sends messages containing certain terms to a specific queue, useful for separating billing from technical requests.
• Department inboxes split traffic by team before any individual assignment happens.
• Round-robin assignment distributes new conversations evenly across available agents.
• Workload-aware routing accounts for how many open conversations an agent already has before assigning another.

Assignment also raises a smaller but important question: does ownership follow the thread or the contact? Thread ownership keeps one agent on a single conversation, while contact ownership keeps one agent responsible for everything a customer sends, even across multiple threads. Tags, labels, and internal notes fill the gap between the two, letting a second agent add context without taking over.

Matching rules then link each message to a contact or deal record, usually by sender address, and that link is what makes reporting possible. When matching fails, messages sit unattached, SLA timers misfire, and support metrics undercount real volume.

Pro Tip: Build inbox automation and assignment rules that mirror your team’s actual escalation path, not an idealized one, since misapplied automation often creates more manual cleanup than it saves.

Permissions, security, and compliance: a go-live checklist

Before turning the integration on for the whole team, confirm the permission scopes are the minimum needed. Requesting broader access than the workflow requires increases the attack surface without adding functionality.

• Grant only Mail.ReadWrite.Shared and Mail.Send.Shared, or their Gmail equivalents, rather than full mailbox or admin-level scopes.
• Require tenant admin consent for any shared mailbox integration rather than letting individual users self-approve.
• Turn on audit logging so mailbox access and send actions are traceable after the fact.
• Set a retention and backup policy for synced email before agents start relying on it as the system of record.
• Decide whether replies go out as send-as (appearing to come directly from the shared address) or send-on-behalf (showing both the agent and the shared address), since the two affect what the customer sees in message headers.

A clear permission structure up front is easier to audit later than a broad grant you have to walk back after agents are already using it daily.

Troubleshooting and scaling: when to change your setup

Most integration problems show up as one of a few symptoms, and each has a fast first check.

1. Authentication failures: check whether the OAuth token expired or a password change broke the connection, then re-authorize.
2. Rate limit errors: check whether you have exceeded the per-profile user limit and need a second OAuth profile.
3. Duplicate messages: check for overlapping sync rules pulling the same mailbox through two integrations at once.
4. Missing send-as capability: check whether the integration only logs mail rather than granting delegated send permission.

Beyond fixing individual symptoms, watch for signals that the model itself needs to change: repeated SLA misses, agents manually re-routing messages every day, or enough concurrent agents that a native inbox can no longer keep queues organized. Those are cues to move toward a dedicated shared-inbox connector rather than patching the native setup further.

A lean path to a working shared inbox

Most of the complexity above exists to solve a problem SendSync built around from the start: connecting Gmail or Microsoft 365 mailboxes without DNS changes or a lengthy configuration process. SendSync lets teams assign, reply, and manage conversations in one smooth workflow instead of stitching together OAuth profiles and admin consent screens by hand. Plans include unlimited users, which keeps costs predictable as a team grows and takes pressure off response times. Full setup and permission details are not publicly listed beyond what appears at Sendsync.

— Nick

Try SendSync: a shared inbox without the setup overhead

The steps above work, but they take real admin time to get right, especially the Microsoft 365 permission scopes and Gmail OAuth profile limits. This service connects Gmail or Microsoft 365 mailboxes without DNS setup, and plans include unlimited users so cost does not climb with headcount the way it does with per-seat tools like Zendesk, Freshdesk, or Help Scout.

• Start a trial and connect your mailbox in minutes.
• Check the Founder, Starter, Growth, or Scale plans for pricing that fits your team size.
• Review setup docs before rollout if you want to map permissions ahead of time.

Head to Sendsync to set up your shared inbox and see how quickly it replaces the manual configuration described above.

Sources

• Set up Gmail OAuth for server-side synchronization
• Set up OAuth authentication for Microsoft Office 365 via Graph API | Creatio Academy

FAQ

What is the difference between a shared inbox and CRM email integration?

A shared inbox is a mailbox multiple agents can access and reply from together, while CRM email integration connects that mailbox to contact and deal records so messages appear alongside customer history. The two often work together: the shared inbox handles the conversation, and the CRM integration provides the context.

Does Gmail integration support sending as the shared address?

Yes, when the integration uses OAuth 2.0 with delegated consent rather than a simple read-only sync. Some integrations only copy mail into the CRM for visibility, so confirm send capability specifically before rolling it out to agents.

How many users can one Gmail OAuth profile support?

A Gmail OAuth email server profile is documented to support up to 100 users, and teams beyond that need to create additional OAuth profiles for the same mailbox. This is a common oversight during setup planning for larger teams.

What Microsoft Graph permissions does a shared mailbox need?

Shared mailbox scenarios generally require delegated permissions including Mail.ReadWrite.Shared and Mail.Send.Shared, along with tenant admin consent. Application-level access is a separate setup, intended for service accounts rather than everyday agent use.

How much does SendSync cost?

SendSync offers four plans: Founder at $10 per month, Starter at $30 per month, Growth at $80 per month, and Scale at $200 per month, all with unlimited users and no per-seat fees. Full details are available at Sendsync.

Recommended

• Admins: Give Full Access and Send As First, or Add Shared Inbox Layer
• Shared Inbox Best Practices for Support Teams in 2026
• Handle Multiple Clients in a Single Inbox
• Support Managers: Run Your Remote Support Team With a Shared Inbox in Days