The Most Underestimated Configuration Area in Any ESM Implementation
Ask any experienced ESM consultant what generates the most support tickets on go-live day, and the answer is almost always the same: access and permissions. An employee cannot see the self-service portal. An HR agent can log in but cannot view cases. A supervisor can see cases but cannot reassign them. A system administrator cannot access configuration settings.
None of these are product defects. They are the predictable result of a security and identity model that was not fully designed, mapped, and tested before go-live.
The reason this happens so often is that the security layer in SAP ESM for HR is not a single configuration screen in a single system. It spans four interconnected layers: SAP SuccessFactors, SAP IPS, SAP IAS, and SAP ESM. Every layer must be configured correctly and connected to the others for any user to experience what they are supposed to experience.
This post explains each layer, how they connect, and how to design the whole model before touching a single configuration screen.
The identity and access model for SAP ESM for HR works as a chain. Each step of the chain depends on the one before it. A break at any point in the chain means the user either cannot access the system or does not see what they should see.
Layer 1 — SAP SuccessFactors EC Permission Roles
This is considered the source system. What the user is authorised to do and see within the SuccessFactors ecosystem.
Layer 2 — SAP IPS (Identity Provisioning Service)
How the user's identity is authenticated and which group they belong to for access provisioning purposes. IPS reads employee identity attributes from SF EC using the sf.user.attributes query and transforms them into SCIM payloads consumed by IAS.
Layer 3 — SAP IAS (Identity Authentication Service)
IAS then manages the user account used for Single Sign-On (SSO) login into SAP ESM and controls business role assignments. The ESM business role assignment is managed via IAS application groups synchronization with two steps:
- SAP IPS assigns IAS group based on SF EC employee attributes (Organization Unit, Reference Role and Team Member Size)
- SAP IPS synchronizes IAS group members with SAP ESM business roles members
Layer 4 — SAP ESM (Users and Business Roles)
What the user can see and do within the ESM platform: the cases, the configuration, the agent workspace, the analytics.
Think of it as a pipeline: SuccessFactors establishes who the person is and what they are authorised to do in the HR system. IAS authenticates them and groups them. IPS provisions their access to the technical components. ESM assigns them a functional role. All four must be aligned.
SAP SuccessFactors Permission Roles
SAP SuccessFactors uses a Role-Based Permission (RBP) model to control access to all SuccessFactors functionality, including the parts of SuccessFactors which are visible to ESM users, the employee profile data, and the HR process tiles. For an ESM for HR implementation, the SuccessFactors administrator must configure permission roles that cover three specific things:
- Access to employee self-service functionality: Employees need permission to access the HR Service tile (or equivalent entry point) from the SuccessFactors Home Page. Without this permission, the employee sees no route into the ESM self-service portal from SuccessFactors.
- HR agent access to SuccessFactors data within ESM: When HR agents view an employee's SuccessFactors profile from within the ESM agent workspace, they are accessing SuccessFactors data through an embedded view. The data they can see is governed by their SuccessFactors permission role, not by their ESM business role. An HR agent with a narrow SuccessFactors permission role will see a narrow profile. A Payroll specialist who needs compensation data must have a SuccessFactors permission role that includes it.
The practical implication: SuccessFactors permission role design is not solely an HR system task. It directly affects what HR agents can see when they access the SF Employee People Profile via ESM.
SAP IPS and IAS
SAP IAS authenticates users, confirming who they are, and organises them into user groups that are then mapped to roles in ESM. When a user logs into SuccessFactors and navigates to the HR service portal, IAS handles the Single Sign-On (SSO) handshake, confirming their identity to ESM without requiring a separate login. From the user's perspective, the experience is seamless. From a configuration perspective, the SSO trust relationship between SuccessFactors, IAS, and ESM must be explicitly established and tested.
Beyond authentication, IAS manages user provisioning through user groups. These groups are the bridge between who someone is (their SuccessFactors identity) and what they can do (their ESM role). The groups you define in IAS must map precisely to the business roles you define in ESM and the role assignments you configure in IPS.
Typical IAS user groups for an ESM for HR implementation:
IAS User Groups and their purpose.
- ESM-Employees & Managers: Employees with access to the self-service widget
- ESM-HRAgents: HR agents with access to the agent workspace and case management
- ESM-HRSupervisors: Team leads with access to case reassignment and team queues
- ESM-HRManagers: HR managers with visibility across team performance and SLA reporting
- ESM-Administrators: System administrators with access to configuration and system settings
The names and groupings above are illustrative — your implementation will define its own group structure. What matters is that the groups are defined before ESM business roles are configured, because the mapping runs in that direction: IAS groups first, ESM roles second.
SAP ESM Business Roles
SAP ESM business roles define what a user can see and do within the ESM platform itself. They control access to workspaces, case types, queues, configuration areas, analytics, and knowledge base management. The five standard ESM business roles and what each one enables:
Employee (Self-Service User)
The most populated role: every employee in scope. Employees can access the self-service widget, browse the knowledge base, create cases, view their own case history, and communicate with HR through the case thread. They cannot see other employees' cases, access agent workspaces, or view configuration.
HR Agent
The operational core of the HR SSC. HR agents can view and manage the cases assigned to their team queue, update case status, respond to employees, create internal notes, view the SuccessFactors employee profile in context, and access knowledge base articles. They cannot reassign cases outside their team, access SLA management settings, or view other teams' queues — unless specifically configured.
HR Supervisor / Team Lead
Supervisors have everything an HR agent has, plus the ability to view and reassign cases across their team, monitor queue volumes and SLA status for their team, and access team-level performance dashboards. This role is critical for SLA management and escalation handling. It is the role that acts when a case is approaching breach.
HR Manager / SSC Manager
Managers have read access across multiple teams and visibility into cross-team analytics, SLA compliance reports, and case volume trends. They do not manage individual cases day-to-day but need the visibility to manage SSC performance and make resourcing decisions.
System Administrator
The administrator role has access to all ESM configuration: case types, service catalog, routing rules, SLA definitions, knowledge base management, channel configuration, and user management. This role should be tightly controlled: broad configuration access in the wrong hands is how service catalogs get accidentally modified, and routing rules get broken.
The most useful way to think about this model is as a chain of mappings. Each layer hands off to the next: SAP SuccessFactors EC Users attributes are read via SAP IPS -> SAP IPS assigns IAS group based on SAP SuccessFactors EC Users attributes -> SAP IPS synchronizes IAS group members with SAP ESM business roles members -> as a result, users are created and assigned to their respective SAP ESM Business Roles.
A user's experience in ESM is the product of all these mappings being correct. If any link in the chain is broken or incomplete, the user will either be blocked entirely or will have an incomplete and confusing experience.
Common Configuration Mistakes
Mistake 1: Configuring ESM roles before IAS groups are defined
The configuration sequence matters. IAS user groups must exist before ESM business roles can be mapped to them. Teams that configure ESM roles first and then try to retrofit IAS groups create mismatches that are time-consuming to diagnose and fix.
Mistake 2: Treating all HR agents as identical
HR agents in different teams often need different levels of data visibility in SuccessFactors. A Benefits specialist does not need to see payroll data. A Payroll specialist should not have access to employee relations case notes. Designing a single “HR Agent” SuccessFactors permission role for all agents creates either over-exposure or under-exposure. Define SuccessFactors permission roles at the team level, not the platform level.
Mistake 3: Testing SSO with administrator accounts only
SSO testing with administrator accounts will pass even when the configuration has gaps — administrator roles typically have broad access that masks edge cases. Test SSO and portal access with representative accounts from each user type: a standard employee, an HR agent, a supervisor, and a manager. Each will expose different gaps.
Mistake 4: Not planning for employee offboarding
When an employee leaves the organisation, their SuccessFactors account is deactivated. If IAS provisioning is correctly configured, that deactivation flows through to IAS and then to ESM — the employee's self-service access is revoked automatically. If it is not correctly configured, departed employees retain portal access. Verify the offboarding flow explicitly as part of integration testing.
Roles and Permissions Readiness Checklist
Before going live, confirm all of the following:
- [ ] SuccessFactors permission roles are defined for each user type, including the Integration Suite service account
- [ ] IAS user groups are created and mapped to SuccessFactors user populations
- [ ] SSO trust is established between SuccessFactors, IAS, and ESM — tested with non-administrator accounts
- [ ] ESM business roles are created and mapped to IAS user groups
- [ ] Every user type has been tested end-to-end: login → correct workspace → correct data visibility
- [ ] HR agent data visibility has been validated by teams: Payroll agents see payroll data; Benefits agents see benefits data; cross-team visibility is blocked where intended
- [ ] Employee offboarding flow has been tested: deactivated SuccessFactors account loses ESM portal access
- [ ] System administrator access is restricted to named individuals and documented
What Comes Next
With routing, SLAs, integration, and identity all designed and configured, your ESM for HR implementation is taking shape. The next phase is making sure it all works before your employees and HR agents encounter it for the first time.
Next post: Blog 9 — UAT: How to Test SAP ESM for HR Before You Go Live
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
