Shared report links: a safer way to send reports to clients

It is 5:40 on a Thursday afternoon. At a small agency, an account manager is putting together the monthly performance report for a nine o'clock meeting the next morning. She screenshots six charts from the dashboard, drops them into a deck, exports it to PDF and attaches it to an email. The file is called report_final_v3.pdf. At half past nine the client asks: "This 412 figure, what date range is that?" She opens the dashboard on her laptop and the same card now reads 418, because two more deals closed overnight. The remaining twenty minutes of the meeting are spent arguing about the report rather than about the business.

This piece is about the third option for getting a report to a client: the shared report link. We start with what a screenshot or a PDF attachment quietly throws away, then look at why a link that needs no login can actually be more controlled than an attachment. From there: what the recipient actually sees, how to choose between password, expiry date and view limit, which reports are safe to expose at all (with a decision table), when a live link beats a frozen export, where your answer comes from when a number is challenged, how a share should end its life, and who writes and audits the sharing rule inside a team.

What disappears when a report travels as a screenshot?

A screenshot is a photograph of a number, not the number itself. The photograph carries no date range, no applied filter, no indication of when the underlying data was last refreshed. The recipient gets the figure and fills in every surrounding condition from whatever you said out loud. Two weeks later that same image turns up in somebody else's deck, and by then none of those conditions exist anywhere except in memory.

A PDF attachment is a step better but carries the same illness. The file freezes the moment you send it while your dashboard keeps moving. When the gap is small nobody notices; when the gap gets wide, trust takes the hit, and it is your credibility that pays rather than the file's. Reading a chart correctly matters, but so does knowing which definition produced it. Without a shared vocabulary for what each chart actually tells you, an attached image does not settle the argument, it only postpones it.

The third loss is the distribution trail. Once an attachment starts being forwarded, you have no idea whose inbox it reached, and there is no way to say "that version is no longer valid".

Why can a no-login link be safer than an attachment?

It sounds backwards at first. How can an address that asks for no credentials be safer than a screen behind a password? The answer is to compare against the right alternative. The alternative is not "give the client a CRM seat"; the alternative is flinging an ungoverned attachment into an email thread. A link replaces that attachment and restores three things the attachment never had: revocability, a lifespan, and a defined scope.

Rocketly's Shared Report Link feature builds those three controls into the act of sharing itself. You open the report at an address that requires no login, and on the same screen you set a password, an expiry date and a view limit, and you can switch the whole thing off whenever you want. The moment you switch it off the address stops working. An attachment has no such button; recalling a sent file amounts to relying on the other party's manners.

Sales teams have been running this pattern for years. You do not make a customer open an account to pay you; you send a link that takes payment in one tap and you control how long that link lives. Report sharing sits in exactly the same place. You hand the outside party a narrow, revocable window rather than an identity.

What exactly does the person opening the link see?

This is the question to answer before you create the share, and most teams never ask it. A report link exposes the report's current definition: the selected period, the filters applied, the grouping and the column layout. The recipient sees all of it. What they do not see is everything around the report, which is the larger part: record pages, other reports, contact cards, internal notes. Sharing opens a window, not a door.

The second layer that defines scope is permissions. Rocketly's Scope by Permission rule means a report only ever contains the rows the person running it is allowed to see, so a team-scoped user pulls only their own team's data. That rule governs sharing too: a link you publish cannot show a row you yourself cannot see.

For internal readers the calculation is different. A colleague should sign in with their own account, and once one-click authentication is in place, internal access carries almost no friction anyway. The link exists to constrain the outside, not to smooth the inside.

Password, expiry, view limit: which one, when?

The three settings do different jobs, and applying all three to every share only manufactures friction. A password protects against the link circulating where it should not: even if the address is forwarded, the content stays shut. An expiry date is for shares whose purpose has a calendar attached to it, such as a monthly review, a live proposal, or a one-off audit. A view limit earns its place in the narrow case where you genuinely mean "one person, one look".

A workable rule of thumb: a share should not outlive the reason it was created. For a monthly report the expiry date is the day the next report goes out. For a performance summary attached to a proposal it is the proposal's validity window. Leaving the duration open-ended means leaving a door open that nobody remembers months later.

The same logic already governs credentials. Just as issuing access keys with a defined scope and a defined lifetime is standard practice, a report link should behave the same way: permanent access is the exception, temporary access the default.

Which reports can leave the building, and which never should?

Not every report is shareable, and that call is editorial rather than technical. The dividing line is whose data the report carries. Totals belonging to the recipient's own account travel comfortably. Reports carrying other clients' records, internal performance breakdowns or personal contact details do not travel at all. And there is a middle category: shareable, but only after it has been through a filter.

Report type	Safe to publish?	Do this first
Period summary for the recipient's own account	Yes	Fix the period and the metric definition
Channel and source performance	Usually	Filter out other clients' data
Team leaderboard	No	Keep it internal
Lead list with contact details	No	Publish an aggregated summary instead
Cash flow projection	It depends	Named counterparty only, with an expiry

