Roles and permissions in a customer portal determine which information each user may see and which actions they may perform. A good model starts with responsibilities, not individual names. First define roles such as organisation administrator, project team member and customer, associate limited permissions with them and then assign users to the correct projects or case records.<\/p>\n
This keeps access manageable as teams, customers and projects change. Without a role model, broad administrator accounts, manual exceptions and uncertainty about who was allowed to publish or change something soon emerge.<\/p>\n
First inventory what the portal contains. Consider project updates, personal data, documents, choices, messages, reviews and user administration. Describe the actions available for each component:<\/p>\n
\u2018Access to documents\u2019 is therefore too broad. A staff member allowed to upload a file does not automatically need to decide which customers it is published to. Separating actions makes clear where extra checks are needed.<\/p>\n
The role describes what someone can do; the scope describes where they may do it. A project team member might publish updates, but only within assigned projects. A customer may view documents, but only within their own case record.<\/p>\n
This combination avoids creating a unique role for every staff member. The same role can be used across projects, while the project or case assignment limits its scope.<\/p>\n
The simplified matrix below is a starting point. Adapt it to your processes and risks.<\/p>\n