Skip to content

Execution Items

For Run Profile activities, JIM stores a per-object record of what happened (with any error details) for the most recent run. These let you go from a high-level error counter to the specific Connected System Objects that failed and the reason for each failure. Execution items are the right place to look when diagnosing why a particular identity didn't sync as expected.

The Lineage, Timeline and Table views compared An execution item's story can be read in three views. The Lineage, the default, shows the object graph as columns, answering what happened and why on one canvas, and is the one view that shows what the item went on to cause in later runs. The Timeline is a vertical narrative with attribute changes inline, for the whole story in one scroll. The Table is a flat, filterable change list, for scanning many changes at once. The Timeline and Table describe the run alone. The view you choose is remembered for your next visit. Lineage the default Timeline top to bottom Table filter chips, sortable columns Shows the object graph, as columnssource to MetaverseObject to target a vertical narrativeattribute changes inline a flat, filterable change listnarrowed object by object Best for what happened and whyon one canvas the whole story,every attributein one scroll scanning manychanges at once After this run what the itemwent on to cause this run alone this run alone The view you choose is remembered for your next visit The Lineage, Timeline and Table views compared An execution item's story can be read in three views. The Lineage, the default, shows the object graph as columns, answering what happened and why on one canvas, and is the one view that shows what the item went on to cause in later runs. The Timeline is a vertical narrative with attribute changes inline, for the whole story in one scroll. The Table is a flat, filterable change list, for scanning many changes at once. The Timeline and Table describe the run alone. The view you choose is remembered for your next visit. Lineage the default Showsthe object graph, as columnssource to Metaverse Object to target Best forwhat happened and whyon one canvas After this runwhat the item went on to cause Timeline top to bottom Showsa vertical narrativeattribute changes inline Best forthe whole story, every attributein one scroll After this runthis run alone Table filter chips, sortable columns Showsa flat, filterable change listnarrowed object by object Best forscanning many changes at once After this runthis run alone The view you choose is remembered for your next visit

An execution item's detail page is split over tabs. Overview carries the item's own story: the execution summary, the Connected System Object it processed, the causality panel and what caused it, and any error. Where the item created or failed on a Pending Export, that gets its own Pending Export tab, because a queued export is a separate subject with its own status, retry count and staged attribute changes. Most items have only the one tab, and the tab bar is hidden entirely in that case rather than offering a choice of one.

The Overview tab opens with a causality panel that answers "what happened to this object, and what did it cause?" without any digging. A summary band leads with a single plain-English sentence describing the run's effect on the object, with every entity mentioned (Connected Systems, Metaverse Objects, Synchronisation Rules) highlighted as a clickable token, and a strip of colour-coded outcome pills beneath it summarising the outcomes at a glance (for example "Projected to the Metaverse", "11 attributes flowed", "Export queued").

