(2024 March) Update to SCIM API DELETE Request
What?
We are enhancing the SCIM API DELETE Request to perform a true delete operation. Previously, this Request executed a PATCH call to set the active attribute to false, merely deactivating the user. This allowed for potential reactivation. However, with the new update, the Request will now formally delete the user in Mural, removing all user identity data and preventing any possibility of reactivation.
Why?
Adhering to the standard SCIM (System for Cross-domain Identity Management) protocol, we've implemented a DELETE mechanism. This addresses a common issue faced by many of our customers, particularly larger ones, who often recycle common email addresses for their employees (e.g., [email protected]). Our previous system posed a challenge as it didn't allow for two accounts with the same email, and there was no method to delete the old user to be able to repurpose the email.
When?
This change goes live on March 27th, 2024, two weeks after we notify relevant company administrators via email on March 13th, 2024.
Changes to Mural Connectors
Okta
None! Okta does not use the SCIM DELETE Request for any of their integrations (including Mural). Okta only supports deactivation.
Microsoft Entra ID (formerly known as Azure Active Directory)
Only customers who have selected the “Delete” action option in their Entra ID configuration (see screenshot below) will be affected by this change.
With our updated Request behavior, a hard delete in Entra ID now corresponds to a hard delete in Mural, utilizing the new SCIM API DELETE Request.
In Entra ID a delete operation is initially performed as a soft delete, which is akin to being "sent to the recycle bin". If a user remains in this state for 30 days, they are then permanently deleted from the tenant, a process known as a hard delete. Additionally, admins also have the option to manually perform a hard delete at any point within this 30-day window. Read more about hard deletes.
Old Mural SCIM DELETE behavior
| Action in Entra ID | "Delete" UNCHECKED | "Delete" CHECKED |
|---|---|---|
| Unassign user from application | active == false (inactive) | active == false (inactive) |
| Disable user | active == false (inactive) | active == false (inactive) |
| Soft delete user | active == false (inactive) | active == false (inactive) |
| Hard delete user | N/A | active == false (inactive) |
NEW Mural SCIM DELETE behavior
| Action in Entra ID | "Delete" UNCHECKED | "Delete" CHECKED |
|---|---|---|
| Unassign user from application | active == false (inactive) | active == false (inactive) |
| Disable user | active == false (inactive) | active == false (inactive) |
| Soft delete user | active == false (inactive) | active == false (inactive) |
| Hard delete user | N/A | NEW deleted == true (SCIM DELETE) |
Opt out of this change
To avoid the new functionality, two opt-out options exist.
- For custom configurations: use a PATCH request. Setting active == false yields the "soft delete" behavior.
- For Entra ID: uncheck the Delete target object action in configuration.
FAQ (frequently asked questions)
-
What happens to content for the deleted user?
Unless the content is explicitly transferred in the “Workspace Members” admin screen or through our Content Transfer API prior to deletion, nothing happens to the content. It will remain in the system and any other users who have access can continue using it.
-
If the content (mural / rooms) is not transferred prior to hard deletion of the user, the content will be without an owner.What if the deleted user is the sole user of the content?
Reminder: In Entra ID, a delete operation first results in a soft delete. If not restored within 30 days, it becomes a hard delete. Content can be transferred during the 30-day soft delete period in Mural.
-
-
Is the delete GDPR compliant?
No, this deletion is not fully GDPR compliant. If you need to process a GDPR compliant deletion please contact [email protected].
-
What happens to the user data in the audit log, reporting, eDiscovery, & in the activity log?
- Audit log: User object remains with anonymized email and name.
- Reporting request: User does not exist.
- Company members: User does not exist.
- Workspace members: User does not exist.
- eDiscovery: Running a search on the deleted user as the “actor” will yield no results. However, if you run a search where the deleted user is NOT the actor, any associated activity will refer to the deleted user as “former collaborator”.
- Activity log: Displays as “former collaborator”.
-
If a user is deleted, what do they see if they try to log in to Mural again?
The user is essentially treated like a new user because the system does not recognize them.
- With automatic provisioning - the deleted user sees the custom support page for unprovisioned users.
- With manual provisioning - the deleted user is prompted to create a new account.