Connect a CRM

Connecting your CRM lets Evergrowth read records from it and push enriched data and qualification results back, so your reps work from a single source of truth. This page walks through installing the integration, authenticating, turning on each object and mapping its fields, setting which records flow in each direction, linking your people to their CRM seats, running an initial import, and reading the sync activity afterwards. For the meaning of the sync states you will see on each record, see CRM sync status.

Before you start

You need a workspace account with full access. The Integrations entry in the left navigation is hidden for read-only accounts.
You need permission to authenticate the CRM. The connect step signs in to your CRM, so have those credentials ready or work with whoever holds them.
Decide which objects you want to sync (Accounts, Contacts, and where supported, Leads) and in which direction before you turn syncing on. Some CRMs can also read in Activities (calls, emails, meetings, tasks, and notes logged in the CRM) and Opportunities (deals) as read-only records. Both are on by default and each has its own switch, so you can pull one and not the other, or neither. Once enabled, they keep arriving automatically on your periodic sync schedule, the same as Accounts and Contacts - see Set the sync rhythm and Run an initial import to bring in what already exists in your CRM.

Steps

Install the integration

In the left navigation, open Integrations. The page is grouped into sections - CRM, Chat with Eva, Eva in your AI assistant, and Data enrichment - with tabs across the top (All, CRM, Chat, AI assistants, Data enrichment) to narrow it to one. In the CRM section, connected CRMs come first. Each connected one shows a status chip, when it last synced (or No syncs yet), how many objects are on, and a warning if any required field is still unmapped. Each CRM not connected yet shows a short description and a Connect button, which only appears if you have permission to change integrations.
Select Connect on the card of the CRM you want to connect. This opens the install flow.
A connect window opens showing Install new CRM Integration. Sign in to your CRM and approve access in that window.
On success you are returned to the integration’s own page after a moment. If something goes wrong, you are sent back to the list with an error message.

Once connected, Manage on the card takes you back to the integration’s page at any time. When the connection is not running normally - paused, or stopped by a problem such as an expired sign-in - the card also shows a Re-authenticate button next to Manage, for anyone allowed to change integrations.

Find your way around the integration page

The page opens with a header card - the CRM’s name, its status, when it was connected, a Run sync button, and an actions menu (the vertical three-dots button) holding Re-authenticate and Uninstall - and then four tabs:

Overview - the health of the connection at a glance, which objects are on, and the two workspace-wide sync settings.
Objects - one object at a time: which directions it flows, which records are allowed through, and how its fields map. This tab is not shown for a connection that has no objects to map.
Users - who in Evergrowth corresponds to which seat in your CRM.
Activity - what the syncs actually did, as whole runs and record by record.

Until the connection is set up, Overview leads with a Finish setting up card that counts off four steps and links straight to each one: turn on the objects you want to sync, map the required fields, link your users, and run your first import. It disappears once no object is missing and a run exists, so it is a checklist rather than a permanent fixture.

Check the connection

The status chip in the header shows Active, Paused, Connecting, or Error. Where the CRM gave a reason, hovering the chip shows it, and the line under the name repeats it.
While the connection is being established it shows Connecting and the page refreshes on its own until it settles.
If the status is anything other than Active, a Re-authenticate button appears next to it. You can also re-authenticate at any time from the actions menu, whatever the current status. Either one reopens the connect window (shown as Re-authenticate CRM Integration) so you can sign in again. Do this whenever the CRM connection has expired or been revoked.
Overview turns the same question into four tiles: Connection (Healthy when active, otherwise the status), Last inbound sync (data pulled from your CRM), Last outbound sync (data pushed to it), and Latest sync (the most recent run, as a count of completed and errored records, linking to Activity). If periodic syncing is on and nothing has come in for more than a week, the inbound tile is flagged in amber - that is the tile to trust over the status chip, because a connection can read as active while nothing is actually arriving.

Set the sync rhythm

The Sync settings card on Overview holds the two workspace-wide settings:

Realtime outbound shows whether changes are being pushed to your CRM. It reads Active once at least one object is switched on in the outbound direction, and Off otherwise, with a hover explaining that nothing is enabled yet. Changes you make in Evergrowth are pushed to the CRM within about five seconds. An object that only reads in does not make this active - pulling data is not pushing it.
Periodic inbound controls how often Evergrowth pulls data from your CRM. Choose from Disabled, Every 15 minutes, Every 30 minutes, Every hour, Every 2 hours, Every 4 hours, Every 12 hours, or Daily. Some CRMs do not allow the shortest intervals, so the list you see may start at a longer one. This one frequency covers every object your CRM supports and has switched on - Accounts, Contacts, Leads, Users, and, where available, Activities and Opportunities - there is no separate schedule for the read-only objects.

