The impact of modifying OTB ACLs for the admin role

[mugi-san]

Hello, Everyone.

Does anyone have insights or experience regarding the impact of modifying out-of-the-box (OTB) ACLs for the admin role to restrict Create, Write, and Delete operations across various tables?

Of course, I am aware that the snc_read_only role works wonderfully, but if we need to achieve this without using it, I need to understand the potential concerns and risks associated with modifying the ACLs.

regards,

[Tejas Adhalrao · Accepted solution]

hi @mugi-san  ,

• Check whether the requirement can be achieved with a custom role/ACL rather than modifying the OOTB admin ACLs.
• Changes to OOTB ACLs can affect applications, integrations, scripts and other platform processes that rely on the existing access.
• Remember that admin has elevated privileges, and some platform operations can also behave differently because of security settings such as security_admin.
• Upgrades may introduce changes to OOTB ACLs, so modified records need to be reviewed during upgrades.
• If the requirement is to make specific users read-only, I would prefer using a dedicated role and ACL conditions rather than changing the baseline admin ACLs.
• Also test carefully in a sub-production instance, including UI, APIs, imports, integrations and background/platform processes.

If the business specifically requires restricting admin users, I would first document exactly which tables and operations need to be restricted and then design the ACLs around that requirement rather than broadly modifying OOTB ACLs.

If this helps, please mark it as Helpful and accept the solution.
Regards,
Tejas