Lockers act as a central identity store for entities of a single type. They act as a focal point for identities, which may be being provided by multiple source systems, to be consumed by one or more target systems. The locker is considered the center point of an entity's path between one connected system and another.

Use Cases

Other than just being a representation of all of the attached links to the locker, the locker can be a useful place to make logic decisions when used in conjunction with Filters. For example, by using a secondary locker and by filtering based on a field being set, a pre-provisioning task can be used to populate the filtered field with a value retrieved externally. This allows for built-in logic in the provisioning task to handle retries, as well as a central location to view which entities have been successfully assigned a value from the task.



Lockers initially require the following configuration:



NameThe display name of the locker. Should be descriptive of its purpose.
Object ClassThe type of object which the locker acts as the central entity repository for.
CommentA comment to be attached to the locker. Optional.


Lockers, like adapters, also require a schema to define the entities they store. The current locker schema is displayed on the locker details page.

To import an adapters schema, click the Request Schema button and select the desired adapter from the drop down menu. Partial schema can be imported by selecting or deselecting the check box beside each schema field. Click Continue with Schema to complete schema import.

Schema fields may also be added manually. To do so click Add Field, enter a field name and choose an attribute type. Click Continue with Schema to add the schema field.


Lockers have priority configuration to control how adapters update existing locker entity values during incoming synchronization. See the Priority page for more information on this topic.

Is this article helpful for you?