Hyperion Shared Services (formally Oracle Hyperion Shared Services) is the centralised user provisioning, authentication, and security management platform for on-premise Oracle Hyperion applications. Every user who accesses Hyperion Planning, HFM, Essbase Administration Services, Workspace, or Financial Reporting must be provisioned through Shared Services — assigned to native Hyperion groups or mapped from an LDAP/Active Directory external directory, and granted application-level roles that determine their access in each Hyperion application. Shared Services acts as the single administrative interface for user governance across the entire on-premise Hyperion environment, reducing the need for per-application user management that would otherwise require separate administration in each Hyperion product.
Shared Services Architecture
Shared Services operates through a Registry — a central repository of application and server registrations that allows each Hyperion application to locate and authenticate against the Shared Services server. When a user logs into Hyperion Workspace, the Workspace application validates credentials against Shared Services, which either authenticates natively (using Shared Services’ own user store) or delegates to an external directory (Active Directory, LDAP, SSO through Oracle Access Manager). Once authenticated, Shared Services supplies the user’s role assignments to each Hyperion application, determining what the user can access within Planning, HFM, or Essbase.
| Shared Services Function | How Implemented |
|---|---|
| Native user authentication | Users stored in Shared Services’ own user directory (OpenLDAP embedded) |
| External directory authentication | LDAP connector to Active Directory or other LDAP-compliant directory |
| SSO integration | Oracle Access Manager (OAM) or SAML provider for enterprise SSO |
| Application role assignment | Roles assigned per application in Shared Services UI; pushed to each Hyperion app |
| User provisioning lifecycle | Create, modify, deactivate users; group membership management |
| Application registration | Each Hyperion application registers with Shared Services Registry on deployment |
Shared Services vs Oracle EPM Cloud Identity Management
In Oracle EPM Cloud, Shared Services is replaced by Oracle Identity Cloud Service (IDCS) for authentication and the EPM Cloud’s built-in User Management for application provisioning. Organisations migrating from on-premise Hyperion to Oracle EPM Cloud must migrate their user provisioning model from Shared Services to IDCS — mapping existing Shared Services groups to IDCS groups, and existing application roles to EPM Cloud predefined and custom roles. This migration is typically a straightforward mapping exercise for applications with well-governed Shared Services configurations, but a significant remediation effort for environments where Shared Services users and groups have accumulated without governance over years.
GCC-Specific Considerations
Many GCC enterprise Hyperion environments use Shared Services in native authentication mode — with users stored directly in Shared Services rather than synchronised from Active Directory — because the initial implementation was designed for simplicity and the AD integration was deferred. This creates a long-term governance problem: when employees leave, their Hyperion access is terminated only if the Hyperion administrator manually deactivates the Shared Services user. In environments without a formal user access review process, departed employees may retain active Shared Services credentials for months or years after leaving — a security exposure that SAMA-regulated entities and CMA-listed companies must address as part of their IT general controls programme.
What Goes Wrong in Practice
The specific Shared Services failure that most commonly causes production authentication outages is a Registry corruption after a server restart or an incomplete upgrade — where one or more Hyperion applications cannot locate the Shared Services Registry and refuse to start. Recovering from Registry corruption requires manual re-registration of each affected application in Shared Services, in the correct sequence, using the epmsys_registry utility — a procedure that is infrequently executed, poorly documented in most IT runbooks, and time-consuming to execute correctly under close-cycle time pressure. Every Hyperion IT runbook should include the Registry recovery procedure with the exact command sequences required.
How Loop Wise Solutions Approaches This
In Hyperion environment health checks and migration assessments, we review the Shared Services user base and group structure as a standard component — identifying dormant users, ungoverned group memberships, and role assignments that do not reflect current job responsibilities. The Shared Services state is the baseline for the user migration plan when transitioning to Oracle EPM Cloud IDCS.
