The Phase That Always Gets Compressed

Ask any project manager on a delayed SAP ESM implementation what happens to the UAT phase when the schedule slips, and you will get the same answer: it gets compressed. Scope gets reduced, test cycles get shortened, defects get deferred, and teams convince themselves that what does not get tested in UAT will get caught in production.

It will. And it will be far more expensive to fix.

UAT — User Acceptance Testing — is the last structured opportunity to validate that everything you have designed, configured, and integrated actually works as intended, end to end, in a realistic environment, with real HR scenarios. It is not a technical check. It is a business validation. And done well, it is what separates a confident go-live from a nervous one.

This post gives you the framework to do it well.

What UAT in ESM Is — and What It Is No

A common mistake is treating ESM UAT as a feature checklist: “Can I create a case? Can I close a case? Can I search the knowledge base?” That approach will pass most scenarios and miss most of the real risks.

UAT for SAP ESM for HR is the validation of **end-to-end workflows** across all configured channels, categories, routing rules, SLA timers, integrations, and user roles, under realistic conditions, performed by the people who will use the system on day one.

The question you are answering is not “does the system work?” It is: “does the system work the way our HR operation needs it to, for every scenario that will arrive on day one?”

That is a materially different test.

Who Needs to Be in the UAT Team

UAT is not an IT activity. It is a joint business and IT activity, and the business must lead it.

The UAT team for an ESM for HR implementation should include:

| Role | Responsibility in UAT |

• | **HR Agents (Tier 1)** | Test case creation, routing receipt, case processing, response templates, SLA visibility |
• | **HR Specialists (Tier 2)** | Test escalated case handling, complex category workflows, direct-to-Tier-2 routing |
• | **HR Managers / Supervisors** | Test supervisor views, SLA dashboards, escalation notifications, team workload visibility |
• | **IT / Integration team** | Test SuccessFactors data validation, outbound transaction execution, IAS/SSO, BTP connectivity |
• | **Employees (pilot group)** | Test the self-service portal, case submission, status tracking, email acknowledgement receipt |
• | **UAT Coordinator** | Manages the test script, logs defects, tracks sign-off, coordinates the go/no-go decision |

The employee pilot group is the component most commonly omitted from UAT. This is a significant gap. HR agents can test the agent workspace all day, but only an actual employee can validate what the self-service experience feels like — whether the portal is navigable, whether the category options make sense, and whether the confirmation emails are clear.

Minimum recommended pilot group size: 10–15 employees drawn from different countries, departments, and seniority levels if your rollout is global.

The Five Test Scenario Types

A well-structured ESM for HR UAT covers five distinct scenario types. Each tests a different layer of the implementation. Missing any one of them leaves a class of risk untested.

Scenario Type 1 — Case Creation by Channel

What you are testing: That every configured inbound channel correctly creates a case, assigns it the right category, applies the right employee context, and routes it to the right team.

Test scenarios to include:

• Employee submits a case via the self-service portal (standard category, correct country)
• Employee emails the **HR mailbox** — case auto-creates with correct subject mapping and employee lookup
• HR agent manually creates a case on behalf of an employee (walk-in / phone call scenario)
• Employee uses SAP Joule — question answered from knowledge base (deflection success), and question not answered — case created automatically (deflection failure → case creation)

What to look for:

• Does the employee's SuccessFactors profile load correctly in the case context?
• Is the auto-acknowledgement email sent within the configured time (best practice: 5 minutes)?
• Does the case land in the correct Agent Group queue?
• Is the category pre-populated correctly for email-created cases?

Scenario Type 2 — Routing Validation

What you are testing: That every case category routes to the correct HR team, under every combination of employee country and org unit that is in scope.

This is the most labour-intensive scenario type because it requires you to test the routing matrix — every category × every country combination — not just a representative sample. Routing errors are silent in the system: the case creates without error, it just lands with the wrong team.

Test scenarios to include:

• Same category submitted by employees in three different countries — verify different Agent Group assignment
• Category that should route directly to Tier 2 (e.g., Employee Relations) — verify it bypasses Tier 1 entirely
• Category submitted by an indirect employee (non-SuccessFactors EC) — verify fallback routing behaviour
• Case submitted outside business hours — verify correct handling (queued, auto-reply, or out-of-hours team)

What to look for:

• Does every category × country combination route to the expected team?
• Is the direct-to-Tier-2 routing behaving correctly for complex categories?
• What happens when the routing rule finds no match? Is there a safe fallback?

Scenario Type 3 — SLA Configuration

