It’s a developer’s worst nightmare. You’ve spent weeks, maybe months perfecting your latest roll-out. You’ve got your workflows, forms and fields all in order and everything works perfectly in dev. You push your sets and do a couple of tests and…wait a minute. Why isn’t anything assigning to the right groups or people? All of that work down the drain! How could this have gone so wrong?
It’s a scary-looking problem with a simple solution. Your core data is not in sync!
So… What is Core Data?
Core data is a set of tables with user, group and organization data that ServiceNow uses to assign and route tasks and other records. What is considered core data will be slightly different in different implementations depending on which tables are being used, but it will generally include the following tables:
- Users [sys_user]
- Groups [sys_user_group]
- Group Members [sys_user_grmember]
- Locations [cmn_location]
- Companies [core_company]
- Departments [cmn_department]
- Roles [sys_user_role]
- User has Role [sys_user_has_role]
- Access Control (ACL) [sys_security_acl]
These are the ones that hold the data on your employees and locations, their roles, what groups they belong to, and what information those groups get to access in ServiceNow. This is the glue that holds all of your processes together, and keeping this data in sync between instances will allow your developers to build and test with the confidence that the thing that works in Dev will work just the same in Prod.
Going with the (Data) Flow
So how do you begin? Start by determining the way you want information to flow. There are multiple ways to go about it, each with their own pros and cons:
OPTION 1: From Dev to Prod
Say we consider Dev to be the source of truth. That means that all of the core data gets entered and manipulated in Dev and then those changes get pushed to the other instances. Seems legit, right? Your developers are used to making changes in Dev and pushing them up to Prod, it’s a familiar way to work. You don’t want them messing with live data in PROD, do you?
Well, maybe. One of the problems with flowing information from Dev to Prod is that so many people have access to that data in Dev. It’s hard to trust data that everyone has had their hands and their test uploads and their data dumps on. Can we really be 100% sure that the spreadsheet of new asset tags that were uploaded last week didn’t make any changes to our core data? Do we want to have to do all that double-checking all the time? Maybe. Maybe not.
OPTION 2: From Prod to Dev
Ah Prod. The clean instance…the one that contains only the stuff we really want to put in it. Surely that’s the best place for your source of truth when it comes to core data. After all, only a handful of people have access to make changes in Prod, and less access means less chance of questionable data. The thing is, Prod is LIVE, meaning people are actively using the system and will absolutely notice right away if something goes sideways due to a change in core data. Making changes directly in Prod is like working fifty feet in the air without a net and for that reason it makes many developers very, very uncomfortable. Are you feeling lucky? Maybe. Maybe not.
OPTION 3: Both/Neither/Hybrid Option
Because Prod is the cleanest, happiest, and BEST place to use as a source of truth, and Dev is the friendliest, safest, and BEST place to make changes, it’s possible that a hybrid option is the way to go. It’s like this: Prod is your source of truth. It holds all of your beautiful, precise, correct core data. Which is why when you want to make a change to it, you could pull that information down to Dev, overwrite the messy, picked over swampland that is your Dev core data, and have a fresh, clean, set of data that matches Prod that you can now make changes to. Make your changes quickly, verify them, then push that data back up to Prod and… voila! Could it work? Absolutely! Will your developers remember to consistently pull down fresh data and push it right back up after making their changes? Every time? Maybe. Maybe not.
The truth is, there is no one best way! It’s up to you to weigh your organization’s needs, consider the precision of your development team, and come up with a data flow that works for all of you. Then all that is left is to decide how often you need to refresh that data from your source of truth, and that will tell you whether you can do it manually, bundle it in to a clone or set up a scheduled job to run in the background and do it for you.
So, my friend, you’ve got a few decisions to make. Setting up a process to keep your core data in sync now can save you months of reworking and extra development time. It can even spare you that little jolt of panic you get when the thing you built in Dev doesn’t work in Prod. We’ve all been there. So do yourself a favor and get that core data in sync!
Author: Carrie Padian – Sr. Technical Consultant
Carrie is a self-described process nerd with almost 20 years of experience in the Information Technology space. She is a frequent blogger, presenter, and podcast panelist for Cerna Solutions, with a unique gift for creative problem solving. You can also find her on Twitter at @ITSMcarriep.