Turn on an object and choose its directions

Open Objects. A row of cards at the top switches between the objects your CRM supports - Accounts, Contacts, and (where available) Leads, Activities, and Opportunities - each showing On or Off and either how many of its fields are mapped or Read only. The object you are looking at is drawn as a pipe between Evergrowth and your CRM, with one lane per direction:

To your CRM - switch this on to push records out. Off, nothing leaves Evergrowth for this object.
From your CRM - switch this on to pull records in. Off, nothing arrives.
Each lane carries a filter control reading No filter or N conditions. Click it to open the conditions that decide which records are allowed through that lane: outbound decides which records appear in your CRM, inbound decides which records are pulled into Evergrowth. Build a condition group and Save, or Delete to clear an existing set. A lane with conditions is drawn as a narrower stream, so you can see at a glance that something is being held back.
Switching both lanes off stops the object syncing altogether. The directions you had chosen are remembered, so turning a lane back on picks up where you left off.

An object your CRM has not set up on its side says so instead of offering the lanes.

If your CRM writes new people as Leads, the Leads object’s outbound conditions are the ones that decide. With Lead writing enabled, a contact leaving Evergrowth is created in your CRM as a Lead, so it is judged against the Lead conditions and not the Contacts ones. Put the conditions that should gate who reaches your CRM on the Leads object in that setup. This matters most for a condition that describes the CRM record itself - for example, one that requires an existing CRM record type - because a person who has never been pushed to your CRM does not have one yet, so a filter like that on Contacts would hold back the very records the sync was meant to create.

Activities and Opportunities have one lane each. These two are read into Evergrowth and never written back, and they have no fields of their own to map, so they show a single inbound lane marked Read only and no field list. Three things to know before you touch them:

Both start enabled. If you have never opened them, the feeds are already running. Turning one off is a deliberate choice, usually because your team does not want that history in the workspace, or because the CRM’s activity volume is noise rather than signal for how you sell.
Accounts and Contacts have to be set up first. Every activity and every deal links to the account and contact it belongs to, so enabling one before those two are syncing is refused with a message saying so. Get Accounts and Contacts mapped and enabled, then come back.
Turning one on does not import history. The switch governs what arrives from now on. To pull what already exists in your CRM, run an import - see Run an initial import. Turning one off likewise leaves what has already synced in place; it stops new records arriving rather than clearing the record.

Switching either one off also stops an import from bringing it in: a manual sync scoped to a disabled feed is refused rather than quietly running.

Map fields

Under the pipe, the same Objects tab lists every Evergrowth field for that object, grouped into collapsible sections that each carry their own mapped-out-of-total progress. Every row shows the Evergrowth field on the left, the connection in the middle, and the CRM field on the right - or Not mapped, with a suggestion where one exists. A field the sync cannot run without carries a Required chip, in amber while it is still unmapped.

To narrow a long list, use Search, the Coverage filter (Mapped, Unmapped, or Required, not mapped, each with its count), and the Group filter.

Click any row - or its Map / Edit button - to open the mapping modal for that one field.
To do several at once, tick the rows (or the checkbox on a group header to take the whole section) and click Map N selected.
Where Evergrowth can already see a matching property in your CRM, a Map N auto-mappable button offers all of them in one pass. This is the fastest way through a first setup: take the automatic ones, then work through what is left.
In the modal, each field shows its Direction and its CRM field. Pick the CRM field from the list, or accept the suggested one - the modal names it and offers a one-click Use suggestion, and Pick a field manually to override. Where a suggested CRM field type is known, it is shown so you can create the right kind of field in your CRM if it does not exist yet.
Where a field supports it, toggle Wrap in HTML for the incoming or outgoing direction to convert the value to or from HTML formatting. Attio has no formatted text fields, so it never offers this: fields Evergrowth creates there, including those for plays and account plans, are plain text, and values arrive without HTML tags.
Where a field supports it, use Always send a fixed value to your CRM to send a constant instead of whatever the record holds - see Send a constant instead of the record’s value below.
Click Save.

Clearing the CRM field on a mapped row is how you unmap it. The modal says the mapping will be removed when you save and offers an Undo, so an accidental clear is recoverable before it lands.

Not every field offers every setting. Which options appear on a row is decided per field, so a row with no fixed-value box simply does not support one.

Let your CRM hand back Evergrowth’s own record id

