Custom process executed or not depending on properties of Account definition

Looks logical. According to You in second case AD account is disabled and so You get the mail. In first case AD account is not disabled!

Move this process to Person table and trigger it on UPDATE and generation condition like

Value = $IsInacive$ <> $IsInacive[o]$ and $IsInacive$ = True

...remeber that this is Identity management , and AD is just one of the target systems.

Hello mekindad,

for the AD Accoount definition the properties "Retain account definition if permanently disabled" and "Retain account definition if temporarly disabled" checked or not, 

the AD account is disabled in any case and this is correct: if an employee leaves the company  his AD account must be disabled.

The properties "Retain account definition if permanently disabled" and "Retain account definition if temporarly disabled" are checked

because I don't want the (deffered) deletion of the AD account when is disabled, but in this case the event DEACTIVATE-ADSaccount is not detected  which is an

unwanted side effect.

The disabling of the user account is controlled by the settings in the manage level not by the account definition.

You might want to check the settings there.

Hello Markus,

The "Full managed" level used in the Account Definition has the following checked settings:

Disable user accounts if temporarly disabled;

Disable user accounts if permanently disabled;

Disable user accounts if deletion is deferred

Lock user account on security risk

Retain groups if user account disabled.

I verified more than once:

when the properties of the Account definition has the settings

Retain account definition if permanently disabled checked
Retain account definition if temporarly disabled    checked

and when the employee leaves the company: the employee is disabled, the AD account is disabled but the custom process is not executed at the event DEACTIVATE-ADSAccount.

When the properties of the Account definition has the settings

Retain account definition if permanently disabled unchecked
Retain account definition if temporarly disabled    unchecked

and when the employee leaves the company: the employee is disabled, the AD account is disabled and the custom process is executed at the event DEACTIVATE-ADSAccount.

giuseppe denora_57852 said:

costum process with event DEACTIVATE-ADSAccount to send

The event "Deactivate" is part of a deferred deletion of an object and is fired when you are trying to delete an object that has a delete delay > 0 configured at the DialogTable for this type of object. And exactly this is happening, if you configure the "Retain account definition..." flags to false. In that case, the system is removing the account definition from the employee and this leads to an deletion of the account. Because a delete delay of 30 days is configured (by default), thesystem first disables the account, creates a deferred delete operation to be run in +30days and fires the DEACTIVATE event.

If the "Retain account definition..." flags are set to true, then the account is disabled because of the settings at the manage level.

So back to the solution of mekindad, and change the process to listen on the person change, or attach it to the Update event and use a generation condition that listens to the change of the AccountDisabled flag to True.

https://support.oneidentity.com/technical-documents/identity-manager/8.1.4/target-system-base-module-administration-guide/6#TOPIC-1533556

The event "Deactivate" is part of a deferred deletion of an object and is fired when you are trying to delete an object that has a delete delay > 0 configured at the DialogTable for this type of object. And exactly this is happening, if you configure the "Retain account definition..." flags to false. In that case, the system is removing the account definition from the employee and this leads to an deletion of the account. Because a delete delay of 30 days is configured (by default), thesystem first disables the account, creates a deferred delete operation to be run in +30days and fires the DEACTIVATE event.

If the "Retain account definition..." flags are set to true, then the account is disabled because of the settings at the manage level.

So back to the solution of mekindad, and change the process to listen on the person change, or attach it to the Update event and use a generation condition that listens to the change of the AccountDisabled flag to True.

https://support.oneidentity.com/technical-documents/identity-manager/8.1.4/target-system-base-module-administration-guide/6#TOPIC-1533556