Cloud Replicator Documentation
Index

Advanced Table Options

This guide covers advanced configuration options for table mappings, including series tables, SystemId usage, deletion tracking, and partition key customization.

Per Day (Series Tables)

What Are Series Tables?

When "Per Day" is enabled, Cloud Replicator creates an additional table/container that stores daily snapshots of your data:

Original Table Series Table
Customers CustomersSeries
SalesHeader SalesHeaderSeries
Item ItemSeries

How It Works

  1. Regular replication updates the main table with current state
  2. Series replication adds records with the current date as part of the key
  3. Each day's data is preserved, building a historical record

Use Cases

  • Trend Analysis: Track how values change over time
  • Historical Reporting: Report on data as it existed on specific dates
  • Compliance: Maintain point-in-time records for auditing
  • KPI Tracking: Monitor daily metrics over time

Configuration

  1. Open the table mapping
  2. Check Per Day
  3. Run replication

Data Structure

In the series table:

  • The PartitionKey is the same company-based key used for the main table
  • The snapshot date is appended to the RowKey, and a separate _RowDate field stores the date
  • All fields from the record are preserved

Limitations

  • Not available for Azure AI Search
  • Increases storage requirements significantly
  • Queries must account for date dimension

Best Practices

  • Enable only for tables where history is valuable
  • Consider storage costs for high-volume tables
  • Set up regular cleanup of old series data in Azure

SystemId as RowKey

What is SystemId?

Every Business Central record has a SystemId field:

  • Globally unique GUID
  • Never changes for a record
  • Survives primary key modifications
  • Automatically assigned by the system

Benefits of Using SystemId

Benefit Explanation
Stability Key never changes even if business key changes
Uniqueness Guaranteed unique across all companies
Simplicity Single-field key regardless of table structure
Consistency Same format for all tables

When to Use SystemId

Enable SystemId as RowKey when:

  • Primary key fields may change
  • Table has a complex multi-field primary key
  • Using Azure AI Search (required)
  • Building applications that track record identity

When to Use Primary Key

Keep primary key (default) when:

  • You need human-readable keys
  • External systems reference by business key
  • Key stability is not a concern
  • Querying by business key is common

Configuration

  1. Open the table mapping
  2. Check SystemId as RowKey
  3. Run replication (existing data will be re-keyed)

Migration Consideration

Changing this option creates new records with new keys:

  • Old records (with old key format) remain in destination
  • May need to clean up old records manually
  • Consider resetting and running full replication

What It Does

When enabled, Cloud Replicator adds SystemId references for all related records:

  • Works with "Unfold" field action
  • Works with "SystemId" field action
  • Automatically includes related record GUIDs

Use Cases

  • Maintaining Relationships: Link records across tables in destination
  • Data Integration: Join tables using stable GUIDs
  • Parent-Child Tracking: Track line items back to headers

Example

For a Sales Line with related Item:

{
  "Document_No_": "SO-1234",
  "Line_No_": 10000,
  "No_": "ITEM-001",
  "Item_SystemId": "abc-123-def-456"
}

The Item_SystemId field allows you to join with the Item table's SystemId.

Configuration

  1. Open the table mapping
  2. Check Add SystemId to All Related
  3. Configure Unfold field actions as needed
  4. Run replication

Replicate Deletions

What It Does

Tracks when records are deleted in Business Central and replicates that deletion to your cloud destination.

How It Works

  1. Business Central Change Log captures deletions
  2. Cloud Replicator reads deletion records from Change Log
  3. Delete operations are sent to the cloud destination

Prerequisites

Before enabling:

  1. Enable Change Log in Business Central
    • Search for "Change Log Setup"
    • Enable Change Log
    • Configure table for "Log Deletion"
  2. Configure Table in Change Log
    • Open Change Log Setup
    • Select your table
    • Enable "Log Deletion" (at minimum)

Configuration

  1. Ensure Change Log is configured (see above)
  2. Open the table mapping
  3. Check Replicate Deletions
  4. A validation ensures Change Log is enabled for the table

Limitations

  • Requires Change Log to be enabled
  • Not available for Azure AI Search
  • Only captures deletions after Change Log is enabled
  • Does not retroactively delete historical records

Best Practices

  • Enable Change Log before configuring deletion tracking
  • Monitor Change Log size (grows over time)
  • Set up Change Log cleanup policies

Additional Partition Key Field

What It Does

Adds an extra field value to the PartitionKey in Azure Table Storage or Cosmos DB Table API.

Default Partition Key

By default, the PartitionKey is:

{CleanedCompanyName}{PartitionKeyPostfix}

With Additional Field

With an additional field (e.g., Customer Group):

{CleanedCompanyName}{PartitionKeyPostfix}_{FieldValue}

Use Cases

  • Sub-Partitioning: Distribute data across more partitions
  • Query Optimization: Faster queries when filtering by the partition field
  • Logical Grouping: Group records by a business attribute

Configuration

  1. Identify the field number you want to add
  2. Open the table mapping
  3. Enter the field number in Additional Partition Key Field
  4. Run replication

Finding Field Numbers

To find a field's number:

  1. Open the table in design mode (Configuration Packages)
  2. View field definitions
  3. Or use Page Inspection on a page showing the field

Example

For Customer table with "Customer Posting Group" (Field 21):

Additional Partition Key Field: 21

Resulting PartitionKey: CRONUS_International_DOMESTIC
                        (Company name + Customer Posting Group value)

Considerations

  • Choose a field with relatively stable values
  • High-cardinality fields create many partitions
  • Changing this requires full re-replication

Combining Advanced Options

Analytics Setup

For comprehensive analytics data:

Per Day: Yes
SystemId as RowKey: Yes
Add SystemId to All Related: Yes
Replicate Deletions: Yes

Search Setup

For search functionality (Azure AI Search):

Per Day: No (forced)
SystemId as RowKey: Yes (forced)
Add SystemId to All Related: Yes
Replicate Deletions: No (not supported)

Simple Archive

For basic data archival:

Per Day: No
SystemId as RowKey: No
Add SystemId to All Related: No
Replicate Deletions: No

Performance Impact

Options That Increase Load

Option Impact
Per Day 2x storage and write operations
Add SystemId to All Related Additional lookups per record
Replicate Deletions Additional Change Log queries

Optimization Tips

  • Enable advanced options only when needed
  • Test performance impact in sandbox first
  • Monitor replication times after changes
  • Adjust engine count based on workload