Last updated: November 2, 2026
You need a clear record of which embedded dashboards and filters your customers actually view. Without it, you cannot explain tenant behavior, support a review, or confirm what each audience saw inside your portal.
How to audit which embedded dashboards and filters your customers view: record the tenant, dashboard identity, and filter state together at load time. That gives you a reviewable trail of each embedded view, so you can answer support questions without guessing from dashboard names alone.
- Audit the tenant context, not just the dashboard title.
- Capture the dashboard and filter state together.
- Keep source dashboards in your BI tool.
- Use one distribution layer across vendors.
- Match the brand to the tenant being viewed.
How do you audit which embedded dashboards and filters your customers view?
You audit embedded views by recording who viewed what, under which tenant, and with which filter state. The audit record should reflect the portal context, not only the underlying BI asset.
If you want the broader delivery model behind this, see what embedded analytics is and embedded reporting benefits. Both explain why the portal layer matters.
Start with tenant, role, and filter definitions
Define tenants, roles, and filter attributes in one JSON configuration. Put the tenant first, then the role, then the filters tied to that role. That order makes the audit trail easier to read later.
This is not just about access. It is about explaining why a user saw a specific dashboard state at a specific time.
Use dashboardId and tenantId for each embedded view
Embed dashboards through a React component or iframe using dashboardId and tenantId. Those two fields anchor the view to the customer context and make the audit trail readable.
If you are comparing delivery models, the multi-vendor analytics guide explains why one integration surface is easier to audit than separate vendor-specific setups.
Keep the source dashboard in the BI vendor
Dashboards remain stored in your own BI vendor. Embedportal handles the distribution layer only, so your audit process stays focused on what was shown through the portal.
That keeps the source of truth in one place while the portal handles tenant-specific delivery.
What should an embedded dashboard audit trail show?
An embedded dashboard audit trail should show the viewing context, the dashboard identity, and the applied filters. If you cannot read those three pieces together, the record will not help you answer support or access questions.
At minimum, define the tenant, the dashboard, and the filter state. Then keep the brand and role context with the event so the view matches the portal experience.
The fields you should capture
- Tenant identifier
- Dashboard identifier
- Role or access context
- Filter attributes in use
- Brand or theme applied to that tenant
That is enough to review the audit trail without opening each BI vendor separately. It also keeps the audit context aligned with the portal users actually saw.
Why filter state matters as much as the dashboard
A dashboard title does not tell you what the user saw. Filters change the data slice, so the same dashboardId can represent different views.
For example, one tenant may view a regional slice while another sees a broader account view. If you only store the dashboard name, those differences disappear.
To keep that context clear, treat the filter attributes as part of the event, not as a separate note.
How do you audit which embedded dashboards and filters your customers view across vendors?
You audit across vendors by standardizing tenant and filter configuration in one portal layer. That gives you one place to define the view, even if the dashboards come from Tableau, Power BI, QuickSight, or Metabase.
Embedportal sits between your existing data and your existing BI tools. It is the embedding layer for customer-facing analytics, and it provides one integration surface on top of four BI vendors.
Dashboards from Tableau, Power BI, QuickSight, and Metabase stay in their source tools. You distribute them through one branded portal instead of rebuilding the same multi-tenant logic four times.
| Audit need | Without a portal layer | With one distribution layer |
|---|---|---|
| Tenant-specific views | Built separately per vendor | Defined once in JSON |
| Dashboard identity | Tracked differently by tool | Mapped through dashboardId |
| Filter context | Harder to compare | Captured as filter attributes |
| Branding | Repeated work per app | Kept per organization theme |
That table shows the core trade-off. A native vendor embed can be fine when you only use one BI tool.
If you need a product-side comparison, see Power BI Embedded alternatives for customer dashboards and what to look for in an embedded analytics platform.
How do you set up the audit flow step by step?
Keep the sequence strict so your records match the experience users had. Each step should add context, not replace it.
- Define your tenants, roles, and filter attributes in one JSON configuration.
- Map each dashboard to the right dashboardId.
- Assign tenantId when you render the embedded dashboard.
- Apply the tenant theme so the portal matches the organization.
That flow keeps the audit trail tied to the same identity the user saw in the portal. It also keeps the setup readable for support and analytics teams.
When a simpler setup is the better choice
If you only need one BI vendor and one internal audience, a native vendor embed or a simpler in-house setup may be enough. You should not add a portal layer if you do not need multi-vendor distribution or tenant-by-tenant branding.
For SaaS products, agencies, and consultancies shipping customer-facing analytics, the trade-off is different. You need a consistent way to distribute dashboards and review what each customer saw.
How does white-label branding help with audit reviews?
White-label branding helps because the audit record matches the experience the customer saw. If each tenant keeps its own colors, logo, and typography, you can review portal usage without switching mental context.
That matters when multiple organizations use the same portal. A clean tenant switch reduces confusion during support reviews and makes portal-level reporting easier to interpret.
Embedportal supports branding with colors, logo, and typography, and each organization can keep its own theme so users switch tenants without seeing another brand.
For related setup guidance, see top embedded analytics dashboards and how to embed Looker dashboards for customers.
What is the quickest way to see this in action?
The quickest way is to book the fifteen-minute walkthrough and watch a customer dashboard embedded live into a demo portal. You will see how dashboardId, tenantId, tenant themes, and the distribution layer fit together.
If you are evaluating whether to build or buy, this is where the trade-off becomes concrete. A native embed is simpler when your scope is small. A portal layer is the better fit when you need one place to distribute, brand, and audit customer-facing dashboards across vendors.
See it in action at Embedportal.
How to audit which embedded dashboards and filters your customers view comes down to one thing: keep tenant context, filter state, and dashboard identity together. When you do that, you can explain what each customer saw, across vendors, from one branded portal.
Frequently Asked Questions
What is the best way to audit embedded dashboard views?
The best way is to record tenant context, dashboard identity, and filter state together at load time. That gives you one audit record that explains what the viewer saw, without relying on dashboard titles alone. It also makes support reviews easier across different BI tools.
Why do filters matter in an embedded dashboard audit trail?
Filters matter because they change the data slice behind the same dashboard. Two viewers can open the same dashboardId and still see different results if their filter attributes differ. If you do not store filter state, your audit trail loses that context.
What fields should you capture for each embedded view?
Capture the tenant identifier, dashboard identifier, role or access context, and filter attributes in use. If your portal applies branding by tenant, include the brand or theme context too. Those fields are enough to review what was shown without opening each BI vendor separately.
When is a native vendor embed enough?
A native vendor embed is enough when you only use one BI tool and one internal audience. In that case, a separate portal layer may add more process than value. If you need multi-vendor distribution or tenant-by-tenant branding, a managed portal is easier to audit.
