Filters are NIM's "workhorse" feature. All previous steps in the workflow exist, essentially, only to support filters.

To get started, Create a filter.


Creating filters in NIM is very similar to building queries in SQL.

Filters apply logical criteria to narrow down your current Vault contents. Thus, a filter's output represents a dynamic subset of data in the vault. Then, each subset becomes the input of a single provisioning function in a target system, via Mappings. By creating combinations of filters and mapping functions for each target system, you progressively build up the logic to automate your organization's entire provisioning lifecycle.

For example, you could create a filter X that returns all users with an account in system Y, but no account in system Z. (This filter would likely use with no logic.) You could then assign this filter to a mapping function that creates users in system Z. This filter might initially return 25 users. The first time the mapping is executed, accounts for those 25 users will be created in system Z. On subsequent mapping executions, the filter will return empty results, and the mapping will do nothing—until more users are added to system Y. And so on.

This example illustrates the "dynamic" nature of filter output. A filter's configuration remains constant. Only its output varies—dynamically—with its input. Thus, filters are the basis of NIM's soll-ist engine.

Filters are not only used with mappings. They are also used with roles, name & password generators, and other objects which require data from the vault.

Invalid filters

Invalid filters are underlined in red:


These filters return invalid output until you reconfigure them. Until then, other objects that use them (e.g., mappings) will fail.

To help debug an invalid filter, use the Validation tools.


If all your filters are marked as invalid, your license key may be expired. See License.