There are multiple procedures for this, and it depends on the kinds of user, and the privileges they should have.

Creating an account

NetID-based Yale affiliate users

The vast majority of ServiceNow users are Yale affiliates with netid-based login credentials. The settings for these kind of users come from multiple data imports. The main user information import is IST-User, which gets netid and related user fields. There are also two LDAP (Active Directory) imports that come from Yale Central Auth. The Yale-User LDAP import includes phone number information and related fields. The Yale-Group LDAP import contains mappings between netids and ServiceNow Assignment Groups (and Groups that serve no purpose except to assign roles).

These users almost never require maintenance, except when something goes wrong with the IST-User import. Find out more about that at: User import issues in ServiceNow

Creation and disabling of these accounts is fully automated by integrations with Central Auth and Active Directory.

Fake user accounts to handle inbound email

These cases are people who have a business need to correspond with Yale, but do not have a netid (and should not have a netid). Examples are people who need to communicate with the webmaster for abuse complaints, certain vendors, etc. These people should be tracked in ServiceNow, and by having unique ids associated with them, we can track their historical issues. Especially useful if they ask for something from one person, the Yale employee says no, and then they come back and try to ask for the same thing from a different person.

We made a decision in late-2012 or early-2013 to allow inbound email from non-Yale people. We ended up handling this by allowing inbound mail to create new fake user accounts. The netid field is set to the email address from which ServiceNow received the email address.

These are the second most-common kind of accounts. As of July 1, 2014, the count of these users is: 2355. The report is https://yale.service-now.com/sys_user_list.do?sysparm_query=GOTOuser_nameLIKE%40

These accounts follow patterns like:

14154568@bigpond.com

Nobody logs into these accounts, but having them allow us to track issues by a unique id. One nice feature is we can control inbound spam from specific users by then toggling their user account to non-Active (which prevents them from generating incidents via email).

Creation of these accounts is fully automated by integrations with email and scripts we wrote at Yale. 

Caveat for all local accounts

For any kind of local accounts, we must first evade Yale Single Sign On (SSO) technology. To do this, we must NOT have a CAS ticket in the browser we use for accessing ServiceNow as a local user. Most people who need to use ServiceNow admin on a regular basis end up using TWO browsers:

1. for their regular daily work, as a signed-in Yale employee
2. for their ServiceNow local-user work (such as admin), as a local user

In this manner, there is a separation of duties, and it's quick to verify work you performed as a privileged user by checking the feature as a non-privileged user.

Local Service accounts

Before trying to access local accounts, read the Caveat for all local accounts.

There are a small handful of user accounts in ServiceNow for various integrations with external systems or services.

These account names correspond to the naming convention: s_

Some examples include:

s_unixsys, used by Unix Systems with scripts that post Incidents into ServiceNow using the API

s_windows, used by Windows group with scripts that post Incidents into ServiceNow using the API

s_sn_drupal, used by web group to integrate between ServiceNow and Yale ITS website

s_nagios, used by Operations to poll certain ServiceNow production services automatically and dynamically contact Production Support team of anomalies

s_update_source, used by ServiceNow for passing update sets between DEV and other SN instances

These accounts almost never require maintenance. Various accounts require certain rights; the most tricky one is the SOAP role (and associated roles with the name soap in them) if the account requires access to the API.

Local named non-admin user accounts

Before trying to access local accounts, read the Caveat for all local accounts.

There are a small number of non-admin user accounts in ServiceNow for various purposes.

These have the naming pattern *-actor.

These were created in 2014 at the request of the new Business Analysts. These accounts generally have the impersonator role, which grants these users the privilege of emulating other users.

Because these accounts have high levels of privilege, we manage them with entries in the post-clone script. Post-Clone Procedure

Local admin user accounts

Before trying to access local accounts, read the Caveat for all local accounts.

There are a small number of accounts with admin privileges. 

Accounts for our vendor Fruition are named with the pattern firstname.lastname

An example is:

allen.doering

Accounts for internal Yale employees are named with the pattern netid-admin

An example is:

ml34-admin

These accounts are most easily found by going to the admin role, and then looking for accounts associated with the role.

Notice that many admin accounts are non-Active in most environments. We retain these accounts as non-active in certain environments because cloning down will change the properties of local accounts, including their credentials. If we didn't have the accounts in the higher environments, we would need to recreate the users manually each time after we did a clone, and that would be a waste of time for everybody involved.

Maintaining the post-clone

The post-clone is stored at: Post-Clone Procedure

It must be hand-edited. Anybody who is granted admin rights in PROD should have the requisite skills to edit this directly.

It then must be hand-deployed out to the instances. CHANGES TO THIS SCRIPT ARE NOT CAPTURED BY UPDATE SETS.

We literally need to copy and paste the changes to each instance.

The script is stored at: System Definition > Scheduled Jobs > Post-Clone Script

So after the hand edit, and the save on the wiki, copy and paste the changes out to DEV, TST, PRE, TRN, PRD.

If you hit Execute Now, it will run now, and you can confirm any changes that could be tested at that time.

If you actually want to see output, you must run it from Scripts - Background

Any code errors you introduce will show up as errors on the Background script console.

Obviously, this will only capture logic code errors, and not failures of writing the script properly to do what you meant it to do.

Creating a new account, and cloning it around

Different people have different opinions about how to do this. None is correct absolutely, so here's an algorithm.

