Named recipients
A share can distinguish intended recipients instead of treating possession of a secret URL as identity.
Secure sharing
Share sensitive content with named recipients, known versions and an explicit lifetime.
External collaboration is useful because it crosses an organisational boundary. That is also what makes it risky. Casewelt treats the act of sharing as its own object, with enough context to know who it is for, what it exposes and when it should stop working.
A practical example
The board pack needs to reach two auditors for fourteen days.
The finance team keeps its normal workspace access. The auditors receive only the approved board-pack version. Each recipient proves control of the intended mailbox before content is served, and the share can expire on schedule or be revoked early without changing employee access.
Casewelt still keeps the two recipients, the file version, the access window and the events generated during the share distinct from one another.
Inbound collection
Ask for files without opening the workspace.
A file request is a time-bound inbound path into a folder. The requester does not receive staff navigation or organisation administration. Mailbox proof and an expiry sit on the request the same way they sit on an outbound share: the organisation still knows who was asked, where the object should land, and when the path should stop working.
What the share knows
Enough context to remain controllable after the email is sent.
Known content
Access can be tied to a specific file version, avoiding an accidental jump to a later draft.
A defined lifetime
Expiry and revocation give the organisation a clear way to end access.
Scoped permissions
Viewing, downloading or resharing can be treated as separate permissions where the product policy requires it.
Separate trust boundary
External access does not need an employee account or the same session surface used by staff.
Auditable events
The record of create, recipient proof, content access and revoke can remain available after access ends.
Design principle
A secure share should answer four ordinary questions.
- Who is it for?Recipients should be distinguishable.
- What exactly can they open?The content and version should be known.
- How long does access last?Expiry and revocation should be explicit.
- What happened while it was live?Access history should survive the share itself.
What a share guarantees
Recipient, surface and lifetime stay explicit.
Recipient identity
A share identifies its intended recipient. Holding the URL alone is not enough to establish access.
Separate access surface
External recipients use a dedicated share surface without staff workspace navigation or organisation administration.
Explicit lifetime
Expiry and revocation are part of the share itself, so external access can end without changing employee sign-in.
See the flow
See the sharing flow with your own scenario.
Use a real recipient, file/version requirement and access lifetime to evaluate the full path.