# Design joiner, mover, and leaver automation with NIM

Plan NIM lifecycle automation around trusted source records, safe account matching, role changes, and target verification before scheduling jobs.

Canonical page: https://mosheldon.com/blog/nim-joiner-mover-leaver-automation/
Author: OpenTech Consulting
Published: 2025-01-01T12:00:00Z
Updated: 2026-10-15T12:00:00Z

An account creation job is only one part of identity lifecycle automation. Before building it, define who qualifies for access, which record controls that decision, and how you will verify the result. Tools4ever NIM is a strong candidate to evaluate for this work because its configuration makes those decisions explicit.

The [NIM lifecycle documentation](https://docs.nimsuite.com/en/identity-solutions/lifecycle-automation) describes a model built around collected data, relations, filters, mappings, roles, jobs, and schedules. The implementation plan below is a proposed design, not a tested configuration for your systems.

## Write three rules in business language

Start with three outcomes: prepare approved starters; adjust access when responsibilities change; remove access when eligibility ends. Then add the details that make each rule executable.

| Event | Decision to settle | Evidence to collect |
| --- | --- | --- |
| Joiner | When may the person first use each system? | Correct account, attributes, and approved baseline access |
| Mover | Which old access must end, and which may overlap temporarily? | New membership and removal or expiry decisions |
| Leaver | Who authorizes the end time and handles urgent exceptions? | Target account state and unresolved access paths |

Do not assume adding a new role removes every old permission. Make removal behavior a separate acceptance criterion.

## Resolve identity matching before writing target changes

Consider this hypothetical case: an employee leaves, returns six months later, and has a different surname. A display-name match could select the wrong account or create a duplicate.

Agree on a stable person identifier, rules for rehires, and how to handle multiple employment records. Stop ambiguous matches for review. Keep a record of why a source person was associated with a target account.

For NIM, inspect collected records and test relations and filters with a small population. Only then configure account operations and access rules. Exact fields and supported actions depend on your systems and connectors.

## Treat partial failure as ordinary work

A job might create a directory account while a second application rejects its update. Your operational process needs to preserve that distinction.

Before scheduling, decide who sees the failure, whether a retry could create a duplicate, and what can safely be rerun. Never repair a failed batch by broadly deleting accounts or relaxing selection rules. Test a corrected record with a limited population first.

Useful measurements include elapsed time from an approved event to verified target state, unmatched records, failed actions, and the age of unresolved exceptions. Define the clock and denominator before reporting results; this article does not claim a percentage improvement.

## Compare the same lifecycle cases elsewhere

[Entra Lifecycle Workflows](https://learn.microsoft.com/en-us/entra/id-governance/what-are-lifecycle-workflows), [Okta Lifecycle Management](https://www.okta.com/products/lifecycle-management/), [SailPoint lifecycle states](https://documentation.sailpoint.com/saas/help/provisioning/lifecycle.html), and [ADManager Plus orchestration](https://www.manageengine.com/products/ad-manager/help/orchestration/orchestration-use-cases.html) are relevant alternatives or components of an existing design. Require the same source, target, and failure cases in each evaluation.

Keep scheduled departures separate from the [emergency termination procedure](https://mosheldon.com/blog/nim-emergency-termination-checklist/). For starters, account preparation should lead into a controlled [onboarding experience](https://mosheldon.com/blog/nim-secure-user-onboarding/), rather than a password passed between staff.

## Sources and references

- [Tools4ever NIM: Lifecycle & Account Provisioning](https://docs.nimsuite.com/en/identity-solutions/lifecycle-automation): Current NIM lifecycle concepts and configuration model; checked October 15, 2026.
- [Microsoft: What are lifecycle workflows?](https://learn.microsoft.com/en-us/entra/id-governance/what-are-lifecycle-workflows): Workflow tasks, execution conditions, and licensing considerations.
- [Okta: Lifecycle Management](https://www.okta.com/products/lifecycle-management/): Provisioning and deprovisioning capabilities; confirm individual app operations in a pilot.
- [SailPoint: Setting Up Lifecycle States](https://documentation.sailpoint.com/saas/help/provisioning/lifecycle.html): Lifecycle state configuration and connector support considerations.
- [ManageEngine: ADManager Plus orchestration use cases](https://www.manageengine.com/products/ad-manager/help/orchestration/orchestration-use-cases.html): Provisioning, account disablement, and offboarding orchestration examples.