OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow employee service practice

ServiceNow employee workflows and HRSD that people can complete

ServiceNow employee workflows and HRSD should make a difficult employee request easier to complete, while giving the service team enough context to act responsibly. OBLYTECH helps organisations shape these boundaries around the work employees actually need to do.

Discuss an employee-workflow priority

Start with the employee moment

Describe the moment that starts the request: a new joiner needs access, a policy question needs an answer, a personal change needs review, or a manager needs help with an employee process. The workflow should make the next action clear without forcing the employee to understand internal team structures first.

Design intake around the information needed

Ask for information because the service team needs it to make a decision or complete work. Explain why a field is present when the request is sensitive or unfamiliar. Keep the first interaction focused, then collect additional context when the case reaches the team that needs it. This creates a better boundary between a useful request and unnecessary exposure.

Make ownership and routing visible

Routing should reflect the work, not merely the name of a department. Define the conditions that send a request to a team, the owner responsible for the next decision and the handoff point when the request changes shape. A case that moves between teams without an accountable owner is difficult for both the employee and the service team to follow.

Keep sensitive information in the right boundary

Employee workflows need a deliberate distinction between what the requester can see, what a manager can see and what only an authorised service team can process. Test the boundary through the case lifecycle, including updates, attachments, approvals and notifications. Do not assume that a correct intake form creates a correct privacy boundary later.

Use approvals only where they change the decision

An approval should answer a real decision question. Define who can approve, what information is available, what happens when the decision is declined and how an amended request returns to the right path. Removing unnecessary approvals can reduce waiting without weakening the decision boundary.

Connect knowledge, cases and follow-through

Knowledge should help an employee choose the right route or complete a safe step. When an article cannot answer the question, the handoff into a case should retain the context the employee has already provided. This creates a practical connection between self-service content and assisted service rather than making the employee start again.

Measure completion without losing context

Measure whether the employee reached a clear outcome, whether ownership changed without explanation, whether the request was reopened and whether the workflow created avoidable handoffs. A count of closed records does not explain why work was easy or difficult. The useful review connects the measure to the path the request took.

For the wider platform operating model, see ServiceNow security, risk and governance. When privacy and role boundaries are central, review ServiceNow access, privacy and segregation of duties.

Discuss an employee-workflow priority

Bring one employee request that creates repeat questions, unclear ownership or avoidable handoffs. OBLYTECH can help map the employee moment, information boundary and accountable route through the platform.

Start the conversation

Which HR requests belong in a case and which belong in a conversation

HR service delivery sits between two kinds of work. Some requests are routine and should be handled as cases: a letter for a mortgage application, a change of bank details, a question about a benefit. Others are sensitive, personal or open-ended, and a case record would be the wrong tool for them. A grievance conversation, a request for adjustments after a medical appointment and a concern about a manager may need a human conversation first, with a case opened only when a decision or an action must be recorded. The design question is where that line sits, and it should be drawn before any intake form is built.

This page is for HR service delivery leads, HR business partners and the platform owners who support them. It assumes HR already receives requests through email, forms or a shared inbox.

RequestCase or conversationWhyBoundary to set
Letter or certificate of employmentCaseRoutine, time-bound and produced from a recordOnly the requester and the processing team see the case
Change to personal detailsCaseNeeds verification and an audit trailVerification evidence is held in a restricted field
Request for workplace adjustmentConversation first, then a caseNeeds discussion before any decision is recordedThe detail stays in the conversation; the case holds the decision and the agreed action
Concern about a manager’s conductConversation first, then a restricted caseDepends on judgment and may need a separate processAccess to the case is limited to the people running the process
General policy questionKnowledge article with a case fallbackUsually answered once and reusedNo personal data is needed to find the answer

Each organization has its own policy, and the point of the design is to make the choice explicit so that the same kind of request is handled the same way each time.

Confidentiality tiers that match how HR actually works

A single confidentiality setting for every HR case is too blunt. Some cases can be seen by the employee’s manager, some only by the HR team and some only by a named investigator. A three-tier model is common in practice: a general tier that anyone in the HR service team may see, a restricted tier for cases that involve personal health, finance or family information, and a sealed tier for cases where access must be limited to a short named list. The tiers should map to real roles, not to job titles that change frequently.