Below the summary, the story can be explored in switchable views; the view you choose is remembered for your next visit:

  • Lineage
    The default: the object graph itself, as columns. A story is at most four columns wide however many systems it involves: the Connected System Objects on the source side, the Metaverse Object, the Connected System Objects on the target side, and a trailing column for anything JIM could not place. The columns are joined by the relationships between them (imported, projected, joined, provisioned, exported, disconnected), reading source to Metaverse Object to target; where a side holds several Connected System Objects the label states only what is true of all of them, so it reads "provisioned" when every one on that side was created, "disconnected" when every one was disconnected under a Disconnect Deprovisioning Action, and "exported" otherwise. Each object is a panel of its own carrying its name, its Connected System and every causally relevant event that happened to it, so a side holding several Connected System Objects still reads as several stories. The view says what happened rather than what is true now, so an object's head names it and nothing more. Where a Metaverse Object was deleted after the run being viewed, the card for that deletion appears beneath the object's events, after them because that is when it happened (What it went on to cause); a deletion the run itself performed is not restated there, since the event that recorded it already links the record. An object JIM cannot open a page for says so on hover instead, because that is a different thing and does not mean the object is gone. This run's own events stand out with an accent ring and a This run marker, while events from earlier runs render subdued beneath them, each carrying the kind of run that recorded it and a link to that run's own execution item. Every card, from this run or an earlier one, carries a small coloured operation marker naming what it did (Created, Updated, Deleted, Joined), so you can see what happened in every column at a glance without reading each sentence in turn. An Export queued card carries the marker only where the run recorded the staged kind at the time; a run from before that was captured shows none, exactly as any other outcome recorded before its marker existed. Where the Metaverse Object's own creation happened on an earlier run than the one you are viewing, the Metaverse Object column states that too, rather than sitting empty because the item that created it lies further back in the chain. Every card says when it happened, relative to now, with the exact date and time on hover. One canvas answers "what happened and why".
  • Timeline
    A vertical narrative read from top to bottom, with attribute change detail expanding inline beneath each event. Useful when you want the whole story, every attribute included, in one scroll.
  • Table
    A flat, filterable change list, better suited to scanning many changes at once than either canvas view. A left-hand navigation lists every object the run touched (the object being synchronised, the Metaverse Object, and any downstream objects it reached), each with a severity dot and a count of the changes recorded against it; an Everything entry at the top flattens every object into one list, adding a leading Object column so a row's owner is never ambiguous. Selecting an object narrows the grid to its own rows: an object-level fact first (leaving scope, joining or being created, disconnecting, being deleted or deprovisioned, provisioned, an export queued, a value cleared or preserved), then that object's individual attribute changes. An event with more than ten attribute changes, such as a change to a large group's membership, is listed as one row giving how many values were added, removed and set, with View all, which opens the event's attribute changes in a scrolling list you can search and filter. Filter chips narrow further by change kind (Scope & Join, Attribute changes, Object changes, Destructive), and every column header sorts. Values render in a fixed-width face so old and new line up, with a removed value struck through and a destructive or constructive change coloured accordingly. The same view works on a Sync Preview: its columns read Current and Would be instead of Before and After, since nothing has happened yet.

The same layout serves every kind of item by lighting a different object: an import lights the source Connected System Object, a synchronisation lights the Metaverse Object (and any target Connected System Objects it staged exports for), and an export lights the target Connected System Object. On a narrow screen the columns stack vertically.

Every event is named once, in the same vocabulary as the rest of the portal (for example "Projected to the Metaverse", "Joined to Metaverse Object"): there is no separate technical vocabulary and no toggle to switch to it. Attribute change detail is built for scanning: each change carries a Set, Add or Remove operation badge and a monospace value (with the previous value struck through where one existed), and a search box plus count-annotated filter chips narrow large change sets quickly.

Everything mentioned links to its detail page: Connected Systems, Connected System Objects, Metaverse Objects, Synchronisation Rules and Pending Exports are all one click away. A Pending Export outcome links to the individual Pending Export it created, not to the target Connected System's whole queue, which matters on a deprovisioning cascade where that queue can hold thousands of rows. Destructive outcomes keep their story even after the object is gone: when a disconnection triggers a Metaverse Object Deletion Rule, the resulting Metaverse Object deleted or Metaverse Object deletion scheduled event shows the deleted Metaverse Object's display name (captured before deletion), why the Deletion Rule fired (for example "last connector disconnected"), the grace period for scheduled deletions, and a link to the deletion record browser, so the full story of a deleted Metaverse Object survives the deletion itself. View deletion record opens that object's own change history directly, rather than the unfiltered browser, and a Connected System Object deleted event offers the same link for the Connected System Object that was removed.

When a Connected System Object joins an existing Metaverse Object through an Object Matching Rule, its Joined to Metaverse Object event says what the join rested on: the value it matched on and what the rule compared, for example Matched on "48213", where Employee ID equals employeeNumber. JIM records both when it makes the join, so they stay accurate after you edit or delete the rule. Joins recorded by v0.16.0 or earlier carry neither. The REST API and Get-JIMActivityExecutionItem return the same facts.

