Here are some tips to avoid some design and programming mistakes you can make with ServiceNow.
Duplicate Records
When you run any import with ServiceNow, you should always check to see if any duplicate records are being created. When using ServiceNow Discovery or any CMDB imports this is especially important.
For instance if you are creating duplicate CIs, users will begin to tie those duplicate CIs to incidents, changes, etc. Getting rid of a duplicate CI once it is related to a task is difficult. You can deactivate the duplicate CI, but then you still have a CMDB with duplicates. Deleting the CI means the task will lose that CI information. Fixing the issue will have some bad consequences either way.
It is important to fix this issue immediately when it happens, so that it doesn't become a disaster. I suggest running Duplicate Record reports monthly to catch these duplicates.
current.update() in a Business Rule
Business Rules run before, after, and display of a record. When you use current.update() in a business rule, that will cause a "double update" of a record or worse.
Here are some examples of the chaos this can cause:
- before Business rule and current.update(): Business rule runs, current.update() saves the record, remaining business rules run and record will saved again
- after Business rule and current.update(): Record saves. after Business rule runs, current.update() saves the record again
- async Business rule and current.update(): Record saves. async Business rule runs later on, current.update() saves the record again
- display Business rule and current.update(): display Business rule runs every time the form is displayed and the form attempts to save due to current.update(). User might not have filled out the form all the way and it is an annoying experience to the user.
Don't use current.update() in a business rule! There are certain situations when it is ok, but very rarely. Same goes with using g_form.save() in a client script.
License Count Check
Every user that has a role counts against your license count. You have to periodically check to make sure you fall under those license counts. If you go over, you'll have to remove some full access or purchase more licenses. If you go way over, you may have a big problem.
ServiceNow licensing is changing with these new releases. Meet with your account representative to check your licensing restrictions.
Workflow Design Mistakes
Designing workflow for items in your Service Catalog is "easy" as long as you follow these guidelines
- Stages. Remember to setup and use Stages in your workflow. If you don't have a closing stage (complete or Request Cancelled), the request will not close. People will eventually ask you why their requests don't close, and you'll have to fix that issue. This article helps if you made that mistake.
- Deadends. Workflows today warn you if you are making a workflow with a dead end. However if you ignore the error it is still possible to do. Just remember to not leave any workflow activities not connected to the next activity or end.
- Broken Scripts. If you use scripts in your workflow, make sure to test thoroughly that they work. Workflow will just stop if encounters a script error. It doesn't throw an error to the user, and the workflow will just stop partially through if left that way.
- Workflow with wrong properties. If you build a workflow with the wrong start condition for Requested Item, it may just take over for all requested items. When building a new catalog item, test your catalog item and another catalog item to make sure you didn't affect other Requested items with your property settings. I like to copy workflows to avoid this issue, but if you like to start from scratch, check your properties.
- Endless Loops. It is possible to create endless loops in workflow. Avoid doing that. This issue is pretty easy to notice in testing and is kind of funny, but not really.
- Complex Workflow. Although you can make spaghetti workflow that looks like it could be used for a space shuttle launch, it isn't a good idea most of the time. Try to make workflow people can understand and handle. I have seen workflows that generate 100's of child tasks. Usually that many tasks mean that they won't get closed due to user availability/interest, and the workflow is unsuccessful.
Error Log Ignorance
Not checking the error or warning logs is a good way to avoid the problems in your life. Just like in life, if you ignore your problems for a long time, it can cause major issues.
Javascript is a resilient language, it can have errors and not crash. However that doesn't mean your system is working great. Check the error and warning logs and fix the issues..
No Update Sets
Teach yourself how to use update sets right away. Don't wait until after your implementation date to start using them. Without update sets, you might be inclined to write code directly in production. This is a really bad idea for lots of reasons. Especially if you are not exactly "servicenow elite" initially and might make a few mistakes.
Email Integration Reliance
In my opinion, email integrations are the worst integrations you can build. They are prone to network error, can be difficult to maintain, and the more you have, the worse it gets. Figure out how to build web services integrations, you will be glad you did.
Report Madness!
Do you need to build 1500 reports for your initial implementation of ServiceNow? No! People will not view that many reports. Pick the important reports you need and have the users build their own additional reports. It can actually be detrimental to the user to have that many reports to pick from, it is sea of reports they don't care about.
Another pitfall is homepages with slow reports or many gauges on them. A useful technique is to run "Debug Homepage Render" on all your homepages. That way you can tell what reports and homepages are slow and fix those issues.
Big Bang Approach
Sometimes you don't have a choice and have to implement ServiceNow all at once and not one application at time. Try to avoid this if you can. Once ServiceNow is in Production, that is when you really get feedback on how it works. Using the Big Bang approach to implementations means you will get a lot of feedback on day 1 of the implementation. It can be very stressful and not fun.
Many Related Lists
In ServiceNow, Related Lists are the lists that load at the bottom of the form. They display records in another table that have a relationship to the current record.
These are most noticeable in Project Management, where there can be many related lists. When you open a project form, ServiceNow has not only has to load that project record, but also do all the queries for the related lists before the form loads. ServiceNow Fuji allows you to adjust the related list loading settings, which can greatly improve performance.
Reading the instruction manual
I do recommend reading the ServiceNow Wiki, ServiceNow Share (and this website!) before you start building a new customization. That customization might already exist. ServiceNow has been around for a long time now, and there are no original ideas anymore. :)