Conceptual scenario
Keep the project tool within the project team.
A project dashboard needs to serve the people working on it. This example covers the owner, temporary collaborators and the access removed at handover.
Explore products ↗A worked planning example, not a customer case study or a released installation procedure.
The working situation
An internal project dashboard
Employees and one temporary collaborator use an internal review dashboard. Clients need the separately published deliverable. The dashboard itself stays private.
Private path
The project’s internal dashboard
- Approved laptop
- Project group
- Internal dashboard
- Audience
- Approved project collaborators
- Resource
- Team-owned internal dashboard
- Application
- Separate login and permissions
Temporary project membership is reviewed at handover.
One project resource. Deliberate membership.
- Source
- Project members’ approved devices
- Destination
- Internal review dashboard
- Audience
- Project access group
- End condition
- Project milestone or collaborator departure
The end condition prompts an owner’s review. It does not automatically expire project membership.
Project permission ledger
Resource plan: the internal review dashboard
Record the resource owner, approved sources and application permissions together. A connection grant and a dashboard role answer different questions.
Scroll sideways to compare every column. With a keyboard, focus the table region and use the arrow keys.
| Resource or audience | Owner | Private network boundary | Application boundary |
|---|---|---|---|
| Review server | Project operations | Private tool host; retains its workspace identity as group membership changes | Dashboard administrator owns accounts and roles |
| Employees’ team devices | Approved project members | Only approved working devices in the project access group | Each person signs in with their own permitted role |
| Contractor enrollment | Named contractor; grant reviewed by the project owner | Temporary project membership, reviewed and removed at handover | Separate contractor account, closed when the work ends |
| Client visitor | Client | No private dashboard grant | Only the separately selected public deliverable, with its own access decision |
Grant the job, not the entire organisation
Assess an access group around the project resource. The review server keeps its workspace identity while membership changes. Application roles determine what each connected person can do inside the dashboard.
A client preview needs a separate publication decision. Teams and agencies covers project ownership and handover; Networks explains the private connection model.
A contractor’s first day
Give access for the project. Close it at handover.
An engineer joins a short project. The owner confirms the supported laptop, approves the intended project group and tests the dashboard with the engineer’s own application account.
Before work
Confirm the resource owner, supported client and intended project group. Approve the contractor’s working device, not every device they own.
During work
Test the dashboard as the contractor. Check that a device outside the group cannot reach it, and that the application still requires its own login.
At handover
Remove temporary membership and verify the observed result. Revoke retired enrollments and close application accounts when the work ends.
If the result is different
Diagnose the boundary before changing it.
Identify which permission needs attention before expanding the project grant or publishing the dashboard.
A collaborator needs one project, not every tool.
Tie the grant to the intended project resource and review its membership. Keep application roles separate from network reachability.
The dashboard owner changes.
Transfer administration deliberately, review temporary memberships and retain a record of who owns removal. A change of application owner is not an automatic network-policy change.
A client asks for a preview.
Define a separate selected HTTP publication if appropriate. The internal dashboard and its administration should not inherit the client’s public entry.
Acceptance criteria
Three results worth recording.
At handover, check the private resource path and the dashboard account separately. A requested change alone does not establish the observed result.
Working session
Useful access
A current project member can reach the internal dashboard and sign in. Confirm that a device outside the group has no intended private grant.
Network handover
Membership boundary
Remove the collaborator’s temporary membership, revoke retired enrollments as appropriate and verify that the intended private grant is no longer effective.
Application handover
Application boundary
Retire old application accounts where the work has ended. Verify the dashboard’s account and session state independently of the network-membership change.
Record what is still unconfirmed.
If a device is offline, record that fresh local state is unavailable. Check policy delivery, the intended gateway state and observed reachability as applicable; do not infer immediate enforcement on an offline device from a requested withdrawal.
This is a worked planning example, not a customer case study or a released installation procedure.
Explore Networks →