Publish Orchestration (K12LISS_API) - PosiEd
Publish orchestration is a mechanism that allows multiple record sets—such as cohort members, class lists, and daily data—to be published together in a single action. Instead of triggering each publish individually and waiting for one process to finish before starting another, orchestration enables users to initiate several publishes at once with a single click.
This significantly improves efficiency, especially in scenarios where multiple related datasets need to be synced. However, while the initiation is simultaneous, the system still processes each publish in a controlled and sequential manner behind the scenes to ensure data integrity.
Key components/fields
Component | Type | Description |
|---|---|---|
Integration Status | Custom Setting | Stores the latest publish status and last run time for each integration method. Used to enforce execution order and track dependencies between methods. |
School Code | Text field | Identifier for each school; used to separate and track integration status per school. |
Source | Text field | Identifier for timetable app |
Bell Times Status | Text field | Tracks the current state of the last publish for Bell Times (Not Published, Queued, In Progress, Completed). |
Rooms Status | Text field | Tracks the current state of the last publish for Rooms (Not Published, Queued, In Progress, Completed). |
Students Status | Text field | Tracks the current state of the last publish for Students (Not Published, Queued, In Progress, Completed). |
Teachers Status | Text field | Tracks the current state of the last publish for Teachers (Not Published, Queued, In Progress, Completed). |
…. |
|
|
How Publish Orchestration Works
When multiple publishes are triggered at the same time, they are not executed in parallel. Instead, the system follows a structured approach:
The first eligible publish begins processing immediately.
All other publishes are placed in a queue.
Each queued job waits until the previous one has completed before it begins.
The execution order is governed not just by timing, but also by data dependencies between record sets.
This ensures that related data is always processed in the correct sequence. For example, records that rely on the existence of other data (such as class memberships depending on classes) will not run before their dependencies are completed.
To monitor progress, you can check:
Apex Jobs for background processing
Integration Status (Custom Settings) for status tracking across record types
Setup Requirements
Before publish orchestration can function correctly, certain configurations must be in place.
Publish Order Log (Required)
The Publish Order log acts as the feature toggle for orchestration. Without it, the system will not enforce any publish order. To configure:
Navigate to Custom Settings
Create or update the relevant record
Set the Source field to: Publish Order
If this step is skipped, all publishes will run without sequencing, which may lead to failures when dependencies exist.
Atlantis Sync School Setup
The setup process differs depending on whether the org is new or already contains existing data.
New Orgs - For newly created orgs, no manual setup is required. The necessary logs and statuses are automatically generated during the first publish.
Existing Orgs - For orgs with previously published data, additional preparation is required to prevent dependency issues. You must:
Update existing record sets
Ensure all statuses are set to: Completed
This step is critical because the orchestration logic checks existing statuses before allowing new publishes to proceed. Missing or incorrect statuses can cause processes to fail.
Understanding Dependencies
Not all publishes are independent. Some rely on others being completed first.
For example, attempting to publish Cohort Members or Daily Data before publishing Classes will result in a failure. This happens because the dependent data does not yet exist in the system, and the orchestration logic prevents the process from running out of order.
When such a situation occurs, the error will typically appear in PosiEd Logs as a dependency-related failure.
Publish Order and Dependency
The orchestration system organizes publishes into two categories: independent and dependent.
Independent Publishes
These publishes do not rely on any other data and can run immediately when triggered (unless another instance of the same publish is already running or queued).
Order | Publish |
|---|---|
1 | Bell Times |
2 | Rooms |
3 | Students |
4 | Teachers |
Dependent Publishes
These publishes require a specific sequence. Each one will only run after its dependency has been completed.
This structured order ensures that all required data is available before a dependent process begins.
Order | Publish | Depends On |
|---|---|---|
5 | Classes | Teachers |
6 | Class Memberships | Classes |
7 | Timetable | Class Memberships |
8 | Daily Data | Timetable |
9 | Daily Deltas | Daily Data |
What Happens When Multiple Publishes Are Triggered at Once
When all publishes are fired simultaneously, each request is logged immediately but not processed right away. Before any processing begins, a gating check determines whether a publish is allowed to proceed:
Independent publishes (Bell Times, Rooms, Students, Teachers) — allowed to run immediately, unless the same publish is already in progress or queued, in which case the incoming request is held until the current one finishes.
Dependent publishes (Classes onward) — only allowed to run if the publish directly before it in the sequence has a Completed status. If not, the request is queued and waits.
Once a publish completes, the system automatically looks for the next queued item in the sequence and triggers it — no manual intervention needed. This continues until all queued publishes have been processed.
Status Flow: Not Published → Queued → In Progress → Completed
Check the Integration_Status_List__c record for your school. Each data type has its own status field — you should see them resolve sequentially from In Progress → Completed, with dependent publishes only starting after their predecessor completes.
In PosiEd Logs, publishes that were held will appear as PUBLISH LOG - PENDING. Successfully processed ones will show PUBLISH LOG - COMPLETED.
Feature Toggle
This orchestration activates only when a PosiEd__Integration_Status_List__c record named PUBLISH ORDER exists. Without it, the system falls back to direct processing with no ordering guarantee.