A permission model should connect each role to the records and actions it needs, including account boundaries, changes and approvals. Define access for agency staff, contractors and clients separately. Test ordinary and exception cases in the chosen system, and review permissions when responsibilities change. Role names alone do not prove that the intended restriction works.
- List each roleInclude staff, contractors, and clients.
- Define required workSpecify records and actions needed.
- Set boundariesSeparate viewing, editing, sharing, and administration.
- Test actual roleVerify normal and restricted actions.
Vendor role names are implementation options, not the permission model.
Start from responsibilities
List who needs to see or act on which information. An owner, delivery team member, contractor and client may need different views and actions. Define those needs before choosing a vendor role name.
- View recordsAccess needed information.
- Edit workChange assigned delivery content.
- Share or exportCheck information leaving boundaries.
- Approve or administerLimit commercial changes and access grants.
Viewing a project should not automatically grant authority to change terms or access.
Separate viewing, editing, sharing, exporting, approving and administering where they matter. The ability to view a project should not automatically imply authority to change its commercial terms or grant another person access.
Prepare a role matrix
| Role | Required information | Actions to review carefully |
|---|---|---|
| Agency owner | Relevant business and operational records | Broad administration and exports |
| Project owner | Assigned delivery and client context | Reassignment and client-facing changes |
| Delivery contributor | Work and assets needed for the task | Access to unrelated account records |
| Contractor | Defined engagement inputs | Shared folders and lasting access |
| Client contact | Agreed deliverables and decisions | Other clients and internal notes |
| Workflow identity | Inputs needed for its bounded action | Excessive record or account scope |
This is a design checklist, not a claim about permissions implemented in ScaleAxis OS or any other platform. Confirm the chosen system’s actual controls and limitations.
Define client boundaries explicitly
Identify which client and project records a client user should access. Include internal notes, financial information and unrelated engagement data in the review. A portal page showing the right project does not by itself prove that other records are inaccessible.
- Intended projectConfirm approved client records.
- Internal notesCheck visibility deliberately.
- Other engagementsVerify unrelated data remains restricted.
- Evidence and testRequest evidence and test appropriate cases.
A portal page showing the right project does not prove other records are inaccessible.
Ask the vendor or implementation owner for evidence of the relevant restrictions and test appropriate cases. The client security questions guide provides broader due diligence questions. Do not infer a security certification or a working control from a feature label.
Test actions as the intended role
Review the experience of the actual role rather than only the administrator. Check the required task and actions that should be restricted, using authorized test records and an appropriate test method.
For an illustrative client reviewer role, the person may need to view a deliverable and record a decision. Check whether they can also see internal comments or access another account’s material. If the system cannot enforce the intended boundary, choose a different sharing process or reconsider the use case.
Control permission changes
Name who can grant, expand or remove access. Record the reason for a change and whether it is temporary. A person covering an absent colleague may need specific access, but that exception should not quietly become a permanent role.
- Change ownerName who grants or removes access.
- Change reasonRecord why access changes.
- Temporary exceptionMark temporary coverage clearly.
- Integration identityReview permissions after configurator leaves.
A temporary exception should not quietly become a permanent role.
Review integrations and workflow identities too. Their permissions can continue after the person who configured them leaves. The access offboarding guide helps reconcile those dependencies.
Keep the model current
Review access when staff, contractors, projects or client relationships change. Use an agreed periodic check for paths that may otherwise be missed. The appropriate rhythm depends on your work and systems; this guide does not establish a compliance requirement.
Record limitations alongside the role matrix. If a permission bundles more capability than required, show that fact and how the agency will handle it. A clear limitation supports a better operating decision than a matrix that suggests controls nobody has tested.
Questions and answers
Can we use vendor role names as the permission model?
Use them as implementation options after defining the work and restrictions. Names such as editor or manager can represent different capabilities in different systems. Verify what the role can actually see and do for your intended case.
Does a client portal guarantee separation between clients?
The portal label does not establish that. Ask for current evidence about account boundaries and test relevant access cases through an authorized process. Treat vendor descriptions as claims to verify rather than proof that your intended configuration is correct.
When should role permissions be reviewed?
Review them when responsibilities, people, engagements or connected workflows change, and on an agreed maintenance rhythm. Name a permission owner, record exceptions and verify removal or transfer during offboarding.