MB-260 common mistakes
MB-260 · Understand the traps and how to avoid them.
Treating Customer Insights - Data as an add-on that appears automatically in an existing Dynamics 365 Sales environment and expecting unified profiles to be visible in Sales without any configuration.
Candidates assume the Customer Insights app is provisioned with the Sales license, but Customer Insights - Data is a separate application with its own environment, storage (Azure Data Lake), and its own admin consent flow. The Sales-side integration requires explicit setup.
What to do instead
Learn the provisioning sequence: create/choose a Power Platform environment, install Customer Insights - Data, grant the required tenant-level consent for the data lake, then separately configure the Customer Insights - Data connection inside Dynamics 365 Sales (or the Power Apps card) so insights surface in the seller experience.
Confusing the roles needed to administer the app with the roles needed to view insights, and assigning Environment Maker to everyone who needs to read customer cards.
The admin, contributor, and viewer roles in Customer Insights - Data are distinct from Power Platform environment roles (System Administrator, Environment Maker), and the exam tests whether you know which permission gates configuration versus consumption.
What to do instead
Map each task to its role: admin for instance configuration and data source credentials, contributor for unification/segments/measures authoring, viewer for consuming profiles and insights. Use environment security roles only for the underlying Power Platform resources.
Uploading a CSV as a one-off import and expecting it to refresh automatically on a schedule.
Candidates conflate the quick 'import data' path with a managed data source. Only a configured data source (with credentials and a refresh schedule) keeps data current; a manual upload is a point-in-time load.
What to do instead
Distinguish ingestion methods by refresh behaviour: manual upload for ad hoc/test data, and connector-based data sources (Azure Data Lake, Dataverse, SQL, S3, etc.) when recurring refresh is required. Configure the refresh schedule on the data source, not on the entity.
Mapping every source column as a semantic type and then wondering why unification produces poor or empty matches.
Candidates believe more mapped fields improve matching, but unification depends on correctly designating which fields are identity keys (name, email, phone, address) and which are merely attributes. Over-mapping adds noise and conflicting values.
What to do instead
Separate the two steps: first map fields to the correct data types for ingestion, then explicitly configure match rules and deduplication rules on the tables that carry identity data. Only identity-relevant fields should feed matching; other fields stay as profile attributes.
Assuming the system automatically knows that CustomerID in the CRM and CustNo in the ERP are the same person.
Cross-source identity resolution is not inferred from column names. Candidates skip the step of telling the system which fields across tables represent the same entity, so records from different sources never converge.
What to do instead
Configure match rules that reference fields from multiple tables, and use exact-match rules for high-confidence keys (email, loyalty ID) combined with fuzzy rules for names and addresses. Validate with the unification preview before publishing.
Choosing 'Live directly from source' versus 'Data lake' output without understanding which downstream features stop working.
Candidates treat the unification output option as a performance toggle, but the choice determines whether segments, measures, and profile enrichment can run, and whether the unified tables are queryable for exports.
What to do instead
Memorize the trade-off: direct-from-source output is faster to set up but limits downstream processing, while data lake output is required for segments, measures, and many enrichment paths. Choose based on which downstream features the scenario demands.
Building segments on raw source tables instead of on the unified customer profile entity.
Candidates see the source entities in the segment builder and pick the one with familiar column names, producing duplicate customers per segment and missing attributes that only exist after unification.
What to do instead
Always build segments from the unified Customer profile entity (and its related unified activities/attributes). Confirm unification has run and succeeded before authoring segments, and verify segment membership counts against source record counts to catch duplication.
Expecting brand-level or industry enrichment data to appear without purchasing or configuring it, or assuming enrichment overwrites existing values.
Candidates conflate the built-in enrichment (which requires specific configuration and, for some providers, licensing) with automatic data enhancement, and they misjudge merge precedence.
What to do instead
Know which enrichment types exist, what each requires to enable, and that enrichment appends or fills fields according to configured precedence rather than blindly overwriting. Check the enrichment status and field mapping after the first run.
Defining a measure and expecting it to be queryable immediately, or building a measure that references a segment that has not been refreshed.
Measures depend on unified data and on segment/attribute state; they run on a schedule or on demand, and a stale dependency produces empty or failed results. Candidates skip the dependency check.
What to do instead
Define the measure with the correct entity, dimension, and aggregation, then verify prerequisites (unification complete, referenced segments refreshed) before running. Use the measure run history and error details to confirm success rather than assuming completion.
Creating an export and assuming it pushes data to the destination immediately, or exporting to a destination whose schema does not match the unified entity.
Exports are scheduled jobs with their own configuration (destination, entity, field mapping, frequency) and they fail silently if credentials expire or the target schema mismatches. Candidates treat export creation as the finish line.
What to do instead
After configuring an export, verify the connection credentials, the field mapping against the target schema, and the schedule, then check the export run history for the first successful run. For predictions, likewise confirm the model has trained and scored before relying on its output fields in segments.