What you are testing: That SLA timers start correctly, business hours are applied accurately, warning notifications fire at the configured threshold, and breach notifications trigger on time.

SLA testing is frequently under-tested because testers do not want to wait for real-time timers to expire. The solution is to use test SLA configurations with compressed timers (e.g., 5-minute resolution SLA instead of 8-hour) in the UAT environment — then revert to production values before go-live.

Test scenarios to include:

• Create a case and verify the SLA milestone fields populate with the correct due timestamps
• Let a case approach the warning threshold — verify the warning notification fires to the correct recipient
• Let a case breach — verify the breach notification fires, and any configured escalation actions execute (reassignment, priority change, supervisor notification)
• Create a case outside business hours — verify the SLA timer does not count non-business hours
• Test a public holiday calendar — verify the SLA timer pauses correctly on a configured holiday

What to look for:

• Do SLA milestone timestamps reflect the correct business hours calculation?
• Do warning and breach notifications reach the right recipients?
• Does the escalation action (reassignment, priority change) execute correctly at breach?
• Are public holidays and time zones handled correctly for each in-scope country?

Scenario Type 4 — SAP SuccessFactors Integration

What you are testing: That the integration between ESM and SuccessFactors works correctly in both directions — inbound employee data validation and outbound transaction automation.

This is the highest-risk scenario type in terms of go-live impact. An integration failure on day one affects every case, not just edge cases.

Test scenarios to include:

• Submit a case as an active employee — verify the full SuccessFactors employee profile loads in the case context (name, employee ID, country, company code, org unit, manager, employment status)
• Submit a case using an inactive employee ID — verify the system handles the lookup gracefully (error message, fallback behaviour)
• If outbound transactions are in scope: trigger an automated HR transaction from a case (e.g., address change, leave request) — verify the transaction executes correctly in SuccessFactors and the case is updated with the outcome
• Verify SSO: log in as an employee via the self-service portal — confirm no separate login is required
• Verify IAS role propagation: log in as each user role (employee, HR agent, HR supervisor, HR administrator) — confirm each sees only what they should see and can perform only the actions they should be able to perform

What to look for:

• Is the employee data lookup fast enough to be acceptable in production? (More than 3 seconds is a usability concern)
• Are all expected SuccessFactors fields visible in the ESM case context?
• Do outbound transactions execute without errors, and are they reflected correctly in SuccessFactors?
• Does SSO work without prompting for credentials?

Scenario Type 5 — End-to-End Lifecycle

What you are testing: The full lifecycle of an HR case — from submission by an employee, through routing, agent processing, escalation if needed, resolution, employee notification, and case closure — across several representative scenarios.

This is the most important test type because it validates the system as a whole, not its individual components. It is also the scenario type most likely to surface integration and configuration gaps that were not visible in isolated tests.

Representative end-to-end scenarios to include:

• Standard query resolved at Tier 1:

Employee submits payslip query via portal → routed to Payroll team → HR agent responds → employee receives notification → case closed → CSAT survey sent (if configured)

• Query escalated from Tier 1 to Tier 2:

Employee submits query via email → Tier 1 agent reviews and escalates → case reassigned to Tier 2 specialist → specialist resolves → employee notified → case closed

• Direct-to-Tier-2 complex case:

Employee submits an Employee Relations query → routes directly to ER specialist → specialist processes → case closed with internal notes

• SLA breach scenario:

Case created → not actioned within SLA window → warning fires → breach occurs → escalation notification sent to supervisor → supervisor reassigns → case resolved

• Joule deflection scenario:

Employee asks a question via Joule → answer provided from knowledge base → no case created → employee confirms resolved

How to Structure Your UAT Script

A UAT script is more than a list of steps. Each test case should contain six elements:

| Element | Description |

1. | **Test Case ID** | Unique identifier (e.g., UAT-CH-001 for channel tests) |
2. | **Scenario Description** | Plain-language description of what is being tested and why |
3. | **Prerequisites** | What must be true before the test can start (user logged in, test employee ID available, etc.) |
4. | **Step-by-step test actions** | Exactly what the tester does, in sequence |
5. | **Expected result** | Precisely what the system should do — not “it works” but “case routes to Payroll EMEA Agent Group within 30 seconds with employee profile loaded” |
6. | **Pass / Fail / Deferred** | The outcome, with space for the tester to add notes |

The level of precision in the expected result is what separates a useful UAT script from a useless one. “System behaves correctly” is not an expected result. “Case appears in the Payroll EMEA Agent Group queue within 60 seconds, with employee name, employee ID, and country populated from SuccessFactors EC” is.

