Guest library — share public reports and brand the anonymous view
Share reports publicly — no login required — either through a browsable Guest Library accessible from your login page, or as direct share links. This is the only lesson that covers the full Guest Library setup end-to-end, plus the branding that makes anonymous users see your product, not stock DashboardFox.
By the end of this lesson
- A working Guest Library accessible from your login page — no authentication required
- At least one report inside it published as Public View
- Guest Branding configured so anonymous users see your colors and logo, not stock DashboardFox
You'll need
- Admin role — only admins can create root-level folders
- At least one report you want to share publicly
- Available Public View licenses — each public-view report consumes one (every tier includes some; add-ons available)
- Reports with hardcoded filter criteria — dynamic security doesn't apply to anonymous users (see security note in Background)
Background
DashboardFox supports three ways to deliver reports: secure embedding into your own application, direct login to the DashboardFox interface, and anonymous public access. This lesson is the third one.
"Guest", "anonymous", and "public view" all refer to the same thing — users hitting a DashboardFox report without any login. Three words, one mechanism.
Two shapes of public sharing
Most teams use both, often for the same reports. The library is for discovery — anyone can browse. The direct link is for distribution — paste into a specific email or webpage.
The license model — Public View seats
Every tier ships with a number of Public View licenses. Each report that's marked Allow Public View consumes one seat. The seat is consumed when the toggle is enabled, regardless of how many people actually view that report — public view licenses are about reports, not viewers. If you run out, you can either turn off Allow Public View on reports you no longer share, or contact team@dashboardfox.com about add-on seats.
Anonymous users have no identity. DashboardFox doesn't know who they are, what group they belong to, or what data they should see. That means row-level security and dynamic profile-tag filtering do not apply to guest reports.
If a report shouldn't show all of its data publicly — and 95% of the time, that's the case — you must hardcode the filters into the report itself before marking it Public View. Filter to a specific customer, a specific region, a specific date range, whatever scope is safe to expose. The hardcoded criteria travel with the report.
If you're already using row-level security on a report and you mark it Public View, the RLS rules silently stop applying. Plan for this before flipping the toggle.
Stuck setting up the library, or unsure if a report is safe to publish publicly? Email team@dashboardfox.com with the report you want to share, what data it shows, and who you're trying to share it with. We can review the security implications before you flip the toggle. Real human, same business day.
Before you start
- Admin role. Only admins can create root-level folders, and the Guest Library starts with a root-level folder. If you're not an admin, this lesson stops here — find your DashboardFox admin and have them run through it.
- Available Public View license capacity. Confirm before marking reports Public View — every Public View report consumes one seat. Check your tier's seat count and how many are already used. If you're near the limit, plan additions carefully.
- Reports prepared with hardcoded filters. Before any report goes Public View, open it and verify the criteria are baked in. Customer = "Acme Demo" hardcoded inside the report definition. Date range hardcoded to last 90 days. Whatever scope is publicly safe. If you're using row-level security on a report, those rules will not apply once it's public — replace with hardcoded criteria first.
- A decision: library, direct share, or both? Library is for browsable collections (multiple reports, accessible from your login page). Direct share is one report, one URL, shared via email or embed. You can do either or both per report. Have a sense of which you need going in.
- Your Application Branding policy already exists. The recommended way to configure Guest Branding is to extend your existing Application Branding policy by toggling Is Guest on, not to create a separate guest-only policy. Make sure Lesson 1 is already done.
Do it
-
Three stages
This walkthrough has three independent stages. Do them in order:
Stage A — Set up the Guest LibraryCreate a root folder with Allow Anonymous turned on. Add subfolders if you want a multi-folder structure. Steps 1–3.
Stage B — Publish a reportCopy or build a report into the Guest folder. Turn on Allow Public View (consumes one license). Optionally enable embedding for a share link. Steps 4–6.
Stage C — Brand the guest experienceToggle Is Guest on inside your existing Application Branding policy, configure logos and colors in the Guest tab, hide features you don't want anonymous users to see. Steps 7–9.
-
Stage A — Step 1: Create a root-level Guest Library folder
Navigate to Documents. Click New Folder at the root level (root-level folder creation is admin-only). Name it something obvious: Guest Library, Public Reports, Shared with the Public — whatever reads clearly to your team.
In the folder configuration, assign permissions. The simplest choice: All Users. This lets your logged-in users browse the Guest Library too (they'll see it alongside their normal library). If you want it hidden from logged-in users and only available to anonymous viewers, assign a specific empty group instead.
If your guest report is part of a compound pattern — a drill-down setup where users click through from a parent to a target, for example — both reports and both folders need to be configured for anonymous access. Each Public View report also consumes its own Public View license. The drill-down lesson covers the multi-report rule.
-
Stage A — Step 2: Turn on Allow Anonymous
Still in the folder configuration, expand Advanced Options. Find Allow Anonymous and toggle it ON. Save.
You'll notice a visual indicator on the folder once Allow Anonymous is on — a small icon making it clear to users (including report authors) that anything saved into this folder could be publicly visible. Save reports here only if they're meant for public consumption.
-
Stage A — Step 3 (optional): Create subfolders
Subfolders work the same way — create them inside the Guest folder, expand Advanced Options on each, toggle Allow Anonymous ON, save. A typical structure:
- Guest Library (root)
- Public Metrics
- Marketing Reports
- Press Kit Data
Each subfolder needs its own Allow Anonymous toggle — the setting doesn't automatically cascade from parent to child.
- Guest Library (root)
-
Stage B — Step 4: Copy a report into the Guest folder
Open an existing report you want to share publicly. (Or build a new one — see the app building lesson.) Use the Copy action to make a duplicate, then save the copy into your Guest Library folder.
Why copy instead of moving the original?The public version often needs different filter criteria than the internal version. By copying, you keep the original internal report intact while making a public-safe variant in the Guest folder. Different reports, different audiences.
At this point the report is in a Guest folder but not yet public — it still shows the default team permission, meaning anonymous users can't see it. The next step is what makes it public.
-
Stage B — Step 5: Apply hardcoded filters and turn on Allow Public View
Open the copied report's Settings. Before doing anything else: verify the report's criteria are hardcoded. Edit the report itself, confirm the filters embedded in the report definition limit data to what's safe to expose publicly. (See the security note in Background — anonymous users have no dynamic security; hardcoded is the only protection.)
Once you're confident the criteria are safe, in Settings → Advanced Options, toggle Allow Public View ON. Save.
The report's status changes from team to guest — a visual cue in the library view confirming this is now publicly accessible. This is also the moment one Public View license is consumed.
-
Stage B — Step 6 (optional): Enable the direct share link
If you want a copy-pasteable URL to share the report directly (in email, embedded in a page, etc.), also enable Allow Report Embedding in the same Advanced Options panel. Save.
A new Share action appears on the report's action menu. Click it to copy the direct hyperlink. Anyone with that URL — no login required — can see the report.
Two distribution paths now exist for this report:
- Via the Guest Library — users hit your login page, click "View Guest Library", browse to this report.
- Via direct link — they click the URL you sent them, see the report instantly.
If you want a report shareable via direct link only (not browsable in the library), don't save it in a Guest folder — keep it elsewhere, but still turn on Allow Public View and Allow Report Embedding on the report itself.
-
Stage C — Step 7: Open your existing branding policy
Navigate to Settings → Branding → Application Branding. Open the existing policy you created in Lesson 1. (Don't create a new dedicated guest policy — extending the existing one is the cleaner pattern, and you only get one Guest policy anyway.)
In the policy's basic settings, toggle Is Guest ON.
Only one Guest policy can be activeIf you ever try to enable Is Guest on a second policy, DashboardFox will block it with an error — you have to disable the existing one first. Guest Branding is global; there's no per-group anonymous experience because there are no groups for anonymous users.
-
Stage C — Step 8: Configure the Guest tab
Toggling Is Guest on activates a second tab at the top of the policy panel — Guest Branding. Switch to that tab.
Configure it the same way as the Application Branding tab in Lesson 1:
- Feature Options — primary/secondary colors, big logo, small logo. These are what anonymous users see in the Guest Library.
- Sidebar Options — what shows in the Guest Library's sidebar.
- Library Options — which columns and elements show. Common changes: Show Created By Column off (don't expose your internal team's names to the public), Show Action Menu often off (anonymous users don't need most actions).
- Dashboard Options — what shows on dashboards viewed anonymously. Often the same patterns as embedded views: hide Save Views, Add Widget, Reorder.
- Advanced Customizations — Custom CSS, JS, HTML — same as the Application Branding tab, scoped to the guest experience.
Save.
-
Stage C — Step 9: Verify
Sign out of DashboardFox. Hit your DashboardFox URL.
On the login page you should now see a new button — View Guest Library. It appears because at least one folder has Allow Anonymous turned on. Click it.
You're now in the Guest Library — anonymous, no login. You should see:
- Your guest branding — logos and colors you configured in the Guest tab
- The folder structure you created
- The report you marked Public View (with a guest status indicator)
- A slimmed-down navigation — no Favorites, no Private library, no Scheduling (anonymous users have no identity, so personalization can't exist)
Run the report. Confirm it returns only the data your hardcoded filters allow.
If a direct share link was generated in Step 6, also test that URL in a fresh private browser window — it should load the report directly, with guest branding, no login prompt.
You have a working connection. Below is what to tighten before real users see it. Skip if you're just testing.
Make it real
Three practical considerations for running a Guest Library in production: which features to actually hide for guests, when to use direct share vs. library, and the embedded-guest session handling pattern.
Common hides for the guest experience
Anonymous users have different needs than logged-in users. The video calls out a few specific toggles worth flipping; here's the longer list most teams end up with:
- Show Created By Column — OFF. No need to publicly broadcast which of your internal team built this report.
- Show Action Menu — usually OFF. Anonymous users don't need most actions (no scheduling, no email).
- Show Profile Menu — OFF. There's no profile to manage when you're anonymous.
- Show Profile Change Password, Show Profile Email, Show Version — all OFF. Same reasoning.
- Show Report Details Create Chart — usually OFF. The visualization builder is a power-user feature; most anonymous viewers just want the report as-is.
- Show Print Icon, Show Export Icon — depends on intent. Public dashboards on a marketing page: probably leave Export on. Internal partner shares: maybe off. Decide per audience.
Library vs. direct share — which when
The two distribution paths solve different problems. A rough rule:
- You have multiple public reports
- You want discovery (browsing)
- The audience is broad / unknown
- You want anonymous access from your own login page
- One specific report needs sharing
- You're emailing or messaging the URL
- The report is embedded in another web page
- You don't want the report in your library at all
Doing both for the same report is common — embed the URL in your marketing site and have it browsable in your library. Two paths, same report, no duplication.
Handling session timeouts when embedding guest content
If you embed a guest report inside your own webpage and the user's connection drops or their session expires, by default DashboardFox shows its login page inside the iframe. For anonymous embedded reports, that's wrong — the user shouldn't see DashboardFox's login at all. The fix lives in the Guest Branding tab's Custom JS field:
Custom JS — redirect on session expiration in embedded guest views
custom_handleexpired_session = function() {
window.location = "./index.html"; // Replace with your page's URL
};Replace ./index.html with the URL of your containing page. Now when sessions expire, the user is bounced back to your own page instead of seeing DashboardFox's login screen inside the iframe.
A note on row-level security for guest content
Reiterating what was flagged in Background, because it's the single biggest mistake teams make: row-level security rules do not apply to anonymous users. The RLS mechanism requires a known user identity to match against profile tags or data tags — anonymous users have neither.
If you're considering publishing a report that was previously protected by RLS, the workflow is: (1) copy the report into the Guest folder, (2) inside the copy, hardcode the filter criteria the RLS rule was enforcing (a specific customer, a specific region), (3) verify by running the copy as an admin before marking it Public View. The original RLS-protected report stays in its original location, untouched, for internal use.
That's the end of Module 5 — branding. Module 6 picks up with server-level admin work: server settings, SMTP, and license management (where your Public View seat tracking lives).
If you're stuck
What goes wrong with Guest Library setup, in roughly the order you'll hit it.
My report shows "team" status, not "guest"
You haven't turned on Allow Public View yet. Open the report, go to Settings → Advanced Options, toggle Allow Public View ON, save. The status indicator will flip to guest and one Public View license is consumed.
I don't see "View Guest Library" on my login page
The button only appears when at least one folder has Allow Anonymous turned on. Verify your Guest Library root folder has the toggle on (Documents → folder → Advanced Options → Allow Anonymous). If you have subfolders with reports, only the root folder needs the toggle for the button to appear, but each subfolder also needs its own Allow Anonymous toggle to actually be browsable anonymously.
⚠️ Anonymous users are seeing data they shouldn't
The single biggest pitfall, and the most consequential. The report's filters aren't hardcoded. RLS does not apply to guests — only criteria embedded directly in the report definition do. Immediately turn off Allow Public View on the report. Then edit the report and bake the limiting criteria into the report itself (customer = "X", region in ('Y', 'Z'), date range = last 30 days, whatever's needed). Re-run as an admin to confirm the data is now properly scoped. Only then re-enable Allow Public View. If sensitive data was already exposed, contact team@dashboardfox.com immediately for advice on next steps.
"DashboardFox only allows one guest branding record"
You already have one Application Branding policy with Is Guest enabled and you're trying to enable it on a second policy. Only one active Guest policy is allowed (guest branding is global). Either edit the existing policy or disable Is Guest on the current one first.
Out of Public View licenses
Each Public View report consumes one seat. To free seats: open reports you no longer need to share publicly and toggle Allow Public View OFF. To add capacity: contact team@dashboardfox.com about Public View add-ons. License usage and limits are visible in server settings (Module 6).
I copied a report into the Guest folder but it's not showing for anonymous users
Two-step problem. The folder has Allow Anonymous on, but the report itself doesn't have Allow Public View. Both are required — folder permission gates discovery, report permission gates access. Open the report's Settings, turn on Allow Public View, save.
Anonymous users get permission errors clicking through a drill-down on my guest report
Same shape as the previous pitfall but now spanning two reports. A drill-down chains a parent report to a target report — if the parent is Public View but the target isn't, anonymous users can run the parent but get blocked when they click through. Both the parent and the target need Allow Public View turned on; each consumes its own Public View license. The target's folder also needs Allow Anonymous on (otherwise anonymous users can't enter the folder when the drill-down resolves). The drill-down lesson's makeItReal block covers the multi-report setup end-to-end.
Guest users can see the report but can't run it / no data shows
Almost always the report's criteria reference something that needs a user context — a profile tag, a "current user" filter, a data tag with no default value. Edit the report, remove the user-context-dependent criteria, replace with hardcoded values, save, re-test.
None of these match my situation
Email team@dashboardfox.com with screenshots of: the Guest folder's Advanced Options panel, the report's Settings → Advanced Options panel, and the URL you're testing with. Same business day reply.
