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

[Miguel Donayre]

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.

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.

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.

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_set
Update Set Preview Problem - sys_update_preview_problem
Update Set Preview - sys_update_preview_xml
Update Set Log - sys_update_set_log

*Access to these tables is not needed for them to capture updates in update sets.

After you finished with the ACLs, you want to grant that role access to the Update Set Menu.
In the Update Set Menu list click on the pencil icon next to the menu and add the new role to it. Add the role to the Roles section of the Application Menu.

You can also create a new menu and to give them access to just the Local Update Sets.

That will depend on how much you want to expose to the target user. I created a new Menu and created a new Module of a list of records from the Update set table.

Next, I wanted to restrict access to what update sets the user can see. I didn't want someone to pick the wrong update set that wasn't their's or let the user see other update sets. I created a before query Business Rule on the Update Set table to limit the records the user can see. I got the idea from this post.
Here is the code I used. *This step is also optional. 

here is the condition-

!gs.hasRole('admin')

here is the script -

(function executeRule(current, previous /*null when async*/ ) {
    var usr = new GlideRecord('sys_user');
    if (usr.get(gs.getUserID())) {
        current.addQuery('sys_created_by', usr.user_name).addOrCondition('sys_created_by', 'system');
    }

})(current, previous);

Finally, I wanted the user to have the ability to pick their update sets from the Update Set Picker in the Header. I followed the ServiceNow instructions found here. 
I had to create a new system property - glide.ui.update_set_picker.role and add the update_set_user role n the "Value" field.Keep in mind that's only one role can be used in the property.

*This step is optional as well, you don't need the update set picker for this to work. 

If you followed the steps correctly you now have the ability to grant Citizen Developers or any user usage of the Update Sets. I have tested this in the Orlando and Paris releases.

Feel free to bookmark this post or mark it helpful, and if you think I've missed something, please let me know so I can get it added.