6.1 DLO Configuration, Primary Keys, Event Time & Data Stream Categories (Profile, Engagement, Other)

DLO Configuration, Primary Keys, Event Time & Data Stream Categories

In Salesforce Data Cloud, the journey from disparate enterprise source data to a unified Customer 360 profile begins with data ingestion. When data flows into Data Cloud through connectors, APIs, or cloud storage buckets, it lands first in the physical lakehouse storage layer as Data Lake Objects (DLOs). Designing DLOs correctly is one of the most critical responsibilities of a certified Data Cloud consultant: errors made during initial stream categorization, primary key definition, or timestamp mapping cannot simply be patched downstream—they often require tearing down and recreating entire data ingestion pipelines.

---

Anatomy of a Data Lake Object (DLO)

A Data Lake Object (DLO) is a physical, structured storage container within Data Cloud's underlying lakehouse architecture (hosted on Hyperforce and backed by columnar Parquet storage). While Data Model Objects (DMOs) represent the standardized, harmonized semantic business entities (e.g., Individual, Contact Point Email, Sales Order), a DLO represents the raw, source-native representation of the incoming data.

┌─────────────────────────────────────────────────────────────────────────┐
│                            DATA STREAM                                  │
│  (Ingestion Pipeline: S3, Salesforce CRM, Ingestion API, B2C Commerce)  │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ Ingestion & Formula Transforms
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                     DATA LAKE OBJECT (DLO)                              │
│  Physical Lakehouse Table (Source Schema + System Metadata Fields)       │
│  - Source Fields: Customer_ID, First_Name, Last_Name, Email_Addr        │
│  - Ingestion Formula Fields: Source_Prefix_PK__c, Normalized_Email__c   │
│  - System Fields: DataSource__c, DataSourceObject__c, CreatedDate__c    │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ Data Mapping Canvas
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                     DATA MODEL OBJECT (DMO)                             │
│  Harmonized Canonical Schema (Customer 360 Semantic Model)              │
│  - Individual DMO, ContactPointEmail DMO, PartyIdentification DMO       │
└─────────────────────────────────────────────────────────────────────────┘

Schema Definitions and Data Types

When a Data Stream is created, Data Cloud inspects the incoming schema and defines the corresponding DLO fields. DLO fields support foundational primitive data types:

• Text: Strings, identifiers, codes, and serialized JSON payloads.
• Number: Integers, floating-point numbers, decimals, currency values, and unit quantities.
• Date: Calendar dates without time components (YYYY-MM-DD).
• DateTime: Timestamps containing both calendar date and precise time of day, represented in ISO 8601 formatting.

Each DLO field has a source field label, an API name (typically appended with __c for custom attributes), and a defined maximum character length. Data Cloud allows consultants to add custom fields or formula fields during stream configuration, but the core table structure directly mirrors the source schema.

System Metadata Fields

Every DLO automatically inherits several standard system metadata fields generated and maintained by Data Cloud. These fields are vital for data lineage, multi-tenant auditing, and pipeline debugging:

---

The Three Critical Data Stream Categories

During Data Stream configuration, the consultant is required to assign the stream to one of three fundamental categories: Profile, Engagement, or Other. This selection dictates the underlying lakehouse storage engine behavior, read/write patterns, deduplication semantics, and eligibility for downstream platform capabilities.

1. Profile Category

• Core Purpose: Models persistent business entities that represent people, accounts, or organizations. Common examples include Customers, Leads, Contacts, B2B Business Accounts, and Sales Reps.
• Key Requirements: Requires an explicit Primary Key. Does not require an Event Time field.
• Write Semantics (Upsert): Profile DLOs operate on an upsert pattern (insert or update). When an incoming record arrives with a Primary Key that already exists in the DLO, Data Cloud updates the existing record with the incoming attribute values rather than appending a duplicate row.
• Identity Resolution Participation: Profile is the ONLY category that can participate in Identity Resolution. Only DLOs categorized as Profile can be mapped to canonical Profile DMOs (such as Individual, Account, Contact Point Email, Contact Point Phone, and Contact Point Address) to form unified customer profiles and link identity graphs.

2. Engagement Category

