The Shattered Kingdom

Once, in the sprawling commercial empire of Northern Trail Outfitters, there lived a consultant named Kael. She was summoned to the capital not because the kingdom was at war — it was worse. The kingdom's data was at war with itself.

Every province — CRM, Marketing Cloud, Commerce Cloud, the loyalty guild in the eastern mountains, the web analytics scribes in the western towers — kept its own ledgers. The same customer might be "Jane Smith" in one ledger, "J. Smith" in another, and "[email protected]" in a third. Nobody could answer the simplest question: who are our customers, really?

King Aldric, ruler of NTO, addressed Kael in the throne room. "I'm told we need something called a Data Cloud," he said, waving a parchment. "My advisors say it can do two critical things."

The king leaned forward. "And what does it mean to build a trust-based, first-party data asset? My merchants keep saying this phrase."

The king nodded. But before anything could be built, they had to answer the first question of the Data Cloud lifecycle.

Kael walked the halls, interviewing guild leaders. The use cases crystallized: ingest and unify data to reconcile customer identity, and use harmonized data to more accurately understand the customer and business impact. Cross-channel orchestration? That was Marketing Cloud's domain. Replacing BI tools? Not Data Cloud's job either.

The functional areas the kingdom needed most? Data Harmonization — mapping disparate schemas into a common model — and Unified Profiles — merging data from multiple sources into a single customer view via identity resolution.

The word harmonize itself became Kael's mantra — it described the process of mapping different schema names (user, contact, subscriber) to a standard data model. Not "integrate," not "merge" — harmonize. The core use case of Data Cloud was exactly that: data harmonization across multiple platforms.

And what about AI's role in this kingdom? Kael knew: AI in Data Cloud enhanced customer interactions through insights and predictions — propensity scores, recommendations, pattern detection. Meanwhile, Data Cloud ensured high availability by distributing data across multiple regions and data centers, and ensured privacy by encrypting data at rest and in transit.

For visualization and analysis of the unified data, the kingdom would turn to Tableau. And for real-time data integration that helped support agents see up-to-the-moment information? That was built right into Data Cloud's capabilities.

With the vision clear, Kael turned to the hard work: building the pipes that would carry data from every corner of the kingdom into one unified reservoir.

The Pipeline of Power

The first challenge was connecting to the kingdom's many data provinces. Each had its own language, its own locks, its own keepers.

The CRM province was easiest. The CRM Connector could stream standard fields in real time. But Kael discovered a nuance right away: the connector used an integration user, and that user needed "View All" permission on every object it touched. When a custom object wasn't showing up in the data stream configuration, the fix was always the same — check that View All permission.

When a CRM data stream was first deployed, it performed a full refresh — pulling all existing records. After that, it streamed changes. And if you updated a formula field on an S3 data stream in upsert mode? Data Cloud initiated a full refresh to recalculate the formula across all records.

The far-east trading posts used Amazon S3 buckets. Kael configured the connection using an S3 Access Key and Secret Key — not certificates, not JWT tokens, not username/password. S3 used IAM-based authentication, plain and simple.

NTO had traders who uploaded daily transaction files to S3, each with a timestamp in the filename. Kael set the refresh mode to "Upsert" (to add without overwriting) and ensured the filename contained a wildcard to accommodate the changing timestamps.

When an S3 data stream failed with "NO FILE FOUND", Kael knew to check two things: that correct permissions were configured for the Data Cloud user, and that the file actually existed in the specified bucket location.

For separate S3 buckets for ingestion and activation, Kael configured dedicated S3 data sources in Data Cloud setup — one for each purpose.

One merchant could only export via SFTP. No problem — Data Cloud had an SFTP Connector for exactly that.

The inventory guild needed near-real-time streaming of stock levels from their custom system. Kael reached for the Ingestion API, which supported both streaming and bulk ingestion from external systems.

For loading 90 days of historical mobile app data and then ingesting ongoing data, the approach was clear: bulk ingestion first for the backfill, then streaming ingestion for real-time ongoing sync.

The Marketing Cloud province was its own beast. Subscriber profile attributes? Use a Marketing Cloud Data Extension Data Stream. For engagement data, the Starter Data Bundles included SMS (MobileConnect), Email, and MobilePush — but not CloudPage. That required custom integration.

