How to Share a Dashboard With a Client Securely

Share a dashboard with a client without the guesswork

Teams often email a PDF, attach a CSV and hope that the client opens the right version. This method fails when files change or when people forward attachments. It also fails when someone asks if the figures are current.

A better pattern is one stable client dashboard link. Publish the exported dashboard once. Put a sign-in step in front of it that only the email addresses of the client pass. When the numbers change, replace the files behind that link. This guide does this with Cloudflare Pages and Cloudflare Access. It also covers Netlify, Vercel and document-tracking tools such as DocSend and Papermark, where they fit better.

What you can publish with a client dashboard link

A static HTML report or an exported dashboard is a snapshot: a set of files that another tool created at a particular time. Common formats include:

• A folder that contains HTML, CSS, JavaScript, images and local data files
• A dashboard exported as PDF, PowerPoint, PNG or HTML
• A CSV file with column headings and fixed rows
• A document folder with a report, appendix, presentation and supporting files
• A front-end demo that runs entirely in the browser

A static HTML report that you share with a client keeps filters or charts only if its exported files include them. It does not connect to Salesforce, a data warehouse or a live spreadsheet on its own.

Capability	Static or exported dashboard	Live authenticated BI application
Data	Fixed snapshot from an export	Queries or refreshes a data source
Access	Shared browser link with a sign-in gate	User account, often with SSO or MFA
Interaction	Features included in the exported files	Live filters, drill-downs and saved views
Updates	Replace or redeploy files	Scheduled or on-demand data refresh
Permissions	Link-level or email-level access	Workspace, role or row-level policies
Best use	Client deliverables and periodic reports	Continuous operational analysis

A static host serves the first category. It is not a BI (business intelligence) data connector, and it does not replace row-level security (rules that show each user only their own rows). If clients need live queries, personal accounts or user-specific data, keep the BI application. Use the sharing and sign-in of that application.

Prepare the export before you share it

A report that works on your laptop can break after upload. Static HTML exports often contain absolute paths (full paths on your own computer), missing fonts or references to a local development server. Before you create the link, open the exported folder on a second device or in a clean browser profile.

Item	What to check	Why it matters
Entry page	The folder has a clear index.html or start document	Clients need an obvious first page
File references	Images, scripts and styles use portable relative paths	Local paths fail after publishing
Data scope	Remove hidden tabs, test records, API keys and unrelated client data	Anyone who can open a front-end file can inspect or download it
CSV structure	Use UTF-8, plain headings and consistent date formats	The file must open cleanly in any spreadsheet tool
File names	Prefer short names without confusing duplicates	Names such as final-v7-REAL.pdf create doubt
Accessibility	Test keyboard use, labels, contrast and text size	Clients can use assistive technology or phones

For readable exports, the WCAG 2.2 contrast guidance asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. These targets are useful even if formal compliance is not required.

File size also matters. A 25 MB report is 200 megabits. On a 10 Mbps connection, it needs about 20 seconds of transfer time, before network overhead. Compress decorative images. For unusually heavy interactive versions, offer a PDF.

Choose where the dashboard will live

Option	Access control	What you learn about viewers	Best fit
Cloudflare Pages with Cloudflare Access	Email one-time code for the addresses or domains that you allow	Access logs show which email signed in and when	HTML dashboards and report folders for a known group
Netlify	One site password, on Pro and Enterprise plans	Nothing per person	Teams already on Netlify that accept a shared password
Vercel	Password Protection is a paid option on Pro and is not available on Hobby. Vercel Authentication only admits Vercel users with access to the project	Nothing per person from a shared password	Projects already deployed on Vercel
GitHub Pages	Public, unless the organization uses GitHub Enterprise Cloud and publishes privately	Nothing by default	Reports that are safe to be public
DocSend or Papermark	Required email, email verification, passwords and expiry dates	Page-by-page viewing statistics	PDFs and decks rather than HTML dashboards

The rest of this guide uses Cloudflare Pages with Access. This setup gives each client contact their own sign-in, and you do not have to build a login system. Sometimes the deliverable is a PDF or a deck, and you want to see which pages people read. In that case, DocSend’s document tracking and Papermark’s link settings are the better choice.

How to share a dashboard with a client on Cloudflare Pages

When the export is ready, follow one repeatable sequence. The result is a single link that the client can still use months later.

1. Freeze the reporting period. Add an as-of date and a timezone, such as Data through July 12, 2026, 5:00 p.m. ET. Do not write Current results.

2. Organize the deliverable. Put the start page at the top level. Put supporting files in folders with plain names. Make dashboards, CSVs and methodology notes easy to find.

3. Create the Pages project. In the Cloudflare dashboard, go to Workers & Pages. Select Create application > Get started > Drag and drop your files. Enter a project name. Drag in the folder. Select Deploy site (Direct Upload docs). Drag and drop accepts up to 1,000 files of up to 25 MiB each. The site is now live at <project>.pages.dev.

