As part of the Spotlight on Tech series, we asked Justin Anonuevo, Lead ServiceNow Developer, how his team is handling the employee ID change.
Give us a brief description of the ServiceNow application and how the employee ID plays a role in managing your business
ServiceNow is a platform used to manage IT Incidents, HR cases, and a growing number of service requests. If you’ve ever had something technical break, needed to go on leave or just couldn’t remember your password, you probably used ServiceNow to contact some of the fantastic support teams on campus to deliver what you needed.
Employee IDs play a critical role in how ServiceNow manages user records and integrates with other systems around campus. Not being a system of record, we maintain a list of users and ID numbers associated with them so that we can work with the systems of record to retrieve information and send requests to fulfill our customers’ needs.
A primary example would be the Human Resources modules we built for Campus Shared Services, which integrates with some external systems like HCM to retrieve and display information to customers and agents that they need to properly request and fulfill services. These services include recruitments, separations and position funding changes.
For example, with Funding Changes, ServiceNow uses the employee ID to get the employee’s current funding information, position details, and manager. This scenario gives customers a reference, so they can focus on only the changes they want to make. Approvers and HR agents then see a form of the old and new information, so they can review the request and make appropriate changes to the actual funding record. This process is all coordinated using the Employee ID as a way to let customers, approvers, agents, and systems work on the same record.
How did you start assessing the impact (if any) the UCPath employee ID change would have on your application? Were there any surprises when coming up with a plan to address the employee ID change?
When we reviewed the documents provided by the UCPath team, our development team was able to engage in discussions about how this could impact the ServiceNow platform and the functionality we currently deliver. We were able to review our programming libraries and custom applications to see where we would run into problems.
Since we had ample notice of the change, our team was able start early work on implementation and run ample tests against the Human Capital Management (HCM) QA instance of the API, which uses the employee ID. Nothing will ever prevent surprises, but this effort lets us find and fix issues early, preventing surprises to our customers. It is significant work for us, but we do this so our customers never know anything changed. Quoting Futurama, “When you do things right, people won’t be sure you’ve done anything at all.”
Do you have any words of wisdom to share, and recommendations for other application owners who are also assessing and planning for the employee ID change?
One of the biggest changes we have to worry about is the length. Changing from nine to eight digits means some of our validation no longer work. It’s not a hard change to make, but we need to make sure we catch it wherever a validation like that takes place. Working early helps us catch problems before our customers do.
A unique identifier (UID) is also a viable alternative when possible. It is more stable, but isn’t zero padded, so it has a variable length, some of which are seven digits long. It won’t be long before it reaches eight digits and overlaps with the new employee ID numbers. Make sure you don’t have any issues with overlap.
It is a lot of work. But it has to be. Employee IDs are one of the core pillars we use to manage identities within UC Berkeley and across the UC system. The best thing we can do is to work early so the transition is smooth and our customers never know anything happened.