Here is an error that came up launching a dashboard that sounds like a localization issue, but it’s not.
Clicking ‘OK’ lets you access the dashboard.
The issue is typically a permissions issue. Check that the role experiencing this symptom has top level tab access to the business objects used by the dashboard. If that doesn’t solve it then check the permissions of the saved searches used. A really quick way, and perhaps the best way to troubleshoot if you can’t shake this error, clone the dashboard in your DEV (STG/UAT) environment and remove dashboard parts one by one to identify the culprit.
Determining your actively logged in users is a little tricky in ISM.
Security History (Frs_ops_logon_history)
Security sessions are derived from the security history business object (Frs_ops_logon_history) and used the status value and logout time to determine “security session” by event type and login type.
This makes identifying the number of active sessions challenging as aggregate functions do not allow use of the distinct function. This limits the use of dashboard parts, as you will get false counts per user.
a19 Consulting – Best Practice System
An advanced workaround would be to create a summarized table similar to the a19 Consulting Best Practice System‘s implementation. More on that on a future blog post.
ISM Administration Tip
PS: Remember one of the culprits for users staying logged in is the dashboard setting for auto-refresh. Setting your security session timeout alone does not solve the issue, you must ensure that the Auto refresh (in minutes) on your dashboards is disabled or set higher than the session timeout number.