• Core Purpose: Models time-stamped behavioral interactions, transactional events, and telemetry data. Common examples include E-Commerce Orders, Website Page Clicks, Mobile App Sessions, Email Opens, In-Store Beacon Pings, and Payment Gateway Transactions.
• Key Requirements: Requires BOTH an explicit Primary Key AND a designated Event Time field.
• Write Semantics (Append): Engagement DLOs operate primarily on append (event-stream) semantics. Each record represents a distinct point-in-time occurrence. While records with identical primary keys can be deduplicated, the storage layer is optimized for high-velocity ingestion and time-series reads.
• Storage Retention Policies: Because engagement records accumulate at massive scale (millions or billions of rows per month), Engagement DLOs support automated Data Retention Policies. Consultants can configure retention rules (e.g., retain for 90 days, 180 days, or 2 years) that automatically purge expired event partitions during background compaction cycles to optimize storage and comply with storage limitation mandates.

3. Other Category

• Core Purpose: Models contextual reference, lookup, catalog, and dimensional master data. Common examples include Product Catalogs, Store / Warehouse Locations, Loyalty Tier Lookup Codes, Postal Code / Territory Mappings, and Currency Exchange Rates.
• Key Requirements: Requires an explicit Primary Key. Does not require an Event Time field.
• Write Semantics (Upsert): Operates on an upsert pattern based on the Primary Key.
• Relational Role: Maps to Other-category DMOs (such as Product, Location, or custom reference entities). These objects provide rich dimensional context to Profile and Engagement DMOs via 1:N or N:1 relationships. They cannot serve as the root anchor for Identity Resolution, but their attributes are frequently utilized in segmentation criteria and Calculated Insights.

Comprehensive Category Comparison Matrix

---

Category Immutability: The Cardinal Consultant Rule

[!CAUTION] Category Immutability is Absolute Once a Data Stream is created and deployed, its Category (Profile, Engagement, or Other) CANNOT be modified. The category dropdown is permanently locked in both the administrative user interface and underlying metadata APIs.

Why is Category Immutable?

The category determines how the underlying lakehouse storage engine physically structures data on disk: columnar partition strategies, delta log transaction protocols, primary key index trees, and downstream semantic graph connections are irrevocably bound to this selection upon stream deployment.

The Real-World Remediation Procedure

If a consultant or administrator accidentally deploys a Data Stream with the wrong category (e.g., selecting Profile for high-velocity website click events, or Engagement for an employee master directory), there is no "edit" or "convert" button. The mandatory remediation procedure is:

1. Unmap Semantic Relationships: In the Data Model canvas, navigate to the target DMOs and remove all field mappings linking the misconfigured DLO to canonical DMOs.
2. Deactivate and Delete Data Stream: Delete the misconfigured Data Stream. Deleting the stream automatically schedules the underlying DLO and its associated raw lakehouse partitions for removal.
3. Recreate the Data Stream: Author a brand new Data Stream from the source connector, explicitly selecting the correct category (Profile, Engagement, or Other).
4. Configure Keys and Formulas: Re-specify the Primary Key, define formula fields, and assign the Event Time field (if Engagement).
5. Deploy and Remap: Deploy the stream, allow initial data ingestion to populate the fresh DLO, and re-establish mappings to the appropriate canonical DMOs.

---

Primary Key Selection Strategies

In Salesforce Data Cloud, a Primary Key (PK) uniquely identifies each row within a Data Lake Object. An invalid or non-unique Primary Key causes severe data corruption: duplicate rows will overwrite each other in Profile DLOs (silent data loss), or queries and identity resolution rules will fail to resolve records accurately.

Single-Field vs. Composite Primary Keys

• Single-Field Keys: Applied when the source system provides a globally unique, immutable identifier for every row (e.g., a standard Salesforce CRM 18-character ID: 003xx000004WXYZAA0, or an enterprise UUID: e4b3c2a1-5678-90ab-cdef-1234567890ab).
• Composite Keys: Applied when no single field in the source record guarantees row-level uniqueness. For example:
  • Order Line Items: Order_Number is repeated for every item in an order; the true unique key is a composite of Order_Number and Line_Item_Sequence.
  • Retail Store Employees: Employee_Badge_ID may be reused across franchises; the true unique key is a composite of Store_Code and Employee_Badge_ID.
  • Digital Web Events: A combination of Session_ID, Event_Type, and Epoch_Timestamp.

