Schedules¶

A schedule defines an automated sequence of operations that JIM executes on a trigger (cron-based or manual). Each schedule contains ordered steps that can run sequentially or in parallel, and supports several step types: Run Profile execution, PowerShell scripts, external executables, and SQL scripts.

Schedules are the primary mechanism for automating identity synchronisation workflows. A typical example is a nightly schedule that imports from each Connected System, runs synchronisation, and exports the results.

Triggers¶

A schedule is one of two trigger types:

Cron
Runs automatically on a recurring pattern.
Manual
Runs only when explicitly triggered.

Pattern types¶

Cron schedules support three authoring modes:

Specific times
Pick days and times of day (e.g. weekdays at 06:00 and 18:00). JIM derives the cron expression from your selection.
Interval
Run every N minutes or hours within a daily window (e.g. every 15 minutes between 08:00 and 18:00 on weekdays).
Custom
Supply a raw cron expression for full control.

The first two modes cover the vast majority of cases without requiring administrators to think in cron syntax. Custom is the escape hatch for the unusual schedules they don't.

Steps¶

Each step has an execution mode and a step type.

Execution mode¶

Sequential
The step runs after the previous one finishes.
Parallel with previous
The step runs at the same time as the previous one.

A stepIndex orders steps; multiple steps with the same index run in parallel.

Step types¶

Run Profile
Execute a Run Profile against a Connected System.
PowerShell
Run a PowerShell script with arguments.
Executable
Run an external executable.
SQL script
Run a SQL script against a configured database connection.

Continue on failure¶