4. Add a client-facing domain. Open Custom domains in the project. Select Set up a domain. Enter a hostname such as reports.yourfirm.com. Do this step before you add Access. Cloudflare does not let you add a custom domain that already has an Access policy (known issues). Access also needs the domain to be an active zone (a domain that Cloudflare manages) on your Cloudflare account. The full steps are in Add a Custom Domain to a Cloudflare Pages Site.

5. Turn on email codes. Go to Zero Trust > Integrations > Identity providers. Select Add new identity provider. Choose One-time PIN. New Zero Trust organizations do not have it on by default (one-time PIN docs).

6. Put Access in front of the domain. Go to Zero Trust > Access controls > Applications. Select Create new application > Self-hosted and private. Select Add public hostname. Choose the report domain. Add an Allow policy that uses the Emails selector for named people. For everyone at the company of the client, use Emails ending in instead. Choose a Session Duration. Select Create (self-hosted application docs). Access denies everyone who does not match an Allow policy.

7. Cover the other addresses. The project is also available at <project>.pages.dev. Each deployment also has a unique <hash>.<project>.pages.dev address. To protect the deployment addresses, go to Settings > General in the project. Select Enable access policy. Then follow the Cloudflare steps to extend that policy to the main pages.dev address. Our Cloudflare Pages Access guide explains these steps.

8. Test as the client. Open the link in a private window and on a phone. Make sure that the Cloudflare sign-in page appears before any content. Make sure that a code arrives at an allowed address. Make sure that every chart, navigation item and CSV download works. An address outside the policy gets no email, but the page still says that Cloudflare sent a code.

9. Send context with the link. State the reporting period, the intended recipients, the decision that you need and how to give feedback. Tell recipients that the sign-in code comes from noreply@notify.cloudflare.com. Then they can find the code if a mail filter holds it.

Choose the right protection for the risk

Match the access to the sensitivity of the work. A gate (a sign-in step in front of the content) reduces casual exposure. But do not overstate what a shared link can protect.

Access method	Good fit	Main tradeoff
Public link	Portfolio samples, public research and non-sensitive demos	Anyone who receives the URL can open it
Shared password (Netlify, Vercel)	Proposals or reports for a small known group	The password can be forwarded with the link
Email one-time code (Cloudflare Access)	Client work where each contact must sign in as themselves	Adds a step before access. You manage the allowed list
Tracked document link (DocSend, Papermark)	PDFs and decks where page-level reading matters	Works best for documents, not multi-page HTML dashboards
Authenticated BI account	Live or regulated data that needs individual permissions	More setup and account administration

An email code proves that the person had access to that inbox at sign-in time. It does not prove legal identity. It also does not show who stayed at the screen after sign-in.

Apply these safeguards:

• Before export, remove secrets and unnecessary personal data.
• Use a long, unique password. Do not reuse a client password.
• Send any password through a different channel from the link.
• Before you share restricted work, make sure that the allowed email list is correct.
• Move highly sensitive or regulated data to a system that meets stronger authentication and audit requirements.

A published JavaScript bundle must never contain a private API credential. Anyone who passes the gate can read every file that the browser downloads.

Update an exported dashboard without sending another link

A stable client dashboard link reduces confusion about versions. Deploy new files to the same project. Then clients return to the same address.

Use this update routine:

1. Save the source material and the previous export in your own version history.
2. Generate a fresh export with a visible reporting date.
3. Deploy the export to the same project. In the Pages project, select Create a new deployment. You can also run npx wrangler pages deploy <folder> --project-name=<project>. On Netlify, drag the folder onto the Deploys page of the site (Netlify manual deploys).
4. Open the shared link in a private window. Test the changed pages.
5. If the client needs to know that figures or conclusions changed, send a short note.

If a deployment goes out wrong, open Deployments in the project. Find the last good deployment in All deployments. Open its menu. Select Rollback to this deployment (rollback docs). Production switches back at once.

Suppose that a consultant publishes an annual revenue forecast of $1.24 million. Two days later, corrected churn data (data about lost customers) from the client raises it to $1.31 million. The consultant deploys the corrected export to the same link. The consultant also explains what changed and why. No second URL is necessary.

After an update, the browser cache can show an old asset. For static HTML, use versioned names such as charts-v3.js or content-hashed assets (file names that change when the content changes). Keep the name index.html stable. For documents, show the revision date inside the file, not only in its filename.

A stable link does not replace communication. Clients can already have the old PDF or CSV on their computers. So material corrections still need a clear message and a short change note.

Use viewing records for better follow-up, not surveillance

After you share a dashboard, it is not always clear if you must follow up or wait. Cloudflare Access records each sign-in. To see the records, go to Zero Trust > Insights > Logs. Select Access authentication logs. Each record shows the email of the user, the application and the time (log docs).