Defect Classification: What Is a Blocker?

Not every defect found in UAT should block go-live. The decision about what to fix before go-live and what to defer requires a clear classification framework. Use a three-tier approach:

P1 — Go-live blocker:

• Any defect that prevents a case from being created, routed, or processed
• Any SSO or IAS failure that prevents users from accessing the system
• Any SuccessFactors integration failure that causes incorrect employee data
• Any SLA misconfiguration that causes incorrect due dates
• Any routing error that sends cases to the wrong team

P2 — Fix before go-live, non-blocking:

• Notification email formatting issues
• Minor UI/label discrepancies
• Knowledge base article content errors
• Non-critical report configuration issues

P3 — Defer to post go-live:

• Cosmetic issues with no functional impact
• Nice-to-have configuration improvements
• Reporting enhancements
• Additional knowledge base articles

The discipline is in enforcing the P1 definition. There is always pressure to accept P1 defects with workarounds. Resist it. A go-live with broken routing or a broken integration is not a go-live — it is a controlled incident.

The Go/No-Go Decision

The go/no-go decision should be made by a defined group — typically the project sponsor, the HR SSC lead, and the IT/integration lead — based on explicit, pre-agreed criteria. Do not improvise this decision in a meeting the day before go-live.

Go-live criteria — all must be true:

• [ ] All P1 defects resolved and re-tested
• [ ] All five scenario types completed with a pass rate of ≥ 95%
• [ ] SuccessFactors integration validated with at least three different employee profiles per in-scope country
• [ ] SSO tested successfully for all user roles
• [ ] SLA timers validated for all in-scope categories and countries
• [ ] At least one full end-to-end lifecycle scenario completed per in-scope country
• [ ] HR agents and supervisors have confirmed readiness (formal sign-off)
• [ ] Cutover plan reviewed and approved (see Blog 10)
• [ ] Hypercare team identified and available from day one

If any of these criteria are not met, the go/no-go decision should be a no-go, with a clear action plan and revised date.

Common UAT Mistakes

Starting UAT too late. UAT should begin no later than three weeks before the planned go-live date. Starting with one week to go leaves no time to fix P1 defects, re-test, and make a confident go/no-go decision.

Testing with fictional data. Use real SuccessFactors employee records (from a test or sandbox environment) in UAT. Testing with invented employee IDs that do not exist in SuccessFactors will not surface integration issues.

Only involving IT in the integration tests. HR operations staff must participate in integration testing. They are the ones who will notice if the employee profile data is incomplete or if an automated transaction produces incorrect results.

Not testing failure scenarios. What happens when SuccessFactors is temporarily unavailable? What happens when an email arrives with an unknown sender? What happens when a case is submitted in a language not currently in the knowledge base? Failure path testing is as important as happy path testing.

Deferring the employee pilot. The self-service portal UAT with real employees is consistently the test that produces the most unexpected feedback — not because of configuration errors, but because of usability and language issues that no amount of internal testing will surface.

Treating UAT sign-off as a formality. If stakeholders sign off on UAT without having actively participated in testing, the sign-off is meaningless. HR agent team leads and the HR SSC manager should be able to look at the test results and say “I tested this myself and it works.”

UAT Readiness Checklist

Before UAT begins, the following must be true:

• [ ] UAT environment is fully configured and connected to SuccessFactors sandbox
• [ ] Test employee IDs are available for all in-scope countries
• [ ] All user accounts (employee, HR agent, HR supervisor, HR administrator) are provisioned and accessible
• [ ] IAS and SSO are configured in the UAT environment
• [ ] UAT test script is finalised and distributed to all testers
• [ ] UAT coordinator and defect log are in place
• [ ] SLA timers have been adjusted to compressed values for testing
• [ ] Joule is configured and connected to the test knowledge base (if in scope for Wave 1)
• [ ] Email channel is connected to a test mailbox
• [ ] Go/no-go criteria are documented and agreed by all stakeholders

What Comes Next

A successful UAT does not mean you are ready to go live. It means you are ready to plan the cutover — the 72-hour sequence of activities that takes the system from a tested UAT state to a live production environment, with HR agents trained, employees notified, and the hypercare team standing by.

That is Blog 10: Go-Live Cutover and the First 30 Days — Making It Stick.

Part of the series: “Implementing SAP ESM for HR — A Practitioner's Guide from Zero to Go-Live.” All content is based on hands-on implementation experience and SAP best practice materials.

What is SAP ESM for HR? And Why Your HR Shared Service Center Needs It

Source link