When a reconnection cancels a scheduled deletion (see Grace period), the rejoining Connected System Object's Joined to Metaverse Object event carries a Metaverse Object deletion cancelled child naming the system that rejoined, when the deletion had been due, and the Deletion Rule that permitted the cancellation, so an administrator can see why the Metaverse Object survived a deletion the Lineage shows was scheduled.

The deletion rule context shown on the detail page is recorded when the decision was made, not looked up from today's configuration: the rule, the trigger mode, the selected authoritative sources, the grace period, the system whose disconnection triggered the evaluation, which sources were still connected at that moment, and the date a scheduled deletion becomes due. It therefore stays accurate after an administrator edits the object type's deletion rules, and it is recorded even when a listed source disconnected but the trigger mode decided not to delete, so "why was this NOT deleted" is answerable too. For a grace period deletion, the context carried on the final housekeeping deletion record is the one captured when the deletion was scheduled. Records written before this capture existed fall back to showing the object type's current configuration, labelled as such.

How much detail the panel can show depends on the ChangeTracking.SyncOutcomes.Level Service Setting (None, Standard or Detailed): lower levels record fewer outcomes and less attribute detail for each execution item.

Deleting a Metaverse Object also has downstream consequences, and those are reported too. Each account queued for removal by an export Synchronisation Rule's Deprovisioning Action appears as a Deprovision queued outcome nested beneath the Metaverse Object deleted outcome that caused it, naming the Connected System the account is being removed from and the export Synchronisation Rule whose Deprovisioning Action said Delete, so the tree shows the deletion and everything it set in motion in one place. Each account the deletion left in place, because its rule's Deprovisioning Action is Disconnect, appears beneath the same outcome as Disconnected from target system, naming that rule: the account still exists in its Connected System, but JIM no longer manages it, and nothing is exported for it. Membership removals staged on groups that referenced the deleted Metaverse Object are reported separately, as their own Pending Export execution items (the referencing group is a different object, with no execution item of its own on the run); each is named after the group concerned and records its Connected System Object's external ID and object type, so it stays readable long after the objects themselves are gone. Both are counted in the Activity's Pending Exports total.

A queued deprovision is distinguished from an ordinary Export queued because the two look alike in the data but mean opposite things. A staged delete carries the target's identifying attribute (its distinguished name, for a directory) so the connector can still find the entry after the Connected System Object has been disconnected from its Metaverse Object; without the distinction that payload was reported as an attribute change, and an account being removed read as an account having one attribute set. Expanding a Deprovision queued outcome therefore shows those values under Target identified by rather than as a change count: they are how the Connected System Object will be located, not something being written to it.

Some accounts never reach a target Connected System before they leave. If a Metaverse Object's deletion, or an object leaving an export Synchronisation Rule's scope, catches a Connected System Object still Pending Provisioning with an unsent Create Pending Export, nothing exists yet in the target system to delete; JIM cancels the provisioning outright instead of deprovisioning it. This appears as a Provisioning cancelled outcome nested beneath the Metaverse Object deleted outcome for a deletion, or on the execution item of the object leaving scope, naming the Connected System the cancelled provisioning targeted. Unlike Deprovision queued, nothing is exported (there is no Pending Export to send), so it is not counted in the Activity's Pending Exports total.

An Export Review, the re-check that a change to an export Synchronisation Rule, or to a Metaverse Object outside synchronisation, triggers, records an execution item per Metaverse Object it changed. Its operation is Export Review, and because there is no Connected System Object behind it, the item's page names and links the Metaverse Object instead, marked as deleted if it has been deleted since. Its causality panel starts from the Metaverse Object too: the Lineage begins with it, followed by the accounts the review provisioned, deprovisioned or disconnected. The REST API and Get-JIMActivity -ExecutionItems return its id as metaverseObjectId. Review items recorded by v0.16.0 or earlier show no operation and no Metaverse Object.

