Study guide

13.3 Activation Schedules, Publishing Cadence & Incremental vs. Full Refresh

Salesforce Certified Data 360 Consultant formerly Data Cloud Consultant

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Solution Overview & Enterprise Value

1.1 Enterprise Customer 360 & Data Cloud Business Value 1.2 Architectural Foundation: Zero-Copy, Hyperforce, Lakehouse & Data Pipeline 1.3 Platform Terminology, Core Entities & Data Lifecycle Stages 1.4 Data 360's Foundational Role in Predictive & Generative AI

2 Chapter 2: Ethics, Privacy & Governance Fundamentals

2.1 Regulatory Compliance, Data Privacy & Ethics in Customer Data 2.2 Consent Management & Preference Enforcement in Data Cloud 2.3 Data Retention, Deletion, and Privacy Right-to-be-Forgotten (RTBF)

3 Chapter 3: Security, Permissions & Tenant Architecture

3.1 Standard Permission Sets, User Roles & Functional Access 3.2 Data Spaces Architecture, Resource Allocation & Tenant Isolation

4 Chapter 4: Administration, Monitoring & Lifecycle Management

4.1 Data Kits & Package Automation for Cross-Org Deployment 4.2 Auditing, Status Monitoring, Error Logs & Data Explorer 4.3 Sandboxes, Change Management & Metadata Deployment

5 Chapter 5: Ingestion Connectors & Source Integration

5.1 Standard Bundles & Salesforce CRM Connectors (Sales/Service/Marketing) 5.2 Cloud Storage (S3, GCS, Azure Blob) & Streaming Ingestion (Web/Mobile SDK, Ingestion API) 5.3 Zero-Copy Data Federation & Snowflake/BigQuery/Databricks Sharing

6 Chapter 6: Data Lake Objects (DLO) & Data Transformations

6.1 DLO Configuration, Primary Keys, Event Time & Data Stream Categories (Profile, Engagement, Other) 6.2 Streaming & Batch Data Transforms: Formula Fields, SQL Transforms & Data Prep Recipes

7 Chapter 7: Data Model Objects (DMO) & Canonical Harmonization

7.1 Customer 360 Canonical Data Model & Subject Areas 7.2 DLO-to-DMO Mapping Patterns, Cardinality & Custom DMO Design 7.3 Data Validation, Schema Maintenance & Field Mapping Best Practices

8 Chapter 8: Identity Resolution Architecture & Match Rules

8.1 Identity Resolution Concepts, Consolidation Rate & Graph Modeling 8.2 Match Rules & Match Criteria: Exact Match vs. Fuzzy Matching (Deterministic & Probabilistic) 8.3 Multi-Party Identification, Anonymous-to-Known Transitions & Contact Point Matching

9 Chapter 9: Reconciliation Rules & Unified Profile Governance

9.1 Reconciliation Rules: Most Frequent, Source Priority & Last Updated 9.2 Unified Profile Schema (Individual & Contact Points) & Resolution Troubleshooting

10 Chapter 10: Segment Architecture & Audience Design

10.1 Segmentation Canvas, Segment Types (Standard UI & Flow) & Query Processing 10.2 Direct vs. Related Attributes, Cardinality & 1:N Filtering Traps 10.3 Segment Schedule, Refresh Frequencies & Exclusion Logic 10.4 Segment Membership Analysis, Population Drift & Sizing Validation

11 Chapter 11: Calculated & Streaming Insights

11.1 Calculated Insights (CI) Architecture, SQL/Builder Syntax & Dimensions vs. Metrics 11.2 Streaming Insights (SI) Architecture, Windowing (Tumbling/Sliding) & Real-Time Signals 11.3 CI vs. SI Architectural Decision Matrix & Performance Optimization

12 Chapter 12: Data Enhancements, Sharing & Analysis

12.1 Referencing Data 360 Data from Other Systems: Enrichments, Related Lists, Data Graphs & APIs 12.2 Reports, Dashboards & Tableau Analysis on Data 360 Data 12.3 Applying Predictive & Generative AI Tooling to Customer Scenarios

13 Chapter 13: Activation Targets & Outbound Activation

13.1 Activation Targets: Marketing Cloud, External Platforms, Cloud Storage & Data Spaces 13.2 Activation Configuration: Audience Mapping, Related Attributes & Payload Optimization 13.3 Activation Schedules, Publishing Cadence & Incremental vs. Full Refresh 13.4 Activation Troubleshooting: Error Logs, Rejection Reasons & Delivery Failures

14 Chapter 14: Real-Time Data Actions & Flow Automation

14.1 Data Action Targets & Webhook/Platform Event Architecture 14.2 Data Cloud-Triggered Flows & Real-Time Business Orchestration 14.3 End-to-End Enterprise Scenario Walkthrough: Ingestion to Closed-Loop Action

13.3 Activation Schedules, Publishing Cadence & Incremental vs. Full Refresh

Key Takeaways Explain This Topic AI