NTO also wanted two years of B2C Commerce transactional history. The B2C Commerce Order Bundle only captured orders created after setup — no historical data. So they needed the bundle plus a custom extract for the backfill.

The Web and Mobile Application Connector had one notable trait: when configuring it, the Tenant Specific Endpoint was auto-generated by Data Cloud — no manual URL needed.

With streams flowing, Kael faced the trickier question: what shape should this data take? She turned to the kingdom's data model — and the art of mapping.

Every data stream had a category. Profile data described individuals and accounts. Engagement (Transaction) data was time-series events — and the Transaction category was what enabled time-based operations in segmentation and calculated insights. Other was for everything else.

The Party subject area contained entities for people and organizations — Individual, Account, and Member. The Sales Order subject area captured revenue and quantity by product family.

Kael's master customer table had name and email. Names mapped to the Individual DMO. Emails mapped to the Contact Point Email DMO — always a separate entity, no matter the source object. Even a custom "Customer Email" object mapped to Contact Point Email.

NTO had three phone fields on their Contact object — work, mobile, home. The Contact Point Phone DMO expected one row per phone number. So Kael used streaming transforms to unpivot the three columns into three rows, then mapped to the DMO.

Phone numbers themselves? The most efficient way to standardize them to E.164 format was to assign the PhoneNumber field type when creating the data stream. It auto-normalized.

Purchase order numbers with leading zeros? Those had to be Text fields — Number fields stripped leading zeros. And for data types in general: propensity to purchase was a Number, active membership was a Boolean, and email address was Text.

When ingesting a DateTime field into a Date field, the time component was simply truncated — only the date part was kept.

Some data sources had no primary key. Kael created composite keys using the CONCAT formula function — combining fields like Customer Region and Customer Identifier into a single unique key.

A formula could also convert a DateTime to a Date for proper DMO mapping — that was a key reason to create formula fields during ingestion.

For ingesting Case data, the right Event Time field was Last Modified Date — it tracked when the record was last changed.

Kael now turned to the transforms — the refineries that shaped raw data into usable gold.

Streaming transforms processed data in real time as it flowed in. They were perfect for normalizing formats from different regions without modifying originals, and for enabling real-time CRM integration.

Batch transforms processed data on a schedule. They could split one record into two (like separating hotel points from airline points into separate DLOs), or normalize product names and replace nulls in a single operation.

A bank had duplicate data across loan applicants and high-net-worth customers. Kael used a data transform to consolidate into one DLO, then mapped to Individual and Contact Point Email DMOs for proper identity resolution.

The beauty company had custom fields — eye color, skin type, hair color — not in the standard Individual DMO. Rather than creating a custom DMO (which would lose identity resolution), Kael added custom fields to the standard Individual DMO.

One relationship almost broke things: mapping Account to Contact Point Address as 1-to-1 caused errors, because an account could have multiple addresses. The fix: change the cardinality to many-to-one.

And when mapping an Order-Headers DLO to the Sales Order DMO using the Engagement category? The DMO got permanently assigned to Engagement, and only Engagement-category DLOs could be mapped to it afterward.

Two dependencies would prevent a data stream from being deleted: if its underlying DLO was used in a data transform, or if it was mapped to a DMO. And before deleting a data stream and its DLO, always check for transform dependencies first.

Disconnecting a data source entirely? First remove the segments and data streams that depended on it.

To create a data graph from several DLOs, they first had to be mapped to DMOs — DLOs couldn't be used directly in data graphs.

For packaging and promoting configurations across orgs — data streams, mappings, identity resolution rulesets, DMOs — the tool was the data kit. Segments and calculated insights weren't supported in data kits, but DMOs and identity resolution rulesets were.

The Forge of Identity

Data was flowing. Data was mapped. But the kingdom still had thousands of scattered fragments pretending to be different people. It was time for the forge — Identity Resolution.

Identity resolution was the feature that matched, merged, and reconciled individual records from multiple sources into single unified profiles. It was the soul of Data Cloud — the step required after ingestion before you could segment.

It also solved the classic problem: multiple leads and contacts sharing the same email address? Identity resolution merged them.

The forge had two sides: matching and reconciliation.

