Key takeaways
- Separate the shared operational view from internal commercial and legal work.
- Scope external access to named voyages, records and contribution rights.
- Review links, notifications, search and exports when testing permissions.
Identify the collaboration boundary
Map the participants involved in the voyage and the work each must perform. Owners, charterers, agents, surveyors and internal departments may need different information at different stages. A common workspace does not imply a common right to see every document in the voyage folder.
Classify records by purpose: operational reports, cargo documents, commercial terms, financial instructions, claims analysis and personal contact information. The categories should support actual decisions rather than become an elaborate filing exercise. Ask what each participant needs to contribute or verify.
NIST's least-privilege principle provides a useful starting point: access should be limited to assigned tasks. Translate that principle into voyage-specific permissions and have the technical team verify enforcement. NIST least-privilege definition.
Separate external contribution from internal review
An agent may need to upload a statement of facts and answer questions about port events. That does not require access to the charterer's negotiation notes or an owner's internal claim assessment. Provide a focused contribution area linked to the relevant voyage and document request.
Keep internal comments from leaking through shared records. If a document has both an external discussion thread and an internal assessment, make the distinction obvious to users. A single comment box with a small visibility toggle can be easy to misuse under operational pressure.
Allow external contributors to see enough status to complete their task, such as whether a requested document was received or needs clarification. Avoid exposing internal approval discussions simply to provide progress visibility. Design a concise external status that communicates the next action without unnecessary detail.
Build a role and record permission matrix
| Participant | Typical permitted records | Typical action scope |
|---|---|---|
| Port agent | Assigned call documents and requests | Upload reports and respond to factual queries |
| Vessel operations team | Relevant instructions and operational records | Report events and propose corrections |
| Chartering desk | Commercial and operational records within authority | Review terms and approve defined instructions |
| Finance team | Approved payment basis and supporting documents | Process authorised accounts and raise discrepancies |
| Claims reviewer | Relevant evidence and restricted analysis | Assess disputed items and prepare reviewed positions |
| External surveyor | Assigned inspection request and uploads | Supply reports within the agreed engagement |
| Workspace administrator | Access configuration and membership | Implement approved permissions without commercial authority |
Treat the matrix as a starting design example. Actual rights depend on the organisation and engagement. Where a user performs several roles, assign the required combination deliberately rather than granting unrestricted access for convenience.
Include lifecycle scope. An agent assigned to one port call should not automatically see all later voyages involving the same ship. A surveyor's completed engagement may call for different access than an active inspection task. Record when access should be reviewed or removed.
Design document sharing with clear ownership
Give each external share an owner who understands the intended audience and purpose. Record whether the share covers a single document, a folder or future additions to a folder. Users should not accidentally authorise access to documents that will be uploaded later under an inherited permission.
Prefer named access where the workflow supports it and apply the organisation's rules for guest identity and authentication. Security specialists should determine the technical controls. The business requirement is that the team can identify who is entitled to receive the information and revoke access when the purpose ends.
Check document previews and versions. A recipient who may see the final report should not necessarily see earlier internal drafts or comments. If the platform exposes version history to external users, account for that in the sharing decision rather than assuming only the visible file is shared.
Test indirect disclosure routes
Review search results, notification emails, calendar summaries and exported reports. Restricted document titles can themselves reveal sensitive activity, even when the file cannot be opened. Test what each role can discover as well as what it can download.
Check whether copied links retain the intended restrictions. A link pasted into a broad group should not expand access by itself if the design calls for named recipients. Also test whether a shared folder's permissions affect new files and whether inherited rights match the business owner's expectation.
Use realistic test records with representative sensitive fields rather than empty sample folders. The purpose is to see how the system behaves under the actual collaboration pattern. Record both successful permitted actions and blocked attempts so usability problems are not solved later by broadening access indiscriminately.
Handle access changes during the voyage
Voyages can involve substituted agents, changed terminals or additional specialists. Create a quick request process identifying the voyage, needed records, action and duration. The approver should see a concrete scope instead of a vague request for access to the whole workspace.
When a participant leaves, review links, guest membership, scheduled reports and integrations associated with their role. Removing a name from a visible project list may not address every access route. The technical team should confirm the actual revocation behaviour.
Keep a record of access approvals and changes. This helps explain why a participant could see a document at a particular time. It also supports periodic review of accumulated access after operational urgency has passed.
Common mistakes
Do not share an entire voyage folder when the participant needs only a document request and upload area. Another mistake is assuming hidden columns or inaccessible file contents prevent disclosure through titles and notifications.
Avoid permanent access for short engagements without a review point. Finally, do not solve every usability complaint by granting broader rights. Determine the missing task and provide the narrow capability that allows it to be completed.
Where Zeaclub fits
Zeaclub provides a multi-party shared workspace for owners, charterers, brokers and port agents.
Zeaclub offers digitalised procedures across the voyage workflow.
Explore Zeaclub
Educational information only; not legal, financial or trading advice. Contract wording and applicable rules control. Verify current requirements and obtain qualified advice before acting.
Frequently asked questions
Should all voyage participants use one shared folder?
They can use a common workspace with different views and contribution areas. A single unrestricted folder is rarely the only way to collaborate. Design the structure around who needs each record and preserve a clear boundary for internal commercial and legal work.
Can an agent edit the statement of facts in place?
Define the contribution and correction process explicitly. The agent may upload a revised document or propose a correction, while the system retains prior versions and relevant review status. Avoid giving broad editing rights to unrelated approved records merely to support that task.
What should happen when a new specialist joins?
Approve access for the specific engagement, records and actions needed. Identify an owner and a review or expiry condition. The new participant should receive enough context to work effectively without automatically inheriting every prior discussion in the voyage workspace.
How can permissions be tested practically?
Use representative accounts to try ordinary tasks, search, downloads, comments, notifications and revoked links. Include future uploads to shared folders and document version history. A useful test proves that legitimate collaboration works while restricted information remains outside the user's permitted scope.