Once your internal dashboard designers have at least "can use" access to the dataset(s), they can start dragging and dropping meaningful insights together in our dashboard editor and query them. This article will explain how to get a meaningful dashboard view on multi-tenant datasets using filters in our application, and sharing your created dashboards with the relevant users.

Building multi-tenant dashboards with an end-user data perspective

When designing a dashboard, it's valuable to have a view that accurately represents what an end-user will see upon opening the dashboard. This might require filtering your multi-tenant dataset(s) to match the data accessible to a single (dummy) end-user. This can be accomplished through static filters set on the dataset's access (see this Academy article), or parameterized filters (in the "Filters" tab in the side menu of the dashboard editor). Below, we explore the advantages of each approach:

  • (Parameterized) filters specified by the dashboard designer in the dashboard editor
    • Advantage
      • Your dashboard designers are able to change the value of the parameter and thus able to see data of other clients (useful to easily get a good representation of how specific clients would see the dashboard and evaluate its performance for those clients). Parameter filters defined in a dashboard can also be useful in case the dashboard should be further filtered down (e.g. a drillthrough dashboard).
    • Keep in mind
      • Dashboard designers should set this up when starting each dashboard design, as by default they are able to see all data in the dataset. This could optionally be avoided by e.g. connecting your development database to Luzmo, and overriding to your production database in the authorization request (see this Academy article!
      • These parameterized filter(s) in the dashboard should be removed when the dashboard is ready for embedding, as (some of) your application's end-users with a "designer" role might be able to edit this dashboard and thus remove those filters (see this article for more information about how to securely set up (parameterized) filters for your embedded insights). To avoid conflicting filters leading to "No data" in your embedded dashboard when you forget to delete the (parameterized) dashboard filter, it is recommended to use the same parameter name(s) as specified to scope your embed access.
  • Static filters set by the "Developer" users who shared the dataset(s) with the designer(s).
    • Advantage
      • Dashboard designers solely have access to a subset of representative (dummy) data that you allow them to have access to!
    • Keep in mind
      • The designer is not able to change the filter value in our UI, while that might be desired to get a preview of another subset of data. Alternatively, this could e.g. be tackled by implementing an impersonate mechanism in your application, ensuring you get the exact same view as your end-users would when looking at the embedded dashboard(s).

Sharing your dashboards

As soon as a dashboard designer has created a meaningful set of insights in their dashboard, they likely want to have it shared with other users(s). If you've created the corresponding groups, we highly recommend making your dashboard(s) accessible to certain users via their group.

  • "Owner" access is required to be able to provide further access to the dashboard. We recommend providing "Owner" access to your "Developer" user(s) (via their group) to facilitate them completely managing the dashboard (e.g. further share the dashboard, delete the dashboard, etc.).
    Note that they require equal or higher access to the dashboard as you'd like to provide to your application's users via Luzmo's Authorization token mechanism.
  • "Can edit" access is required to be able to make further changes to the dashboard, but the user(s) are not able to share nor delete the dashboard itself. This might be interesting for your "Designer" users.
  • "Can use" access only allows a user to view & interact the dashboard, or create a duplicate dashboard. This might be useful if you don't want other users to change your dashboard itself, but they can duplicate it and customize their duplicate dashboard.
  • "Can view" access could be useful for your internal "Viewer" users, who should only be able to interact with the dashboard(s) you share with them.

Adding your dashboards to Collection(s)

After adding the dashboard(s) and making it accessible to the desired users, you can also add them to one or more Collection(s) as a way to group related dashboards together. If there are users with access to the Collection but not yet to the dashboards(s) you add to that Collection, our platform will inform you about this and allows you to also provide those users and/or groups the desired access to your dashboards.


In the last article of this course, we'll provide some interesting resources to further elevate your setup!

Previous
Next

Need more information?

Do you still have questions? Let us know how we can help.
Send us feedback!