Matching rules determined which records belonged to the same person. NTO used CRM ID as a primary key across CRM and Marketing Cloud. Kael mapped both to Party Identification using CRM ID as the identification name for both — the same name, critically — and created a matching rule based on Party Identification matching on CRM ID.

For exact-match rules on identifiers like Loyalty ID, the Party Identification object was designed for exactly that — storing external identifiers and supporting exact matches.

A healthcare client worried about family members sharing PII — a wife and husband using the same email or phone. Kael advised matching on Patient ID via Party Identification, not email or phone, since those could be shared in healthcare contexts.

If the consolidation rate was too low — meaning too few records were being merged — the fix was to increase the number of matching rules. More rules meant more ways to find matches. Adding attributes to existing rules made them stricter, which could reduce matches.

But what if identity resolution was over-matching — merging people who shouldn't be merged, like roommates sharing an email? The fix was careful: create a new ruleset with stricter matching criteria, compare both rulesets side by side, then migrate only after verification.

The other side of the forge was reconciliation — deciding which attribute value wins when sources conflict. Does CRM's email trump Marketing Cloud's? Does the most recently updated name win?

Reconciliation rules answered this using strategies like Source Priority (rank sources), Most Occurring (majority wins), and Last Updated (most recent wins).

The Source Sequence reconciliation rule (also called Source Priority) set the priority of specific data sources when building unified profile attributes. If CRM was ranked above Marketing Cloud, CRM's first name would win.

The Ignore Empty Value option prevented empty/null values from being selected as the "winning" value during reconciliation. Critical for ensuring only populated values made it to the unified profile.

When a unified profile wasn't storing the latest email address, Kael's first troubleshooting step: confirm the reconciliation rules are correctly configured. If Source Priority was set wrong, the oldest email might be winning.

To ensure the best address from customer orders appeared on the unified profile, Kael set the Contact Point Address reconciliation to Source Priority and moved the Order DMO to the top.

Deleting an identity resolution ruleset had consequences: unified customer data associated with it was removed, and DMO dependencies were cleaned up.

To validate the results, Kael used three tools: Identity Resolution itself (for match/reconciliation outcomes), the Data Explorer (for browsing DLO/DMO data), and the Profile Explorer (for visually inspecting unified profiles).

After identity resolution, segmentation was performed on the Unified Individual entity — the merged, deduplicated profile.

The Cartographer's Map

With unified profiles forged, Kael became a cartographer — drawing the borders of segments that defined which customers would receive which experiences.

The pipeline order was sacred: Refresh Data Stream → Identity Resolution → Calculated Insights → Segments → Activation. Every step depended on the one before it.

Three types of criteria could be used in segments: direct attributes (on the segmented entity itself), related attributes (from related entities), and calculated insights (pre-computed metrics). Data stream attributes weren't directly usable — they had to be mapped to DMOs first. And streaming insights weren't available directly in the segment canvas either.

Containers were the building blocks. When Kael put product color = "black" and product type = "pants" in a single container, she got people who bought black pants — both attributes on the same record. When she used two separate containers linked by AND — one for "red" products, one for "shoes" — she got people who bought at least one red product AND at least one pair of shoes, potentially in different transactions.

If the wrong container path was selected for transaction-based segmentation, the segment could be smaller or larger than expected — different paths traverse different relationships.

For suppressing recent purchasers from a 6-month purchase segment, Kael used segmentation exclude rules.

For a birthday campaign, the operator "Is Anniversary Of" matched month and day regardless of year — perfect for annual recurrence.

For "customers who visited in the last 7 days," Kael used "Last Number of Days" — a rolling window relative to the current date.

The filter "City Is Equal To 'San José'" was case-insensitive but preserved special characters — it matched 'San José' and 'san josé' but not 'San Jose' (without the accent).

For value suggestions — the picklist-style dropdown when building segments — they were enabled during Segment Setup configuration for the DMO. After modeling new data, value suggestions took up to 24 hours to process and become available.

To test different target populations, Kael adjusted direct attributes, related attributes, and population filters in the Segment Canvas.

Nested segments referenced existing segments within new ones, ensuring foundational criteria were consistently applied and auto-updated.

A reusable container block with common exclusion criteria could be shared across multiple segments and updated in one place.