A record tells you that the link reached the right person. It does not tell you which pages the person read.

For total traffic, open Metrics in the Pages project. Under Web Analytics, select Enable (Web Analytics for Pages). Web Analytics counts visits for the whole site, not per person. If page-level reading matters, as with a proposal, send that part as a PDF through DocSend or Papermark.

Treat every record as a signal, not proof of intent:

Activity	Where you see it	Reasonable reading	Useful response
One sign-in from a client address	Access authentication logs	The link reached that person	Follow the agreed schedule instead of calling at once
Several sign-ins over a few days	Access authentication logs	The report is in use	Refer to it in your next message
Long time on the pricing page	DocSend or Papermark page statistics	Commercial terms possibly need discussion	Offer to answer scope or pricing questions
PDF downloaded	Your document tool, where it records downloads	Someone possibly reviews it offline	Do not assume approval or internal circulation
Feedback form submitted	Your form tool	The visitor took an explicit action	Reply to the stated question promptly

For example, an agency sends a proposal at 10:00 a.m. and sees a sign-in at 2:15 p.m. This supports a thoughtful message the next morning. It does not support an instant call that tells the client that you saw them read page 12. Such a call feels invasive.

A static site cannot store form submissions by itself. To collect answers, use one of these:

• On Netlify, add data-netlify="true" and a name attribute to an HTML form. Then turn on Enable form detection under Forms (Netlify Forms).
• On any host, embed a Google Form or a Tally form in the report.
• For documents that you share through Papermark, turn on the visitor feedback setting of Papermark.

Ask focused questions, for example which forecast to use or who approves the next stage. Collect only the information that you need. Explain its purpose. Follow the privacy rules that apply to you.

Five practical client dashboard link examples

These composite examples (each one combines several typical cases) show where static publishing works well. They do not describe specific customers.

Situation	Published material	Access and follow-up
Freelance proposal	An 18-page PDF with scope, schedule and price	DocSend or Papermark with email verification. Follow up the next business day after a view
Agency report	Static HTML charts, campaign notes and a CSV export	Cloudflare Pages behind Access for the client’s email domain. Discuss the findings in the next call
Financial consulting snapshot	A forecast PDF plus an assumptions workbook	Access or a Netlify password. Deploy corrected figures to the same project
Founder product demo	A browser-based front-end demo and a contact form	Netlify with Netlify Forms, password-protected during review
AI-generated status report	Reviewed HTML and PDF output from an internal agent	A script deploys with Wrangler after a person approves the files

The agency example shows the limit of an exported dashboard. The campaign charts show the data that was available at export time. A page refresh does not query an advertising platform, unless the export already includes a safe, working backend connection. For periodic reporting, create a new export. Deploy it to the existing client dashboard link.

For AI-generated reports, a person must review client names, numbers, permissions and confidential content before publication. Automation adds little value if it publishes the wrong quarter or exposes the data of another customer.

Secure dashboard sharing mistakes

Most publishing failures are ordinary. Examples are a missing file, a weak gate or a snapshot that people take for live data.

Mistake	Better approach
Uploading only a ZIP archive	Publish a clear browser entry page and offer the archive as an optional download
Leaving local or absolute paths in HTML	Use relative references and test outside the original project folder
Embedding tokens in front-end code	Remove credentials and keep private services behind an authenticated backend
Protecting the custom domain but not pages.dev	Enable the project’s access policy and cover the main pages.dev address too
Using public access for confidential work	Choose email sign-in or a password based on the audience
Calling an export real-time	Display the reporting period and the last export time
Creating a new URL for every revision	Deploy to the existing project when continuity matters
Reading a download as approval	Get each decision directly from the client

Final checklist for secure dashboard sharing

Publish the export as a controlled browser experience. Prepare the files. State when you exported the data. Choose protection that matches the risk. Test the client dashboard link from the side of the recipient.

Remember these limits:

• Static reports are snapshots, not live data connectors.
• Passwords and email codes improve control, but they do not replace every form of authentication.
• A stable link reduces confusion about versions. Sign-in records and page statistics can guide a considerate follow-up.
• Drag-and-drop publishing is enough for most work. Command-line and scripted deploys can come later.

Good, secure dashboard sharing is good client communication. It gives the client a working link, dated numbers and a clear next step.

A docs portal with Ask AI
and support tickets

Connect a repository, or describe your product to start. Each docs site has search, Ask AI, an API console, an MCP server and support tickets.

• Publishes from GitHub on every push
• Works with Mintlify repositories
• API console from your OpenAPI file
• MCP server and llms.txt for AI agents
• Ask AI and support tickets
• Analytics for people and AI agents

Start Free→ Questions? Ask AI in our docs

No card required.