In Hyperion 220.127.116.11, there is a change in how security is deployed. If you are having an issue deploying Planning security with Essbase adhoc access, and the user can’t
- Access Essbase Adhoc
- Access FR reports using an Essbase connection
- Access Essbase directly
you are not alone. This is not classified as a bug, but it sure can cause a lot of frustration. If you have a user that needs access to Essbase directly, the user can’t be associated to ONLY Planning applications. For them to get access to Essbase, even to access the Planning application, they must have security to a native Essbase application (a NON Planning application).
From the Oracle Doc ID 1328741.1
Trying to add the “Essbase” application access type to a Planning user in Shared Services so the user can access native Essbase applications using the Excel Add-in. Shared Services confirms the update when saved but when checking the user again, it only has “Planning” access. This also happens when trying to use the MaxL command to modify the application access type.
Starting in EPM v11.1.2, a user’s type (application access type) cannot be changed by Maxl, the EAS console or manually via Shared services console. The type is automatically assigned based on the roles that the user has.
- If a user has a role on a Planning application only, then that user is treated as a Planning user.
- If the user has a role on a Essbase application only, then the user is treated as an Essbase user.
- If the user has roles on both Planning and Essbase applications the user is treated as a Planning and
In order for a Planning user to access native Essbase applications in the Excel Add-in, the user will need to be given access to a native Essbase application. For example, assign the Planning user “Read” access to the Demo application.