An object leaving an export Synchronisation Rule's scope where the rule's Deprovisioning Action is Disconnect is reported as a Disconnected from target system outcome on its execution item: the account stays in the target Connected System, but JIM no longer manages it. The outcome names the Connected System, links the account and names the rule whose Deprovisioning Action left it in place; a Deprovision queued outcome likewise names the rule that queued the delete. Nothing is exported for a disconnection, so it is not counted in the Activity's Pending Exports total either. It is distinct from Disconnected, which means the execution item's own Connected System Object was disconnected from its Metaverse Object.

Changes already queued for a target Connected System can become unnecessary before they are exported: a value changed and then changed back, or a mapping corrected after a run staged updates from it. When a synchronisation finds the target already holds the value the Metaverse Object now wants, it withdraws the queued change rather than exporting it, and records a Pending Export changes withdrawn outcome on the item of the object whose change made it unnecessary. The outcome names the Connected System and links the account, counts the changes withdrawn, and expands to show the queued values under Withdrawn from the Pending Export. Nothing is lost: the account keeps the value it already holds, and any other change queued for it still exports. A queued change replaced by a newer one for the same attribute is not a withdrawal; the newer one is the Export queued outcome beside it. Nothing new is queued, so it is not counted in the Activity's Pending Exports total. Recalling values withdraws queued changes the same way, so deleting a Synchronisation Rule, deleting a Connected System through synchronisation, and the stranded value sweep record the same outcome on the item of each object whose values they recalled.

Applies to new runs

Outcomes recorded before this distinction existed remain as they were written, so a deprovisioning cascade on an older Activity still reads Export queued. Runs from this version onwards use the new outcome.

An object that leaves an import Synchronisation Rule's scope while the rule's Out-of-Scope Action keeps its join is recorded as Left scope, join kept, naming the rule whose scope it left and the Metaverse Object it stays joined to. Nothing flows from it and nothing it contributed is recalled, so nothing is nested beneath it. Activities recorded before this outcome existed show these objects as Attributes flowed instead, although nothing flowed, and count them in the Activity's Attribute Flows total; the Left scope, join kept filter chip on those Activities still finds them.

A Deletion Rule that evaluates and decides not to delete records nothing, because nothing happened, so the causality views show a Metaverse Object not deleted step on the Metaverse Object column with the reason beside it ("an authoritative source is still connected"). The rule that decided it is available underneath as Deletion Rule in force at the time, collapsed, and is the rule as it was recorded at the moment of the decision rather than the object type's current configuration.

Values JIM could not import

A Connector can find a value it cannot read as its attribute's type: a date that does not exist, letters in a number column, a decimal wider than JIM can hold. JIM can also be handed a value it cannot hold: two dates of one attribute less than a microsecond apart (JIM holds a date to the microsecond), or both true and false for a true or false attribute, which holds one value. Neither is treated as no value. The object's execution item lists every such value under Attribute Values Not Imported: each value as received, what its attribute expected, whether the Connector or JIM found it (Found By), and why it could not be imported. Where the Connector says where the object was read from, the item gives that too, and it also appears as Source in the Execution Summary: the File Connector gives the file and row, and the LDAP Connector the entry's distinguished name.

JIM leaves the attribute exactly as it already held it. Nothing is removed from the Connected System Object, so nothing flows on to the Metaverse Object or out to other Connected Systems. The rest of the object imports as normal, a new object is imported without the attribute, and the next import that can read the value applies it.

A whole number too large for its attribute. The reason reads Not a whole number JIM can hold (File, LDAP and SCIM Connectors): the value is sound, and the attribute's type is too small for it. Where the Connector lets you choose the type, as the File and SQL Connectors do, override the inferred type with a wider one. Where the Connector states the type itself, as the LDAP and SCIM Connectors do, correct the value in the Connected System or stop selecting the attribute.

When the value is an object's External ID, JIM cannot tell which object it is, so that Full Import does not check the Object Type for deleted objects, and the Activity says so: marking objects deleted on that basis could remove one the Connected System still holds. Checking resumes on the next Full Import that reads every External ID.

Causes and consequences

The Lineage reads beyond the run in both directions: up the chain to what caused the item, and down it to what the item went on to cause in later runs, each on the object it happened to. Causality explains both, including how each branch says where it ends.