Deprovisioning rules are called in the following circumstances:
Deprovisioning rules are not called in the following circumstances:
Deprovisioning rules are configured when you create or modify a management agent by using Management Agent Designer. The options for deprovisioning rules are listed in the following table.
|Make them disconnectors||The disconnector object is subject to join and projection rules the next time you run the management agent. This is the default behavior.|
|Make them explicit disconnectors||The explicit disconnector object is not subject to the management agent's join and projection rules on subsequent runs. If you want to link this object to a metaverse object again, you must use Joiner.|
|Stage a delete on the object for the next export run||The object becomes an explicit disconnector and a delete operation will be staged for export to the connected data source. At the next export, the object will be deleted from the connected data source, and then the connector space object will be deleted during the next import. The metaverse object that the connector space object was linked to might now be subject to object deletion rules. For more information about object deletion rules, see Object deletion rules.|
|Determine with a rules extension||With this option, you can evaluate the connector space object before selecting an action to perform. After evaluating the object, you can make it a disconnector object, stage it for deletion, rename the object to a deleted objects container, or modify the object's attributes (for example, you can set a user account to disabled). For more information, see Rules extensions.|
For example, you have management agents configured to provision objects from connected data source A to connected data source B. The deprovisioning rule for management agent A is set to Make them explicit disconnectors, while the deprovisioning rule for management agent B is set to Stage a delete on the object for the next export run. When an object in connector space A then becomes disconnected, provisioning rules are called and the connector space objects from both connector space A and connector space B are disconnected. Deprovisioning rules are then called, and the object in connector space A becomes an explicit disconnector, and the object in connector space B becomes a deletion, staged for export.
The following flow chart shows the sequence in which management agent rules are applied.
By default, when a connector space object is disconnected from a metaverse object, all of the attribute values that the connector space object contributed to the metaverse object are recalled from the metaverse object. If there are any Import Attribute Flow rules for these attributes configured on other management agents who have connector space objects linked to this metaverse object, these will be evaluated in order according to the attribute precedence settings to repopulate the metaverse with values for these attributes. The rules engine will process all of the connector space objects until the attributes are repopulated or the available connector space objects are exhausted.
However, there are certain scenarios where you would need the attribute values to remain in the metaverse, even though the source for those attribute values has been disconnected. For example, you might import user accounts from one directory in order to populate another directory. After the initial migration, you delete the accounts from the source directory. By default, the objects in the source connector space are disconnected, and the attributes contributed by them are recalled from the linked metaverse objects. By selecting the option in the Management Agent Designer to not recall attributes upon disconnection, the objects can be safely disconnected in the source connector space without affecting the attribute values in the metaverse objects.