Most delivery still happens by attachment or a link to a shared drive. You export, you send, and the file is somewhere you have no visibility into, inside a company whose staff turnover, agency partners, and internal drives you know nothing about.
For final delivery that’s the arrangement. It’s the earlier stages where the habit costs you something, because a client reviewing three options doesn’t need to hold three files.
Match the access to the stage
At review and approval, they need to look and give notes. Invite them to the registration and leave downloading switched off, which is where it starts. They see the work; they don’t get a copy to circulate.
At scoping, before anything is signed, they need to know the work exists and is yours. The registration’s public page proves that without exposing the work at all.
At final delivery they get the file, because that’s what they’re paying for. Switch downloading on for that person, or send it directly if the workflow demands.
The pattern that causes trouble is using final-delivery access at every stage, so a client who reviewed three concepts ends up holding all three, including the two nobody bought.
How invitations actually work
You can invite an existing Dacr user, an organization, or any email address. An emailed invitee has to create a Dacr account before they can see anything, which matters before you promise a client a two-minute look.
Downloading starts switched off for every viewer and is enforced server-side, so an invited viewer genuinely cannot pull the file until you allow it. For an email invite you can’t set it at all until they’ve accepted, so the sequence is invite, wait for acceptance, then enable downloading if they need it.
What you can take back, and what you can’t
An invitation can be withdrawn. Access ends immediately. They can no longer view or download the work, while the registration record itself is unchanged and its public attributes stay verifiable.
The public page is different, and it’s worth not confusing the two. It’s the registration’s own address rather than something you generate per recipient, so it can’t be revoked and anyone you send it to can forward it. That’s fine for what it’s for, proving ownership, and wrong for anything you’d want back.
Files you emailed are wherever they’ve reached. That gap matters in the situations nobody plans for: the account manager leaves, the agency loses the account, the relationship ends badly.
The registration should exist before the send
A registration made before delivery records the work as it left you. If a question comes up later about what was delivered, or a variant appears you didn’t produce, there’s a fixed version to compare against.
Registering afterward still creates a record. It creates one dated after the work was already in someone else’s hands, which is a harder thing to explain than it sounds.
Decide it once
Make the access decision at registration rather than at the moment of sending. With default privacy set and an invite-based delivery pattern, it’s settled in advance instead of at six in the evening with a client waiting.