First, go maintain the post-clone. Once you've done that, come back to these instructions.

1. Go to DEV, User Admininstration -> Users -> New
2. In the New User dialogue, at minimum, populate the NetID, First name, Last name. If they are a vendor, also populate email address and Business Phone. We will need Business Phone to hand over their login credentials. If you are immediately handing the account over, leave the Active toggle alone. If it will be a few days, toggle Active to false. Also set a temporary password, ideally difficult, which you can remember. Writing it down is okay; this is temporary, and you will need to share it with the user receiving the account. Copy the temporary password to your clipboard, and paste it into the user record. Also set the toggle for "Password needs reset".
3. Save and Stay, and now you will see Roles.
4. Edit roles and add any that are required.
5. Clone this account by: Right Click on colored bar at the top of the user record dialogue, then choose Export -> XML (This record)
6. Save the record to your local machine
7. Go to TEST, User Admininstration -> Users
8. Right click on colored bar at the top of the user records listing, then choose Import XML, and use the browser file picker to retrieve the record you just saved to your local machine
9. Use the Users people picker tool to pick the record you just added. Manually add back any role(s) you assigned in step 4
10. Paste in the temporary password.
11. Save and Stay.
12. Go to PRE, User Admininstration -> Users
13. Right click on colored bar at the top of the user records listing, then choose Import XML, and use the browser file picker to retrieve the record you just saved to your local machine
14. Use the Users people picker tool to pick the record you just added. Manually add back any role(s) you assigned in step 4
15. Paste in the temporary password.
16. Save and Stay.
17. Go to PRD, User Admininstration -> Users
18. Right click on colored bar at the top of the user records listing, then choose Import XML, and use the browser file picker to retrieve the record you just saved to your local machine
19. Use the Users people picker tool to pick the record you just added. Manually add back any role(s) you assigned in step 4
20. Paste in the temporary password.
21. Save and Stay.
22. Go to TRN, User Admininstration -> Users
23. Right click on colored bar at the top of the user records listing, then choose Import XML, and use the browser file picker to retrieve the record you just saved to your local machine
24. Use the Users people picker tool to pick the record you just added. Manually add back any role(s) you assigned in step 4
25. Paste in the temporary password.
26. Save and Stay.

Handing the account to the user.

It is Yale Policy to never email a password or other sensitive information. For Yale affiliates on campus, do the account exchange in person. This also allows you to confirm the user can access their account. For vendors, schedule a phone call, and provide the password verbally over the phone.

The actual handoff algorithm:

At meeting: start with PROD

1. Direct user receiving account to visit yale.service-now.com/side_door.do
2. login in with username, and temporary password
3. confirm they have reset their password. You can tell by reviewing the user record. The toggle for 'Password needs reset' will untoggle after they have successfully changed their password
4. toggle off their PRD access by untoggling the Active flag on their user record. Alternatively, force a run of the post-clone to untoggle their PROD Active flag on their user record.
5. Direct user receiving account to visit yalepreproduction.service-now.com/side_door.do
6. login in with username, and temporary password
7. confirm they have reset their password. You can tell by reviewing the user record. The toggle for 'Password needs reset' will untoggle after they have successfully changed their password
8. toggle off their PRE access by untoggling the Active flag on their user record. Alternatively, force a run of the post-clone to untoggle their PROD Active flag on their user record.
9. Direct user receiving account to visit yaletest.service-now.com/side_door.do
10. login in with username, and temporary password
11. toggle off their TST access by untoggling the Active flag on their user record. Alternatively, force a run of the post-clone to untoggle their PROD Active flag on their user record.
12. Direct user receiving account to visit yaledevelopment.service-now.com/side_door.do
13. login in with username, and temporary password
14. You probably need to leave their DEV access.
15. Don't worry about TRAIN unless this is a trainer. In most cases, we leave TRAIN access toggled off, and we just wait for the next PROD clone to create the account (which is disabled from the PROD clone, and further never enabled by the post-clone script)

Deleting / disabling an account

NetID-based Yale affiliate users

We retain the netid account in our system for data tracking, and the account will be marked inactive when Central Auth (IST and Active Directory) toggle it accordingly and we run the next import against that data.

Fake user accounts to handle inbound email

These are non-login accounts. These accounts do default to Active. At times we may want to toggle them to in-Active. Doing so will prevent them from ingressing new Incidents via email. This is a useful feature if particular email addresses are sending spam into ServiceNow.

Local Service accounts

These are local accounts, and they're pretty useless unless they are toggled Active. If we toggle them inActive, or we take away Roles / Group associations, we may also render the account useless for the purpose it was created for. Don't disable these unless we've already spoken to the group that manages the application they were created for.

Local named non-admin user accounts

These are local accounts, and there are only a handful of them. Generally, if these accounts exist, it's because the user does not have admin in that environment. Once we trust a user enough to grant them admin, we should probably take away their non-admin local account.

Taking away a local non-admin account requires editing post-clone. See  Post-Clone Procedure

It's safe to delete these accounts when we no longer need them. It's unlikely we would ever re-grant a non-admin local account.

If all we are doing is granting or denying a specific instance, that can be done with changing post-clone (see procedure) and then running post-clone again manually in the environment where the access is getting granted. If access is getting taken away in a specific instance, we still need to change post-clone, but we will need to manually toggle off the access in the environment losing the access.

Local admin user accounts