When a segment failed with "references too many data lake objects," the fix was to split the segment into smaller segments and/or use calculated insights to reduce query complexity. Calculated insights also resolved "segment is too complex" errors that occurred with deeply nested segments.

A new custom DMO not visible when creating a segment? It wasn't of category Profile — only Profile-category DMOs appeared in the segmentation canvas.

To apply consent during segmentation, Kael included Consent Status for applicable engagement channels as a filter criterion in each segment.

The Segment Membership DMO stored historical membership data — who had been in a segment over time, enabling analysis across years.

Segment and activation publishing used the org-level time zone, but the UI adjusted the display to each logged-in user's time zone.

The Watchtowers of Insight

Segments alone weren't enough. The kingdom needed intelligence — computed metrics, real-time pattern detection, and instant reactions. These were the Watchtowers: Calculated Insights and Streaming Insights.

A customer wanted to segment on Customer Lifetime Value, but CLV wasn't in the source data. The sequence: Ingest Data → Map to Data Model → Create Calculated Insight → Use in Segmentation.

For the Visual Insights Builder, the minimum requirements were at least one measure (metric) and at least one dimension (grouping).

The join path for a lifetime value calculation: Unified Individual → Unified Link Individual → Sales Order. The Unified Link connected unified profiles to their source records.

For a calculated insight to appear in the segmentation canvas, it needed two things: a dimension including the Individual or Unified Individual ID, and the primary key of the segmented table as a dimension.

NTO wanted LTV broken down by channel — website, mobile app, retail. The tool: metrics on metrics (multi-dimensional metrics), which computed an overall metric and then broke it down by dimensions.

A banking insight had value (metric), branch (dimension), and high-net-worth (filter). In activation, only the dimension ("branch") could be included as an attribute — not metrics or filters.

When modifying an existing calculated insight, existing dimensions could be removed (though this might impact dependent segments).

Customers who deposited >$250K in 5 years and didn't use advisory services? That took a calculated insight (for the deposit computation) plus a segment (applying the advisory filter).

The real-time watchtowers were the Streaming Insights. They processed data in near-real-time with configurable time windows — perfect for detecting browsing patterns like a candidate visiting a jobs page twice in 24 hours, or performing 15-minute-window aggregations on Interaction SDK data.

For segmenting customers who purchased in the last 24 hours with the most up-to-date data, streaming insights provided near-real-time segmentation.

Building insights on unified profiles was, in fact, a key functionality of Data Cloud itself.

For quick, no-development insights like average sales per day for the past week, an analyst could simply use Salesforce Reports.

Displaying all cases associated with a Unified Individual on a contact record? That took the Profile API (to retrieve the data) and Lightning Web Components (to render it in the CRM UI).

The Banners of Activation

Insights were useless unless they reached the outside world. Activation was the act of sending segments to their destinations — unfurling the banners.

Configuring an activation to Marketing Cloud required two mandatory steps: choose a segment and select contact points (e.g., email). Adding extra attributes was optional. Calculated insights were used in segment creation, not added to activation directly.

Why was the activated count smaller than the segment count? Because Data Cloud enforced the presence of a Contact Point for Marketing Cloud activations. No email contact point → not activated.

NTO used Fuzzy Name and Normalized Email matching. To ensure the best email was activated, Kael set the source priority order in activations to prefer contact points from the desired source.

When personalizing emails with mutual fund information, the activation setup was: choose the segment, choose the Email contact point, add Fund Name as a related attribute, and filter for Fund Type = "Mutual Fund".

An activation contained orders older than the segment's 30-day criteria. Why? Because related attributes in activation don't inherit the segment's date filters. The fix: apply a date filter on the related attributes within the activation itself.

Related attributes not showing in the activation payload at all? Two areas to check: the engagement events had to have occurred within the last 90 days, and the correct relationship path had to be selected. Different paths meant different available attributes.

To minimize count differences between Data Cloud segments and Marketing Cloud data extensions, Kael filtered by geographical divisions to align with Marketing Cloud business unit scope.

Providing a mailing list from a segment: create the segment, select Email as the activation target, activate directly.

When activating to S3, the .csv file contained the actual data payload. The .json file contained segment metadata (definition, schema, timestamps) for the destination system.

