logo

NJP

Granting Non-Admin and Non-Delegated Developers access to Update Sets

Import · Sep 29, 2020 · article

There is a semi-new buzz word "Citizen Developer," making its rounds in the SN community. Citizen Developers are end-users from outside your IT organization who create objects on platforms sanctioned by IT.

If your company is thinking about or using the Citizen Developer approach, managing the new army of citizen developers and using them effectively means granting them the ability to use and create update sets. OOTB the only way for a user to get access to update sets, and its functionality is either with the Admin role, the teamdev_user role, or making them a Delegate Developer. In granting one of those options to a Citizen Developer, you also give them a lot more permission and functionality than they sometimes need. "With great power comes great responsibility." - Ben Parker.

Here is a scenario for implementing this solution - Allow each Department/Service group to create Catalog Items for their Department's/ Service's catalog (non-scoped, global app level) in a non-prod environment. Without granting them the Admin Role or making them a Delegated Developer.

OOTB, the catalog_editor and catalog_manager roles take care of creating and editing Catalog Items. But what about access to update sets so that the new Catalog Items or Catalog Item edits can be pushed to Prod from the Dev/Test environment(s)?

The following post will show you how to grant a Citizen Developer access to the update set without being an Admin or a Delegated Developer.

The first thing you will need to do is create a new role to associate with the update sets' usage—I created one and named it - update_set_user.

image

Next, we need to add that role to the existing or create new Read, Write, and Create ACLs on the Update Set table (sys_update_set ). I left the delete ACL out, but if you want to grant them the ability to delete an update set just add one for delete.

imageimageimage

We also need to add that role to the existing or create new Read and Write ACLs on the Customer Update table (sys_update_xml). *The Write ACL is optional. It is needed in case they need to move updates from a Default or wrong update set to the or the correct update set.

imageimage

There are other optional tables you can add read and write access to if you want them to see and edit on those tables - Retrieved Update Set - sys_remote_update_setUpdate Set Preview Problem - sys_update_preview_problemUpdate Set Preview - sys_update_preview_xml

Update Set Log - sys_update_set_log

View original source

https://www.servicenow.com/community/developer-blog/granting-non-admin-and-non-delegated-developers-access-to-update/ba-p/2287728