Helpdesk migration
Field-level mapping, validation, and rollback between Gmelius and Intercom. We move data and schema; workflows are rebuilt natively in Intercom.
Gmelius
Source
Intercom
Destination
Compatibility
9 of 11
objects map 1:1 between Gmelius and Intercom.
Complexity
CModerate
Timeline
2-4 weeks
Overview
Moving from Gmelius to Intercom is a platform-category shift: Gmelius is a Gmail extension that layers shared inbox functionality onto existing email threads, while Intercom is a dedicated multi-channel helpdesk with its own conversation model, team inbox, and AI layer. Gmelius stores no public API, so we extract all data via the Gmail API and Google Contacts API, reconstruct Gmelius Shared Inboxes as Intercom Inboxes with team assignments, map email threads to Intercom Conversations with full message threading, translate Shared Labels to Intercom Tags, and convert Shared Templates to Intercom Macros. Automation Rules and Kanban board configurations have no export path — we document the rule logic and board layout during discovery and hand off a written rebuild specification for the customer's admin. SLA configurations and analytics are tier-gated in Gmelius and migrate as metadata rather than live dashboards. We do not migrate workflows, sequences, or browser-extension configurations as code.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Gmelius object lands in Intercom, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Gmelius
Shared Inbox
Intercom
Inbox + Team
1:1Gmelius Shared Inboxes map 1:1 to Intercom Inboxes. During discovery we capture each Shared Inbox's member list, assignment rules, and SLA configuration. We create corresponding Intercom Teams (Settings > Inbox > Teams) and assign the migrated teammates to the matching team. The Gmelius inbox name becomes the Intercom Inbox name. Note: Intercom Inboxes are workspace-scoped, not user-scoped, so Gmelius team members who previously accessed a shared inbox individually will access the Intercom Inbox as team members.
Gmelius
Email Conversation (thread)
Intercom
Conversation
1:1Full email threads export from Gmelius via the Gmail API. Each thread becomes one Intercom Conversation with all messages preserved in chronological order as Conversation Parts. The original email headers (Message-ID, In-Reply-To, References) map to Intercom's internal thread tracking. Attachments are downloaded from Gmail and re-uploaded as Intercom Conversation attachments. Assignee, status, and tags from Gmelius migrate as conversation metadata. Email addresses on the From/To/CC fields map to Intercom Contacts (created if they do not exist).
Gmelius
Shared Label
Intercom
Tag
1:1Gmelius Shared Labels are Gmail-native and export via the Gmail API label list. We recreate them as Intercom Tags (Settings > Tags) and apply them to the corresponding Conversations. Label hierarchy (parent label / child label) is flattened to a dot-notation tag namespace (e.g., billing.high-priority becomes a tag named 'billing.high-priority') because Intercom Tags are flat. The customer chooses whether to keep the full taxonomy or consolidate during scoping.
Gmelius
Shared Email Template
Intercom
Macro
1:1Gmelius Shared Email Templates store text with variable placeholders. We export the full template library including subject line, body, and merge field syntax. At Intercom we create Macros (Settings > Macros) using the same content. Variable placeholders in Gmelius syntax (e.g., {{contact.first_name}}) are translated to Intercom's {{token}} syntax. HTML-formatted templates are preserved; plain-text templates are migrated as-is.
Gmelius
Automation Rule
Intercom
Rule (documentation only)
lossyGmelius Automation Rules define conditional routing, auto-assignment, and follow-up sequences stored as extension-local configuration. There is no export mechanism. We capture every active rule during the discovery walkthrough via screen recording and structured intake, document the trigger condition, action sequence, and exception path, then hand off a written rule specification to the customer's admin for rebuild in Intercom Rules. Multi-step rules with AI dispatching (Gmelius Pro tier) require the most reconstruction effort. We do not migrate Automation Rules as executable code.
Gmelius
Kanban Board
Intercom
Inbox View (custom filter)
lossyGmelius Kanban boards visualise email pipelines by status columns. Board columns map to Intercom Inbox Views with custom conversation filters per column (e.g., filter by assignee + status = 'Open'). Card-to-conversation associations are preserved during migration by applying the corresponding conversation status on import. Custom board layouts with non-standard column logic are documented as filter specifications for the customer's admin to configure in Intercom. Kanban card metadata (due dates, priority) migrates as conversation-level custom attributes.
Gmelius
Contact (via Google Contacts)
Intercom
Contact
1:1Gmelius does not maintain its own contact database — contacts live in Gmail and Google Contacts. We export contacts via the Google Contacts API, preserving name, email, phone, company association, and any Gmelius-specific contact tags applied to threads. Contacts are created as Intercom Contacts (Contacts > Import > CSV) with external_id set to the Google Contact ID for deduplication. Duplicate contacts (same email, different Google Contact ID) are merged at import.
Gmelius
SLA Configuration
Intercom
SLA (Pro+ tier) + Custom Attribute
1:1SLA & Email Analytics is a Gmelius Growth and Pro tier feature. SLA rules (first response time, next response time, resolution time) are exported as custom conversation attributes in Intercom (Conversation Attributes or custom attributes on the Contact). Intercom's native SLA feature is available on the Pro and Enterprise tiers and requires manual configuration post-migration with the migrated SLA values. Dashboard-level analytics from Gmelius are not importable and are documented for rebuild in Intercom Reports.
Gmelius
User / Team Member
Intercom
Teammate
1:1Gmelius users correspond to Google Workspace accounts. We extract the user list (name, email, role within Gmelius) and map them to Intercom Teammates. Inactive Gmelius users are created as inactive Intercom teammates. Permissions mapping: Gmelius Admin becomes Intercom Admin; Gmelius Member becomes Intercom Agent. The customer's Intercom admin provisions the teammates before migration and we reconcile any gaps in a user provisioning queue.
Gmelius
Email Note / @mention
Intercom
Conversation Part (internal note)
1:1Email notes and @mentions applied to Gmelius threads are exported as Intercom internal notes (Conversation Parts with part_type = 'note'). Note authorship and timestamps are preserved. The note author maps to the corresponding Intercom Teammate. Attachments on notes migrate as Intercom Conversation attachments linked to the note.
Gmelius
Shared Draft
Intercom
Macro
1:1Gmelius Shared Drafts are collaborative email drafts stored as draft objects in the Gmelius extension layer. Since Intercom does not have a shared-draft concept, we export Shared Drafts as Intercom Macros using the draft content. The customer chooses which drafts to preserve as reusable macros versus discarding. Variable placeholders are translated to Intercom token syntax.
| Gmelius | Intercom | Compatibility | |
|---|---|---|---|
| Shared Inbox | Inbox + Team1:1 | Fully supported | |
| Email Conversation (thread) | Conversation1:1 | Fully supported | |
| Shared Label | Tag1:1 | Fully supported | |
| Shared Email Template | Macro1:1 | Fully supported | |
| Automation Rule | Rule (documentation only)lossy | Fully supported | |
| Kanban Board | Inbox View (custom filter)lossy | Fully supported | |
| Contact (via Google Contacts) | Contact1:1 | Fully supported | |
| SLA Configuration | SLA (Pro+ tier) + Custom Attribute1:1 | Fully supported | |
| User / Team Member | Teammate1:1 | Fully supported | |
| Email Note / @mention | Conversation Part (internal note)1:1 | Fully supported | |
| Shared Draft | Macro1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Gmelius gotchas
Gmail-only lock-in is irreversible for mixed email environments
No formal public API on lower tiers limits programmatic data export
Automation Rules are extension-local state with no export mechanism
All team members must share the same plan tier
Extension conflicts with other Gmail add-ons cause UI instability
Intercom gotchas
S3 JSON export omits conversation transcripts
Workspace isolation prevents workflow migration
Fin AI resolution fees compound with automation success
Two-year conversation history limit on historical export
Private app rate limits share workspace quota
Pair-specific challenges
Migration approach
Discovery and Google Workspace authorisation
We conduct a discovery session with the customer's admin to enumerate all Shared Inboxes, Kanban boards, Shared Templates, Automation Rules, and SLA configurations. We capture the Gmelius plan tier, user list, and conversation volume estimate. We then set up Google Workspace OAuth 2.0 scopes for Gmail API and Google Contacts API access, scoped to the specific Gmelius user accounts in use. We export a full list of Gmelius users and map them to Intercom teammates for provisioning.
Data extraction via Google Workspace API
We extract all email threads (messages, headers, attachments, labels) via the Gmail API in paginated batches. Attachments are downloaded to local storage and re-uploaded to Intercom during import. Google Contacts are extracted via the People API. Gmelius-specific metadata (assignee, tags, SLA status) is extracted from the extension configuration captured during discovery. All extraction runs read-only against the source environment.
Intercom workspace provisioning and schema design
We create the Intercom workspace structure before importing data. This includes provisioning Teams (mapped from Gmelius Shared Inboxes), creating Inbox Views (mapped from Kanban board columns), creating Tags (mapped from Shared Labels), and creating Macros (mapped from Shared Email Templates). SLA configurations are documented as custom conversation attributes for manual configuration on Intercom Pro or Enterprise. Custom Objects are not required for this migration unless the customer has Gmelius Pro features that reference external CRM data.
Demo migration and reconciliation
We run a sample migration of 50-100 conversations into a staging Intercom environment. The customer's admin reviews the conversation threading, tag application, assignee mapping, and attachment fidelity. We reconcile row counts against the source extraction log and correct any mapping issues before the production migration. This step also surfaces whether Intercom's conversation-merge behavior for multi-thread customers requires a suppression strategy.
Production migration in dependency order
We run the production migration in record-dependency order: Teammates first (validated by the customer's Intercom admin), Contacts (from Google Contacts), then Conversations (with assignee, tags, and SLA metadata applied). Attachments upload in parallel with message imports. Automation Rule specifications and Kanban board column mapping are delivered as written documentation for the customer's admin to rebuild in Intercom Rules and Inbox Views.
Cutover, delta sync, and rebuild handoff
We freeze writes on the Gmelius source, run a final delta migration capturing any new conversations during the migration window, then enable Intercom as the system of record. Active Intercom Outbound campaigns are re-enabled post-cutover. We deliver the Automation Rule inventory, Kanban board mapping document, and SLA rebuild specification to the customer's admin. We support a three-day hypercare window for reconciliation issues raised by the team. Workflow rebuilds and Rule recreation are outside migration scope.
Platform deep dives
Gmelius
Source
Strengths
Weaknesses
Intercom
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 3 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Gmelius and Intercom.
Object compatibility
3 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Gmelius: Not publicly documented.
Data volume sensitivity
Gmelius doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Gmelius to Intercom migration scoping. Not seeing yours? Book a call.
Walk through your Gmelius to Intercom migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Gmelius
Other ways to arrive at Intercom
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.