Run Profiles

A Run Profile defines a synchronisation operation that can be executed against a Connected System. Each Run Profile specifies the type of operation (import, sync, or export), a batch size, and (where applicable) a target partition or file path.

Run Profiles are the building blocks of schedules: each schedule step typically references a Run Profile to execute. Run Profiles can also be executed directly for one-off operations.

Run types

A Run Profile is one of:

• Full Import
  Read every object from the Connected System and replace the existing connector space view.
• Delta Import
  Read only the objects that have changed since the last import. Faster, and only available where the connector supports change tracking.
• Full Synchronisation
  Evaluate every connector space object against the Synchronisation Rules; produce projections, joins, Attribute Flows, and Pending Exports. Its preview action shows what it would do without running it; see Previewing a Full Synchronisation.
• Delta Synchronisation
  Evaluate only objects with pending changes since the last sync. Faster.
• Export
  Flush Pending Exports out to the Connected System.

Batch size

Controls how many objects are processed per batch during execution. Larger batches reduce overhead per object but cost more memory and increase the blast radius if a batch fails. Sensible defaults differ per connector; tune as needed for your scale.

Partition and file path

For connectors that expose multiple partitions (for example LDAP) or that operate on files (the file connector), the Run Profile pins the operation to a specific scope. A connector can have several Run Profiles of the same run type, each scoped to a different partition or file.

A Run Profile that targets no partition reads from every partition currently selected on the Connected System, so it follows your selections automatically.

When a targeted partition is deselected

Selecting a partition on the Connected System's Scope tab is how you tell JIM which parts of a directory it manages, and that decision binds every Run Profile. If you deselect a partition that a Run Profile targets, that Run Profile becomes inoperable: JIM refuses to run it, naming the Run Profile and the partition, rather than reading scope you have withdrawn. The Run Profiles tab marks it Not selected beside the partition name, the REST API returns targetsDeselectedPartition on the Run Profile, and Get-JIMRunProfile surfaces the same property, so you can find every affected Run Profile before a scheduled run reaches one:

Get-JIMRunProfile -ConnectedSystemId 1 | Where-Object targetsDeselectedPartition

To resolve it, either select the partition again, or edit the Run Profile to target a partition that is selected. Deleting the Run Profile is also valid where the partition has genuinely been retired.

Deselecting a partition or container changes what a Full Import considers deleted

A Full Import treats any object it does not find as deleted from the Connected System, which marks the corresponding Connected System Objects obsolete and, on the next synchronisation, disconnects them and recalls their contributed attribute values. Narrowing import scope therefore has consequences well beyond "JIM stops reading these objects". Review the scope change before saving it.

Verification Mode (Full Import)

Full Import automatically skips loading and comparing objects whose content has not changed since the last import, using a stored content hash (see how Full Import detects unchanged objects). This is transparent and needs no configuration.

Verification Mode is an optional toggle on a Full Import Run Profile that temporarily disables this optimisation: every object is fully compared regardless of its stored hash, and JIM reports an error if a stored hash matched but the comparison still found a change. Use it to validate the optimisation after an upgrade, or to investigate a suspected discrepancy; leave it off for everyday imports, since it forgoes the performance benefit. The toggle only applies to Full Import Run Profiles; enabling it on any other run type is rejected.

Safeguards

Export

An Export Run Profile can carry a limit on how many creates, updates and deletes a single run may attempt against the Connected System: Max creates, Max updates and Max deletes. Each is optional and independent; leave any of them blank for no limit, or set one to 0 to refuse that change type outright. The three limits are only valid on an Export Run Profile; setting one on any other run type is rejected.

A run that would exceed a limit attempts none of that change type. JIM counts how many of each change type are pending at the start of the run; if a type's count is more than its limit, JIM attempts none of that type at all this run and leaves every one of them exactly where they were: still Pending, untouched. There is no partial attempt: JIM never processes up to the limit and stops partway. Other change types are unaffected and continue normally, whether they carry their own limit or none. The Activity for a run that withheld anything completes as Complete with warning, naming the limit, how many were pending, and what to do next, and the Activity's exportCreatesWithheld / exportUpdatesWithheld / exportDeletesWithheld counters record exactly how many were withheld (see Activities). Resuming needs no action beyond raising or clearing the limit, or reducing what is pending, then running the Export Run Profile again.

To clear a limit, set it back to no value:

Set-JIMRunProfile -ConnectedSystemId 1 -RunProfileId 12 -MaxDeletes $null