Activation schedules govern when audience payloads are delivered to external targets and must be synchronized with Segment refresh cadences to avoid redundant processing of unchanged data.

Incremental (Delta) Refresh delivers only net-new members, modified member attributes, and deleted/dropped members since the previous publish run, optimizing network bandwidth and downstream processing.

Full Refresh regenerates and transmits the complete audience snapshot, replacing the entire dataset at the destination target (mandatory for target rebuilds or significant schema changes).

Target platforms exhibit varying refresh capabilities: Marketing Cloud Engagement and Cloud Storage support both Incremental and Full refreshes, whereas Ad Platforms (Google/Meta) rely on incremental delta synchronization to preserve matched user pools.

The end-to-end data processing lifecycle enforces a strict operational sequence: Ingestion -> Transformation -> Identity Resolution -> Calculated Insights -> Segmentation -> Activation.

Last updated: September 2026

13.3 Activation Schedules, Publishing Cadence & Incremental vs. Full Refresh

Quick Answer: Data Cloud Activations execute on a defined publishing schedule (or via manual on-demand trigger) to deliver audience segments to activation targets. Activations support two primary synchronization modes: Incremental (Delta) Refresh , which exports only net-new, modified, or removed audience members since the last run, and Full Refresh , which publishes a complete snapshot of the entire segment. To maintain system performance and cost efficiency, Activation schedules must be strictly aligned with upstream Segment refresh cadences ; activating an audience more frequently than its underlying segment refreshes wastes processing credits without delivering updated data.

The Data Cloud Operational Sequence & Dependency Chain

To understand activation timing, consultants must visualize Data Cloud as a sequential data manufacturing pipeline. Each stage depends upon the successful completion of the preceding stage: +-------------------------------------------------------------------------------------------------+

  • | THE DATA CLOUD END-TO-END TIMING PIPELINE |
  • +-------------------------------------------------------------------------------------------------+
  • | STAGE 1: Ingestion & Data Transformation |
  • | - Batch connectors ingest external files; Ingestion API / SDK streams real-time events. |
  • | - Batch data transforms execute (hourly or daily) to clean and shape raw DLO data. |
  • +-------------------------------------------------------------------------------------------------+
  • │
  • ▼
  • +-------------------------------------------------------------------------------------------------+
  • | STAGE 2: Identity Resolution Ruleset Execution |
  • | - Scheduled rulesets evaluate match rules and reconciliation rules across Individual DMOs. |
  • | - Produces updated Unified Individual, Unified Contact Point, and Link tables. |
  • +-------------------------------------------------------------------------------------------------+
  • │
  • ▼
  • +-------------------------------------------------------------------------------------------------+
  • | STAGE 3: Calculated Insights (CI) Processing |
  • | - Batch SQL aggregations run against Unified DMOs (e.g., Recalculate LTV, Churn Scores, RFM). |
  • +-------------------------------------------------------------------------------------------------+
  • │
  • ▼
  • +-------------------------------------------------------------------------------------------------+
  • | STAGE 4: Segment Evaluation & Refresh Schedule |
  • | - Segment query engine evaluates criteria against Unified Profiles, DMOs, and CIs. |
  • | - Generates the updated Segment Membership table. |
  • +-------------------------------------------------------------------------------------------------+
  • │
  • ▼
  • +-------------------------------------------------------------------------------------------------+
  • | STAGE 5: Activation Schedule Execution |
  • | - Extracts qualifying segment members, resolves contact points, packages payload attributes. |
  • | - Delivers payload (Incremental or Full) to destination Activation Target. |
  • +-------------------------------------------------------------------------------------------------+
  • The Golden Rule of Publishing Alignment

An Activation cannot publish data newer than the Segment's last refresh, and a Segment cannot evaluate data newer than the last Identity Resolution and Calculated Insights runs.

Important

Consultant Best Practice: Scheduling Cadence Synchronization. If a marketing team configures a Segment to refresh once every 24 hours (e.g., at 02:00 UTC), but sets the Activation schedule to run every 1 hour, runs 2 through 24 will simply re-evaluate an unchanged segment table. This consumes unnecessary system processing bandwidth, inflates run history logs, and generates redundant empty delta files or duplicate API calls. Always align Activation schedules to trigger shortly after the Segment refresh window completes (e.g., Segment refresh at 02:00 UTC, Activation publish at 03:00 UTC).

Loading diagram... Data Cloud Upstream Processing Pipeline and Downstream Activation Alignment

Incremental (Delta) Refresh vs. Full Refresh

Choosing between an Incremental Refresh and a Full Refresh fundamentally dictates network efficiency, target storage consumption, and downstream operational logic. +-------------------------------------------------------------------------------------------------+

  • | INCREMENTAL REFRESH VS. FULL REFRESH COMPARISON |
  • +-------------------------------------------------------------------------------------------------+

[ INCREMENTAL (DELTA) REFRESH ] [ FULL REFRESH (SNAPSHOT) ]