Most of the time Evergrowth recognizes an incoming CRM record by the link it already holds for that connection, and failing that by name and website. That is enough for a single CRM. It stops being enough when the same company reaches you twice - typically because your team mirrors records between two CRMs, so the second copy arrives through a connection that has never seen it, under a name or a domain that drifted somewhere in the copying. Name and website matching misses it, and you get a parallel account with its own contacts underneath.

The fix is to let the CRM carry Evergrowth’s own record id and give it back. Map the Evergrowth record id outbound to a field in each CRM - the same identifier you see as EG-ACC-ID on an accounts export and EG-CON-ID on a contacts one - and every record Evergrowth writes carries it from then on. When a copy of that record comes back in from any connection, the id resolves it exactly, ahead of any name-and-domain guess, and the copy updates the record you already have instead of creating a second one. Accounts, contacts, and leads all read it.

Two deliberate limits are worth knowing. The id only ever resolves a record inside your own workspace, so a value that arrived in a CRM field from somewhere else cannot reach anyone else’s data. And the id is only ever read, never written: a CRM field holding the wrong value cannot overwrite the identity of the record it just matched. Nothing changes for a single-CRM setup, where the connection’s own link already does this job.

Send a constant instead of the record’s value

Some CRM fields are not really about the record at all - they are about where the record came from. A lead source that should always read the same thing, a channel tag your reporting groups on, a marker that tells the rest of your CRM which system created the row. Mapping those to a record field is the wrong shape: there is nothing on the account or contact to map, and asking reps to type the same word onto every record is how the field ends up half empty and inconsistent.

On an outbound mapping, leave Always send a fixed value to your CRM empty and Evergrowth sends whatever is on the record, as usual. Type something into it and Evergrowth sends exactly that text every time the record syncs, ignoring the value on the record itself. A lead source that always reads “Evergrowth” is the typical case.

As soon as a fixed value is set, a second choice appears: Replace the value already in your CRM.

On - the fixed value always wins and overwrites what is already in the CRM field.
Off - Evergrowth only fills the field in while it is still empty in your CRM, so anything your team already put there is left untouched. That includes a dropdown value Evergrowth does not recognise as one of the field’s options: it counts as filled, not empty.

Off is the safer default on any field a human might have set by hand, and the right choice when the constant is meant to fill gaps rather than to govern the field. Turn it on when the constant is the single source of truth for that field and a stale value there would misreport your pipeline. Because a fixed value applies on every sync of every record in scope, decide this before your next import rather than after - a mistaken overwrite is a lot of records to correct.

Eva: this is a per-field, outbound-only setting on the field-mapping modal, and it exists alongside the direction and Wrap-in-HTML settings rather than replacing any of them. The overwrite switch only appears once a fixed value has been typed in - a customer who cannot find it has probably left the value box empty. Clearing the box removes the fixed value and returns the field to sending the record’s own value. When a customer reports “every record in my CRM has the same value in this field,” a fixed value is the first thing to check; when they report “Evergrowth is not overwriting what my rep typed,” the overwrite switch being off is the expected behaviour rather than a sync failure.

If a CRM field shows a warning icon, it is system-managed in your CRM and Evergrowth cannot add new picklist or multi-select options to it automatically. Make sure that field’s options in your CRM include every value Evergrowth might send, or the value may not appear there.

Coming the other way, Evergrowth keeps the list of options for a mapped dropdown or multi-select field in step with your CRM on its own. It refreshes those lists every hour, and refreshes them again as soon as an incoming record arrives carrying an option it does not recognize, so an option your team adds in the CRM after the mapping was saved becomes usable without anyone re-saving the mapping. This covers the dropdown fields your team created in the CRM; the CRM’s own built-in dropdowns have a fixed set of options and need no refresh.

One thing to know about timing: the record that triggers a refresh is not filled in retrospectively. Until the refreshed list is in place, an incoming record whose dropdown value was unrecognized arrives with that field empty and still reports as Synced, because the sync itself succeeded. Once the list is current, that record picks the value up the next time it changes in your CRM. If you need a set of older records corrected sooner than that, ask your administrator: repairing a window of already-synced records is done for you rather than from this page.

Link your people to their CRM seats

The Users tab is how a record owner in Evergrowth becomes the native owner of the record in your CRM. Every owner push - the real-time sync, the ownership rules, and imports - looks the owner up here. It is laid out as three sections so the work left to do is obvious:

