CRED × CRM — How the integration works in the CRED UI

Audience: CRED commercial users connecting their CRM (HubSpot, Salesforce, or Microsoft Dynamics 365) to CRED.

Purpose: A CRM-agnostic explainer of what the CRED app does when you connect a CRM — sync direction, mapping, manual triggers, enrichment, troubleshooting, and where to find action logs. Use this as the entry point. Each CRM has its own dedicated article for the specifics that differ.

1. The mental model

CRED is a bidirectional CRM extension. When you connect a CRM, three things happen:

1. Read sync (CRM → CRED). CRED pulls records from your CRM into its own database so the rest of the CRED app (lists, signals, scoring, outreach, agents) can work on them.

2. Write sync (CRED → CRM). Records you create or update in CRED are pushed back to the CRM so your reps see one source of truth.

3. Enrichment (CRED data graph → the record). CRED can enrich a record with the proprietary CRED graph (firmographics, contacts, signals, scores). Enrichment is a separate step from sync — this distinction is the most common source of confusion. See section 5.

Per-CRM specifics live in their own article

This article covers behaviour that is the same across every CRM. For the things that differ — entity types supported, exact sync cadence, OAuth scopes, write-back rules, known limitations — jump to:

• HubSpot: CRED × HubSpot — sync, enrichment, troubleshooting

• Salesforce: CRED × Salesforce — sync, enrichment, troubleshooting

• Microsoft Dynamics 365: CRED × Dynamics — sync, enrichment, troubleshooting

2. What CRED syncs

CRED supports the same core entity model across every CRM. The exact entity names and per-entity field coverage vary by CRM (see the per-CRM article).

Custom fields: CRED auto-discovers every custom field on every supported object during the initial setup and creates a corresponding mappable field in CRED. You decide which ones to map.

3. Sync settings — the four modes

Every entity in every CRM connection is governed by a SyncSettings record with one of four update modes. The mode determines how CRED handles values that exist in both systems.

You can set the mode per entity per direction in Settings → Integrations → [your CRM] → Sync settings.

4. How sync runs — under the hood

Every CRM uses the same two-phase ingestion pipeline. The cadence and API endpoints differ; the architecture does not.

Phase 1 — Read

CRED queries the CRM for records modified since the last sync, paginates through them, and stores the raw payload as ImportRecord rows.

• Initial sync (first time you connect): A full read of every supported entity in dependency order — Users → Accounts → Contacts → Pipelines → Stages → Opportunities. Large CRMs (hundreds of thousands of records) can take hours. Progress is visible in the UI.

• Incremental sync (every run after that): CRED filters by the CRM's modified-date field (LastModifiedDate, modifiedon, lastmodifieddate) and only fetches records that changed since the last sync.

• Stale-task recovery: If a read task hangs for more than 15 minutes it is restarted automatically. Records that fail Phase 2 are retried after 4 hours.

Phase 2 — Process