Transmits only changes since last run: Transmits the entire qualified audience:

  • ┌─────────────────────────────────────────┐ ┌─────────────────────────────────────────┐
  • │ + Net-New Members (INSERT / ADD) │ │ All Current Segment Members │
  • │ ~ Modified Attributes (UPDATE) │ │ (Complete Population Snapshot) │
  • │ - Dropped Members (DELETE / REMOVE) │ │ │
  • └─────────────────────────────────────────┘ └─────────────────────────────────────────┘
  • Payload Size: Small (Kilobytes to Megabytes) Payload Size: Large (Gigabytes)
  • Downstream Impact: Fast upsert; preserves state Downstream Impact: Truncate & reload; heavy I/O
  • +-------------------------------------------------------------------------------------------------+
  • 1. Incremental Refresh Mechanics

In an Incremental Refresh, Data Cloud compares the current segment membership and payload attributes against the state recorded during the previous successful activation run. It categorizes every change into one of three operations:

Added (New) Members: Profiles that newly qualified for the segment criteria during the latest segment refresh.

Updated Members: Profiles that previously existed in the segment, but whose payload attributes (e.g., LoyaltyTier , LastPurchasedCategory , or ContactPointEmail ) changed in upstream DMOs.

Deleted (Dropped) Members: Profiles that were in the segment during the previous run, but no longer qualify based on updated behavioral or demographic criteria (e.g., an individual made a purchase, disqualifying them from an "Abandoned Cart" segment).

How Target Platforms Process Incremental Deltas:

Marketing Cloud Engagement (Shared Data Extension): Data Cloud upserts records into the Shared DE using the defined Subscriber Key. New records are inserted, modified records have their attribute columns updated, and dropped members are either retained with a status flag or deleted depending on the MCE connector configuration.

Cloud Storage Targets (S3, GCS, Azure Blob, SFTP): Data Cloud generates an incremental delta file containing an explicit action indicator column (typically titled Action or ChangeType ) with values INSERT , UPDATE , or DELETE . Downstream ETL pipelines read this column to execute target database merges without wiping historical records.

External Advertising Platforms (Google Ads, Meta Ads): Incremental refresh is critical for digital advertising. The connector transmits API ADD operations for new profiles and REMOVE operations for disqualified profiles. This ensures established ad audience match pools remain intact without resetting machine-learning optimization cycles or cookie lifespans.

2. Full Refresh Mechanics

A Full Refresh completely bypasses delta calculation. It exports every single profile qualifying for the segment at the moment of execution, alongside all mapped payload attributes.

When to Use Full Refresh:

Target Schema Restructuring: When an activation configuration has been modified to add or remove payload attributes, a Full Refresh is required to align the target schema.

Downstream Platform Requirement: Some third-party systems, direct-mail print vendors, or analytics engines cannot process delta merge logs; they require a daily master file replacement.

Data Corruption Recovery: If a downstream data extension or cloud folder is accidentally deleted or corrupted, executing a manual Full Refresh restores the complete audience state.

Platform-Specific Refresh Support Matrix

Not all Activation Targets support all refresh modes. Understanding these platform-specific boundaries is essential for the consultant exam.

Target Platform Incremental (Delta) Refresh Full Refresh Native Member Removal Handling Typical Publishing Frequency

Marketing Cloud Engagement Supported (Default) Supported Records updated/removed in Shared DE Every 12 or 24 hours (or on segment refresh)

Amazon S3 / GCS / Azure Blob Supported Supported Delta files output explicit Action column Scheduled batch (12h/24h) or manual trigger

Google Ads Customer Match Supported (API Delta) Not Recommended API emits REMOVE call for dropped users Every 12 to 24 hours

Meta Ads (Custom Audiences) Supported (API Delta) Not Recommended API emits removal payload for dropped users Every 12 to 24 hours

Salesforce Core CRM Objects Supported (Upsert) Supported Core records updated or removed from Campaign Near-real-time / scheduled batch

Scheduling Frequencies & Manual Publishing

Data Cloud provides declarative scheduling controls within the Activation editor:

Publishing Schedule Intervals: Typically configured for 12-hour or 24-hour automated cycles. Depending on the tenant licensing tier and connector specifications, some activation targets support hourly activations.

"Publish Now" (On-Demand Trigger): Administrators and marketing specialists can manually trigger an immediate activation run by clicking Publish Now on the Activation record page. This is commonly utilized during campaign launch validation, emergency marketing communications (e.g., weather-related flight cancellations), or end-to-end integration testing.

Tip

Manual Activation Execution Order: If an administrator updates source data in core CRM and immediately clicks Publish Now on an Activation, the outbound payload will not reflect the new data! Why? The source data has not yet flowed through Ingestion -> Harmonization -> Identity Resolution -> Calculated Insights -> Segment Refresh. For an immediate end-to-end refresh, the practitioner must refresh the Segment first, and then execute Publish Now on the Activation.