The "filter first" row is the one that gets skipped most often. Before opening a channel performance report to a client you need to exclude other accounts' data, narrow the team filter on a prebuilt report, or change the field selection on a custom one. The care required when exposing output that contains personal data is the same care described in protecting customer data more broadly: data leaves in the narrowest form that still does the job.

Live link, frozen export, or scheduled delivery?

All three are legitimate, and the choice depends on what the recipient will do with the report. A live link suits situations where you want the data to stay current: a campaign in flight, progress against a monthly target, an open project. Whenever the recipient opens the page, they see the state at that moment. A frozen file exists to document a moment instead, as a contract annex, an audit record, a formal notification. Rocketly's Report Export downloads any report as PDF, Excel or CSV, and the output follows whatever period and filters are selected at that instant. For heavy exports, Background Export runs the job in the background and opens the download link once the file is ready.

The third route is establishing a rhythm. A summary that arrives on its own at a fixed hour creates a cadence without the recipient having to ask; Scheduled Report runs on a daily, weekly or monthly send time and emails the output to a recipient list. For most teams the right combination is two of the three: a frozen summary once a month, alongside a live link that stays open.

The cost of choosing wrongly is invisible but real. Send a live link and say "look at this figure", and you will be explaining yourself next week when the figure has moved. Send a frozen file and say "this is where we stand", and it becomes wrong at the first refresh.

Where will your answer come from when a client questions a number?

The real test of a shared report is the moment the recipient challenges a figure. A good answer to "where does this 412 come from?" should come from the report itself, not from memory. Rocketly's Methodology Panel sits next to each metric and states which records, which filters and which date field produced that number.

The second question is usually about freshness. The Data Freshness Indicator states when each report and dashboard card was last updated, which removes the risk of treating a cached figure as current; when in doubt, the refresh button bypasses the cache and pulls the data again. The third question is comparison, and Period Comparison places the previous equal-length period alongside the current one in one click, adding the difference for every summary metric.

When the question falls outside the report's scope, the right move is not to widen the report but to build a new slice. Assembling your own report by choosing fields, filters and grouping is faster than answering each new question with another screenshot. Save that slice as one of your Saved Report Views and you never have to rebuild it: next month the same link opens with the same definition.

How does a shared link's life actually end?

Every link you open should have a closing plan. In practice there are three ways one ends: the expiry passes, the view limit runs out, or you switch it off by hand. The first two are automatic and therefore reliable; the third depends on somebody remembering.

There are still cases where manual revocation is the only option: the relationship ends, ownership changes hands inside the team, or the report's definition shifts. Change a filter or the period logic and the link out in the world may now be answering a different question entirely, and nobody notices, because the address has not changed.

Then there is the case where the number itself breaks. With a link live outside the company, learning from the client that a metric has gone strange is the worst possible order of events. An alerting setup that flags a drop past a threshold reverses that order: you see it first, and you either revoke the link or add the explanation. Dashboard Annotations help here too. Pin "campaign paused on this date" to that day on the chart, and the explanation stands beside the number instead of arriving by email.

Who writes the sharing rule, and who audits it?

In a one-person team this section is unnecessary; past three people it becomes unavoidable. With no written rule everyone applies their own threshold, and the loosest threshold becomes company policy by default. The written rule does not need to be elaborate. Four lines will do: which reports may be published, what the default duration is, when a password is mandatory, and where open links are listed.

Auditing is the part most teams skip. Looking at the list of open shares once a month is enough to catch the ones nobody closed. That habit works alongside shared visibility and clear ownership: every open link has an owner, and when that owner changes roles or leaves, the link gets reviewed with everything else they held. An unowned link is a forgotten link.

A report link is not the only address you expose to the outside world either. A booking link that writes appointments straight into the CRM falls under the same policy. Every address that goes to a client should answer the same three questions: who created it, how long it stays open, and what data it touches.

If you want to turn this into a habit rather than a policy document, the fastest route is to try the report library and the shared link settings against your own data: start a free account and publish your first report behind a link with an expiry date.

FAQ

Does the person opening a shared report link need an account?

No. The link requires no login, so the recipient sees the report as soon as they open the address. If you set a password, only someone who knows it gets in. Internal readers should still sign in, because that is where permission scope applies.

Does the data keep updating after the link is shared?

With a live link, the recipient sees the data as it stands at the moment they open the page, and the freshness indicator on the card states when it was last updated. If you want to share a fixed moment instead, send an exported file.

I sent it to the wrong person. What now?

Revoke the link; from that moment the address stops working. Then recreate the share with a password and an expiry date, and review the report's scope while you are at it.

Can I share the same report with several clients?

Technically yes, but the better practice is a separate link per recipient. Separate links let you tune the duration and view limit for each one, and revoke a single recipient without disturbing the rest.