Guest and External Reviewers
External reviewers — clients, contractors, consultants, or specialist advisors — can participate in document reviews and transmittal acknowledgements without being granted full project workspace access. Kazinex uses a token-based guest share model: a unique, time-limited URL gives the guest scoped access to exactly the record they need, and nothing else. No login or account creation is required.
Token-based access model
Each guest share generates a unique, cryptographically signed URL. The URL encodes the scope (which record), the permitted actions (review, acknowledge, etc.), and the expiry conditions. Anyone with the URL can access the share — access is not tied to an identity until the guest optionally provides their name or email in the portal.
| Characteristic | Detail |
|---|---|
| No account required | The guest does not need a Kazinex account or project membership. |
| Scoped access | The URL provides access only to the shared document or transmittal. |
| Time-limited | The share expires at a configured date or after a set number of accesses. |
| Revocable | The creating user or project admin can invalidate the URL at any time. |
Share scope options
| Scope | What the guest sees | Use for |
|---|---|---|
| Document-level | The specific document and its metadata; ability to add review comments or markup. | External reviewer participation in a workflow step. |
| Transmittal-level | The transmittal cover sheet and document list; acknowledgement button. | Formal transmittal acknowledgement without workspace access. |
Creating a guest share
- Open the document or transmittal record.
- Select Share externally (or Guest share in the transmittal actions menu).
- Set the Expiry type:
- Date-based — the link becomes invalid after a selected date.
- Access-count-based — the link expires after being opened N times.
- Optionally enable Require guest name and/or Require guest email — the guest must provide these before accessing the content.
- Add optional Instructions text shown to the guest in the portal.
- Select Create share. A unique URL is generated.
- Copy the URL or use the Send by email option to dispatch it directly.
Guest Portal interface
When the guest opens the share URL, they see a stripped-down portal showing only the shared item:
| Element | Description |
|---|---|
| Record summary | Document title, number, revision, or transmittal number and cover sheet. |
| Instructions | Any instructions the share creator added. |
| Attachments | The document file available to view or download (if enabled). |
| Response tools | For document shares: comment box, markup tools, and review outcome selection. For transmittal shares: acknowledgement button. |
| Submission status | Confirmation message once the guest submits a response. |
Guests do not see the project register, team members, other documents, or any other workspace content.
Share management
| Action | Where |
|---|---|
| View active shares | Open the document or transmittal → Shares tab. Lists all active and expired shares with creation date, expiry, and access count. |
| Revoke a share | Open the share in the Shares tab and select Revoke. The URL immediately becomes invalid for new accesses. |
| View access log | The Shares tab shows how many times the link was opened, last access timestamp, and guest-provided name/email (if required). |
Workflow integration
Guest shares can be linked to a specific workflow step. When a share is created for a step participant:
- The guest's review response is recorded against that step.
- The step is not marked complete until the guest response is received (consistent with other step completion rules).
- The project team can monitor the step status from the workflow timeline without having visibility into the guest's workspace.
Security considerations
- Share URLs should be treated as credentials. Do not post them in public forums or shared communication channels unless the target recipients are controlled.
- Use date-based or access-count expiry to minimise the window of exposure.
- Revoke shares immediately if the recipient changes or the document is superseded.
- Enabling Require guest email creates an attribution record, which is useful for audit trail completeness.
Related
- Workflow Templates — external participants as workflow step assignees
- Transmittals Guide — guest acknowledgement of formal transmittals
- Audit Trail — guest portal access events are logged
- Access Control Groups — managing full project team access