Prepare a portal access matrix by listing each role, the records it needs and the actions it may take. Specify whether access applies to the person's own records, an assigned team or the whole business. “Admin” and “user” are rarely detailed enough to make a useful development brief.
This is a requirements-planning exercise. A completed matrix helps a developer and business owner discuss expected behaviour; it does not configure a system, prove it is secure or certify compliance.
Begin with tasks and record types
For a fictional service company, the portal contains customer requests, internal notes, assigned tasks and summary reports. Reception staff route new requests. Specialists update assigned work. A supervisor handles reassignment and checks progress.
Start with these real tasks rather than job titles alone. Two people with the same title may cover different teams. Someone acting as temporary cover may need limited access for a defined period instead of permanent access to everything.
OWASP's authorization guidance recommends least privilege, denial by default and permission checks on every request. For the business brief, that means explicitly stating required access and testing what should be refused, as well as what should work.
Build a role-resource-action matrix
The following fictional matrix is deliberately small. Expand each combined action into separate columns when permissions differ; viewing, editing, approving and exporting should not automatically travel together.
| Role | Resource and scope | Allowed action | Explicit limit |
|---|---|---|---|
| Reception | Incoming request summary | Create and assign to a queue | No bulk export or approval |
| Specialist | Assigned customer requests | View and update work progress | No unrelated-team records |
| Supervisor | Own team's requests | Review and reassign | No automatic company-wide access |
| Reporting reader | Approved summary report | View | No editing source records |
Include attachments and notes in the resource list. Permission to see a request summary does not necessarily imply permission to download every associated file. Identify bulk actions separately because their effect differs from handling one record.
Resolve the ambiguous cases
The employee belongs to two teams
Write down which records each team assignment permits and how overlapping roles combine. Do not leave it to a developer to guess whether broader or narrower access should win. The implementation approach needs review by the person responsible for security.
Someone provides temporary cover
Record the reason, approver, start and end of the temporary access. Specify who checks that it ends. A calendar note without an accountable reviewer is easy to miss when normal work becomes busy.
A manager changes responsibilities
Treat the move as a review of existing access, not only an addition of new permissions. The old team relationship may no longer justify access to its records. Update both the work assignment and the access requirement.
Use positive and negative acceptance tests
Write paired tests for each important permission. “A specialist can open an assigned request” is the positive case. “The same specialist cannot open another team's request” is the negative case.
Ask the implementation team to test enforcement through the underlying application requests, not just whether a button is hidden. Also include downloads, searches, exports and reassigned records in the test plan where they exist. A different route to the same record should not accidentally change the rule.
Use synthetic accounts and fictional data for review. Store expected outcomes alongside the matrix, and record who approved any change. When a feature introduces a new record type or action, update the requirements rather than assuming an existing role covers it.
Prepare a join, move and leave checklist
For a new starter, confirm their tasks, team, approved role and named approver. For a role change, review both new and old access. For departure, name the person responsible for removing access and transferring open work through the organisation's approved process.
Keep access review separate from task continuity. Removing access should not make customer requests ownerless; transferring requests should not leave the departing person with continuing permissions. Agree responsibilities for both outcomes.
The finished planning pack should contain the matrix, unresolved questions, example tests and lifecycle owners. Bring it to Tralionex's web portal planning service to discuss a defined scope and the security responsibilities the project will require.
Describe scope as carefully as the action
“Can view requests” leaves an important question unanswered: which requests? Write scope alongside every permission. It may be limited to assigned records, a named team or a particular customer relationship. If the scope depends on a relationship, explain what should happen when that relationship changes.
For example, the fictional specialist completes work on a request and it moves to another team. Should the specialist retain read access to the completed work? The answer depends on a documented business need. Put the question in the matrix for an accountable decision rather than leaving the implementation to infer continuing access from past involvement.
Review sensitive actions individually
Some actions have a wider effect than ordinary editing. Reassigning all of a colleague's work, exporting a set of records or changing another person's role should receive explicit requirements. Identify the actor, resource, allowed scope, review step and evidence to retain. A broad “supervisor” checkbox does not communicate these distinctions.
Keep business approval and system administration separate in the discussion. A person who maintains software accounts does not necessarily approve customer work. A person who approves a service change does not necessarily need to change permissions. If one individual currently performs both tasks, document the two responsibilities anyway so future staffing changes are easier to review.
Include automated actors in the inventory
A scheduled import or integration may read or change records without a staff member using a screen. List those workflows with their required actions and the person accountable for their operation. Do not assume a process should inherit the full access of whoever first configured it.
When discussing business automation, bring the relevant rows from the access matrix as requirements for the integration. The technical team should determine how access is implemented and reviewed. This planning exercise should never contain live credentials or instructions for sharing account passwords.
Make exception access temporary and reviewable
Sometimes a supervisor needs to help with an unusual case outside their normal team. Record how that need is requested, who approves it, what access is needed and when it should end. Keep the exception tied to the task rather than silently redefining the permanent role.
After the task, check whether the exception can be removed and whether any associated work needs transfer. If the same exception recurs, review whether the original role definition is wrong. Repeated one-off permissions can otherwise turn a clear matrix into an inaccurate picture of the system.
Prepare a useful review meeting
Bring the matrix, a few fictional records and a list of unresolved decisions. Ask each role owner to explain one allowed task and one task they should not perform. Then walk through a new starter, a team transfer and a departure. Capture disagreements as specific rows or conditions to resolve.
The output should be a dated, approved requirements version with a change owner. Give the developer the expected outcomes, including negative tests, and ask how the implementation will demonstrate them. Do not label the matrix “secure” merely because everyone has signed it. Its value is that the intended behaviour is explicit enough to implement, test and revisit.
Frequently asked questions
Can we use one administrator account for the team?
Ask your implementation team to design individual accountability and appropriate administrative access. A shared role name should not become an excuse for unclear responsibility.
Does a role determine all access?
Not necessarily. Team, record ownership and temporary assignments may also matter. Include those conditions explicitly in the brief.
Should exports have separate permission?
Yes, treat exporting as its own action to review. Seeing a record on screen does not automatically establish a business need for bulk downloads.
How often should the matrix be reviewed?
Review it when roles, workflows or features change, and agree a periodic owner-led review suited to the business. There is no universal interval in this worksheet.
Plan your next project with Tralionex
Bring a synthetic role-resource-action matrix, unresolved access questions and example acceptance tests. Discuss portal requirements with Tralionex so the proposal can identify implementation, review and ongoing security responsibilities clearly.