The tier must be set at intake and checked again whenever the case changes shape. A routine request can become sensitive when a manager adds a comment or an attachment, and that change should trigger a review of who can see the case. The boundary has to hold through updates, notifications and attachments, not only at the first screen.

Replacing, extending or sitting beside existing HR tools

Many HR teams already use a human resources information system for records and a separate tool for case handling. The workflow decision is whether ServiceNow should replace the case tool, extend it, or sit beside the HR system and take only the service requests. Replacement is the cleanest on paper and often the most disruptive in practice, because employee records and case histories must be moved and reconciled. Sitting beside the system is often the least risky first step, provided the handoff of data is controlled and the source of each field is clear.

Extending means ServiceNow reads from the HR system but does not hold the authoritative record. That arrangement works when the lookups are reliable and their cost is acceptable. It fails when the HR system is slow, its fields are inconsistent or its access model cannot be mirrored. The decision should follow a short test of the data the workflow actually needs, not a general comparison of platforms.

Case categories an HR team can maintain

HR case categories are often copied from a template and then left alone, and the result is a list of categories that nobody uses correctly. A workable list is short, describes the work rather than the department and maps to a distinct resolution. If two categories lead to the same action, they should be merged. If a category exists only for reporting, it should be moved into reporting. The list should be reviewed whenever a policy changes, because policy change is a common reason an existing category stops fitting.

Each category should also have a named owner in HR who understands the policy behind it. Without that owner, the category becomes a place where cases wait for a decision nobody is equipped to make, and the employee has no way to tell whether the case is progressing.

What a manager should see and what they should never see

Managers are both users of the HR service and subjects of some cases. A manager may need to see that a request is in progress, that a decision is pending or that an action is due. They should not automatically see the content of a case that concerns their own conduct, a health matter or a complaint. The design has to separate the manager’s view of progress from the case’s content, and it has to do so consistently across updates, email notifications and attachments.

Notifications are a common leak. A workflow that sends a full summary to a manager’s inbox may expose information the manager should never have read. Notifications should carry a status and a link that resolves only for people with access, and the design should be tested by someone who is deliberately looking for the leak.

  • Confirm which roles can see the case status, the case content and the attachments as separate permissions.
  • Test the notification text for each tier, not only the case screen.
  • Check the access rules again when a case is reassigned to a new team.

Service levels for HR cases that depend on other teams

Many HR cases cannot be closed by HR alone. A payroll correction needs finance, an access change needs IT and a workplace change needs facilities. A service level that measures only HR’s own step will look healthy while the employee waits for the other team. The better approach is to set the expected time for the whole case, record each dependency with its own expectation and show the employee which step is waiting and on whom.

The service level and experience management route is about connecting scope, timer rules, ownership, targets and review evidence. For HR, the expectation should be written in terms of what the employee will be told and when, since an employee who knows the next step is less likely to escalate than one who sees nothing move.

Common questions about HR service delivery workflows

Does HR service delivery suit a small HR team?

It can, if the team starts with a short list of routine cases and a single confidentiality tier. A small team benefits most from clear routing and a consistent letter or change process. Sensitive case handling can wait until the routine work runs well.

What happens when a case becomes an investigation?

The case should move into a sealed tier with a named investigator, and the original intake should remain as a record of how the matter arrived. The investigation process itself usually sits outside a general service workflow, and the design should be clear about where the platform’s role begins and ends.

Can employees see the progress of their own cases?

Yes, for the status and the next expected step. The employee should not see internal notes or the content of other people’s cases. The status view is often the most valuable thing an employee gets from a workflow, because it removes the need to chase.

How does this connect to the employee front door?

Employees should reach HR cases from the same entry point as other services, but the front door should not reveal sensitive case categories to people who do not need them. The employee center and self-service route is about organizing employee tasks, knowledge, search and ownership, and the HR case design should be planned with it.

If HR requests are arriving by email or in a shared inbox, and sensitive cases are being handled in the same place as routine letters, bring one request type and its path through the team. Discuss your HR service workflow with OBLYTECH.

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More in this section