Key takeaways
- Map real business participation before creating broad user groups.
- Distinguish permission to view information from authority to act on it.
- Test the receiving person's view, including linked files and exported content.
- Review access when a person's role or involvement changes.
- Keep a supported route for correcting permissions without sharing accounts.
Begin with participants and purposes
Identify the people involved in a representative fixture or voyage and describe why each needs access. A commercial colleague may need to prepare an offer, an operator may need approved voyage information and a port agent may need a defined call-related instruction. Those purposes do not automatically require identical views.
Use actual task descriptions instead of relying only on job titles. The same title can cover different responsibilities across offices, and a temporary participant may perform a narrow task for only part of a voyage. Access design should reflect that involvement.
Ask the information owner which material each task requires. A shared operational view may need a confirmed instruction without exposing every negotiation message that preceded it. The design discussion should identify the useful information boundary before administrators implement it.
This article proposes a business-facing access worksheet. Security specialists should determine the technical implementation and organisational controls appropriate to the actual environment.
Separate viewing, changing and communicating
A person who needs to read an approved handover may not need to edit its source. Someone who prepares a draft may still need another person's review before it is sent outside the desk. Treat those actions separately in the role description.
Distribution deserves an explicit question. A user may be able to see information internally but should not assume that every recipient is authorised to receive it. The business owner should define which output is intended for which audience and how the user recognises that boundary.
Administration is another distinct activity. Changing membership or permissions can affect many records even when the administrator does not participate in the underlying commercial work. Do not infer the administrator's business decision authority from their ability to configure the system.
Where the software combines actions within a broad role, make that limitation visible to the rollout owner. The team may need a different workflow, additional review or a narrower scope of use. Renaming a broad role does not change the capabilities it grants.
Build a task-specific permission worksheet
| Participant purpose | Information needed | Action to test | Boundary to review |
|---|---|---|---|
| Prepare a commercial draft | Relevant enquiry and permitted source material | Create and revise the draft | Whether distribution requires separate review |
| Accept an operational handover | Approved instructions and visible open items | Read, acknowledge and raise questions | Whether the receiver can alter the approved source |
| Coordinate a defined port call | Call-specific information approved for sharing | Update the assigned task or response | Visibility of unrelated fixtures and negotiations |
| Provide temporary desk cover | Work within the delegated scope | Perform the named cover tasks | Start, end and limits of the delegation |
| Maintain user access | Approved membership instructions | Add, change or remove the relevant permission | Separation from commercial approval authority |
The worksheet describes proposed review questions, not capabilities of any particular product. Confirm what the selected system actually supports and document any gaps before relying on the design.
Include both permitted and prohibited test actions. A successful test is not merely that the operator can open the required record. It also checks that the role cannot reach information or actions outside the agreed business scope.
Test the information path beyond the main screen
Review links, attachments, notifications and exports as part of the user experience. A carefully limited main view can be undermined by an attachment shared more broadly or a notification that contains unnecessary information.
Ask a representative recipient to follow the normal task path in the approved test environment. Can they identify the current instruction? Can they open its necessary supporting material? Does a link reveal unrelated information? These questions are more informative than a role label alone.
Use fictional or appropriately approved test records. Do not expose a real counterparty's confidential material merely to demonstrate that a restriction has failed. The test should reproduce the permission boundary without creating an avoidable disclosure.
Record the observed result and the configuration tested. If the team later changes group membership, sharing settings or document storage, it should assess whether the earlier test remains representative.
Treat access changes as part of rollout maintenance
NIST SP 800-128 places security within configuration management. This supports considering access-related configuration during rollout review, without prescribing the business roles below.
For the proposed workflow, define how the business owner requests a permission change and how its completion is confirmed. An operator who cannot perform an authorised task needs a usable support route; otherwise, the desk may develop informal ways around the intended design.
Include changed responsibilities, temporary cover, departed participants and completed business relationships in the review process. Access that was appropriate when a voyage began may no longer match a person's involvement later.
Avoid using another person's account as the fallback for a permission problem. The organisation's approved support process should preserve an identifiable user and a clear business reason for the access granted. Specialists can determine the appropriate emergency arrangements where ordinary support is unavailable.
Fictional case: the port-call guest sees too much history
A fictional chartering desk invites a port-call coordinator into a voyage workspace. The coordinator needs the approved arrival information and a place to answer a defined operational question. The invitation uses the same broad group that internal operators use.
During a controlled test with fictional material, the coordinator can also open draft commercial exchanges unrelated to the call. The main task screen looked appropriate, but a linked history panel exposes a wider record than the business owner intended.
The rollout team changes the proposed sharing design and repeats the task with the recipient's role. It verifies both that the coordinator can perform the call-related task and that the unrelated history is outside the shared view. If the selected system cannot support that boundary, the owner must decide on another approved method.
The example illustrates why the test should follow the complete task path. Checking only the invitation email or landing page would not have revealed the difference between the intended purpose and the effective access.
Make exceptions visible to the business owner
Sometimes a narrow business need can only be supported by a broader available role. Present that fact plainly. State the additional information or actions the role permits and ask the responsible owner to decide whether the proposed use remains acceptable.
Do not record such a decision as a technical success without its limitation. A temporary exception should identify the affected users, business purpose and review condition. It should not become the default merely because later teams copy the initial configuration.
Review whether users can understand their responsibilities. Even a sound permission design can leave uncertainty about which information may be sent externally. Operating instructions should explain the relevant business boundary in ordinary language and identify where questions go.
Common mistakes
Avoid assigning broad roles solely because they are convenient to administer. Other mistakes include testing only the main page, forgetting attachments, carrying temporary cover access forward and confusing system administration with commercial authority.
Do not assume that a person who can see a record is entitled to redistribute it. Define and test the intended information path.
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 share the same role?
Base the decision on their tasks and information needs. Similar involvement in a voyage does not establish that every participant needs the same records or actions.
Is an invitation enough evidence that access is correct?
No. Review the effective permissions and test the recipient's task path, including connected files, notifications and any supported exports.
Who should approve an access exception?
Use the organisation's authority arrangements. The relevant business and information owners need to understand the broader access and its purpose; administrators implement the accepted configuration.
When should access be reviewed again?
Use triggers appropriate to the work, such as changed responsibilities, temporary cover ending, a participant leaving or a material configuration change. Keep the review connected to actual involvement.