Gmail and Google Workspace

On the Google side sits a Gmail or Google Workspace mailbox reached through the Gmail API: messages, threads, labels, drafts and the Sent folder, plus the per-mailbox sending limits Google enforces. A Workspace mailbox also sits under domain administration, which controls whether third-party applications may touch it at all. On the AppBO side sits the outbound email channel (templates, campaigns, workflow emails and one-to-one conversation replies) together with the conversation view on each contact record where replies are meant to appear.

You connect them for two reasons that are often confused. The first is identity: a message sent from a real Workspace address arrives from the person the recipient already corresponds with, authenticated by the domain's existing SPF and DKIM records, with no new sending domain to warm up. The second is continuity: because the platform speaks to the mailbox rather than to a relay, the sent message can be written into the user's own Sent folder, and the recipient's reply can be read back, matched to the contact and attached to the right conversation, so the thread reads the same whether you look in Gmail or in the CRM.

What this connection is not is a bulk sending channel. Google's per-mailbox limits are designed for human correspondence, and a marketing campaign pushed through a mailbox will hit them, damage the mailbox's reputation, or both. The sound pattern is a connected mailbox for one-to-one and workflow mail, and a dedicated sending domain for campaigns. The two coexist, each doing the job it is suited to.

1. Decide the role of this mailbox before connecting it. One-to-one conversation and workflow mail is the right job; campaigns are not. If you need both, plan the dedicated sending domain in parallel rather than later.
2. Confirm the mailbox is a real user mailbox, not a group address or an alias. Group addresses cannot complete a user authorization, and sending from an alias is a separate setting inside Gmail that must already work manually before the platform can use it.
3. For a Workspace domain, check with the administrator whether third-party app access is restricted. In a restricted domain an administrator must allow the application before any user's consent screen will complete.
4. Verify the domain's existing email authentication is healthy: an SPF record that covers Google's sending infrastructure, DKIM enabled and published for the domain in the Workspace admin console, and a DMARC record present. A connected mailbox inherits these, so a domain with broken records sends badly from day one.
5. In the sub-account, open the integrations or email settings area and start the Google connection for the user who owns the mailbox.
6. Complete Google's OAuth consent screen signed in as that user. Read the permissions on the screen itself and grant them; treat the consent screen as the authoritative list rather than assuming particular scope strings.
7. If consent fails, capture the exact error Google shows. A domain restriction, an organizational policy and an unverified application produce different errors and different fixes, and only one of them is something you can resolve inside the platform.
8. Set the from-name and the display address. Confirm the address shown is the mailbox you intended rather than another address on the same account.
9. Decide whether replies should go to the mailbox or to a different address, and set reply-to accordingly. Routing replies away from the connected mailbox breaks the thread-back behavior you connected it for, so do this deliberately.
10. Choose which outbound traffic uses this mailbox. Where the platform lets you select a sending channel per workflow, per campaign or per user, assign the mailbox to conversations and internal-feeling mail and leave campaigns on the dedicated domain.
11. Configure the signature in the platform. Gmail's own signature is applied by Gmail's compose window and will not be added to platform-sent mail.
12. Verify sending: email a test address, confirm it arrived, and inspect the received headers to see the authentication results and the sending path.
13. Confirm the sent copy appears in the mailbox's Sent folder, if that behavior is configured and expected.
14. Verify reply ingestion: reply from the test address and confirm the reply appears in the contact's conversation in the platform, threaded under the original rather than as a new message.
15. Verify threading in Gmail too: the reply and the platform's response should sit in one Gmail thread, not three.
16. Check bounce handling by sending to a deliberately invalid address on a domain you control, and confirm the bounce is recorded against the contact rather than sitting unseen in the mailbox.

Platform to Gmail

• Outbound messages: from-name and address, to, cc and bcc as configured, subject, HTML and plain-text bodies, and attachments.
• Threading headers on any message the platform sends as a reply, so Gmail groups it with the existing conversation.
• A copy of the sent message written into the Sent folder, where that behavior is enabled.
• Reply-to overrides where a workflow or campaign sets one.
• Tracking elements the platform adds, such as open pixels and rewritten click URLs, where those features are turned on.

Gmail to the platform

• Inbound replies to platform-sent messages, matched to a contact by address and attached to that contact's conversation.
• Thread and message identifiers used to keep the conversation grouped correctly.
• Bounce and delivery-status notifications arriving in the mailbox, which update the contact's email status where the platform parses them.
• Out-of-office auto-replies, which arrive as ordinary messages and will land in the conversation unless filtered.
• The connected account's address and basic profile, used to label the sending channel.

What does not move

