New Feature: Dashboard Facts

[SeanMiller1]

In the RSA Identity Governance and Lifecycle 7.2 release, we have introduced a new component that can be used on dashboards to display a single value "fact".  Dashboard Facts are a convenient way to provide high level information on a dashboard with click through support to dive into the details.  Combined with other dashboard components you can build very powerful dashboards targeted to specific users or roles.

To create a dashboard fact, you will need to decide on the fact you want to show.  For example, maybe I want to know how many applications have been onboarded into RSA Identity Governance and Lifecycle.  Dashboard facts can appear on any type of dashboard (Welcome, Object, or Topic level).  Along with the fact you will want some visualizations like a name, a colour for the fact, and some descriptive text to explain why anyone cares about the fact (or to give the context for the fact).  When creating a fact, the most important thing to keep in mind is what is the fact meant to convey.  For example, if I show a number of 100 is that a good thing or a bad thing someone may want to drill into more.  For this reason, keep your facts concise.  In addition to the fact itself, you can configure an url that allows the fact to be clicked on to get more details.  This is especially useful to provide a high level dashboard that links to a lot more content like a report or a detail screen within the product.

It is highly recommended you start with thinking about the fact you want to present and is there an efficient way to get the value to display.  Performance is the key as the query will be run everytime the dashboard is displayed.  RSA recommends using values that are not calculated at runtime.  For example, use counts for objects that are gathered daily and stored in the public view PV_TELEMETRY_DATA  rather than a query that does an actual count every time the query is executed.

To showcase this new feature and help system administrators, the 7.2 release includes a new dashboard available out of the box called 'System Admin' Dashboard.  Facts like the number of admin errors are shown on this dashboard with click through support to take the end user to the actual admin errors.

For additional information on this update – please check out this additional context:

[JamiePryer]

I cant wait to see what customer come up with here. This is my personal favourite addition to the new release!

[DocFrank]

Which URL Parameters are allowed? there is a whitelist I believe...

What I am after is using such a fact in an object dashboard. Then I want to run a report when clicking on the fact. However, I need to pass the CurrentObjectID which I then believe will NOT work as the link will kick me over to the report object (and the report, when accessing the CurrentObjectID variable in its SQL will simply have the OID of that report, not the one from the referrring object).

[MHelmy]

Just to be clear, where do you plan to use the Dashboard Fact (Home dashboard or Object dashboard)?

Also there are two built-in report variables :CurrentUserID and :TargetObjectID. You should never need to manually pass :CurrentUserID as it will always be auto-populated based on the current logged in user, so I'll assume you are talking about :TargetObjectID.

I think they bigger problem here is that dashboard facts do not yet support the use of :TargetObjectID / :CurrentUserID (at least from my testing). So you won't have a "scoped” dashboard fact to start with so it can redirect you to a "scoped” report result.

[ArmelLupapi1]

Impressive!

[MohammadSajid]

There are two built-in parameter as follows (same as mentioned in doc) in report:

CurrentUserID — The value of this parameter is automatically replaced by the ID of the currently logged in user. This parameter can be used in any dashboard.

TargetObjectID — The target ID of the selected object. This parameter can only be used in object dashboards and is replaced by the selected object on that dashboard.

So currentUserID parameter value will get replace on runtime on whatever the value defined in report definition with with currently logged-in user.

Other than this, let’s say you defined a param in query, like where Application_Id = :appId  and use the 10 as value for appId.

Now, you want to replace this parameter value on clicking on Dashboard Fact, then you can use the Full URL string field in dashboard fact definition, since there you can provide the running report URL in this field and along with the run report URL, you may provide the param with new value additionally, like below:

http://<ip>:<port>/aveksa/main?Oid=<reportId>&ReqType=Dialog&ObjectClass=com.aveksa.gui.objects.report.GuiReport&PageID=ViewReportDialogData_save&Action=New&appId=<NewValue>

Note: Currently, URL parameters field supports only pageId parameter to form the URL to link to particular page (without mention full URL).

[DocFrank]

Hi Mohammad,

I can see that the iframe that contains the fact lists the TargetObjectID in its URL (if I configure the fact to be part of an object dashboard).

This TargetObjectID I can't use as :TargetObjectID in the SQL for the fact (I get an error here).

Plus, in the URL that can forward me to the tabular report the TargetObjectID doesn't get forwarded. I can hardcode it (and it doesnt get removed or overwritten) but I want the ID of the object the dashboard is displayed for.

Final goal is to have one report configured that shows me a full report of something that a fact only shows the one number summary. I neither want to use several dashboard facts using basially the same logic just having the appId or whatever URL parameter, nor several report templates. Just one pair of a fact and a report.

What would speak against a future improvement "mirroring" the TargetObjectID from the dashboard component (iframe) to the dashboard fact and then using it in the dashboard fact SQL and the link towards the report/URL?

[MohammadSajid]

Sorry for late reply, I've missed it.

Actually, we were planning for the use case, you mentioned, in phase 2, based on customer response about this particular feature.

We can address this new patch, if customer is looks for this.

[MohammadSajid]

We've fixed it in V7.2.0 P05 on wards.

Thanks