Everything JIM does, in one place.

At the core of JIM is a synchronisation engine built on the Metaverse pattern. Connected Systems import into a central hub, where Connected System Objects are matched and fused into a single canonical Metaverse Object, then exported to the systems that need them.

Imports can be full or delta, so large estates only move what changed. Attribute Priority deterministically decides the agreed value for every attribute, and Pending Exports let you review what JIM is about to change before it touches a target.

Leaving is handled as deliberately as joining. When an identity is deleted or falls out of a rule's scope, each export Synchronisation Rule's Deprovisioning Action decides what happens to the downstream account: disconnect it, disable it, or delete it. That applies to every account the rule covers, whether JIM provisioned it or matched one that already existed.

• Bidirectional sync of Users, Groups, and custom object types
• Full and delta imports
• Deterministic Attribute Priority across systems
• Object Matching Rules join records into one identity
• Pending Export review before anything is written
• Per-rule Deprovisioning Action for leavers and out-of-scope identities

Most synchronisation tools tell you what happened after a run. JIM also tells you what a change would do before you commit it. Edit a Synchronisation Rule's Scoping Criteria or Attribute Flow, change an Object Matching Rule, deselect a Container, or refresh a schema, and a Configuration Change Preview reports, object by object, what would enter or leave scope, which values would change, which accounts would be deprovisioned, and which Metaverse Objects would become eligible for deletion. Nothing is changed until you save.

Sync Preview asks the same question of a single object: what would synchronising this Connected System Object or Metaverse Object do, end to end, including every downstream account it would deprovision? Previews are available in the portal, through the REST API, and from PowerShell, so a change can be checked in a pipeline before it is applied.

Guard-rails catch what a preview does not. Run Profile Safeguards cap how many creates, updates, and deletes an export may attempt, and how many deletions a Full Import may newly detect, so a broken filter or mistaken rule change warns instead of making mass changes. A destructive schema refresh stops and asks what to do rather than committing silently, and a Metaverse Object can wait until every authoritative source has gone before it is deleted, so one source failing or being rebuilt cannot trigger deletions.

• Configuration Change Preview before you save
• Sync Preview for any single object
• Run Profile Safeguards cap mass creates, updates, and deletes
• Destructive schema refreshes pause for a decision
• Deletion can wait for every authoritative source to go
• Portal, REST API, and PowerShell

JIM ships a sensible default schema, but not a fixed one. Administrators create, rename, re-icon, and delete their own Metaverse Object Types, and create, edit, and bind their own Metaverse Attributes. No vendor involvement, and no professional-services engagement to model the identities your organisation actually has.

Everything you can do in the portal you can also do through the REST API or the PowerShell module, so schema is part of Identity as Code like the rest of a deployment. Destructive changes are guarded rather than merely warned about: deleting a Metaverse Object Type is refused while Metaverse Objects still hold values or Synchronisation Rules still target it, and configuration-only references are cascade-removed behind a type-the-name confirmation. Every schema change is audited.

Built-in Metaverse Attributes also carry recorded Standard Mappings to their SCIM 2.0 and LDAP/Active Directory counterparts, with notes wherever the correspondence needs care, so you can see at a glance which attribute to target when connecting a directory. You can record your own mappings on custom attributes.

The Data Flow view draws the whole picture together: every Attribute Flow across every Connected System, in both directions, so you can see where each Metaverse Attribute's value comes from and what writes it back out.

• Custom Metaverse Object Types beyond Users and Groups
• Custom Metaverse Attributes, bound to the types that need them
• Portal, REST API, and PowerShell: the same control on all three
• Guarded deletion, with configuration-only references cascaded
• Standard Mappings to SCIM 2.0 and LDAP/AD counterparts
• Data Flow view of every Attribute Flow, in both directions
• Every schema change audited

When a plain copy is not enough, JIM's expression language transforms values as they flow. Reference attributes like spreadsheet cells, combine them with operators and built-in functions, and JIM evaluates the result for each object during synchronisation. No programming experience required.

Expressions drive Attribute Flow, conditional logic, and scoping filters inside Synchronisation Rules: build an email address from a name, set account state from employment status, or skip objects that fall out of scope.

Expressions are checked before they reach a directory. Test one where you write it, with a box for each attribute it reads, and catch a malformed result before the Synchronisation Rule is saved. Each expression also decides what happens when an attribute it reads has no value: evaluate anyway, contribute nothing, or fail, so a missing surname never becomes a malformed email address in a target system.

// Build an email address from first and last name
Lower(mv["First Name"]) + "." + Lower(mv["Last Name"]) + "@company.com"

// Enable or disable an account based on employee status
IIF(Eq(mv["Employee Status"], "Active"),
    EnableUser(cs["userAccountControl"]),
    DisableUser(cs["userAccountControl"]))

// Use the preferred name if set, otherwise fall back to the first name
Coalesce(mv["Preferred Name"], mv["First Name"])

JIM ships a modern web portal for configuration, monitoring, and day-to-day administration. Everything you can see, you can also drive headlessly: the same platform exposes a full REST API.

The API carries an interactive Scalar reference, and scoped API keys let you script JIM into your own tooling and pipelines. Administrators sign in through Single Sign-On.

• Web admin portal
• Full REST API
• Interactive Scalar API reference
• Scoped API keys
• Single Sign-On via OpenID Connect

A built-in scheduler runs synchronisation on cron or interval triggers, with multi-step Run Profiles that execute sequentially or in parallel. Set it once and JIM keeps every system in step on whatever cadence you need, from near real-time to nightly.

Every Schedule keeps a record of how its runs ended. Each Schedule Execution shows every step with its outcome, its duration, and a link to the Activity it produced, so a failed overnight run no longer has to be pieced together the next morning.

