Case Study · Secure Share
Designing a safer way for enterprise teams to share Confluence pages outside their organization without losing admin control.
With no fast secure path, people exported, screenshotted, and emailed pages instead. Admins lost visibility the moment content left Confluence.
The share flow and admin policy model I designed ship in the secure external sharing product, where expiry, revocation, and audit sit with admins rather than with whoever is sending a page. Every install is a separate organisation.
Atlassian Marketplace, vendor listings, August 2026Context
Enterprise teams keep important knowledge in Confluence and regularly need to share selected pages outside the organization. Without a secure path, users export, copy, or screenshot content and admins lose visibility. The real problem was balancing speed for users with expiry, revocation, and audit control for admins.
When secure sharing feels slower than an unsafe workaround, users avoid the secure path. The experience had to make the safe action feel like the easiest action.
Confidentiality and proof note
Due to NDA restrictions, this case study uses white-labelled recreations, anonymized impact themes, and outcome summaries instead of live screens or account data. The product logic and design decisions are preserved.
The call
Two audiences with opposite priorities. The question was not which controls to build, it was who should be forced to think about them. Putting them in the share dialog would have made every employee a part-time security officer. That was the call, and everything else followed from it.
Shared principle
Fast for users, governed for administrators.
The split was not a guess. Several independent signals pointed the same way: senders wanted the share action to stay fast and obvious, while admins wanted expiry, access control, revocation, and audit visibility to live in a layer they owned and could answer for.
Converges to
Balancing speed and control
Run the same share under the model that shipped and the model I argued against. Switch between them and watch what the sender is made responsible for.
1Pick a real sharing moment
A producer at your agency needs the rollout plan today, and will never have a login here.
2Decide who has to think about security
Q4 Partner Rollout Plan
External agency, no Confluence seat
Applied automatically · Partner Collaboration
An admin set this once. The person sharing never sees it as a question.
One decision for the sender: who receives it.
What happens
Link is live. The agency reads the current page without a licence, and access ends in 14 days whether or not anyone remembers to end it.
The call I made
Expiry is the organisation's risk decision, not the sender's convenience decision. It belongs in policy.
The shipped version looks almost empty. That emptiness is the design work: five decisions were moved off the person least equipped to make them.
Each of the three decisions below cost something. Naming the cost was how the trade got agreed rather than relitigated.
The sender's flow stayed on the one job they are qualified to do: choose who receives it. Expiry, access restriction, revocation, and visibility moved to the people who own that risk.
Cost: power users lose per-share control. Accepted, because inconsistent security set by hundreds of senders is worse than slightly rigid security set once.
Common sharing actions pick up safe rules automatically. Advanced options stay reachable, but nothing blocks the everyday share to collect them.
Cost: the product looks less capable in a feature comparison. Accepted, because a control nobody sets is not a capability.
Knowing what was shared, by whom, when it expires, and whether it can be pulled back carried the same design weight as creating the link.
Cost: significant scope in a small team. Argued for by reframing it as the thing buyers actually evaluate.
Making the case
Security features are easy to specify and hard to feel. Most of the disagreement in this project dissolved once the requirement was attached to something everyone in the room had already lived through. These are the comparisons I kept coming back to.
In my online exams at Manipal, every question paper on screen carried my own roll number across it. Photographing the screen did not get you a clean copy of the paper. It got you a copy with my roll number on it.
So the product had to
Watermark every view with the person viewing it, not with the company logo. A download block stops the lazy copy. Attribution is the only thing that survives a photograph of a screen, and it changes behaviour before anything leaks.
A phone brand ships review units weeks before launch. A dozen reviewers hold the same material, and every one of them publishes at the same minute. The material moves early. The visibility does not.
So the product had to
Split having it from opening it. Material can be distributed ahead of time and stay sealed until a moment the admin sets, so preparation stops being a security risk.
Structure
Once the split was agreed, the structure fell out of it. The interesting part is not the map, it is the rule that decided every placement.
Where things live
One rule decided every placement: if getting it wrong hurts the company, it belongs to the admin. If getting it wrong only slows one person down, it belongs to the sender.
Anyone sharing a page
Why here
Everything here is reversible by one person, and getting it wrong costs that person time rather than costing the company an incident.
Whoever owns security
Why here
Every item here has organisation-wide blast radius. Putting it in the share dialog would have delegated company risk to whoever happened to be sending a page that afternoon.
People you shared with
Why here
An external viewer should learn nothing about internal structure. The share is a window into one page, not a door into the space.
Both sides of that split, white-labelled and operable. The sender's side is deliberately almost empty. The admin's side is where the weight went.
The same decision, seen from the sender's side. Their whole experience is three moments, and the design work was making the middle one uneventful.
The journey, in plain words
4 stages
“I will export it to PDF and email it. Everyone does that.”
What the design does
Put the secure path exactly where the unsafe one starts, so the protected action is the one already within reach.
“I do not know what our security rules are, and I do not want to guess.”
What the design does
Policy applies silently. The sender is never asked a question they are not qualified to answer.
Held back
This stage shaped the design but sits too close to the product to show. Happy to walk through it in conversation.
“I need this to stop working now, and I need to know who already saw it.”
What the design does
Revocation and the view history sit together, so cutting access and understanding the exposure are one task instead of two.
The share itself is deliberately the least memorable step. Everything worth designing sits either side of it.
Ownership
The team was small: a product manager, an engineering team, and design. I led the product design direction and drove the separation of the everyday share flow from the admin policy layer, so the product stayed flexible without pushing security decisions onto every user.
Where the disagreement was
Wanted per-share controls visible in the dialog, because competitors listed them as features.
How it resolved
I showed the same share moment under both models rather than debating it abstractly. Once the cost of five decisions per share was operable, the conversation moved from feature parity to adoption.
Policy inheritance is harder to build than a form with switches.
How it resolved
Scoped it as tiers rather than free-form rules, which kept the model small enough to ship while covering the sharing patterns research had surfaced.
The product was being positioned as a sharing tool, the category it would lose in.
How it resolved
I pushed to position it around control instead of sharing. That changed the marketplace narrative and, in turn, what the first screen had to prove.
Impact
The revamp reshaped external sharing for both sides: a fast protected path for users, inherited control for admins, and a clearer story for buyers during evaluation.
Before
After
The product story became easier to explain around secure external sharing, protected links, expiry, revocation, and admin visibility.
The experience gave admins clearer control over how shared content could be accessed, managed, expired, and revoked.
The marketplace-facing narrative was improved to communicate business value faster during evaluation.
Judgment
Security UX is not about showing more controls, it is about placing control at the right level: safe defaults for users, visibility and recovery for admins. The harder call was positioning. I pushed to frame the product around control rather than sharing, which changed both the product UX and how we told the story during evaluation.
If I ran it again, I would put the policy tiers in front of admins earlier. The tier model was the piece with the longest shadow, and it was validated last.
Next Project
SCIM Provisioning for Jira →