We naturally find it easier to add than to remove. Adding feels comfortable and safe, while removing feels risky, as if you might break something that’s already working. It’s a well‑known principle in engineering, product design, psychology, and even everyday decision‑making.
Deletion in SAP Cloud Identity Services – Identity Provisioning (IPS) is no different and may bring the same sense of uneasiness, especially when it involves removing groups and their members. Over the years, IPS has introduced multiple features to control deletion, such as properties, scopes, filters, and conditions. That’s why understanding what they do and which one has priority over the others is essential.
The ABAP Case
Recent improvements in the SAP AS ABAP connector have fine‑tuned the deletion behavior for groups and group members (considered roles and user assignments).
If you now delete a group in the source system and that group also exists in the AS ABAP target, running a job will remove the user assignments in the target, not the group itself. Before 27 January 2026, IPS returned an error (“deletion of groups is not supported”) and no deletion occurred.
If you now remove a group member in the source system and that assignment exists in AS ABAP, the job will remove the corresponding assignment in the target. However, whether IPS also removes pre‑existing assignments (those that IPS did not originally provisioned) depends on the value of the ips.overwrite.existedbefore.assignments property:
ips.overwrite.existedbefore.assignments=false Only the assignments provisioned by IPS are removed. Pre‑existing assignments are preserved. ABAP keeps what it originally had.
ips.overwrite.existedbefore.assignments=true (default) The assignments provisioned by IPS are removed along with all pre-existing assignments. ABAP does not keep what it originally had.
A Table Says It All
They say a picture is worth a thousand words. In the following deletion scenarios, a table might be worth even more.
Let’s assume you have the following setup:
Group 1 exists both in the Identity Directory (source) and in the AS ABAP (target).
In the source system, Group 1 is assigned to User 1 and User 2, and these assignments are provisioned to the AS ABAP target by IPS.
In the target system, Group 1 is also assigned to User 3, who exists only in AS ABAP and the same user has not been provisioned by IPS from the source.
With this setup in mind, here’s what will happen when you delete the group in the Identity Directory or remove the assignments there, depending on whether the following two properties are enabled or disabled: ips.delete.existedbefore.entities and ips.overwrite.existedbefore.assignments:
Best Practices
How to delete users and groups with Identity Provisioning? Here are some best practices to help you decide.
Note: Users and groups are handled differently. Some target systems do not support deleting groups. In those cases, group deletion only results in the removal of its members.
Note: There is no dedicated Deletion job in IPS. Deletion is triggered by a Read job that no longer retrieves a user it previously read from the source system.
When a user can be deleted in the target system:
The user was provisioned by IPS from a source to a target system, and the deletion job is run for the same source → target pair.
During the deletion job, the user is no longer read from the source (has been deleted in the source or does not match the filter property), or the user no longer meets the condition configured in the source or the target transformation.
The deletion job is run in full read mode (ips.delta.read = false), and there are no failed entities in the job statistics.
The target transformation does not include skipOperations: [“delete”].
No deletion threshold in the target is preventing you from deleting the user, such as a the ips.delete.threshold.users property.
The ips.delete.existedbefore.entities=true property is enabled in the target before the deletion job is run.
ips.delete.existedbefore.entities=true
IPS can delete “existed before” entities in the target, only if this property is enabled before the deletion job is run as mentioned above.
When a user is considered “existed before”:
If during the first provisioning job, the user exists in the target and IPS does not create it but only updates it.
If the user is created in the target by provisioning job from another source → target system pair, where the target points to the same backend system.
If the source or the target system has been reset and IPS provisions the user again.
A common customer scenario where entities are recognized as “existed before” is when they are first read from a source system, provisioned to a target, and then returned to the same source system this time acting as a target (AS ABAP → Identity Directory → AS ABAP). If you are in such a roundtrip scenario and want IPS to delete an entity, enable the property before the deletion job runs.
When a user is not considered “existed before”:
For example, IPS creates a user with provisioning job from Identity Directory → AS ABAP. Even if the user is later updated by a subsequent provisioning job, if it is deleted in the source, it will be deleted in the target with or without enabling the property.
Although the scope name suggests deletion, this expression in the write transformations actually triggers an update. It means: When an entity is deleted in the source, don’t delete it in the target, only update it. In the example above, it sets the user as inactive.
Note: When both ips.delete.existedbefore.entities=true and “scope”: “deleteEntity” are configured in the target, IPS processes them in the following order:
IPS first checks the property ips.delete.existedbefore.entities.
IPS then evaluates the scope deleteEntity.
IPS checks the property again to decide the final operation, that is, whether the entity existed before and whether IPS is allowed to delete it.
Resulting behavior:
If the property is set correctly and before the job runs, IPS triggers delete.
If the property is false, missing, or set only after the job has run, and scope: deleteEntity is present, then the scope is executed, IPS triggers update.
Filters and conditions
Both filters and conditions can lead to deletion. Filters are always applied on the source system. When set, IPS only reads entities that match the filter criteria. Conditions can be defined on both – the source and the target. When set, IPS reads all entities first and then provisions only those that satisfy the condition.
As you work with IPS, use deletion wisely. When configured properly, it’s just as safe and predictable as addition.
We naturally find it easier to add than to remove. Adding feels comfortable and safe, while removing feels risky, as if you might break something that’s already working. It’s a well‑known principle in engineering, product design, psychology, and even everyday decision‑making.Deletion in SAP Cloud Identity Services – Identity Provisioning (IPS) is no different and may bring the same sense of uneasiness, especially when it involves removing groups and their members. Over the years, IPS has introduced multiple features to control deletion, such as properties, scopes, filters, and conditions. That’s why understanding what they do and which one has priority over the others is essential.The ABAP CaseRecent improvements in the SAP AS ABAP connector have fine‑tuned the deletion behavior for groups and group members (considered roles and user assignments).If you now delete a group in the source system and that group also exists in the AS ABAP target, running a job will remove the user assignments in the target, not the group itself. Before 27 January 2026, IPS returned an error (“deletion of groups is not supported”) and no deletion occurred.If you now remove a group member in the source system and that assignment exists in AS ABAP, the job will remove the corresponding assignment in the target.However, whether IPS also removes pre‑existing assignments (those that IPS did not originally provisioned) depends on the value of the ips.overwrite.existedbefore.assignments property:ips.overwrite.existedbefore.assignments=falseOnly the assignments provisioned by IPS are removed. Pre‑existing assignments are preserved. ABAP keeps what it originally had.ips.overwrite.existedbefore.assignments=true (default)The assignments provisioned by IPS are removed along with all pre-existing assignments. ABAP does not keep what it originally had. A Table Says It AllThey say a picture is worth a thousand words. In the following deletion scenarios, a table might be worth even more.Let’s assume you have the following setup:Group 1 exists both in the Identity Directory (source) and in the AS ABAP (target).In the source system, Group 1 is assigned to User 1 and User 2, and these assignments are provisioned to the AS ABAP target by IPS.In the target system, Group 1 is also assigned to User 3, who exists only in AS ABAP and the same user has not been provisioned by IPS from the source.With this setup in mind, here’s what will happen when you delete the group in the Identity Directory or remove the assignments there, depending on whether the following two properties are enabled or disabled: ips.delete.existedbefore.entities and ips.overwrite.existedbefore.assignments: Best PracticesHow to delete users and groups with Identity Provisioning? Here are some best practices to help you decide.Note: Users and groups are handled differently. Some target systems do not support deleting groups. In those cases, group deletion only results in the removal of its members.Note: There is no dedicated Deletion job in IPS. Deletion is triggered by a Read job that no longer retrieves a user it previously read from the source system.When a user can be deleted in the target system:The user was provisioned by IPS from a source to a target system, and the deletion job is run for the same source → target pair.During the deletion job, the user is no longer read from the source (has been deleted in the source or does not match the filter property), or the user no longer meets the condition configured in the source or the target transformation.The deletion job is run in full read mode (ips.delta.read = false), and there are no failed entities in the job statistics.The target transformation does not include skipOperations: [“delete”].No deletion threshold in the target is preventing you from deleting the user, such as a the ips.delete.threshold.users property.The ips.delete.existedbefore.entities=true property is enabled in the target before the deletion job is run. ips.delete.existedbefore.entities=trueIPS can delete “existed before” entities in the target, only if this property is enabled before the deletion job is run as mentioned above.When a user is considered “existed before”:If during the first provisioning job, the user exists in the target and IPS does not create it but only updates it.If the user is created in the target by provisioning job from another source → target system pair, where the target points to the same backend system.If the source or the target system has been reset and IPS provisions the user again.A common customer scenario where entities are recognized as “existed before” is when they are first read from a source system, provisioned to a target, and then returned to the same source system this time acting as a target (AS ABAP → Identity Directory → AS ABAP). If you are in such a roundtrip scenario and want IPS to delete an entity, enable the property before the deletion job runs.When a user is not considered “existed before”:For example, IPS creates a user with provisioning job from Identity Directory → AS ABAP. Even if the user is later updated by a subsequent provisioning job, if it is deleted in the source, it will be deleted in the target with or without enabling the property.For more information, see Manage Deleted Entities. “scope”: “deleteEntity”{ “constant”:false, “targetPath”:”$.active”, “scope”:”deleteEntity”}Although the scope name suggests deletion, this expression in the write transformations actually triggers an update. It means: When an entity is deleted in the source, don’t delete it in the target, only update it. In the example above, it sets the user as inactive.For more information, see Transformation Expressions.Note: When both ips.delete.existedbefore.entities=true and “scope”: “deleteEntity” are configured in the target, IPS processes them in the following order:IPS first checks the property ips.delete.existedbefore.entities.IPS then evaluates the scope deleteEntity.IPS checks the property again to decide the final operation, that is, whether the entity existed before and whether IPS is allowed to delete it.Resulting behavior:If the property is set correctly and before the job runs, IPS triggers delete.If the property is false, missing, or set only after the job has run, and scope: deleteEntity is present, then the scope is executed, IPS triggers update. Filters and conditionsBoth filters and conditions can lead to deletion. Filters are always applied on the source system. When set, IPS only reads entities that match the filter criteria. Conditions can be defined on both – the source and the target. When set, IPS reads all entities first and then provisions only those that satisfy the condition. As you work with IPS, use deletion wisely. When configured properly, it’s just as safe and predictable as addition. Read More Technology Blog Posts by SAP articles