Recommended values: set Max deletes to a small share of the target Connected System's population (for example, a few percent) on any Export Run Profile writing to a production directory; a broken import filter or an unintended Synchronisation Rule change can then withhold the whole deprovisioning attempt and warn you, rather than working through the whole directory. Leave Max creates and Max updates blank until a new Connected System's initial load has finished, since that first export is legitimately a mass create; consider capping them afterwards for the same reason as deletes.

Letting a legitimate mass change through

A limit exists to stop a run nobody meant to be this big; it is not meant to be raised every time a genuine bulk operation comes along. If you know in advance that a run will legitimately exceed a limit (a planned bulk deprovisioning, a large onboarding batch), run a second Export Run Profile against the same Connected System with no limit set, and trigger it by hand rather than adding it to a Schedule. This gets the large, deliberate change through without touching the limited Run Profile that protects your regular scheduled runs.

Raising or clearing the limited Run Profile's own limit works too, but is the weaker option: it is easy to forget to put the limit back afterwards, and until you do, the safeguard is gone for every run that Run Profile makes, scheduled or not. A second, unlimited Run Profile kept out of Schedules cannot be forgotten in the same way, because it is never run except when you choose to run it.

Full Import

A Full Import Run Profile can carry a limit on how many Connected System Objects a single run's deletion detection may newly mark as deleted: Max detected deletions (a count) and Max detected deletions percent (a share, 0 to 100, of the Connected System Objects in the run's scope when it starts). Each is optional and independent; leave either blank for no limit, or set one to 0 to refuse to mark anything as deleted. Both are only valid on a Full Import Run Profile; setting either on any other run type is rejected.

A run that would exceed either limit marks nothing as deleted. JIM works out which Connected System Objects would newly be marked as deleted (excluding objects this run already saw, and objects already marked from an earlier run); if that count is more than Max detected deletions, or more than Max detected deletions percent of the Connected System Objects in scope, JIM marks none of them: every one stays exactly as it was. Objects the import did see are still created and updated as normal; only the marking of missing objects as deleted is withheld. There is no partial marking. The Activity for a refused detection completes as Complete with warning, naming the limit, how many objects were found missing and what share that is, and what to do next, and the Activity's detectedDeletionsWithheld counter records exactly how many were withheld (see Activities). Resuming needs no action beyond raising or clearing the limit, or fixing the Connected System's scope or the connector's filters, then running the Full Import again.

A refused detection also means the run does not count as a successful Full Import for the post-clear reconciliation gate: the Connected System's last successful Full Import time is not stamped, so the stranded-value sweep stays shut until a Full Import passes.

Recommended values: set Max detected deletions percent to a small share (for example, 5 to 10%) on a Full Import Run Profile against a large Connected System; a broken filter or base DN dropping a plausible-looking fraction of the population is easier to catch as a share than as a raw count. For a small Connected System, where a single genuine departure is already a large share of it, prefer Max detected deletions as a count instead: a percentage limit trips (or fails to trip) on rounding rather than on anything meaningful once the population is only a handful of objects.

Asynchronous execution

Triggering a Run Profile returns an activity ID. The actual work runs on the worker process and is monitored via activities. For long-running runs, polling the activity gives you live progress counters; the per-object execution items let you drill into individual failures after the fact.

Common workflows

Setting up Run Profiles for a new Connected System:

1. Create the Connected System and import its schema
2. Create the Run Profiles you need: a Full Import, a Full Synchronisation and an Export at minimum, since the first run has to look at everything rather than only what changes. Add delta variants for ongoing operation, and keep the full variants for periodic ground-truth refreshes.
3. Use the full variants to bring the Connected System in, in the order Initialising JIM sets out, before switching to delta; then either add the delta Run Profiles as steps to a schedule for automated execution, or run them on demand for one-off operations

Running a one-off import:

1. Find the right Run Profile for the Connected System
2. Execute the Run Profile and capture the returned activity ID
3. Watch the activity to monitor progress and inspect the result

Manage Run Profiles

• JIM portal
  Run Profiles tab on a Connected System in the admin UI
• PowerShell
  Run Profile cmdlets (Get-JIMRunProfile, New-JIMRunProfile, Invoke-JIMRunProfile, etc.)
• REST API
  Run Profile endpoints in the interactive API reference

See also

• Connected Systems -- Run Profiles belong to a Connected System
• Schedules -- automated execution of Run Profiles
• Activities -- monitoring Run Profile execution
• Concepts: Synchronisation Pipeline -- what each run type does in detail