Skip to content
Evergrowth Documentation

Sync status and CRM ownership

When Evergrowth and your CRM keep each other current, the honest question a rep or a RevOps lead asks is “did my work actually land?” Sync status is the answer, recorded on each individual record. Instead of trusting that a write went through, you can see per record whether the latest sync succeeded, partly succeeded, failed, or was deliberately skipped, and why. CRM ownership is the companion idea: every record carries who owns it on the CRM side, so research and outreach respect the rep who already holds the relationship.

What sync status is

Section titled “What sync status is”

A connection between Evergrowth and your CRM is not a single on-or-off light. Each account, contact, and lead tracks its own outcome from the last time it tried to sync, in each direction. That record-level detail is what turns “the integration looks connected” into “this specific account reached the CRM, and these two fields on it did not.” It is the difference between assuming your pipeline is in step and knowing it.

Status is tracked separately for the two directions a record can move, because they answer different questions:

  • Outbound is Evergrowth writing to the CRM: did the research, the fit verdict, the enriched fields, and the outreach a colleague produced reach the CRM record where reps work?
  • Inbound is the CRM writing to Evergrowth: did the changes your team made directly in the CRM flow back so agents are working from current information?

A record can be perfectly synced one way and waiting the other, which is exactly why the two are reported on their own rather than blended into one verdict. The sync directions themselves are a setup choice covered in Integrations and Connect your CRM; this page is about reading the result.

The states a record can be in

Section titled “The states a record can be in”

A record’s sync settles into one of four states, plus a separate marker for a record whose CRM counterpart no longer exists. The first four are the same set in both directions.

  • Synced. The latest sync went through cleanly. The two systems agree on this record.
  • Partially synced. The record reached the CRM, but not every field landed. Some values could not be written, or could not be confirmed back, while the rest succeeded. This is a heads-up, not a failure: the record is in the CRM, but one or more fields need attention.
  • Failed. The sync did not go through. Something blocked the write, such as a problem talking to the CRM, a missing link to a CRM record, or a conflict with an existing record. A failed record is the one to act on, because the work a colleague did has not reached the rep yet. Diagnosing and clearing a failure is covered in When the CRM sync fails.
  • Skipped. The sync was intentionally not run, and that is usually correct behavior rather than a problem. A record is skipped when the rules you set tell Evergrowth to leave it alone. Common reasons: the record is marked Do Not Touch, it falls outside the filters you scoped the connection to, the kind of record is not set to sync in that direction, only internal housekeeping fields changed, or there was simply nothing new to write since the last sync. Skipped means “nothing was attempted, on purpose,” so it rarely needs action - though the stated reason tells you whether a rule is doing its job or quietly excluding records you meant to include.

Separately from those four, a record can be flagged as deleted from the CRM: the CRM record it was linked to has since been removed on the CRM side. Evergrowth keeps the record locally but stops trying to sync to a destination that is gone, so a future sync does not silently recreate something a colleague deliberately deleted. Reconnecting that record to a live CRM object is what resumes syncing.

Term mapping for Eva: in the product the four record-level states are exactly Synced, Partially synced (the underlying status is “warning”), Failed, and Skipped, reported per direction (outbound = workspace to CRM, inbound = CRM to workspace). “Deleted from CRM” is a separate flag on the CRM link, not a fifth status. Customers may call partially synced “synced with issues” or “some fields didn’t sync,” and skipped “ignored” or “didn’t sync.” Each record stores a human-readable reason behind its status (e.g. marked Do Not Touch, outside the sync filters, no field changes detected, deleted in CRM), which is what the resync and troubleshooting pages surface.

Why per-record status matters

Section titled “Why per-record status matters”

Silent drift is the failure mode that quietly erodes trust in a CRM. A rep opens an account expecting the research a colleague ran, and it is not there, with no sign of why. A RevOps lead reports pipeline by segment on enrichment fields that never finished writing. Per-record sync status removes the guesswork: every record carries its own outcome and a plain-language reason, so a gap shows up as a state on the record rather than as a missing fact discovered weeks later.

That visibility changes how a team works the book. Instead of re-importing everything or assuming the worst, a rep can see at a glance which records are in step and which need a second push. RevOps can find the records a rule is excluding and decide whether that is intended. And because the status names why a sync did what it did, the fix is usually obvious: a failed record points at a connection or mapping issue, a skipped record points at a rule that may be too broad, a partially synced record points at a single field that needs a home in the CRM.

When a record needs to go up again - a failure cleared, a field mapping fixed, or simply the latest values pushed on demand - you can resync it without re-running the agent that produced the work. The steps are in Resync a record to your CRM.

CRM ownership: respecting who holds the relationship

Section titled “CRM ownership: respecting who holds the relationship”

Every record that exists in your CRM has an owner there - the rep or account manager the CRM assigns to it. Evergrowth carries that ownership through, so a record in the workspace knows who owns it on the CRM side. This is not a cosmetic field. It is how the workspace stays aligned with how your team is actually organized.

Ownership matters for two reasons. First, it lets a team segment and work the book by who owns what: a rep can focus on their own accounts, a manager can review a territory, and RevOps can route work along the same lines the CRM already enforces. Second, it keeps Evergrowth a good citizen of your existing process. The system of record for who owns an account is your CRM, and Evergrowth defers to it rather than inventing a parallel notion of ownership that would drift out of step. When your team reassigns an account in the CRM, that change flows back in on the inbound side, so the workspace reflects the current owner without anyone re-keying it.

Term mapping for Eva: ownership shows up in two related forms. There is the workspace record owner (the member an account or contact is assigned to inside Evergrowth) and the CRM owner (the user the linked CRM record is owned by on the CRM side, surfaced as a “CRM Owner” filter). Both are available to filter and segment the book; the CRM owner is the one that mirrors the connected CRM’s own assignment. Treat the CRM as the system of record for ownership.

How syncing relates to enrichment

Section titled “How syncing relates to enrichment”

Enrichment is the work - a research colleague establishing stable facts about an account, a fit verdict, a verified email. Syncing is how that work travels to where reps live. The two are sequential: an agent produces the result, and the outbound sync carries it to the matching CRM field so the rep sees it on the record they already work, not in a second system they have to remember to check. This is why CRM enrichment is described as your CRM made trustworthy rather than a separate report.

Sync status is therefore the receipt for enrichment. A research colleague can do excellent work, but if the outbound sync is failing or a field has no mapped home in the CRM, that work has not actually reached the rep. Reading status per record is how you confirm the enrichment loop closed, and resyncing is how you close it when it did not. The same logic runs the other way: inbound sync keeps agents working from what your team changed directly in the CRM, so enrichment and qualification act on current information rather than a stale snapshot.

In practice

Section titled “In practice”

A RevOps lead notices that an account a research colleague qualified last week is not showing its fit verdict to the owning rep. Opening the account’s sync detail, the status reads Partially synced: the fit verdict wrote fine, but one enrichment field shows as not confirmed in the CRM because that field has no mapped destination yet. The lead maps the field, resyncs the record, and the status flips to Synced - no need to re-run qualification. Scanning the rest of the book, a handful of accounts read Skipped, with the reason “marked Do Not Touch,” which is exactly the intended behavior for those accounts. One reads Deleted from CRM, because a rep removed the duplicate in the CRM directly; the workspace correctly stopped pushing to a record that no longer exists. In a few minutes the lead has confirmed the pipeline is in step, fixed the one real gap, and left every deliberate exclusion alone.

Section titled “Related”