You spend an hour adding custom fields to Affinity—wealth advisor tier, asset location, family structure—then sync to Gmail. Four hours later, your team notices the fields are gone. You pull the contacts back into Affinity. The custom data is still there, but it never made it to Gmail. Your relationship manager works in Gmail; Affinity is the vault. When the sync doesn't bridge them, you lose the source of truth. This is not a rare edge case. Affinity's bidirectional sync with Google Workspace has hard limits baked into the Gmail API, and Affinity's sync architecture was not built to handle them. If you manage client relationships at depth—contact tags, deal association, custom fields, interaction history—the sync will eventually strand critical data. Understanding where and why this happens is essential before it costs you a deal or a client relationship. Where Affinity's Gmail sync actually breaks The sync failure is not uniform. Some data moves cleanly; some orphans silently. Understanding the exact failure points helps you decide whether to work around the limits or switch platforms. Custom fields don't sync back to Gmail This is the most common failure. You create a custom field in Affinity—"Client Wealth Tier," "Next Review Date," "Account Custodian"—and set values for your contacts. When Affinity syncs to Gmail, these fields do not appear in Gmail contacts. The data lives only in Affinity. Your team works in Gmail. They see the contact name, email, phone, and standard fields (company, title) but not the relationship context you've built in Affinity. They add notes to the Gmail contact. Those notes sync back to Affinity, but the moment they need to filter or act on your custom fields, they are blind. Why this happens: The Gmail API's Contacts scope (people.me.connections) supports only a fixed set of standard fields. Custom fields are a Affinity-specific schema. Google's API has no contract for arbitrary key-value pairs on a contact. Affinity could work around this by writing custom fields as plain-text notes in Gmail's notes field, but that makes them unsearchable and fragile. Affinity's choice has been to keep custom fields Affinity-only. Contact tags disappear in Gmail In Affinity, you tag a contact with "Warm Lead," "Referred by John," or "Needs Quarterly Check." These tags are relationship metadata—they drive your workflow. You sync to Gmail. The tags do not appear. Gmail has no native tags field in its Contacts API. The data is orphaned. When your team opens Gmail and needs to know if this contact is warm or cold, they have no signal. They may send a generic email. A warm lead gets a template; a referred lead gets a personal note. Without the tag, the interaction degrades. Deal associations and pipeline context stay in Affinity only Affinity has a Deals module. You can link a contact to a deal—say, a $500K wealth management engagement. When you sync to Gmail, the deal does not appear. Your relationship manager opens Gmail, sees the contact, and has no idea they are in active negotiations or that a deal just closed. They may send an ill-timed message or miss an opportunity to deepen the relationship. The Gmail Contacts API has no deals field. Unlike Salesforce, which has explicit relationship objects, Gmail is fundamentally a contact store. Affinity could layer deal context as custom fields or notes, but Google's API limits note length and searchability. The context stays trapped in Affinity. Interaction history syncs one direction only Email sent from Gmail can be logged to Affinity if you use Affinity's Gmail extension. But if your team sends an email from a Gmail web client without the extension installed, or if the extension fails silently, the interaction is lost. Affinity has no server-side webhook to capture all Gmail sends. You are dependent on client-side instrumentation. In a distributed wealth advisory team, this breaks quickly. Sync timing and concurrency issues Affinity syncs to Gmail on a schedule—typically every few hours, not in real-time. If your team updates a contact in Gmail (adding a note, changing a number), Affinity pulls it back. But the reverse is slower. You add a contact to Affinity, assign it to a relationship manager, and the manager does not see it in Gmail for hours. They may add the contact to Gmail manually, creating a duplicate. When the sync eventually runs, you have duplicate records and broken merge logic. Gmail's API also has rate limits: 1 million quota units per day per account, with each contact read or write consuming units. At scale, with hundreds of relationship managers and thousands of contacts, you hit the limit. Affinity's sync queues. Contacts wait. The sync falls behind. The core API problem: Gmail wasn't built for CRM sync The root cause is architectural. Gmail's Contacts API (now Google Contacts API v1) was built to sync your personal address book across devices, not to support a unified CRM ecosystem. It assumes: Flat contact schema. Standard f