Data 360 / Salesforce CRM

Data 360 Is Connected, but CRM Data Won’t Load: A Troubleshooting Guide

A practical guide to finding where Salesforce CRM data stops reaching Data 360.

By Envaxon9 min read8 stagesDocumentation checked
In this guide

An active CRM connection is one checkpoint. You still need to establish that the connector can read the source, the data stream is processing, and the required data reaches the model used by your business.

This guide covers the Salesforce CRM connector into Data 360, including Sales Cloud and Service Cloud data and issues following a Data Kit deployment. Marketing Cloud Connect for SFMC Engagement is a separate integration.

You’ll need access to the affected Data 360 stream, a CRM administrator who can inspect source objects and connector permissions, and one record you can safely use for validation. Some screens and permission-set names still use “Data Cloud”.

Find your starting point

What you seeStart here
A stream failed and you don’t know whyStage 1: capture the error
Authentication or trust errors, particularly after a sandbox refreshStage 2: verify the connection
INVALID_FIELD, INVALID_TYPE, or missing source fieldsStage 3: check source access
Failure immediately after a Data Kit deploymentStage 4: check deployment dependencies
Data arrives more slowly than expectedStage 5: check processing mode
Ingestion succeeds, but the required modeled data is missingStage 6: inspect the DLO and DMO
Stage 01

Capture the actual failure

Goal: identify the failing stream and operation before changing configuration.

  1. In Data 360, open Data Streams and select the affected stream.
  2. Open Refresh History. Record the failed operation’s timestamp, status, refresh mode and record statistics. Open its error details; download the log when available.
  3. Note the source org, connection, object and last successful refresh. Check Salesforce Trust for an incident affecting your service and instance at that time.

Record what changed before the failure: a sandbox refresh, deployment, field deletion or permissions change. Treat this as evidence to investigate, rather than proof of the cause.

Passing result: you can name the failed operation and its exact error, or establish that no operation has started.

Official resource: Data Stream and Data Lake Object Refresh History.

Stage 02

Verify the correct CRM connection

Goal: establish whether the connection’s trust relationship is healthy.

  1. Open Setup → Data 360 Setup → Salesforce Integrations → Salesforce CRM.
  2. Locate the connection used by the failing stream. Open its row-action menu and select Verify Connection.
  3. Follow the result-specific instructions. If verification succeeds, continue to Stage 3. If reauthentication is required, use the documented procedure for that connection type.

A sandbox refresh changes the sandbox Org ID and can break the existing trust relationship. Reauthentication can restore it. The recovery procedure differs for home-org, sandbox, other production/development and Data 360 One companion connections.

Don’t disconnect a production connection as a generic troubleshooting step. First identify which recovery path applies and which streams or targets depend on it.

Passing result: the intended source org is verified and authenticated. Data access and ingestion still need their own checks.

Official resource: Verify and Reauthenticate a Salesforce CRM Connection.

Stage 03

Check source objects, fields and connector permissions

Goal: prove the connector has access to the schema required by the stream.

  1. In the source CRM org, open Setup → Object Manager. Find the object and field API names from the error log and confirm they still exist.
  2. Open Setup → Permission Sets → Data Cloud Salesforce Connector → Object Settings. Have the CRM administrator check the required object and field access, including related objects referenced by lookup fields. Salesforce documents Read, View All Records and View All Fields requirements; review the scope before changing access.
  3. Review Setup → View Setup Audit Trail around the first failure. Look for deleted fields, changed permissions or removal of the connector permission-set assignment.

The connector uses the Platform Integration User. A human administrator being able to see a field does not establish that the connector can read it.

For a deliberately deleted field, follow Salesforce’s procedure to disable the obsolete stream field and review its downstream dependencies. For lost access, restore the required, approved access.

Passing result: the required schema exists and the connector has the documented access to it.

Official resources: CRM refresh errors caused by missing fields or objects · Salesforce CRM permissions.

Stage 04

Check Data Kit deployment dependencies

Use this stage when the issue started after a deployment. Otherwise, continue to Stage 5.

  1. Confirm the target org has the intended CRM connection and every source object and field referenced by the stream.
  2. Review the kit’s dependencies and publishing sequence, including required DMOs, fields and relationships. For sandbox-to-production change sets, confirm the kit is the supported DevOps type.
  3. Inspect the deployed connector and stream states. Follow Salesforce’s post-deployment activation procedure; where connector activation is required before CRM streams can deploy, complete that step before the documented redeployment.