To include a CRM Campaign ID in the S3 filename, Kael added it to both the activation name and the filename specification.

To modify attribute names for Cloud File Storage targets, she set preferred attribute names during activation configuration.

The activation target for publishing to the Audience DMO (for Query API retrieval) was the "Data Cloud" type. And the object for activation membership was the Data Activation Object.

Activation alerts notified users when an activation failed.

To pause a segment activation with the intent to reuse it later: deactivate the segment (preserves configuration for reactivation).

Activation was set to publish every 12 hours, but updates were delayed by up to 24. Kael reviewed two things: that calculated insights ran before segments refreshed, and that segments refreshed after data ingestion completed.

Multiple segments publishing simultaneously caused delays. The fix (without reducing frequency or segments): stagger publish schedule start times to prevent overlapping processes.

Ensuring nightly ecommerce data was ready for scheduled activations? Use Flow to trigger a change data event to refresh calculated insights and segments before activations ran.

Data Actions were the kingdom's messengers — triggering real-time updates to external systems when data changed. A CRM field needing update as soon as a DMO record changed? Data action. Proactive Slack/email notifications when data streams failed, plus case creation and dashboard updates? Data action.

A platinum banking customer visiting investment pages 3+ times in 24 hours needed an immediate email. The solution: streaming insight (to detect the pattern) with a data action (to trigger a Marketing Cloud journey immediately).

Tracking daily transaction volume in real time and alerting on anomalies? Same pattern: streaming insight + data action.

To ensure a data action from a streaming insight triggered hourly, Kael set the journey entry schedule to run every hour.

Segment intelligence setup required Data Cloud Admin permissions. And which segment errors or status to check? Dashboards and Reports could show when each segment was last published.

The Walls of Consent

No kingdom could survive without honoring its people's rights. Data Cloud was no different. The Right to be Forgotten was law.

To honor it, two mechanisms existed: add the Individual ID to a headerless file and use the delete-from-file functionality, or use the Consent API to suppress processing and delete the Individual and related records. Either way, the deletion cascaded — it removed the Individual and records from any DMO and DLO related to them.

Two Consent API considerations: deletion requests targeted Individual profiles specifically, and they were passed to all connected Salesforce clouds.

For deleting a customer's personal data formally, the Data Rights Subject Request tool was the proper mechanism.

When Marketing Cloud Connector was the data source, deletion requests for that data had to be submitted through Marketing Cloud settings.

The War Room

Every kingdom has internal politics. NTO had brands, regions, and permission levels. The war room was where Kael organized who saw what.

NTO had multiple brands and needed data separated by each. The answer: Data Spaces — logical data segregation within a single org, with separate identity resolution, segmentation, and activation per space.

For a bank needing to keep business and personal loan contacts legally separate, two data spaces were the solution.

Segregating CRM Account data by country for different users? Data spaces with filtering on the Account DLO based on Country.

When EMEA sales reps couldn't see APAC data, the cause was simple: they hadn't been assigned to the permission set associated with the APAC data space.

If an object couldn't be mapped during data space setup, you needed to navigate to the Data Space tab and explicitly add the object to the new data space first.

Permission sets governed who could do what. The Data Cloud Marketing Specialist could create, manage, and activate segments — but could NOT create reports or manage data sources. The Data Cloud User was the minimum for reviewing ingested data and validating DMO mappings with edit ability. Data Cloud Admin was needed for setting up Segment Intelligence.

The Coronation

Months passed. The shattered kingdom was whole. Every data stream flowed through the pipeline. Identity resolution forged unified profiles from chaos. Calculated insights illuminated the numbers. Segments carved audiences with precision. Activations carried the kingdom's messages to every corner.

On the day of the coronation — the go-live — King Aldric asked Kael to recite the sacred order one final time.

She looked out over the kingdom. The data lake objects had been mapped to data model objects. The streaming transforms ran in real time. The batch transforms cleaned and normalized. The Party Identification objects stored every loyalty ID and patient ID. The reconciliation rules ensured the right values won. The data spaces kept the brands apart. The consent walls stood firm.

And the Data Cloud — their unified view of every customer in the realm — hummed with purpose.

— End of the story. Beginning of the exam. —