Skip to main content

Processing

Identity data processing

Turn current Vault data into clear, reusable decisions that mappings, roles, jobs, and reports can act on.

Processing sits between Systems and Output. It does not directly provision accounts. Instead, it connects, selects, shapes, and generates the values that output workflows use to make supported changes in target systems.

Choose the tool for the jobDirect link to Choose the tool for the job

A typical processing pathDirect link to A typical processing path

  1. Collect systems and verify their current data in the Vault.
  2. Create inter-system relations when a workflow must connect data across systems.
  3. Build a filter that returns exactly the records the workflow should process.
  4. Add a name or password generator when the target mapping needs a derived username, email address, or initial credential.
  5. Send the validated filter output into mappings, roles, exports, or notifications.
Start with a filter you can explainA filter is the reusable decision point in most NIM workflows. Give it a clear name, test its output with representative records, and keep its criteria focused before using it in a mapping or role.

How processing tools work togetherDirect link to How processing tools work together

ToolInputOutputCommon use
Inter-system relationKeyed records from two systemsA usable cross-system relationshipMatch employees to existing directory accounts.
FilterCurrent Vault data and optional relationsA selected, shaped set of recordsFind active employees without a target account.
Name generatorFilter columnsOne or more generated target valuesCreate a unique username or email address.
Password generatorOptional filter columns and password rulesA generated password valueSet an initial password during account creation.

Before using processing output in productionDirect link to Before using processing output in production

  • Confirm the source data is current and the required tables, columns, keys, and relations are configured.
  • Test filters with records that should match, should not match, and represent edge cases such as missing data.
  • Review generated values for collisions, prohibited characters, and target-system requirements.
  • Test a single mapping operation before scheduling a job that creates, updates, or removes many records.
tip

If data is correct in a system table but missing from a filter, inspect the filter’s start table, expressions, relations, and column exclusions before changing the mapping that consumes it.

Next stepDirect link to Next step

Most implementations begin with Filters. When the filter output is correct, continue to Output to map the result to target-system changes.