HRSD Implementation Guide

[Max Dore]

This article covers general information and specific gotchas that most Technical Consultants (aka Developers) encounter to help guide you to a successful HRSD implementation, regardless of the Release version.

To those who have experienced additional HRSD related gotchas or have great tips, please comment them! I will review and add them to this article periodically so we can all learn, improve, and have a living document we can all refer to for success. Give this a thumbs up if you find any of it helpful too!

Before the Project:

Incomplete Requirements & Scope Creep:

• Failing to fully capture business requirements (such as detailed service definitions, Record Producers, and escalation paths) can lead to scope creep and misaligned expectations. Identify potential risks early, such as integration delays or dependency issues with third-party vendors and develop contingency plans.
• Tip: Use standardized templates (like an HR Services Requirements Workbook) and run focused discovery sessions with the proper stakeholders.

Plugin and Release Readiness:

• No need to wait until development begins to start a Go-Live workbook. Include all Plugins (including dependencies if any) and any Release compatibility issues later down the road. Later you will add all information and steps which will guide you toward Go-Live.
• Tip: Verify your instance’s release version and planned upgrades, and ensure all required plugins are installed by the proper party before starting configuration.

Integration Strategy Gaps:

• Not planning for integrations with external systems (Workday, SuccessFactors, etc..) will delay data synchronization and affect end-to-end processes. Most of the time integrations take the longest to develop so begin asap.
• Tip: Develop a clear integration strategy early in the project with proper mapping and error-handling procedures.

Stakeholders:

• Depending on the size of scope and organization, employee related products often mean that HR stakeholders must work with the IT stakeholders, if not others too. In my experience, this creates a lot of delays because all parties must be on the same page for timelines, administration, who does what and when, etc..
• Tip: Start workshops only when there is a conclusion to move ahead.

Security & Role Misconfigurations:

• Failing to properly design COE security policies (and possibly ACLs) can expose sensitive HR case data and/or lead to agents seeing cases outside their domain.
• Tip: Define role-based access and “Deny-Unless” security upfront and test these during the design phase.

During the Project

Activating a COE:

• Depending on the Release you are working with, you may be able to toggle on a COE table within the COE Configuration module and then have access to that table.
• Going forward with Releases, you cannot toggle on a COE, you must first create a Topic Category, Topic Detail, and then create your HR Service(s). When configuring a new COE there will be missing records that OOTB activated COEs have. These include notifications, inbound actions, SLAs, assignment rules / matching rules, contextual search, agent assist on those COEs and others. What some developers do to same time is use records of existing COEs to Insert and Stay with the new COE table and add their specific configurations.

COE Fields:

• Don’t create the same fields on each COE table. For those that are used on multiple COEs, make use of table inheritance and create them on the core case table. Create on the child COE table only if the field is applicable for that COE’s HR Service(s).
• Field creation process: create the field, add it to the form layout, on the pre-existing “Hide HR service fields and related lists” UI Policy you must add a UI Policy Action with Visible set to False, and on the HR Service(s) it is meant for add the new field name to “Service table fields” on the HR Service.

Customization Overload:

• Excessive customizations (think overly complex navigation handlers, custom UI actions using DOM hacks) can break with Release updates. Lead developers should identify what customizations are likely needed for each Story and why this solution had to be chosen.
• Tip: Get customizations approved by the Governance board. This guarantees all parties are in agreement and not lead to blame.

Navigation and Redirection Pitfalls:

• Misconfigured navigation handlers can force users into the classic UI or lead to inconsistent workspace views, impacting agent productivity.
• Tip: Test navigation scripts extensively with different roles.

Insufficient Training and Knowledge Transfer:

• Underestimating the training needs of both the technical team and end users may result in resistance or misconfiguration post-deployment. Hold a KT session for each Sprint. Whether people attend or not, you should record and share it for their later use (with permission of course).
• Tip: Too often this task waits until the end of an implementation and there is too much to convey and digest at once with too little time to dedicate to it, so begin at the start.

Update Sets:

• If using Update Sets, there are several things to know to minimize errors and surprises:
• There are certain records that do not get automatically added to Update Sets so you must add them manually: tables that don't extend the sys_metadata table such as Users/Groups and their relationships, Checklists and their Items, Scheduled Jobs, Tags, Restricted Caller Access, COE Security Rules’ Groups, translations records, and many others records like tables that do not have the update_synch attribute.
• Developers create records by mistake, we all do, and these most often get recorded to Update Sets. Therefore, before closing an Update Set, remember to search for and remove DELETE type of updates. The exception is for records in the target instance that need the record deleted. Furthermore, there may be INSERT_OR_UPDATE records that were also unintentionally added to the Update Set(s) which should be removed. Both of these are because only the necessary updates (sys_update_xml) should be moved between instances.
• Working with scoped applications means that you will need at least one Update Set per scope. For example, update records in the HR Core scope must be in an Update Set of the HR Core scope. While you technically can mix and match update record scopes in one Update Set, this will lead to lots of errors you can’t bypass so keep them separate, no matter how many Update Sets you must create.

Performance and Scalability Issues:

• Custom dashboards, too many UI components, large queries and the likes lead to increased response time.
• Tip: Optimize dashboard configurations, limit the number of components on landing pages, test on multiple device types, and test response times.

Integration & Data Sync Delays:

• Inconsistent data from external systems due to API rate limits or misconfigured integration flows can lead to incomplete or delayed HR case information.
• Tip: Monitor integrations continuously, establish clear SLAs with integration partners, and collect all party contacts and vacation dates to plan around. You don’t want to get to UAT and find out key testers are out of office for a month.

Too Much Too Late:

• Have a hard-set date for when the last tweaks of configurations are accepted. I would recommend having this be at the very least two-four weeks before go-live depending on the size of the project, could be even before. This hard-set date must be communicated and confirmed by all parties at the beginning.
• Tip: In my experience, translations are often the last ones to be pushed through at the last minute in HRSD projects. Plus, if it’s handled by a 3rd party the timeline is out of your control, so don’t put yourself in that situation.

After the Project

Post Go-Live Optimization Overlook:

• Failing to monitor KPIs (such as case resolution times, agent productivity, and user satisfaction) can hide inefficiencies in the system.
• Tip: Use dashboards and periodic HRSD Maturity Assessments to continuously monitor performance and gather feedback from end users.

Change Management and Ongoing Training:

• Hold recurring meetings with all key stakeholders to discuss progress, integration challenges, and any delays caused by third-party testing. Without ongoing support and training, users might revert to old practices, and custom configurations may not evolve with business needs.
• Tip: Use project management tools to share dashboards that show progress, risks, and upcoming milestones.

Documentation Gaps and Knowledge Loss:

• Not updating internal documentation with lessons learned or customizations made during the project can result in knowledge loss over time. This documentation will help you and your team improve with each iteration, as well as provide up to date training for future employees/admins.
• Tip: Maintain a living document (many call this a playbook) and incorporate feedback and experiences to keep it current.

Unaddressed Scalability and Maintenance Challenges:

• As case volume increases, performance and configuration issues may surface, requiring periodic tuning and optimization.
• Tip: Plan for regular system reviews, update processes with new ServiceNow releases, and keep an eye on community best practices.

Conclusion

A successful HRSD implementation on any release requires careful planning, mindful customization, and continuous post-deployment optimization. By anticipating these common gotchas and recommended tips, technical consultants can mitigate risks and ensure a smoother, more effective deployment.

If this was helpful give it a 👍 and remember to share what you think would be great to add and I’ll check it out. Let’s all get better together!