Ingestion Formulas for Composite Keys

Because Data Cloud requires a single field to be designated as the Primary Key during stream setup, composite keys must be constructed using Ingestion Formula Fields directly within the Data Stream configuration:

/* Ingestion Formula: Composite Primary Key on Order Line Item Stream */
CONCAT(source.Order_Number, "_", source.Line_Item_Number)

The Multi-Source ID Collision Hazard & Tenant Prefixing

In enterprise environments, Data Cloud frequently consolidates data from multiple instances of the same technology—such as two distinct Salesforce CRM orgs (e.g., North America Sales and European Service) or two regional POS databases.

[Salesforce Org NA]  Contact ID: 0035000000abcdeAAA  --> John Doe (Chicago)
[Salesforce Org EU]  Contact ID: 0035000000abcdeAAA  --> Marie Dubois (Paris)

WITHOUT PREFIXING (Disaster):
0035000000abcdeAAA arrives from EU --> OVERWRITES John Doe in Profile DLO!

WITH TENANT PREFIXING (Best Practice):
NA Record PK: "SFDC_NA_0035000000abcdeAAA"  --> John Doe preserved
EU Record PK: "SFDC_EU_0035000000abcdeAAA"  --> Marie Dubois preserved

[!IMPORTANT] The Multi-Tenant Prefixing Pattern Standard 15-character or 18-character Salesforce object IDs are generated pseudo-randomly within each individual org. Across distinct orgs, IDs CAN and DO collide! If two CRM instances ingest into the same DLO without tenant prefixing, records will silently overwrite one another. Consultants must ALWAYS employ an ingestion formula field to prefix source IDs with an org or tenant code:

CONCAT("SFDC_NA_", source.Id)

---

Event Time Field Selection & Timestamp Handling

For any Data Stream categorized as Engagement, the selection of the Event Time field is mandatory. The Event Time dictates when the interaction legitimately occurred in the real world.

Selecting the Authentic Business Timestamp

Consultants must ensure they designate the field representing the actual consumer interaction rather than an internal system audit date:

• Correct Event Time Choices: Order_Placed_Date__c, Email_Clicked_Timestamp__c, Pageview_Occurred_At__c, Payment_Authorized_Date__c.
• Incorrect Event Time Choices: CreatedDate (reflects when an ETL job ran), SystemModstamp (reflects when a database index updated), Batch_Ingested_At__c.

UTC Standardization and ISO 8601 Formatting

Data Cloud internally normalizes and stores all event timestamps in Coordinated Universal Time (UTC). Ingesting timestamps in arbitrary local formats without timezone offsets leads to chronological distortion across time-series metrics:

• Compliant Formats: Standard ISO 8601 representations: YYYY-MM-DDTHH:mm:ss.SSSZ (e.g., 2026-09-21T14:30:00.000Z) or strings with explicit offset indicators (e.g., 2026-09-21 09:30:00 -05:00).
• Non-Standard Timestamps: If an external file connector supplies timestamps in non-standard strings (e.g., MM/dd/yyyy hh:mm:ss a), an Ingestion Formula Field must be configured using date/time parsing functions to convert the string into a valid DateTime type before the stream is deployed.

Late-Arriving Data Rules & Partitioning

In enterprise operations, behavioral events do not always arrive instantaneously. Mobile devices lose internet connectivity and cache events locally; retail stores upload batch register logs once per night; third-party ad networks deliver clickstream data with multi-hour delays. This is known as Late-Arriving Data.

• Partitioning by Event Time: Data Cloud partitions Engagement data on disk based on the designated Event Time, NOT the system ingestion timestamp (CreatedDate).
• Historical Placement: When an event that occurred 48 hours ago arrives today, Data Cloud retroactively places that record into the appropriate historical 48-hour-old lakehouse partition.
• Downstream Processing Impact:
  • Calculated Insights: Cumulative metrics or sliding window aggregations (e.g., "Customer spend over the last 7 days") will automatically recalculate and incorporate the late-arriving event on the next scheduled execution of the insight.
  • Real-Time Triggers: If a real-time event trigger relies on an immediate 5-minute event window, events arriving hours late will fall outside the active evaluation window and will not trigger immediate synchronous alerts, but will be accurately reflected in historical segmentation.