Scheduled Jobs

By Optimizely Education
Published: Mar 10, 2026
Rating 1 star 2 stars 3 stars 4 stars 5 stars

Average rating: 0 No reviews

Outline

At a glance

Batch orchestration: Use ScheduledJob for non-real-time work and make it restart-tolerant for cloud process recycles.
Editorial flow: Use IContentEvents to hook into publishing lifecycles, keeping blocking and background logic clearly separated.
Startup extensibility: Choose IInitializableModule for CMS-specific bootstrapping and IStartupFilter for broader .NET middleware concerns.
PaaS boundary: Design for Azure App Service limits so long-running work does not turn into zombie jobs with commitment issues.

Extending Optimizely CMS 13 requires a clear understanding of its asynchronous execution models and initialization pipeline. For enterprise PaaS developers, the challenge is not simply making code run, but making it run reliably within a multi-instance, auto-scaling Azure-based environment.

1. Scheduled Jobs: Orchestrating Background Tasks in DXP

Scheduled Jobs are the standard mechanism for batch-oriented operations such as PIM synchronization, log cleanup, or CRM reconciliation. In a cloud environment, those jobs must be interruption-aware and safe to resume.

1.1 Technical Anatomy and the Stop Pattern

A custom job inherits from the ScheduledJob base class. If an editor stops the job from the UI or the Azure host recycles the App Service, the job must release resources and exit cleanly through the Stop() hook.

[ScheduledPageType(
    DisplayName = "Daily Inventory Import", 
    GUID = "...", 
    Description = "Syncs stock from ERP via Secure API")]
public class InventoryImportJob : ScheduledJob
{
    private bool _stopStopped = false;

    public override string Execute()
    {
        OnStatusChanged("Starting secure import...");
        
        for(int i = 0; i < 100; i++) 
        {
            // CHECK THE STOP SIGNAL: Vital for DXP stability
            if (_stopStopped) return "Process safely interrupted by host.";
            
            OnStatusChanged($"Processing batch {i}%");
            // Batch logic: Perform DB writes in small units
        }

        return "Import successfully completed.";
    }

    public override void Stop() => _stopStopped = true;
}

1.2 The 1-Hour DXP Environment Boundary

Under the hood, DXP background threads may be terminated if execution exceeds roughly 60 minutes. That makes resilience patterns important rather than decorative.

The Checkpoint Strategy: Design checkpoint-aware jobs. Store the last processed key or batch marker so the next execution can resume instead of replaying millions of records.
Execution Locks: DXP ensures that only one instance of the application runs the job at a time, reducing the risk of cluster-wide race conditions.

2. Real-Time Hooks: Mastering IContentEvents

When the system must react immediately to editorial actions, such as enriching content on publish or responding to a media upload, developers use the event system.

2.1 The Sequence of Events: Sync vs. Async

Publishing (Synchronous): Occurs before the SQL transaction is committed. This is where validation logic can inspect or block the operation.
Published (Asynchronous): Occurs after the content is committed. In DXP, this event can be propagated across instances through platform messaging infrastructure.

Architectural Warning

Never place a slow external API call inside a synchronous publishing event. That blocks the editorial thread and makes the CMS UI feel frozen while the editor wonders whether the platform is broken or merely judging them.

3. Initialization and Lifecycle Hooks

Beyond jobs and content events, Optimizely provides extensibility points during startup and application initialization. Choosing the correct hook matters because not all startup logic belongs in the same place.

3.1 IInitializableModule vs. IStartupFilter

IInitializableModule: Best suited for CMS-specific initialization such as event subscription, registration work, or content-related bootstrapping.
IStartupFilter: Better suited for global ASP.NET Core pipeline behavior, especially when middleware ordering or application-wide startup behavior must be influenced.

In practice, use IInitializableModule when the concern belongs to the CMS runtime, and use IStartupFilter when the concern belongs to the broader web application startup sequence.

Conclusion

Extending Optimizely CMS 13 through Scheduled Jobs and lifecycle hooks is about building background and startup logic that behaves well under cloud pressure. By designing jobs that can stop safely, resume intelligently, and respect DXP runtime limits, and by keeping synchronous event handlers fast and disciplined, developers create solutions that remain reliable even in distributed environments. Mastering these extensibility patterns is less about making the code clever and more about making the platform dependable when real traffic, real editors, and real infrastructure constraints all show up at once.