Home How We Work Security Assurance Resources
/ Technology · Compute Architecture · Orchestration

Data orchestration with people in control.

Automated batches build downstream data, visuals and reports on the same engine as every query. Each run is decided, planned, run and recorded, and the Command Center lets business owners find a failure, check its inputs and re-run it themselves.

Schedules and event triggers · Readiness and sign-off · Reuse or recalculate · Versioned audit trail · Command Center
What orchestration adds

Orchestration: the same engine, with control.

Orchestration runs on the shared engine and adds control: it decides when to run and what to rebuild, plans the order, logs every step and writes versioned results, and people can step in at any point. No separate workflow tool to license or manage.

Execution engine

How a run is decided, planned, run and recorded.

Before anything is calculated, the engine decides whether the run can start, works out what it needs, what can be reused and in what order to build the rest. That keeps large batch runs fast, within memory and fully traceable.

One run, stage by stage · reused or recalculated
Dashed: unchanged, reused at its current version. Coral: recalculated as a new version. Illustrative.
01
DecideShould the run start?
  1. 1TriggersOn a schedule, on an event such as a file landing or an upstream run finishing, or by hand.
  2. 2ReadinessInputs and dependencies are checked; a missing input holds the run.
  3. 3Sign-off gatesSteps that need approval wait for it before continuing.
02
PlanWork out what the run needs
  1. 4Building blocksFind every source, table and report the run touches.
  2. 5VersionsPick the right version of each one.
  3. 6OrderSequence the artifacts, then the columns and cells inside each.
  4. 7Reuse or recalculateRebuild only what changed; reuse the rest.
03
RunCalculate in stages
  1. 8Stage by stageWorktables, then intermediate tables, then reports, logged as it runs.
  2. 9SQL or Excel rulesEach artifact runs the logic it is defined with: its SQL, or the versioned rule parsed from its Excel formula.
  3. 10RetriesFailed steps retry as configured, then alert the owner and pause.
04
RecordVersion and audit everything
  1. 11New versionsLog the version of every artifact used and created.
  2. 12Audit trailWhich artifacts, which versions, and how each value was calculated.

Intermediate tables can also be kept as stored tables when users need them for audit.

Command Center

Monitoring and re-running jobs.

One screen to monitor runs, inspect their inputs and re-run failures. The six steps below follow a failed run from detection to re-execution.

  1. Step 01

    Watch every run

    Scheduled report groups sit beside the batch history: what ran, what triggered it and how long it took.

    • LoggedBatch 45 · scheduler · 3m 25s
    • FailedBatch 42 · costing report
    • ActionPause, resume or execute now
    Command Center with scheduled report groups and a batch execution history showing completed and failed batches with trigger and duration
  2. Step 02

    See what a run depends on

    Open a group to see its reports and every source, master file and parameter, with the version each will use.

    • ReadyPrimary sales data · v1
    • ReadyProduct master · v3
    • MissingSKU master · the run waits
    A report group expanded to show its five reports and dependencies, with source and master file versions and a missing SKU master flagged
  3. Step 03

    Schedule or start a run

    Pick report groups, then set the frequency, time and start date, or run a group straight away.

    • GroupPrimary sales dashboard demo
    • ScheduleDaily at 06:00 from 01 Dec 2026
    Schedule new execution dialog with one report group selected and a daily 06:00 schedule configured
  4. Step 04

    Spot the failed run

    The execution history marks the failed run. Open it to see what triggered it and which group it belongs to.

    • FailedRun 141 · 30 Jun · 08:16 PM
    • ActionAnalyse execution, then re-run
    Manual run screen with the execution history showing run 141 as failed and its details opened
  5. Step 05

    Review before re-running

    The review lists dependent reports and sources, and lets you pick the version of each input the re-run reads.

    • Scope5 reports · no dependent reports
    • VersionASM target data · v5 selected
    • ActionAdd to queue
    Re-execution queue review listing the dependent sources for a report group, each with its selected version
  6. Step 06

    Confirm and execute

    Confirm the queued run and choose whether to rebuild tables and keep adjustments already posted.

    • OnRecreate tables from inputs
    • OffRetain report adjustments
    • RunPrimary sales dashboard executes
    Execute confirmation listing the reports to run, with options to recreate tables and retain report adjustments
Common questions

Frequently asked questions.

Do we still need Airflow or another workflow tool?

No. Scheduling, orchestration and the Command Center ship with the platform, with no separate workflow tool to license or manage. Runs start on a schedule, by hand, or on events such as a file landing or a process completing. Steps run in dependency order, failures retry as configured, owners are alerted, and runs can be paused, restarted from a checkpoint or held for sign-off, with every run logged.

How does a run decide what to recalculate?

The execution engine first identifies the building blocks a run needs (sources, worktables, business tables, intermediate tables and reports) and the right version of each. Artifacts whose inputs have not changed are reused; the rest are recalculated in order, worktables first, then intermediate tables, then reports. Every artifact used or created is logged with its version, with an audit trail of how each value was calculated.

Can business users re-run a failed run themselves?

Yes. In the Command Center they see every run with its inputs, open a failed run, review the dependent reports and sources, choose the version of each input and queue the re-run, with options to recreate tables and keep report adjustments.

Talk to us about your compute workloads.

Send us one report, reconciliation or pipeline that takes too long or keeps failing today. We'll run it on the platform and show you the execution path, the memory it needed and the time it took.

  • Benchmarked on your data shape, not a demo set
  • A walkthrough of the engine and scheduler for your architects
  • A comparison with your current infrastructure spend