Each ImportRecord is converted into a CRED entity (Account, Contact, Opportunity, …). Relationships are resolved (a Contact's company is matched to an existing Account, etc.). Fields are written into CRED's typed schema based on your mapping configuration.

Write-back (CRED → CRM)

When you create or update a record in CRED, a DATA_SYNC_CREATE or DATA_SYNC_UPDATE task is scheduled that pushes the record back to the CRM. Write-back respects the per-entity update mode and (for custom fields) the per-field NULL_VALUE_ONLY / OVERWRITE setting.

5. Sync vs Enrichment — the most common source of confusion

Sync moves a record between CRED and the CRM. Enrichment attaches CRED's proprietary data (firmographics, contacts, signals, scores) to a record. They are different actions and they are not bundled by default.

Why "Sync with [CRM]" doesn't enrich at the same time

The "Sync" button is a data-movement action, not an enrichment action. Even if you have already paid for enrichment credits, the sync button alone will not consume them. To get an enriched record into your CRM you need either:

1. Enrich first, then sync. Click Enrich on the record (or batch enrich a list), wait for the enriched fields to populate in CRED, then click Sync with [CRM]. The enriched values flow through the mapped CRED-custom fields.

2. Use a workflow with both steps. A CRED workflow can run Enrich → Sync to CRM as two consecutive steps, so every record entering the workflow is enriched before being pushed to the CRM.

3. Turn on auto-enrich on create. In Settings → Integrations → [your CRM] → Enrichment, enable Auto-enrich on create. New records that arrive via sync (or via the "Add to CRED" button) are enriched immediately, then synced back.

This separation is intentional — enrichment costs credits and customers should always opt in. There is no global "always enrich on sync" toggle by design.

6. Manual sync — how to trigger it from the CRED UI

Manual sync is supported in both directions in every CRM. The exact button label and location is in the per-CRM article.

CRM → CRED (pull a record or list now)

• Single record: open the record in CRED → click Refresh from [CRM] (3-dot menu on the record header). CRED issues an immediate read for that record's CRM ID.

• List / collection: open the list → Sync → Pull from [CRM]. Schedules a targeted read for every record in the list.

• Whole CRM (full re-sync): Settings → Integrations → [your CRM] → Run full sync. Use this only when you suspect a drift — it is heavy.

CRED → CRM (push to the CRM now)

• Single record: on the record header, click Sync with [CRM]. Creates the record in the CRM if it doesn't exist, or updates it if it does. Returns the CRM URL on success.

• Bulk: select records in a list → Bulk actions → Sync to [CRM].

• Workflow: add a Sync to CRM step at the end of a workflow.

Important: Manual sync respects your SyncSettings — if write-back is set to OFF for an entity, the button is disabled. If a custom field is set to NULL_VALUE_ONLY and the CRM already has a value, that field is skipped during the manual push (this is intentional, not a bug).

7. Field mapping — why "not all mapped fields are passing over"

Fields can fail to sync for one of seven reasons. Walk this list before raising a ticket.

If the field passes all seven checks and still doesn't sync, capture the record's CRED ID and the CRM ID and raise a ticket. Include the action-log entry from section 8.

8. Action logs — where to look when something goes wrong

Every sync action (read, write, manual trigger, workflow step) writes to the CRED action log. There are four places to look, in order of usefulness.

1. Record-level activity timeline

Open any record in CRED and click the Activity tab. You see every sync attempt for that record — timestamp, direction, fields touched, success/error message, and the CRM correlation ID. This is the right starting point for "field X didn't make it" questions.

2. Integration sync log

Settings → Integrations → [your CRM] → Sync log. A reverse-chronological feed of every sync task: entity type, direction, records read, records written, errors. Each row drills into a per-record breakdown.

3. Workflow run log

For records moved via a workflow (e.g. Enrich → Sync), Workflows → [workflow name] → Runs. Each run shows every step's input, output, and any error per step.

4. Audit log (admin only)

Settings → Audit log. Captures admin actions like reconnecting an integration, changing field mappings, switching update modes, or running a full re-sync.

What to send if you raise a support ticket

• The record's CRED ID and CRM external ID

• The action-log entry (copy/paste or screenshot) including the correlation ID

• The field name(s) you expected to sync

• The current update mode and field mapping configuration

• Approx timestamp of when you triggered the sync

9. Common gotchas (every CRM)

• The "Sync" button is not the "Enrich" button. See section 5. Enrichment is opt-in and uses credits.

• First sync is slow. Initial reads can take hours for large CRMs. After that, incremental syncs are minutes.

• Field mapping changes do not retroactively sync. If you map a new field today, only records modified after today will carry that field through — unless you trigger a full re-sync.

• Picklist / option-list values are case-sensitive in most CRMs. Mapping a CRED enum to a CRM picklist requires the CRM picklist to contain that exact string.

• Reconnect after permission changes. If you enable a new HubSpot scope or grant a new Salesforce profile permission or edit a Dynamics security role, reconnect the integration so CRED picks up the new scopes.

• Owner / user mapping requires the user to exist in CRED. If a CRM record's owner is a user not yet in CRED, the owner field is left blank until that user is invited and matched.

10. Where to go next