• The existing mailbox history. Nothing from before the connection is imported, and old threads do not appear on contact records.
• Mail unrelated to platform conversations. The integration is not an inbox mirror; messages it cannot associate with a contact conversation stay in Gmail.
• Google Contacts. The address book does not populate or update CRM contacts.
• Labels, filters, rules and Gmail's categories. A platform tag is not a Gmail label and neither follows the other.
• Gmail's own signature, vacation responder and templates.
• Drafts composed in Gmail. A half-written reply in Gmail is invisible to the platform.
• Google Chat and Spaces messages, Drive attachments stored by reference rather than attached, and anything in Calendar, which is a separate connection.

Scenario: an inquiry arrives, the owner answers from her Workspace address through the platform, the prospect replies from her phone, and the thread stays intact everywhere.

1. A prospect submits the contact form on the website. The platform creates a contact and a conversation.
2. A workflow sends an acknowledgement through the connected Workspace mailbox. The recipient sees the firm's address as the sender, authenticated by the domain's existing DKIM signature.
3. A copy of that acknowledgement appears in the owner's Gmail Sent folder, so her own records are complete without her doing anything.
4. The prospect replies from her phone with two questions. Google delivers the reply to the mailbox.
5. The platform reads the reply, matches the sender address to the contact, and attaches the message to the existing conversation rather than creating a second one.
6. A workflow triggered by the inbound reply stops the three-step nurture sequence that was queued, applies an engaged tag and raises a task for the owner.
7. The owner answers from the conversation view in the platform. The outbound message carries the original message's threading headers.
8. In the prospect's mail client the answer appears inside the existing thread. In the owner's Gmail the whole exchange sits as one thread rather than three unrelated messages.
9. The owner's answer includes a booking link. The prospect books, and a separate calendar connection writes the appointment into the owner's calendar.
10. Two weeks later the prospect's mailbox is full and a later message bounces. The bounce notification arrives in the connected mailbox, the platform records the delivery failure against the contact, and a workflow flags the record for a phone follow-up instead.
11. A month later the firm runs a newsletter. That campaign goes out over the dedicated sending domain, not the mailbox, so the mailbox's reputation and sending allowance are untouched and the one-to-one channel keeps working.

Rate limiting

Two separate ceilings apply. The Gmail API has its own per-user quota, and the mailbox has a sending allowance that Google enforces regardless of how the message was submitted; Workspace and consumer accounts differ, and Google publishes the current figures in its Workspace administrator and Gmail help documentation. Exceeding the mailbox allowance can suspend sending for a period, which looks inside the platform like messages simply failing. Check the current published limits before planning volume, and route anything resembling a campaign elsewhere.

Retries and idempotency

A send that times out after the message was accepted will be retried and the recipient gets it twice. There is no universal idempotency key for a mailbox send, so the practical protections are at the workflow level: anchor sends on a single trigger, guard the branch with a tag or field so a replayed trigger is a no-op, and avoid sending from two workflows that can both fire on the same event. On the read side, dedupe inbound mail on the message identifier, because a poll can return the same message more than once.

Field-mapping traps

The from-address is the mailbox, so a template with a different sender hard-coded into it is silently overridden. A frequent source of confusion when one sub-account has several sending channels. Reply-to is the field that decides whether replies thread back; point it away from the mailbox and the conversation view stops updating while everything still appears to work. Merge fields that are empty render as literal placeholders, so set fallbacks. Display name and address are separate: changing the display name does not change which mailbox sends.

Duplicate creation

Duplicate conversations appear when a prospect replies from a different address than the one on file, so the platform cannot match them and creates a new contact. Workspace users with several aliases cause the same problem in reverse. Normalize addresses, store secondary addresses on the contact where the platform supports it, and merge rather than delete when you find a pair. Duplicate sends come from a contact appearing in two lists that both trigger the same workflow.

Sandbox versus live

There is no sandbox mailbox. Use a throwaway Workspace user or a spare consumer account for testing, and never prove a new workflow against the production mailbox that answers customers. A loop that sends to itself will fill the real inbox and burn the day's allowance.

Authentication expiry

The grant breaks when the user changes their password, when they revoke the application in their Google account's security settings, when an administrator restricts third-party access, when a Workspace license is removed, and sometimes after long inactivity. The platform usually keeps accepting the workflow and failing the send, so the visible symptom is customers not replying rather than an error anyone notices. Check connection health on a schedule and watch for a sudden drop in outbound volume.

What commonly breaks

• Campaigns sent through the mailbox, hitting the sending allowance and damaging the address's reputation.
• A Gmail filter or rule archiving platform mail, so replies are never read back into the conversation.
• Out-of-office auto-replies treated as genuine engagement, stopping a nurture sequence that should have continued.
• A departing employee's mailbox staying as the sub-account's sending channel after their license is removed.
• SPF, DKIM or DMARC records broken by a DNS change made for an unrelated reason, which degrades delivery with no platform-side symptom.
• Click tracking rewriting links to a domain that does not match the sending domain, which some filters treat as suspicious.
• Threading lost when a subject line is edited mid-conversation by a workflow, splitting one thread into two.