Design recommendations for an HRSD annual benefit eligibility review process

Kohei Tominaga1
Kilo Sage

Looking for design recommendations for an HRSD annual benefit eligibility review process.

Requirements:
• All eligible employees must review and respond annually
• Most employees will have no changes
• If no changes are reported, we would like to avoid creating an HR case
• If changes are reported, an HR case must be created and processed
• Some changes may result in benefit suspension or termination, so follow-up HR actions must be tracked and completed
• We need to track the end-to-end process and ensure there are no employees who reported a change but never completed the required follow-up process

We considered Surveys/Assessments, Content Publishing To-dos, and creating HR cases for everyone, but each approach seems to have trade-offs.

How have others implemented this in a Fit-to-Standard way within HRSD?

2 REPLIES 2

SupriyaWaghmode
Mega Sage

Hi @Kohei Tominaga1  ,

 

To achieve a Fit-to-Standard implementation in ServiceNow HRSD that minimizes case volume while ensuring strict compliance, the best practice is a hybrid approach combining Lifecycle Events (LE), Targeted Campaigns (Content Automation), and Employee To-Dos

 

Stage Component Functional Behavior
1. Push Initiative Content Publishing & Campaigns Send targeted communications (emails, portal banners) directing employees to their Employee Center To-Do list.
2. Initial Response HR Task (Lifecycle Event) The employee is assigned a single HR Task of type "Submit Catalog Item" or "Custom URL/Form" within an overarching Lifecycle Event.
3. Decision Routing ServiceNow Decision Tables The employee selects a boolean/radio option:
• "No Changes": The task completes, updating the LE state. No HR case is created.
• "Changes Reported": The system triggers a downstream Activity Container within the same LE.
4. Case Fulfillment HR Service / HR Case If changes are reported, a specific HR Case is dynamically spun up. This case holds the workflow for validating the change and updating downstream payroll/benefits providers.
5. High-Risk Tracking HR Task Checklist & SLAs If the change triggers a suspension/termination, specific sub-tasks are added to the HR Case. Response SLAs ensure HR professionals complete these actions timely.

 

If my response helped, please mark it as the accepted solution so others can benefit as well. 

 

Thanks & Regards ,

Supriya Waghmode 

sanjaygupta
Tera Guru

A Fit-to-Standard approach would be to use Lifecycle Events for the annual review and create HR cases only when an employee reports a change that requires HR intervention.

This avoids creating unnecessary HR cases for employees who confirm that their benefits remain unchanged, while providing visibility into the activities that require follow-up.

I would suggest the following design:

  • Configure an annual review Lifecycle Event for the eligible employee audience.

  • Add an employee activity to capture the annual eligibility confirmation.

  • Include conditional questions to identify whether the employee has any changes to report.

  • For employees reporting no changes, complete the review activity without creating an HR case.

  • For employees reporting changes, trigger the relevant HR service to create an HR case.

  • Configure the required HR tasks or child cases for benefit suspension, termination, or other follow-up actions.

  • Track completion through the Lifecycle Event activities and associated HR cases.

  • Configure the HR service activity to wait for the generated HR case to complete before closing the activity.

  • Use the Lifecycle Event activity status to monitor outstanding employee responses and follow-up actions.

  • Build reports to identify employees who reported changes but still have incomplete activities or open HR cases.

This approach uses the existing HRSD Lifecycle Events framework rather than creating a separate case for every employee.

One important consideration: the conditional branching and automatic case creation based on the employee's response may require Flow Designer configuration. Validate this against the capabilities of your installed release before introducing custom development.

References:

Hope you find this helpful!