# NIM

### Filters

Filters are NIM's "workhorse" feature. Almost everything you do in NIM is accomplished using filters.

To get started, Create a filter.

A filter applies logical criteria to your current Vault data, in order to produce a subset of that data. Then, that subset—the filter's output—becomes the input for a different object in NIM, which performs some action with it. Most importantly, filters provide the input for functions in Mappings, members for Roles, and reports inside Notification templates. Filters can also be used with Export tasks and Multi-export tasks to produce CSVs for downstream consumption outside of NIM.

Since filters operate on data in the vault, a filter's output changes as the contents of the vault change. For example, suppose you create a filter that returns all user accounts in system X. As accounts are added or removed from system X (and system X's data is collected and thus refreshed in the vault), the filter's output changes accordingly.

The true power of filters, however, is joining tables from different Systems. This is possible due to the universal format of the data in the vault. You do this with Relation items. For example, suppose you create a filter that returns all users with an account in system X, but no account in system Y. (This relation item would likely use with no logic.) You could then feed this filter into a user create mapping function for system Y. This filter might initially return 25 users. The first time the mapping is executed, accounts for those 25 users will be created in system Y. On subsequent executions, the filter will return empty results, and the mapping will do nothing—until more users are added to system X. And so on.

Using filters in this way, you can progressively automate your organization's entire provisioning lifecycle. You aren't limited to user accounts; you can work with any type of resource supported by the Connectors of the involved systems. This is dynamic provisioning. Based on rules defined in filters, changes in source systems automatically trigger NIM to provision changes into target systems. Most of the work is front-loaded. After you've built up your provisioning rules using filters, mappings, and other features in NIM, it runs by itself. You only intervene when you need to change the rules.

Although mappings and roles are the most important ways in which filters are used, they are not the only ways. Almost every feature in NIM relies on filters in some way. The bottom line is: the data in the Vault is the foundation of NIM, and filters are how you use that data.

### Tip

NIM's filters operate on the same basic principles as queries in SQL.

#### 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.