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 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.

...

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. 

...

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

...

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.

...

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.