Scheduling Strategies

This guide covers best practices and strategies for scheduling Cloud Replicator jobs to meet your data freshness and performance requirements.

Understanding Replication Patterns

Incremental Replication

After the initial full replication, subsequent runs are incremental:

Only modified records are processed
Based on SystemModifiedAt timestamp
Rollback Time setting prevents missed changes

Full Replication

A full replication processes all records:

First run for a new table mapping
After "Reset Last Replication"
When significant data changes occur

Factors Affecting Schedule

Data Freshness Requirements

Requirement	Recommended Frequency
Real-time	Every 5-15 minutes
Near real-time	Every 15-30 minutes
Hourly updates	Every hour
Daily sync	Once or twice daily

Data Volume

Volume	Consideration
Small (<10K records)	Can run frequently
Medium (10K-100K)	Consider off-peak hours
Large (100K+)	Schedule during low usage

Business Central Load

Consider user activity patterns
Avoid scheduling during month-end processing
Leave headroom for manual operations

Cloud Destination Limits

Azure Table: High throughput, scalable
Cosmos DB: RU/s limits, cost implications
AI Search: Indexing speed limits

Common Scheduling Patterns

Pattern 1: Business Hours Sync

Use Case: Keep data current during working hours

Schedule:
- Monday-Friday
- 8:00 AM - 6:00 PM
- Every 30 minutes

Off-Hours:
- One sync at 10:00 PM
- Catch overnight changes at 6:00 AM

Pattern 2: Tiered Frequency

Use Case: Different tables have different freshness needs

Critical Tables (Customers, Orders):
- Every 15 minutes
- All day

Standard Tables (History, Reports):
- Every 2 hours
- Business hours only

Archive Tables:
- Once daily
- 2:00 AM

Pattern 3: Nightly Batch

Use Case: Data freshness can wait until next day

Schedule:
- Every night at 2:00 AM
- Full sync all tables
- Complete before business hours

Pattern 4: Continuous Sync

Use Case: Mission-critical data freshness

Schedule:
- 24/7 operation
- Every 5-10 minutes
- Monitor closely for issues

Implementing Tiered Schedules

Creating Multiple Job Queue Entries

Create one Job Queue entry per tier, all running codeunit 70319900, and use the Parameter String to target a specific set of tables (by Table No.) in each job:

Create Job for Critical Tables
- High frequency (every 15 min)

- Parameter String: `18	36	37` (Customer, Sales Header, Sales Line)

Create Job for Standard Tables
- Medium frequency (hourly)
- Parameter String: 27 (Item)
Create Job for Archive Tables
- Low frequency (daily)
- Parameter String: 17 (G/L Entry)

All table mappings must still be marked Active — the Parameter String narrows each job to a subset of the active mappings.

Targeting Tables per Job

Use the Parameter String (a Table No. filter) to control which tables each job replicates:

Job	Parameter String	Tables Replicated
Job 1 (Critical)	`18&#\|;36&#\|;37`	Customer, Sales Header, Sales Line
Job 2 (Standard)	`27`	Item
Job 3 (Archive)	`17`	G/L Entry

Alternative: Multiple Index Mappings

Create multiple mappings with different indexes:

Index 0: Critical sync (frequent)
Index 1: Archive sync (daily)

Avoiding Conflicts

Overlapping Jobs

When multiple jobs might overlap:

Stagger Start Times
- Job 1: :00 and :30
- Job 2: :15 and :45
Use Unique Job Categories
- Different categories for different schedules
- Helps identify which job is running
Monitor Execution Times
- Ensure jobs complete before next run
- Adjust frequency if overlapping occurs

Engine Resource Conflicts

All jobs share the same engine pool:

Total concurrent engines limited by system
Jobs may queue if resources are busy
Consider reducing engine count for non-critical jobs

Handling Initial Load

First-Time Setup

For initial replication of large datasets:

Schedule During Maintenance Window
- Weekend or overnight
- Minimal user impact
Temporarily Increase Resources
- Higher engine count
- Higher Cosmos DB RU/s (if applicable)
Run Manually First
- Don't wait for Job Queue
- Monitor progress directly
Then Enable Schedule
- After initial sync completes
- Incremental syncs are faster

Monitoring Schedule Performance

Key Metrics to Track

Metric	Where to Find
Job Duration	Job Queue Log Entries
Records Replicated	Replication Log
Engine Utilization	Engine Pulse List
Errors	Replication Log

Signs of Schedule Issues

Jobs overlapping regularly
Increasing job duration over time
Frequent errors in logs
Data freshness SLA misses

Adjusting Schedules

Based on monitoring:

Too slow: Increase engine count
Overlapping: Reduce frequency or stagger times
Resource contention: Schedule at different times
Cost concerns: Reduce frequency for large tables

Seasonal Considerations

High-Volume Periods

During busy seasons (holidays, month-end):

Consider reducing frequency
Schedule around peak transaction times
Monitor system performance

Low-Volume Periods

During quiet periods:

Can run more frequently
Good time for initial large replications
Consider maintenance tasks

Rollback Time Configuration

Purpose

Rollback Time adds an overlap period to replication filters:

Ensures no records are missed
Handles timestamp precision issues
Catches records modified during previous sync

Setting Rollback Time

In Cloud Replicator Setup:

Rollback Time: 5 minutes (example)

Recommendations

Sync Frequency	Rollback Time
Every 5 min	2 minutes
Every 15 min	3 minutes
Hourly	5 minutes
Daily	30 minutes

Impact

Longer rollback times:

More redundant processing
Higher safety margin
Slightly longer sync times

Documentation and Communication

Document Your Schedule

Maintain records of:

Job configurations
Schedule rationale
Table assignments to jobs
Contact for issues

Communicate with Users

Inform stakeholders about:

Data freshness expectations
Scheduled maintenance windows
How to request urgent syncs