What JIM solves.

When someone joins, changes role, or leaves, their access has to change across every system they touch, and doing it by hand is slow, inconsistent, and a standing security risk. Leavers keep access they should have lost; joiners wait days for the accounts they needed on day one.

JIM makes your HR system the source of truth for the identity lifecycle. A new starter gets accounts and entitlements wherever they're needed, automatically. A change of role re-flows the right access. A termination revokes it as soon as HR records it, across every downstream system in scope, not just the accounts JIM happened to create itself.

Inbound rules read joiner, mover, and leaver events from the authoritative source, whether JIM reaches it through its database, a SCIM 2.0 interface, or a file feed; Synchronization Rules project the resulting identity state out to every Connected System; and the built-in scheduler runs the cycle on whatever cadence you need, from near real-time to nightly, weekly, or longer. Each export rule carries a Deprovisioning Action, so you decide per system whether a leaver's account is disconnected, disabled, or deleted.

Authoritative data rarely lives in one place, and which system owns what varies from one organization to the next. HR might own the org structure, for example, while the email system generates the email address, the service desk mints the badge number, and finance assigns the cost center. Each of those values needs to find its way back to the systems that depend on it.

JIM writes data back to source systems as readily as it reads from them. Once a value is generated downstream (an email address, an account identifier, an employee number), JIM can return it to HR, or to any other system that should hold it, keeping the whole estate consistent.

Synchronization Rules are directional. The same engine that imports from a system can export to it, including back into the very Connected System an inbound rule reads from, so a value derived from HR data, such as an email address, can return to the HR record it was built from. Every write-back is under explicit, attribute-level control.

Entitlements are mastered in different places: a security group in the directory, a role in an application, a license group in your cloud tenant. The same access often needs to exist in several systems at once, and keeping them in step by hand means memberships drift, with access granted in one place never reaching the others that rely on it.

JIM treats groups as a first-class object type, alongside users. A membership mastered in one system is synchronized out to every other system that honors the same entitlement, so granting or revoking it in the system of record propagates everywhere it applies.

Groups and their memberships are imported into the Metaverse like any other identity data. Synchronization Rules then export those memberships to the Connected Systems that need them, adding and removing them as the source changes, so every target stays in step.

Mergers, acquisitions, and aging platforms leave you with the same people represented many times over, across many systems, with no agreement on which record is right. Migrating off a legacy identity platform usually means a risky big-bang cutover.

JIM fuses duplicate records from every system into one canonical identity in its Metaverse, with deterministic Attribute Priority deciding which source wins for each attribute. JIM's Identity as Code makes those configurations quick to develop and deploy, so you can migrate incrementally, running JIM alongside the platform you're replacing until you're ready to switch.

Object Matching correlates records across systems; the Metaverse holds the single fused identity; Attribute Priority resolves conflicts attribute by attribute. Identity as Code makes the whole configuration repeatable and reviewable, so a migration becomes a series of small, verifiable steps rather than one irreversible event.

The same person is 'jsmith' in the directory, 'john.smith@' in email, employee 4471 in HR, and a numeric identifier in the line-of-business app. Answering a simple question (is this all one person, and what do they have access to?) means manual detective work across systems that agree on nothing.

JIM correlates identities across every Connected System and gives you one joined-up view. Every Metaverse Object knows exactly which system records contributed to it, so 'who is this, everywhere' becomes a single lookup instead of an investigation.

Self-contained Object Matching Rules join records on the attributes that actually identify a person, and constant-time matching keeps that join fast even as the number of systems and objects grows. Full causality means every correlated value can be traced back to the system it came from.

A subsidiary, an acquisition, or a partner runs its own directory, and a handful of identities need to stay in step with the parent: a subsidiary Active Directory that should reflect the parent's joiners and leavers, a cross-domain boundary that needs selective synchronization. It is too small to fold into the central platform and too persistent to keep fixing by hand.

A dedicated Edge Sync instance synchronizes just those two directories, in just the directions you specify. It runs next to the systems it serves, owned by whoever owns that boundary, without touching the central identity fabric or waiting on it.

Both directories connect as Connected Systems over LDAP; Synchronization Rules project the chosen objects and attributes one way or both. The whole configuration is Identity as Code, so the next subsidiary is a parameterized copy of the first rather than a fresh build.

A line-of-business application needs a current, accurate feed of who works here: a roster, a set of accounts, the right group memberships. Today someone exports a spreadsheet and imports it by hand, or a brittle script does it on a schedule and breaks quietly when nobody is looking.

An Edge Sync instance owns that one feed. It reads from the authoritative source and keeps the application populated automatically, on whatever cadence the application needs, with none of the scope or ceremony of a central deployment.

The source and the application become Connected Systems, reached over SQL, SCIM 2.0, LDAP, or a file, whichever each one offers; a Synchronization Rule maintains the feed and removes access when it should lapse. Templated as Identity as Code, the same pattern serves the next application with a configuration change rather than a rebuild.

Contractors, temporary staff, and other non-employees rarely live in the HR system that drives everyone else. They arrive, need access, and (more importantly) need it removed the day they leave, but the authoritative record for them is a separate list the central lifecycle never sees.

A focused Edge Sync instance treats that separate list as its source of truth and drives the joiner and leaver lifecycle for just that population, so non-employees get the access they need and lose it on time, without waiting to be modeled in core HR.

The non-employee source is a Connected System; inbound rules read arrivals and departures; Synchronization Rules grant and revoke downstream, with a Deprovisioning Action per system deciding whether a departure disables the account or removes it outright. Built as Identity as Code, the instance is version-controlled, auditable, and reproducible like the rest of your infrastructure.

Some identity data cannot be pooled. A regulated business unit, a jurisdiction with data-residency rules, or a security boundary may forbid a population's attributes from flowing into a single organization-wide store at all.

Edge Sync turns that constraint into a deployment choice. A dedicated instance synchronizes the regulated population in isolation, inside the boundary, so the data is governed where it has to stay rather than centralized and then carved back out again. This is data sovereignty as a deployment property, not a contractual promise: the regulated attributes never leave the boundary or the jurisdiction that governs them, and no external platform ever sees them.

The instance runs container-native within the boundary, connects only the systems inside it, and shares nothing with the central fabric. Identity as Code keeps its configuration version-controlled and auditable, which is exactly the evidence a regulated boundary has to produce.

Replacing a legacy synchronization platform usually means a big-bang cutover: scope the whole estate, rebuild every rule, parallel-run, and switch everything at once. It is high-risk, and it asks you to trust a new platform across your entire estate before you have seen it run.

Edge Sync lets you start with one workload instead. Stand JIM up against a single bounded problem your current platform handles badly, prove it in production while the old platform keeps running, then add workloads one at a time and complete the central migration only when JIM has earned it.

Each workload is its own templated Edge Sync deployment, built and promoted as Identity as Code. Because every instance is the same product you will eventually run centrally, the final cutover is the picture completing rather than a leap of faith.