SPM inline edit requires security_admin – recommended operating model?

[debzmac]

We have a dedicated SPM administrator / implementation specialist responsible for routine SPM configuration and UX, while privileged platform/security administration is centrally controlled.

A recent example is enabling inline edit on an existing Goal/Target Relationship field "Contribution to Goal" scale. The users already have write access and can update the same data through the form; the requirement is purely to improve the user experience for maintaining existing records with inline edit. However because list editing is controlled through list_edit ACLs, the change requires elevated security administration. In an organisation where SPM administration and privileged security administration are deliberately separate roles, this creates a dependency on the central platform team for what is otherwise routine BAU SPM configuration.

I completely understand the security rationale for controlling ACL changes, but I am interested in the recommended operating model for this scenario.

Is the expected pattern typically:

• controlled/elevated security_admin access for the SPM administrator when required;
• a lightweight privileged-change fulfilment route through the central platform team;
• delegated field-specific controls;
• or another supported pattern?

The concern is less about this one change and more about avoiding a situation where routine SPM UX/configuration becomes unnecessarily dependent on a separate team purely because the underlying control is implemented through an ACL.

Would be interested in how other enterprise SPM customers handle the separation between SPM administration and privileged platform/security administration?

[Kieran Anson · Accepted solution]

Delegated administration solves this and has been around for a while. This works for the SPM plugins/store apps that aren't global. Some of the older content will be in the global scope and will require a full admin to action any security related work. 

https://www.servicenow.com/docs/r/application-development/delegated-development-and-deployment/t_Add...

Another alternative is the recently introduced "developer sandbox" experience. This is a paid for offering but allows an org to have multiple development environments and isolate developers from each other. With this, access can be broadened because of the sandbox nature. The deployment of code is then more vigorously reviewed to validate what is being deployed