How to share notes with a PIN: a practical guide

Sharing a note should answer three questions: where is the information, who needs to read it, and what should happen next? A long message thread often answers the first question only temporarily. The note gets buried, someone forwards an older attachment, and the next person cannot tell which instructions are current.

A link-and-PIN workflow gives a recipient one project entrance and a predictable place to review published information. In Draftnod, notes live inside the existing client, project, task and version structure. The terminology in the workspace still matters: a task can hold the purpose of a note, while a draft version holds the text or link you want someone to review. This guide explains that workflow without implying that a PIN makes every kind of information safe to share.

Decide what the recipient should see

Start with the outcome, rather than the tool. Are you sharing instructions, asking for a correction, or seeking approval of a particular revision? Put that outcome in the title. “Workshop arrival instructions — confirm your equipment” gives a reader more direction than “Notes”.

Keep the shared record limited to what the recipient needs. Remove unrelated names, account details and private observations. A project portal is a shared context, so plan its contents for everyone who receives that project's link and PIN. If two audiences need different material, use separate projects rather than relying on a heading to separate their access.

Before setting anything up, read how to organize shared notes. A smaller, well-defined project is easier to maintain than an expanding collection of unrelated pages.

Create the project using the existing controls

The workspace owner creates an account and adds a client record. For a broader use case, that record can represent the person or group receiving the notes. Create a project under that record, and set its six-digit PIN using the existing project controls. The underlying workflow and account permissions remain the same.

Choose a project name the recipient will recognize. Avoid putting a PIN or sensitive personal detail in the name. Add a task for the specific note, with a brief that explains its purpose and any relevant deadline. If a recipient submits a request from the portal, it remains pending until the owner accepts it; simply receiving a request does not mean the work has been agreed.

Save privately before publishing

Add a draft to the task. The draft caption can contain the note itself, and an external link can point to a document or other deliverable when the information lives elsewhere. Save draft retains an unpublished version. Publish is the separate action that makes the version available in the project portal.

Use that separation as a short review checkpoint. Read the note as if you had no background context. Check dates, spelling, file access and the action you are requesting. Remove working comments that are meant only for you. A draft that looks finished in your workspace is still private until you publish it, so tell recipients only after the relevant version is available.

Send the link and PIN with useful context

Copy the portal link for the correct project. Send a concise message naming the project and the task to open. Share the PIN privately, and consider a separate communication channel where practical. This reduces the chance that a casually forwarded link carries every access detail with it, but it does not prevent an authorized recipient from copying information.

A useful invitation looks like this:

Please open the workshop project and review “Arrival instructions”. Version 1 contains the venue details and equipment list. Leave a comment if anything is unclear. I will send the six-digit PIN privately.

Do not publish the PIN on a public page or place it inside the shared note. Double-check that you copied the intended project link, particularly when you maintain several projects for the same group.

Explain how feedback and revisions work

Recipients do not need a Draftnod account to enter the project portal. They open the link, enter the PIN and select the relevant task. Published versions provide a stable reference for comments and decisions. Ask the recipient to name the detail that needs changing rather than sending a vague “please update this”.

If a change is needed, save a new version and publish it. Keep the previous version as history, and say which version is now ready for review. When the task needs a formal decision, use the existing approval or request-changes controls. For ordinary instructions, a comment may be enough; do not require approval merely because the button exists.

The version history guide explains how to keep revisions understandable, and the feedback guide provides examples of actionable comments.

Understand the boundary of PIN access

A PIN is an access mechanism, not an assurance that a recipient will keep a note confidential. Anyone who receives valid access details may be able to read the shared project. An external document has its own permissions, and Draftnod does not automatically grant access to that service.

Use Draftnod's privacy policy to understand the product's published data practices. For general account-protection habits, consult CISA's Secure Our World resources. Those resources cover broader security behavior; they do not certify a particular note-sharing product.

If a PIN is forgotten or no longer appropriate, use Set / change PIN and share the replacement privately. Review project access when the audience changes. The PIN sharing safety guide includes a practical checklist for choosing suitable content.

A final checklist before you invite someone

• The project contains only information intended for this audience.
• The note title describes the reader's next action.
• The correct version has been published.
• Every linked file has suitable permissions in its original service.
• The invitation identifies the note, and the PIN is shared privately.
• You have a clear plan for comments, revisions and the final decision.

Open your workspace and try the workflow with a low-risk note first. Keep the first example small enough that you can check the entire recipient experience before using it for a larger handoff.