Linked - the pairs already treated as the same person. Records owned by the Evergrowth user get the linked CRM user as owner. Use the search box to find someone in a long list, relink to a different seat, or unlink the pair.
In Evergrowth, not linked yet - people whose owner pushes fall back to matching by email. An unlinked person is not broken: they are matched to the CRM user with the same address. Where such a match exists it is offered on the card as Email match, so linking it is one click. Linking is what you need when the two addresses differ, which is common when people sign in to the CRM with a different work address.
In your CRM, not linked yet - CRM seats nobody in Evergrowth is linked to. You can link from this side too, which is the quicker direction when you are working through a CRM’s user list rather than your own team’s.

A linked pair can carry a warning about either side of it, and each one asks for something different:

A deactivated CRM user means the seat you linked to is switched off in your CRM. Records fall back to the email match until you relink the person to a live seat or unlink the pair.
Invite pending means the teammate has not accepted their Evergrowth invitation yet. The link is already in place and will work the moment they do, so there is nothing to do here.
Deactivated on the Evergrowth side means the person’s own workspace access was switched off. Unlink the pair to free that CRM user up for somebody else.
A person no longer in the workspace means they have been removed from Evergrowth entirely, and the pair can be unlinked to free up the CRM seat.

The last three look alike from the outside but are not the same state, and only two of them need action - an invited teammate who has simply not signed in yet is not a broken mapping.

If your CRM has no concept of a record owner, the tab says owner push is not supported and linking has no effect there. Where owner pushes are supported, an owner with no CRM seat at all is left out of the push rather than guessed at, so the CRM keeps whatever owner it already had.

Run an initial import

Turning on syncing only affects records that change from then on. To bring in or push out records that already exist, use Run sync in the header (or Run import on the setup checklist):

Choose the scope: Initial syncs everything from your CRM in the order the sync requires, or Custom to do one object of your choice. An initial run always imports.
For a custom run, choose the direction - Import from your CRM, or Export to it - then the Object. The object list covers your synced objects (Accounts, Contacts, and where supported, Leads) plus, on an import, Users and - where your CRM supports them - Activities and Opportunities. Those three only ever come into Evergrowth, so they are not offered on an export. Enable Accounts and Contacts syncing first, since each activity and deal links to the account and contact it belongs to. A feed you have switched off is skipped here too.
Under Existing records, decide what the run is allowed to do: Create missing records and update existing ones, Only create records that are missing, or Only update records that already exist. The modal restates your choices as one sentence before you commit, so read that line - it is the difference between filling gaps and rewriting what is already there.
Click Start import (or Start export). A run can create or overwrite many records at once, so treat it as a deliberate act rather than a refresh.

While a sync runs, a Sync in progress chip appears in the header, Run sync is disabled, and Overview shows the run building up on the Latest sync tile.

Read what the syncs did

The Activity tab has two views:

Sync runs - one row per import or export, with its status, direction, the objects covered, and when it started. Expanding a row shows the run’s own id and a breakdown per object: status, start and finish, and a meter splitting the records received into processed, rejected, and in progress. The rejected count links straight to the record log filtered to errors, which is the fastest route from “this run had problems” to why.
Record log - one entry per record that synced in or out, including skips and errors with their reason. Each entry’s direction reads as an arrow between Evergrowth and your CRM’s name, the same wording the sync runs use. Filter by Search, Status, Entity, and Direction, and open an entry to see the full detail: the reason it landed the way it did, the CRM’s record id, the CRM record received, the data sent to the CRM, the conditions applied, and the record as it stood at sync time. Entries that came from a periodic sync rather than a manual run are marked as such.

What happens next

Enabled objects sync automatically: outbound changes reach your CRM within about five seconds, and inbound pulls - including Activities and Opportunities, where your CRM supports them and you have left them on - run on the frequency you set.
A manual run appears under Sync runs with a status of Queued, In progress, Completed, Failed, or Skipped, and keeps updating on its own while it works.
An owner assigned in Evergrowth is pushed to the CRM as the record’s native owner, resolved through the Users tab. A person nobody has linked and whose email matches no CRM user syncs without an owner, so the CRM keeps its own default - check that tab first if owners are not landing.
Where a CRM record arrives carrying an owner whose seat you have linked, the Evergrowth owner follows it, so an owner change made in the CRM is reflected here rather than fighting the sync. Unlinked CRM owners are left alone; an email match is deliberately not trusted in this direction.
In Salesforce, an update Evergrowth sends to an existing lead does not re-run your lead assignment rules, so the lead keeps its owner. A new lead still goes through your assignment rules, unless Evergrowth set its owner itself.
Synced records carry a sync status on the account and contact pages - see CRM sync status for what each state means and Resync to CRM to retry a single record.