A successful metadata deployment does not establish that ingestion has started. Verify both separately.

Passing result: the dependencies and connection are available, the stream is deployed, and its ingestion state is understood.

Official resources: Create a Data Stream from a Data Kit · Data Kit considerations and common issues · Post-deployment validation.

Stage 05

Check whether the stream is batch or streaming

Goal: distinguish an ingestion failure from a processing mode that doesn’t meet your freshness requirement.

  1. Open the stream’s record page and inspect Frequency to identify its processing mode.
  2. If you expected streaming, check eligibility. Initial ingestion uses batch processing. Unsupported objects or batch-ingested fields, including some formula fields, can prevent streaming.
  3. Compare the actual refresh history with the agreed data-freshness window. Investigate missing or failed runs separately from processing latency.

The Data Cloud Salesforce Connector permission set is intended for the Platform Integration User. Salesforce warns that assigning other users to it can interfere with streaming permissions; don’t use it as a general human-user access role.

Passing result: you know the actual processing mode and whether observed timing is expected, failing or unsuitable for the use case.

Official resources: CRM Connector Streaming · Data Stream Schedule.

Stage 06

Trace a record through the DLO and DMO

Goal: locate the boundary between missing source data and missing modeled data.

A Data Lake Object (DLO) holds ingested data. A Data Model Object (DMO) represents mapped data in the customer data model.

  1. Open Data Explorer. Select the correct data space, choose the DLO and filter for your validation record using its source identifier.
  2. Check the relevant source values. Then select the intended DMO and inspect the corresponding mapped values, accounting for the configured identifiers and relationships.
  3. If the DLO contains the expected data but the DMO does not, open the stream’s Data Mapping section and review its field mappings and relationships.

Use the observed stopping point to choose the next investigation. Missing DLO data leads back to ingestion; missing modeled data leads to mapping checks. If both are correct, investigate the specific identity-resolution, segmentation or activation step that consumes them.

Passing result: the validation record and required values are present at each boundary you have checked.

Official resources: View Your Data in Data Explorer · Map Data Model Objects.

Stage 07

Recover, then verify a real update

Goal: demonstrate that data moves correctly after the identified issue is resolved.

  1. Apply the correction supported by your evidence. If a refresh is required, use Refresh Now for the affected stream and the refresh mode appropriate to its documented behavior.
  2. Monitor the resulting operation. A full refresh replaces destination data and can process substantial volume. Some on-demand requests are ignored or handled differently depending on the stream’s current state; avoid repeated clicks or overlapping recovery attempts.
  3. Make an approved, reversible update to a validation record. Record the source time, confirm the value reaches the DLO and intended DMO, then verify the downstream business action within its agreed window.

Example validation: a test customer’s approved status change reaches the model used by a renewal audience. Check the resulting audience membership as a separate step, rather than treating a successful ingestion as proof that the campaign is ready.

Passing result: the expected value reaches the intended destination, required fields are complete, and no new relevant errors appear during the validation window.

Official resources: Data Refresh Process for Extraction · Data Mapping.

Stage 08

Record ownership or escalate with evidence

Goal: leave a recoverable workflow and a useful investigation record.

  1. Document the confirmed cause, correction, validation result and workflow owner. Record the expected freshness window and how exceptions will be noticed.
  2. If the cause remains unresolved, open a Salesforce Support case with the affected org and connection, stream/object identifiers, exact errors, timestamps with time zones, recent changes and steps already attempted.
  3. Include a minimal reproduction and a redacted example where permitted. Keep credentials, access tokens and unnecessary customer data out of attachments.

Describe an unresolved failure as an observed symptom. Call it a confirmed defect only when you have supporting confirmation.

Passing result: the workflow has an owner and a recovery record, or Support has enough evidence to investigate the remaining failure.

Official resources: Create a Support Case · Troubleshooting CRM Connections.

What “resolved” should mean

Use these recommended acceptance checks for the workflow you’re repairing:

  • The intended source connection is verified.
  • Required objects and fields are accessible to the connector.
  • The stream completes the required operation successfully.
  • A controlled source update appears correctly in the DLO and intended DMO.
  • The required downstream audience or action uses the correct data.
  • Freshness, ownership and recovery expectations are documented.

Need help locating the failure?

If your CRM connection looks healthy but your teams still work around missing records with exports and manual reconciliation, contact Envaxon to discuss a scoped data-flow diagnostic review.