Set per step. By default, a failing step halts the schedule. Turn this on for steps where downstream work should proceed regardless (for example, an optional reporting step that shouldn't block the rest of the run).

Executions¶

Each schedule run produces a Schedule Execution record with per-step progress. Active and historical executions can be listed, retrieved, and (for active ones) cancelled.

A Schedule Execution typically appears as a parent activity with one child activity per step; this lets you walk down a schedule's execution tree from a single high-level record into the per-step detail.

Seeing how a run ended¶

The Schedules list shows each schedule's last run and, beside it, how that run ended. A run that stopped on a failure names the step it stopped on, so you can tell at a glance whether last night's schedule did what it was supposed to. A schedule that has never run says so.

Expanding a schedule's row lists its recent executions with their outcomes, how long each took, and how many of its steps ran. This is the quickest way to tell a one-off failure from a step that has been failing all week.

The same last-run outcome is available to automation. Get-JIMSchedule and the Schedules list REST endpoint carry it on each Schedule as LastExecutionId, LastExecutionStatus, LastExecutionCurrentStepIndex, LastExecutionTotalSteps, LastExecutionCompletedAt and LastExecutionErrorMessage, so a monitoring script can ask whether last night's run succeeded without walking the execution history. See the Schedules cmdlets for the field-by-field description.

The Schedule Execution view¶

Selecting an execution opens a view of that single run:

Every step, in the order it ran, with its outcome and duration.
Steps that share a step index are shown as a group, because they ran in parallel.
A link from each step to the Activity that produced it, where the per-object detail and any error live.
The error that stopped the run, where one did, together with whether Continue on failure was set on the step that failed.

Steps after a hard failure are shown as not run, rather than pending: the run has stopped, and they never will.

An execution that is still in progress refreshes as it goes, and can be cancelled from this view.

Watching one run¶

While a schedule is running, its tasks are grouped under a header in Admin > Operations > Queue, and that header draws the whole schedule as a rail: one marker per step, in the order they run, with the step names underneath and the step it has reached named beside them ("Step 2 of 5").

The rail shows the whole schedule, not just the part still queued. A task is removed from the queue the moment it finishes, so steps already done would otherwise disappear as the run progressed; their outcomes are read from their Activities instead. A step that failed stays visible as a failed marker, including when the group is collapsed to a single row.

A step running several tasks at once is drawn as one divided marker, a wedge per task, each carrying that task's own outcome. So a step where one of two parallel imports has failed while the other is still running reads as exactly that, rather than as a single colour for the whole step. The wedges are ordered by outcome rather than by task, so a failure always starts at the top of the marker and stays visible however wide the schedule fans out.

A step's position counts step groups: steps that run concurrently share one position, so a schedule of six steps where two run together is five steps long.

Enabled flag¶

Disabled schedules don't fire on their cron trigger and don't appear as eligible for manual run. This is useful for temporarily pausing a schedule during maintenance without losing its definition.

Built-in schedules¶

JIM ships with a small number of built-in schedules that are part of the product rather than something you create. They behave like any other schedule with one difference: their name is fixed and they cannot be deleted. You can still change when they run and enable or disable them.

Temporal Scope Reconciliation
Keeps relative-date scope filters live for objects whose source data isn't changing. Both the import and export hot paths skip an object that hasn't changed since the last run, so a leaver whose end date has just passed, or a joiner whose start date has just arrived, would otherwise never be re-evaluated until something else about them changed. This schedule periodically re-checks those time-driven scope transitions and routes the affected objects back through the normal synchronisation engine, so date-driven deprovisioning and staged provisioning happen on their own. It runs hourly by default; lower the interval for tighter timing, or raise it to reduce background work.

What you can and can't do with a built-in schedule:

✅ Re-time it
Change the trigger pattern or interval (for example, run the reconciler every 15 minutes instead of hourly).
✅ Enable or disable it
Pause it during a maintenance window and re-enable it afterwards.
❌ Rename it
The name is fixed so the schedule stays recognisable and JIM can keep it maintained across upgrades.
❌ Delete it
Built-in schedules are part of the product; disable one instead if you don't want it to run.
❌ Change its steps
The step composition is defined and maintained by JIM; the Steps tab is read-only for a built-in schedule.

The portal reflects this: a built-in schedule's name and steps are read-only in the editor, and its delete action is replaced with a lock. These rules are enforced everywhere, not just in the portal: the PowerShell module and REST API reject a rename, delete or step change, and the underlying application layer is the authoritative backstop.

Auditing¶

Every configuration change to a schedule is recorded in the immutable audit log (Activities): creating, editing, enabling, disabling, re-timing and deleting are each captured as an Activity attributed to whoever made the change, the same audit trail JIM keeps for Connected Systems and Synchronisation Rules. Running a schedule is tracked separately, as a schedule execution and its per-step Activities.

Change history¶

Every change to a Schedule's configuration (including its Steps) is recorded as a versioned snapshot, the same way as for Synchronisation Rules and Connected Systems. The History tab in the Schedule editor shows the timeline of changes, each as a field-by-field "before and after", and lets you compare any two versions. A step's SQL connection string is treated as a secret: a change to it is recorded, but its value is never stored or shown.

The same history is available from the Get-JIMConfigurationChangeHistory cmdlet (-Type Schedule -Id <guid>) and the Schedule change-history REST endpoints in the interactive API reference.

When changing a schedule from automation you can record a reason alongside the change, exactly as for Synchronisation Rules and Connected Systems: pass -ChangeReason on the Schedule write cmdlets (New-, Set-, Remove-, Enable-, Disable-JIMSchedule and the step cmdlets), or the optional changeReason field/query parameter on the REST write endpoints. The reason shows with the change and on its Activity.

Common workflows¶

Setting up an automated nightly sync:

Create a schedule with a cron trigger, a specific-times pattern, and the schedule enabled
Add ordered steps for each operation: imports first, then syncs, then exports (typically sequential)
Verify by triggering a manual run before the first scheduled fire
Monitor the resulting execution to confirm each step completes as expected

Running an ad-hoc sync via a manual schedule:

Create a schedule with a manual trigger
Add the steps for the operations you want
Run it when you need it; monitor the execution

Pausing a schedule during a maintenance window:

Disable the schedule
Do the maintenance work
Re-enable the schedule; the next scheduled fire-time picks up automatically

Manage Schedules¶

JIM portal
Schedules area of the admin UI
PowerShell
Schedules cmdlets (Get-JIMSchedule, New-JIMSchedule, Invoke-JIMSchedule, etc.)
REST API
Schedules and schedule execution endpoints in the interactive API reference