Scalar rule values not cleared after source resource deletion

[ArekHilger]

What is a one sentence summary of your feature request?

Automatically clear scalar rule values on source ResourceTypes when the related source resource is deleted or no longer returns a value, to avoid stale data and non-conforming errors.

Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.

The customer uses a Directory connector to retrieve information from target applications back into NIM.
For example, they retrieve the DN of an Active Directory account through scalar rules on a source ResourceType.

The issue is that values retrieved through these scalar rules are not cleaned when the source resource is deleted.

Current flow:

NIM creates an AD account.
Synchronization retrieves the account DN into NIM.
NIM deletes the AD account.
Synchronization runs again.
The old DN value remains in NIM instead of being cleared.
NIM later recreates the AD account in another Organizational Unit.
A new DN exists, but the previous stale DN value remains.
This causes non-conforming / non-reconciliation errors.

Expected behavior:

When the source resource is deleted, or when the source no longer returns a value for a scalar rule, NIM should provide a supported way to automatically clear the previously stored scalar value.

This would ensure that NIM reflects the current state of the target system and does not keep obsolete values from deleted resources.

This feature would be useful because the current behavior creates stale data and requires manual cleanup, which is risky and inefficient.

How do you currently solve the challenges you have by not having this feature?

Currently, the customer has no standard automatic way to clean these values.

The only available options are manual or custom workarounds, such as:

manually identifying stale values
cleaning them through scripts or database-level operations
creating additional custom logic to reset values
manually resolving resulting non-conforming errors

These workarounds are not ideal because they are time-consuming, error-prone, and can require technical intervention outside normal product usage.

Upload any other supporting files that you think should be considered in this idea.

manage.myaccess-qual.nexans.com_20260407130542_kadi_mya_admcgi_nexans_com_yqqtvetseok.zip (2.7 MB)manage.myaccess.nexans.com_20260417074903_younes_mya_admext_nexans_com_ubewm4qd1sh.zip (2.7 MB)DLAzure_To_User.xml (1.33 KB)

[Kamil.Wojenkowski]

I’m not sure if it is the same issue and related.

We have a similar issue when an entry is deleted but the resource type stays with all the scalar rules in errored.

I think there are two different types of deletions, and this is what is causing the issue.

One is a real deletion, for example a deletion performed in AD and sent through the LDAP protocol. Another case is when you change the export configuration. When you change a filter in the AD connector, the data will no longer be exported and will no longer be present in the repository, but it will not receive an LDAP delete.

For example, if we change objectClass=user to objectCategory=Person.

All the users that have been removed will not get the real delete and will be stuck like in the image above.

Something similar is maybe happening to the scalar rule.
Because for me, we see all the scalar rules as well in errored even when they are not there.

@ArekHilger
In your case I think the real delete request is not received and it tries to move the account.