Admin Duty Separation with a Single Account

If you typically use a single account for your "admin" duties, as well as for creating and updating tasks, approving changes, and so on, it would be easy to accidentally utilize your "admin override" functionality without even knowing it. There is no notification or other indicator when you're only able to see some option because you're an admin and thus overriding an ACL! You might end up accidentally making some change that you shouldn't be able to make, such as approving or changing the state of a change record that would otherwise be locked down.

To avoid this, some companies require that admins have two separate accounts: one "normal" account with their group's non-admin roles, and a separate "admin" account that they must log into locally on the instance. This is an okay solution, but requires a lot of flipping back-and-forth, makes it difficult to update tickets as you're working on stuff, and often leads to people just using their admin account for everything because it's more convenient.

There is however, a better way! To avoid accidentally using your "admin powers" when you don't mean to, you can simply set the admin role to an elevated privilege!

Okay, so perhaps "simply" wasn't the right word to use there, but it can be done without too much hassle. Unfortunately, the Elevate privilege field on the admin role is protected by an ACL that cannot be modified or deactivated based on its protection policy. While you cannot bypass the protection policy to modify this ACL, you can bypass the ACL itself using a background script. To make admin an elevated privilege, follow the steps below:

  1. Elevate to Security admin so you can modify role records.

  2. Open the background scripts module from System Definition > Scripts – Background.

  3. Run the following script:

var grAdminRole = new GlideRecord('sys_user_role');
grAdminRole.addQuery('name', 'admin');
grAdminRole.setLimit(1);
grAdminRole.query();
if (grAdminRole.next()) {
    grAdminRole.setValue('elevated_privilege', true);
    grAdminRole.update();
}

Once you're done, be sure to navigate to the admin role in the sys_user_role table, and update the description to something more succinct (since this will show in the "elevate roles" dialog).

The one main down-side to this approach, is that it makes the admin role elevated for everyone - including the OOB system administrator account. This mainly causes an issue whilst deploying update sets.

You should be able to get around this pretty easily, by adding additional roles to the system admin account to ensure that it has all the permissions it needs even outside of the admin role; and you’ll need to make sure you use the system administrator account for instance-to-instance calls, such as retrieving update sets and such. 
It may take a little bit of ACL-fiddling (and I may write a script at some point to automatically update all admin-dependent ACLs to work with a secondary admin role), but you should be able to sort this out without too much trouble in your instance.

I’ve been using this in one of my instances for a few months, and aside from the above-mentioned issue deploying update sets, and an issue with a scheduled script that was running under the system account (both of which were easy fixes), I’ve had no major issues.

Special thanks to Top Tanti for helping me bypass the protected ACL to make this work!