Hi Kai,
Thanks for the response! We’ve got some questions / concerns with the planned implementation and how it will work with our set-up.
Some information on our current set-up
- Currently, we have quite a few customers and quite a lot of dashboards. Critically, not all customers see the same dashboards. We have some core dashboards that all customers get to see. We also have some custom dashboards that can be shared between a few customers or specific to one customer. We need a scalable to manage who has access to what.
- We have the ability to set a specific dashboard to load when switching to a specific page.
- We have built an admin tool where our support team can modify which custom dashboards a customer has access to, as well as modifying which dashboards are “core” dashboards that all customers can see, and which dashboards are used as “landing pages” on specific pages of the application.
- Minimal onboarding set-up for new customers. Currently since all customers have access to core reports, this means that we have NO reporting set-up for those customers. We have minimal reporting set-up for giving them access to a core-report, either when they are new or have been a customer for years since it’s a simple change in our admin tool.
- We have built a drop-down menu where customers can switch between any dashboard that they have access to, where it’s clearly marked as “Core” and “Custom” ex:
CORE
Dashboard 1
Dashboard 2
CUSTOM
Dashboard 3
Dashboard 4
- We have the ability to set specific URLs for specific dashboards. This allows users to bookmark specific pages and load those specific dashboards quickly.
- Having different URLs also gives us the ability to see which customers are loading which dashboards and for how long, usage metrics that would likely go away if all we’re loading is one single iframe for ALL dashboards.
- And we have one dashboard that’s used more as a pop-up with specific parameters (ex. when looking at item A, I click to see more details, which loads pop-up that’s just a dashboard embedded with a single graph filtered to that one item using the filter value passed into the payload). This is essentially drilling down, but from our application to holistics.
- We need a way to ensure customers are only seeing their data, whether it’s a core/custom dashboard, or the pop-up drill-through. We’ve built this into our internal tooling, but there’s edge-cases where this logic could fail if we’re not careful.
Questions on the new feature
- It looks like each “portal” is set up in holistics code and has a static set of datasets / dashboards. If every customer needs to see a different set of dashboards, does this mean we’d need a portal for each customer? This seems like a lot to set up and manage. We’d likely still need our in-house admin tool then to manage which customers can see which portal, so this would require quite a bit of work on our end to switch to using. This also likely means a lot of on-going work to set-up new customers, and possibly to maintain already existing customers as well.
- It looks like this would remove the need of our drop-down for dashboard selection, so we’d need to get creative with a way to mark which dashboards are core vs custom. Maybe titles? This is probably not as important but still a consideration.
- This looks like it would take away our ability to do all of the following. Can you confirm if that’s true, or if there’s workarounds?
A. Specify which dashboard is used as the “landing pages” on specific pages of our application.
B. Allow users to bookmark specific dashboards
C. Seeing usage metrics per user and dashboard and link that back to our internal data. This might be possible given how we’re passing in the “embed_user_id” and “embed_org_id” but I want to make sure. - I’m unsure if this feature would work on the single graph that’s being used to drill into information on one specific item (we don’t want lots of extras here, minimal functionality), so it might still require us to maintain our current set-up for that. Maintaining both methods of RLS + embedding sounds like a lot.
- Is the Embedded Self-Service something that we can turn off?
A. Based on your image, it looks like maybe we can just not pass in the datasets. We would want to make sure users don’t see prompts for being able to do it, but then not be able to do anything. This seems like a cool feature, but we’d want to curate our datasets a lot more to make them user-friendly before opening it up, and I’m not sure that’s work we’re immediately going to prioritize.
B. I’m also curious how the “custom dashboards” would work. Would those be one time use? Saved as canvas dashboards? If they save as canvas dashboards, does that require a github PR? And similarly how would collaboration work? - Given the mention of “embed users” with distinct user and org IDs, would we be charged per seat for these users?
- This seems like a big change versus how we’re currently showing embedded reports to customers. We were prepared to make that change as part of the migration to holistics, but we’d need to check with our support, customer, and product teams that we’re definitely ok making these additional changes for our users. This will likely requires some work on our side to prep/train our users on as well.
Summary
Overall the feature seems really cool, but it might not meet our needs in quite a few ways and would likely be a lot of work to switch to and maintain. Is there any way we could get the ability to pass in the user_attribute value to the embedded payload like you originally proposed, and continue to use the current method of embedding of single dashboards?
Thanks so much,
Anya
P.S. If we can’t make this work for us, we have an idea for a workaround, but it might not be possible with the upcoming auto-publish feature as explained here, so I want to consider that as well.