Share a Live Dashboard as a Link

“Live” here means one always-on link plus the revisions you push: you (or your agent) upload a new file, and the client keeps the same URL. It is the report at its latest version, always in one place, rather than a warehouse you have to wire up.

If you run weekly reporting for clients, here is what you get:

• One URL the client reopens instead of hunting Slack for “final_v4.pdf.”
• Revisions in place. New numbers on Monday, same link.
• A scrollable page, not 16:9 slides. Charts stay readable; nobody scrolls past dead “appendix” slides.

That is the job agencies and consultants actually have. Weekly reports, metric walls, and long proposals die when you slice them into 16:9. A shareable live dashboard is a scrollable page on a URL: one link for the client, revisions when the numbers change, optional live scroll sync when you talk through it.

You do not need a BI tool or a second product. This is the same hosting model as how to share an HTML presentation, with kind set to dashboard. If you go live, viewers can follow your scroll. An agent can publish a revision when you ask. Nothing updates itself.

Why dashboards should not be decks

Slides are a talk track. Dashboards are a place to look. Forcing a report into slides creates:

• Charts too small to read.
• “Appendix” slides nobody advances to.
• A PDF-shaped expectation, when what the client actually wants is a link they can reopen.

Clients who say “just send the dashboard” want a URL they can reopen on Monday, not a deck to sit through. Give them that, and the weekly check-in stops being a meeting nobody reads afterward.

Sharing and presenting a dashboard

The share path is the same token URL as a deck. Recipients scroll. If you go live in presenter view, scroll position and section can sync. Viewers who follow you stay on the part you are explaining.

Pins use a CSS-style anchor on a section instead of a slide index. Highlights (freehand strokes) persist for dashboard review sessions. That is the closest thing to “markup this chart” without editing the HTML.

Allow pins only if you want comments on the page. Turn them off for a clean client send.

Revisions: one link, new numbers

The useful pattern for agencies:

1. Create the dashboard once.
2. Each week, the agent (or you) replaces index.html with updated figures.
3. The client keeps last month’s URL.

That is “always-on” in the product sense: the link is always up and always shows your latest upload. If a chart must pull real-time data, build that fetch into the HTML itself and test the link before you send it.

Tell clients to reopen the same link each week - the newest version is always at that URL, so nobody hunts for the latest file.

When to use a presentation, and what to tell clients

Use a presentation when you will stand up and click. Filmstrip, notes, and laser all assume slides. A dashboard you try to “present” as slides will feel like scrolling a website while people wait. That can be right for a working session. It is wrong for a 12-minute pitch.

Many teams keep both: a dashboard as the leave-behind, a short deck as the talk. Two presentations, two links, same library.

Tell clients: “This URL is the report. Refresh it next week for the new numbers. You do not need an account.”

Keep the promise simple and true: the URL is the report, and it refreshes when you push a new version. If a chart needs to reflect live data, build that into the HTML yourself and test the link first. And if someone needs a PDF for a steering pack, export it from the tool that produced the charts, then host the interactive version here for everyone else.

Building the page

A dashboard is just a well-structured HTML page:

• One vertically scrolling layout, not a stack of hidden slides.
• Clear section headings, so navigation and live scroll sync have something to anchor to.
• Internal links and simple interactive controls are fine.
• Keep the file under the upload limit (10 MB on the free plan).

When you upload, Prezzly usually recognises a scrolling page as a dashboard and a slide layout as a presentation. When you publish through a connected agent, Model Context Protocol (MCP) does not guess for you (see MCP for presentations), so say you want a dashboard explicitly or you tend to get slides. If it ever guesses wrong, you can switch the type on the presentation page in a click.

Speaker notes are a slide feature. If you need a talk track while you scroll a dashboard, keep a separate outline; speaker notes for HTML presentations apply to slide decks. And if the same numbers also need a stand-up version, publish a short deck alongside the dashboard - the report stays scrollable, the pitch stays slides, and both live at their own link.

Frequently Asked Questions (FAQ)

Is a Prezzly dashboard a BI tool?

It is a host for the dashboard you build. You bring the data in your HTML file, and Prezzly keeps it at one shareable link that refreshes when you push a new version. If you want live queries, wire them into the file itself.

Can I embed the dashboard in Notion?

Paste the share URL into Notion and it becomes a bookmark link; readers click through to the full-screen viewer. That keeps the interactive version intact instead of flattening it into a static preview.

How long does the share link last?

Same rules as decks. Guest view: 72 hours. Account share links: default 7 days, free plan capped at 30, absolute max 365 days. You pick the lifetime when you create the link.

Will viewers see my editor UI?

No. They see the hosted page in a viewer. Free-plan viewers may see Prezzly branding.

Can I convert a deck to a dashboard later?

Yes. The owner can switch kind on the detail page if the HTML is actually a scrolling page (or the other way around).

---

If the artifact is a report, do not fake slides. Publish a dashboard, send one URL, and revise that URL when the numbers change.