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.
Answers before you ask.
Centralised security and user provisioning for on-premise Hyperion — authentication, authorisation, user provisioning, and lifecycle management across Planning, HFM, Essbase, and related applications. It is the single point through which users are granted roles and access to the Hyperion suite, rather than each application managing its own users separately.
Because it consolidates user administration for the whole suite in one place, so provisioning, role assignment, and de-provisioning are managed consistently. Without it, each Hyperion application would need separate access administration, inviting inconsistency and orphaned accounts. Shared Services gives a single, governable view of who can access what across Hyperion.
OAM handles authentication — single sign-on proving identity; Shared Services handles provisioning and authorisation — mapping authenticated users to Hyperion roles and applications. Authentication and authorisation are distinct concerns: OAM establishes who the user is, Shared Services decides what they may do within Hyperion. They are often used together.
Shared Services is an on-premise Hyperion component. EPM Cloud uses the cloud identity service and identity domains for equivalent user and access governance. So Shared Services belongs to on-premise architecture, and a cloud migration replaces its role with the cloud identity mechanism rather than carrying it forward.