Sharing · 5 min read
Sharing links and images in notes: access, context and file limits
Share external files and images with useful captions, appropriate permissions and a clear distinction between the note and the source asset.
Written with AI assistance and checked against Draftnod’s product workflow. Examples are illustrative.

A shared note often points to information somewhere else: a document, a design file, a folder or an image. The note can explain what the recipient should do, but it does not automatically make the source asset available.
The most common practical mistake is to send a working link that only the owner can open. Another is to provide a file with no explanation of whether the recipient should review, edit or simply reference it. This guide covers both the access boundary and the writing that makes shared assets useful.
Choose whether the note or the file is the main record
Decide where the recipient should find the instructions and where the deliverable lives. In Draftnod, a task and its published versions can hold the note and review record, while an external file remains in its original service.
If the note is the main record, summarize the purpose and link to supporting assets. If the file is the main working material, use the note to state the review scope and identify the relevant version.
Avoid maintaining two conflicting instruction sets. When details live in an external source, explain that relationship so the reader knows where to check changes.
Use descriptive links
A link should say what it opens and why it matters. “Participant schedule — review arrival times” gives more direction than “Click here”.
Include enough context to distinguish similar assets. If a project has several quotes or drafts, identify the supplier, version or date where appropriate.
W3C's accessible writing tips recommend meaningful link text. This helps people scanning the note and those navigating links with assistive technology.
Check permissions in the source service
The source service controls who can open an external file. A Draftnod project link and PIN do not grant permission to a document or design account elsewhere.
Choose the appropriate sharing setting for the intended audience. Avoid making a sensitive file public merely to remove friction. Use the source service's own account or link controls where needed.
For example, Google Drive's file sharing help describes its sharing controls. Check the documentation of whichever service you actually use, because permissions and available options differ.
Explain whether the linked file can change
A link to a live working document may show different content later. That is useful for ongoing work, but it can complicate a review tied to an earlier published note.
Say whether the file is a working source, reference copy or approved snapshot. Where the source service supports versions, identify the relevant revision. Do not imply that publishing a Draftnod version freezes an external file.
The version history guide explains how to keep comments and decisions meaningful when revisions occur.
Use image uploads within the actual plan limits
Draftnod's Free plan supports text and external-link drafts without new image uploads. Standard and Pro provide image storage with their existing project, task and storage limits.
The existing image workflow allows up to five images per request, note or version, with a maximum of 10 MB for each image. Storage availability and remaining capacity still matter; a paid plan is not unlimited storage.
Check the pricing section for the current plan presentation. Do not assume an image upload is available simply because an older image remains viewable after a plan change.
Give images a useful caption
A caption should explain what the recipient should notice. “Entrance from the street — use the door beside the sign” is more useful than a filename.
If an image contains important text, include the essential instruction in the note as text too. A recipient may be reading on a small screen or may not be able to inspect the image easily.
Use images to support the instruction rather than replace every sentence. A process can benefit from a reference image, while the action and exception still need clear wording.
Review the asset before publishing
Check that the file or image is the intended version and does not contain unrelated private details. Crop or redact material using appropriate tools before uploading when necessary, and verify the result.
Saving a draft keeps the version unpublished. Publish is the separate action that makes it available in the project portal. Review the caption and links at that boundary.
The PIN sharing guide covers how to invite a recipient, and the PIN safety guide helps decide what content belongs in the shared project.
Ask for feedback on a defined asset
Name the version and the part of the asset you want reviewed. “Check the entrance photo and confirm the landmark is recognizable” gives the recipient an observable task.
If the asset changes after feedback, publish a new version and describe the difference. Keep the decision tied to the material actually reviewed.
The feedback guide provides a format for comments that identify the location, problem and desired correction.
A pre-sharing asset checklist
- The asset is the intended file or image.
- The caption explains its purpose.
- The link text identifies the destination.
- The source service allows the intended recipient to open it.
- The note explains whether the file is live or a reference copy.
- Private or unrelated content has been removed.
- The correct Draftnod version has been published.
Open your workspace and test one text-and-link note before adding a larger collection of assets. A useful shared file is accessible, correctly identified and connected to a clear next action.


