Are YOU a ServiceNow Jedi?
Whether you’re a new administrator or an experienced consultant, you need to know these things to become a master of the ServiceNow force.
Since I started SNCGuru, I’ve had several people who were just starting their ServiceNow experience ask me what I would recommend they focus on to really start learning ServiceNow. I’ve wanted to write an article on this topic for quite some time but it’s kind of a hard thing to tackle. Obviously, there’s a lot to choose from but I’ve finally narrowed things down to a pretty reasonable list of topics to get started. I’m sure this list will evolve over time so check back often for updates!
You’ll notice that the list below doesn’t include anything about personalizing field labels or creating reports. I assume that if you’re serious about being a ServiceNow administrator or consultant you’ve at least got the initiative to go out to the ServiceNow wiki and demo site and click around a bit to figure out the simple things. When in doubt, use the left nav or right-click!
You’ll also notice that I haven’t given detailed instructions on how to accomplish the tasks in the article below. Again, there’s a ton of information on the wiki and on SNCGuru that you can reference to help you along. I strongly believe that real learning usually occurs when you have to take the time to figure something out yourself, so dig in and try it out. If that’s not something you’re comfortable with then IT or Development probably isn’t the right career path for you :).
Here’s the list. Below each item are a few example challenges that you can try out to see if you’ve got a good handle on the topic. Topics and challenges have been chosen based on the things that I see most commonly in ServiceNow implementations. If you’re just playing around and learning this stuff, the ServiceNow Demo site is one place you could try something out. If you mess up your production instance you can’t blame it on me!!! Good luck, and may the force be with you!
1 – GlideRecord
Understanding how to access data via script is incredibly important…it’s also not that difficult :). Once you learn a few basic techniques you’ll be amazed how many things you can accomplish just by following the same query routines in different places in the tool.
- Query for all incidents with a category of ‘hardware’…log a count of records returned
- Query for all incidents created in the past 3 days where the caller is ‘Joe Employee’…log a count of records returned
- Use script to insert a new incident record where ‘Joe Employee’ is the caller and the priority is 1
- Modify the above script to insert the same incident along with an affected CI (by name)
- Delete all incidents updated by ‘ITIL User’ in the past 24 hours. Log the number of each record deleted along with a total count of records deleted.
- Use a business rule to abort the submission of any incident with a high priorty
2 – Accessing user information
There are so many tasks in ServiceNow that come down to knowing something about the user accessing a record or form element and then acting on that information. Besides GlideRecord, this is probably the single-most important type of scripting task to master in ServiceNow.
- Query for the ‘ITIL User’ record
- Set up a department on your user record. Use a UI action to show an information message with the sys_id of your department.
This should be done in no more than two lines of code. It’s possible to do it in one!
- Set up a new reference field pointing to the User table. Make it so that the currently logged-in user is the default value for this field.
Hint: Take a look at the dictionary entry for the ‘Opened by’ field.
- Use a client script or UI policy to display an alert message showing the title of the currently logged-in user.
- Set yourself up with some roles and test (in both a client script and a business rule) to see if you have that role.
3 – System security
System security often ties in very closely with finding out information about a particular user. Many of the same server-side scripting techniques used in item 2 above will apply here as well. There’s a lot you can do without any scripting though if you understand how the order of security operations works.
- Only allow admins to delete user records
- Allow admins to update all user records and everybody else to update their own record
- Allow users with the ‘itil’ role to update user records for users in their own company
- Disallow ANY deletion of Task records (even admins)
- Disallow ‘itil’ users the ability to read the ‘State’ field on incident records
- Disallow ‘itil’ users the ability to read any record where the state is ‘Closed’. Hint: You shouldn’t use an ACL for this one!
What Everybody Should Know About ServiceNow Security
4 – Client scripting and UI Policies
One of the most important things to learn about client scripting is how it differs from business rules. ‘current’ and ‘gs’ are off-limits here! Instead you use ‘g_form’ and ‘g_user’ (which are off-limits for business rules).
- Set up a client script on your incident form to hide a field, make a field mandatory, and make a field read-only. Do the same thing with a UI policy.
- Download and install the ‘Firebug’ plugin for Firefox (or the equivalent for your browser of choice). Learn how to inspect elements on the form.
- Create a client script to populate the ‘Location’ field on the incident form with the location of the Caller as the ‘Caller’ field changes.
- Stop the submission of any Priority 1 incident created by a user without the ‘itil’ role. Alert the user when this happens.
- Set up a confirm prompt to ask users with the ‘itil’ role or ‘itil_admin’ role if it is okay to submit a Priority 1 incident.
5 – Graphical workflow
There are a lot of applications for graphical workflow, but it’s absolutely critical to understand this if you want to deploy Change request or Service Catalog. Approvals, subtask generation, and rollbacks are all usually best set up in graphical workflow.
- Set up a simple workflow for Change request records with a type of ‘Comprehensive’
- Add 3 approvals to your change request. The first should be an approval from the manager of the person requesting the change.
The second approval should be from all APPROVAL GROUPS associated with Affected CIs on the change. The third approval should be
from the CAB (you may need to create a new group record for this).
- Any time any of the approval activities results in a rejection the workflow should get rolled back to the beginning
- If all approvals pass, 2 tasks should be generated. The second task should not start until the first task finishes.
- Set up a workflow for a catalog item
- Add an approval for the ‘Requested for’ person’s manager
- Approval by the manager should result in 2 tasks being generated that run at the SAME TIME
- Rejection by the manager should result in an email notification being sent out to the ‘Requeted for’ person and the ‘Opened by’
person indicating that the approval was rejected and the item will be closed
- Mark the item as complete when tasks are finished or when the manager rejects
6 – Import Sets
Chances are you’re going to need to bring data into the system at some point. You’ll need to learn how to coalesce and transform data so that you can get it in the right place.
- Open the ‘Windows Server’ list and export the contents of the list to CSV. This is the best way to create an good template for CSV or XLS data sources.
- Based on this template, add a few new Windows Server CIs to the CSV file. Modify some of the attributes of some of the CIs that you exported.
- Using this modified data, create a data source and transform map to import the CSV data back into the instance. Make sure that the correct CIs were updated and the correct CIs were inserted. Did you set up the correct coalesce value?
- Add a ‘Transform Map Script’ to get the values of 2 of the import fields for each row, concatenate them, and populate them into a new field.
- Change your CSV again to blank out the names of some of your Computers. Modify your transform map script to ignore the transform of any record coming in that does not have a name.
7 – Email Notifications
I’ve never deployed ServiceNow without meeting a requirement for multiple email notifications on multiple tables. You may be tempted to use graphical workflow to accomplish this, but the standard business rule event trigger method is actually a lot more flexible. It’s also not that bad once you understand the steps needed to make it happen.
- Set up an end-to-end email notification using a business rule trigger.
- Send an email notification from graphical workflow.
- Trigger an event from graphical workflow that sends an email.
- Navigate to ‘System Logs->Email’ and examine the contents of some of the emails you’ve sent. Re-send one of these emails from the email log.
8 – Reference Qualifiers and Dependent fields
Reference qualifiers and Dependent fields allow you to present context-sensitive choices to your users when they fill out a form. Reference fields are usually used when you’ve got a lot of choices or you’ve got some complex filtering needs. Dependent fields are great when you just have a simple filtering need based on another field value on the form.
- Set up a filter on the incident list. Copy the query for this filter and understand how it is formatted.
- Set up the ‘Configuration Item’ field on the ‘Incident’ form to only show Business services. You should not change the referenced table to accomplish this.
- Modify your reference qualifier to show Computers. Check against the ‘Computers’ module to verify the count. If the numbers didn’t match up, why?
- Modify your reference qualifier to show ALL Computers, Servers, etc. Hint: The query for this should only reference a single table.
- Open a couple of Business service and computer records and assign them to a particular user. Modify your reference qualifier to only display Business
services and computers assigned to the user populated in the ‘Caller’ field.
- Set up a new field on the incident form called ‘Sub-subcategory’. Without writing any code, make this field dependent on the Subcategory field.
9 – Service Catalog and Catalog Scripting
This is a very big topic that can also vary widely depending on what you’re trying to accomplish. Graphical workflow is key here so make sure to complete number 5 if you’re diving into this area. Most of this is UI-driven so these tasks will focus more on the common scripting tasks in the service catalog. You should set up a few catalog items, content items, and record producers to practice with here.
- Open up any catalog item and set up a client script that shows/hides a field based on the contents of another. Do the same with a catalog UI policy.
- Set up a record producer for the incident table that contains a ‘Caller’ and ‘Configuration item’ reference fields the same as your incident form. Automatically
populate these fields onto an incident record without using any scripting.
- Create a reference qualifier for your ‘Configuration item’ variable that shows only CIs assigned to the user populated in the ‘Caller’ field.
10 – Table and Field Manipulation
Simple field and table manipulation is almost always something that can be done without any scripting at all in ServiceNow. It’s also something that can get you into a lot of trouble if you don’t know what you’re doing! Mastering this is one of the keys to being able to extend the functionality of your instance to completely new areas that are specific to your organization. These exercises will help you get your bearings.
- Add a new 40-character string field to a table.
- Personalize the dictionary for this field. Change the field to a new field type. Notice that not all of the available field types show up in the list to change to. Why?
- Change the max length of the field to 255. What happens to the look of the field? Change the max length to 256. What happens to the look of the field? Change
the max length back to 40. What happens? Why?
- Delete your field. Hint: NEVER delete a dictionary entry!
- Create a new table. Add fields to the table. Set the display value for the table. Set up auditing for the table.
- Add a few records to your new table. Without using any script and without using the record list, delete ALL of the records from this table.
- Delete your table. Hint: NEVER delete a dictionary entry!
- Create a new CI class by extending the ‘Configuration Item’ table. Find the number of tables that extend the ‘cmdb_ci’ table.