Every part of JIM is configurable through a cross-platform PowerShell module, so entire deployments become Identity as Code: repeatable, version-controlled, and auditable. Templated edge deployments and incremental migrations become genuinely practical.

• Cron and interval schedules
• Sequential and parallel Run Profiles
• Step-by-step Schedule Execution history
• Cross-platform PowerShell module
• Identity as Code (IDaC)

JIM can give the accounts it provisions their first password, set a password on demand, and deliver one person's password change to every Connected System configured to receive it. It is one Set Password operation, the same in the portal, the REST API, and PowerShell. Today it reaches directories through the LDAP Connector: Active Directory, Samba AD, OpenLDAP, and 389 Directory Server.

Delivery is decoupled from synchronisation. Each change is queued encrypted, once per Connected System, and sent by a dedicated Password Delivery Service, typically within about a second, so one unavailable system never holds up the others. An unreachable system is retried; a system that refuses a password has the change parked with its own words for why, rather than retried forever. JIM reads each directory's password policy, so a password it generates meets the rules the target will enforce, and a read-only check confirms encryption, mechanism, and permissions before anything is sent.

Passwords are handled as secrets, not data. No page, API response, cmdlet, log, or Activity will show one, and every attempt is recorded, so 'was this person's password ever set there, and if not, why not?' always has an answer.

• Initial passwords for newly provisioned accounts
• One Set Password operation across portal, REST API, and PowerShell
• Queued encrypted and delivered per Connected System
• Retries for unreachable systems, parking for refusals
• Password policy discovered from AD, OpenLDAP, and 389 Directory Server
• Never displayed; every attempt recorded

JIM is secure by default. Administrators sign in through your own identity provider over OpenID Connect, so there are no shared service accounts to manage. Sensitive data is encrypted at rest with AES-256-GCM.

Fine-grained roles govern who can do what inside JIM, and every release ships signed with an SBOM attestation. Every dependency, transitive ones included, is locked to an exact version, so a build is reproducible and tamper-evident from source through to container image. The whole platform runs fully offline, so it is at home in air-gapped and regulated environments.

Credentials get the same care. Attributes that hold credential material, such as unicodePwd and userPassword, cannot be imported or flowed as ordinary identity data, so passwords never land in the Metaverse or its change history. LDAPS certificates are always validated before credentials are sent; that check cannot be switched off, so a directory using a private certificate authority is trusted explicitly from the portal instead. Endpoints that accept a password refuse any request JIM cannot confirm arrived encrypted.

• OIDC SSO with any compliant provider
• AES-256-GCM encryption at rest
• Role-based access control
• No shared service accounts
• Credential attributes kept out of identity data
• LDAPS certificates always validated
• Signed releases with SBOM attestation
• Reproducible, dependency-locked builds
• Air-gap ready

Every operation JIM runs is recorded as an Activity: what changed, when, and as part of which run. And because every value flows through the Metaverse, JIM can trace each attribute back to the system and the rule that set it.

Per-object history shows how an identity reached its current state, attribute by attribute, with every value change recording the Synchronisation Rule that contributed it. Any change can be walked back to its root cause: an export links back through the synchronisation that decided it and the import that started it, even when those ran days earlier. Together that answers 'why is this value what it is?' for any identity, which is exactly what auditors and regulators expect to see.

It all comes together in the causality panel on each Run Profile Execution Item. It opens with a plain-English summary, then offers three views of the same story. Lineage, the default, traces an outcome from its source records through the Metaverse Object to every target, and back to the root cause. Timeline reads top to bottom, with each attribute change shown inline. Table lists every change flat, to filter and sort. Every object involved is a link, and the story still reads correctly after those objects are renamed or deleted. Sync Preview uses the same Timeline and Table views, so what did happen and what would happen read the same way.

Deletion decisions get the same treatment. When JIM decides whether to delete an identity, the reason is explained from the facts recorded at the time, so the explanation stays accurate after the rules change.

Access to JIM is audited alongside the work JIM does. Administrator sign-ins and API key authentication attempts land in the same Activity log, with failed attempts aggregated by key, IP, and reason so the trail stays bounded under credential-spraying, and with their own configurable retention period.

• Full audit log via Activities
• End-to-end causality tracking
• Causality panel with Lineage, Timeline, and Table views
• Per-object change history
• Every change tied to a run and a rule
• Causal chain from any export back to its root cause
• Deletion decisions explained from recorded facts
• Sign-in and API key authentication auditing

JIM is built to run real estates. The pipeline is validated at 500,000 users and 25,000 groups, including groups of up to 495,000 members, with bounded memory throughout: a Full Import of 210,000 objects completes in around eight minutes. Delta imports keep large, frequent runs cheap, and in the event of an unrecoverable error workers resume cleanly from where they left off.

Progress is pushed, not polled. PostgreSQL notifies JIM's services the moment work changes state, and that reaches the browser live, so a Run Profile execution advances in front of you with throughput and an estimated time remaining rather than refreshing on a timer. Multi-step schedules step forward near-instantly instead of waiting on a polling cycle, and the same live progress is available in the terminal, so you can watch a half-million-object run from wherever you work.

Every run shows its whole journey as numbered steps, including the connector's own, so a long but healthy phase can be told apart from a stuck one. Service Health shows whether JIM's background services are alive, what each is doing, and which version it runs, with a portal-wide banner for administrators if one stops or stalls, and a single overall status for your monitoring scripts to alert on.

• Validated at 500,000 users and 25,000 groups
• Groups of up to 495,000 members
• Bounded-memory pipelines
• Delta imports for large estates
• Resumable workers
• Live, step-by-step progress with throughput and time remaining
• Service Health for JIM's background services