Who can run GDPR actions

GDPR erasure actions in MobilityManager are deliberately restricted, because pseudonymizing a user is irreversible and touches personal data across multiple databases. This article explains exactly who is allowed to run these actions and the two layers of protection that enforce it.

The permission: users:manage

Both GDPR endpoints — the eligibility check and the erasure itself — require the users:manage permission. Without it, the request is rejected before any processing happens. This is the same permission that governs managing user accounts elsewhere in the platform.

The role requirement: SystemAdmin

Holding users:manage is necessary but not sufficient. The pseudonymization service performs a second, independent check: the requesting account must hold the SystemAdmin role. This is defense in depth — even if a lower-privileged account somehow reached the service with the permission attached, the operation still stops with a "Forbidden" result.

Additional guardrails

Beyond who you are, the platform enforces rules about who you may erase:

• You cannot pseudonymize your own account. Ask another SystemAdmin to process it.
• You cannot pseudonymize another SystemAdmin. Remove the SystemAdmin role from that account first, then proceed.
• You cannot pseudonymize an account that has already been pseudonymized.

Note: Reading the audit trail is governed by a different permission, settings:view. Being able to view audit entries does not grant the ability to run GDPR erasure, and vice versa.

Tip: To let a colleague process erasure requests, assign them the SystemAdmin role and make sure their permission set includes users:manage. Both are required together.

Related

• Pseudonymize a user (GDPR right to erasure)
• Check whether a user can be pseudonymized
• GDPR compliance in MobilityManager
• View and filter audit entries