Skip to content

Sharing

Not everyone who needs to review your planning documents has — or wants — a Forginate account. Share links solve this: a link-based, read-only portal to a product's approved documents, served at share.forginate.com, that an outside stakeholder can open in any browser.

A share is an unguessable link scoped to one product's documents. Whoever holds the link can:

  • Read approved documents — and only approved versions. Drafts, pending edits, and unapproved versions are never visible through a share.
  • Leave comments on documents. These land in your normal document feedback stream, tagged as coming from the share, so you see external review alongside internal notes.
  • Record an approval on a document — useful when a client's sign-off is part of your process.

A share can never reach anything else: other products, project settings, runs, costs, or any control surface. It is strictly a document review window.

A link is a credential

Anyone holding the link has its access. Send share links over private channels, and revoke a link the moment it should no longer work.

The review agreement (clickwrap)

Before a share recipient can use the portal, they're presented with a review agreement and must accept it. The acceptance is recorded — which agreement version was accepted, and when — so you have a record that every external reviewer agreed to the terms before seeing your documents.

If the agreement text is later updated, recipients are asked to accept the new version on their next visit.

Creating and managing shares

Shares are managed per product from within the app:

  1. Open the product and go to its sharing controls.
  2. Create a share — Forginate generates the link. Copy it and send it to your reviewer.
  3. The share list shows each link's status and activity, including when it was last used.
  4. Revoke a share at any time. Revoked (or expired) links stop working immediately — the portal rejects them on the next request.

You can create multiple shares for the same product — for example, one per client contact — so revoking one reviewer's access doesn't affect the others.

What the recipient experiences

  1. They open the link — no login, no account creation.
  2. They accept the review agreement.
  3. They see the product's document tree (approved documents only) and can read each one.
  4. They leave comments where they have feedback, and record approval where asked.

That's the entire surface. There is nothing for them to configure and nothing they can break.

Shares vs. project team membership

Share linkProject team member
Account requiredNoYes
SeesApproved documents onlyDocuments, versions, requests, activity per their role
CanRead, comment, approve docsEverything their role allows, incl. editing
Access controlHold the link (revocable)Role-based, per person
Best forClients, external stakeholders, sign-offCollaborators doing the work

If someone needs to edit documents, chat with the vibe editor, or see the pipeline, invite them to the project instead — see Teams and roles.

Good practices

  • One share per reviewer. Individual links mean individual revocation and a cleaner comment trail.
  • Revoke when the engagement ends. Shares don't need to live forever.
  • Approve deliberately. Only approved document versions are visible externally, so your approval action doubles as your "ready for outside eyes" control.

Forginate — build software with an AI factory.