> For the complete documentation index, see [llms.txt](https://hub.equipme.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.equipme.io/classes/admin/roles-and-permissions.md). # Roles and permissions {% @arcade/embed url="" flowId="5bExjx1ekOR7xOxm7gex" %} A role is the baseline. It decides which parts of the portal a user sees at all, and you assign it from the role itself, in its Users tab, rather than from the person. That is worth getting used to, because it also tells you how to take it away again. You remove the user from the role, and the access goes with it. Permissions on the employee record are the fine adjustment on top. Anything the role already grants is locked there, so you can only set what the role leaves open. If a permission looks greyed out on a user, the answer is not on that screen, it is in the role. Three of them change more than they appear to. **Access to the entire marketplace** ignores whatever you enabled for self service and opens the full catalogue. Useful for IT staff, surprising if you forget it is on. **Record service instances and inventory** creates active services without approval, ordering or fulfilment. That is what you want when entering existing stock, and not what you want as a standing right. **Remove service instances and inventory** deletes an active service without deprovisioning it. High impact, keep it with the few people who understand the consequences. The rest, self service, showing prices and costs, and employee access for a location manager, are everyday settings you can hand out without much thought. ### The other way round: starting from the user {% @arcade/embed url="" flowId="HYDtvwJQB4EsvtZ0cBUy" %} The same result can be reached from the employee record, through its Permissions tab. Nothing behaves differently, it is the same rights seen from the other end. Which route to take depends on the question you are answering. Starting from the role is right when you are deciding how a group of people should work: every controller, every location manager, everyone in support. Starting from the user is right when one person needs an exception, or when someone asks why they cannot see something and you want the answer for them specifically. The second route is also the faster way to understand what a person actually has, because role based rights and individual ones sit on the same screen there, the locked ones coming from the role and the open ones you can still set. ### Read more {% content-ref url="/spaces/sefXXH6Iz8RCwoM5daoW/pages/eIFV3vEE6BA09zfmWi9S" %} [Roles and rights](https://app.gitbook.com/o/tyg0OyVUuxExVkZRRN7N/s/sefXXH6Iz8RCwoM5daoW/settings/portal-settings/roles-and-rights) {% endcontent-ref %} {% content-ref url="/spaces/sefXXH6Iz8RCwoM5daoW/pages/OLgnloGys8SrUfwNKSaw" %} [Role Overview](https://app.gitbook.com/o/tyg0OyVUuxExVkZRRN7N/s/sefXXH6Iz8RCwoM5daoW/settings/portal-settings/roles-and-rights/role-overview) {% endcontent-ref %} {% content-ref url="/spaces/sefXXH6Iz8RCwoM5daoW/pages/vO7Eu5A5PcHEO85mj0HJ" %} [Individual Permissions for Employees](https://app.gitbook.com/o/tyg0OyVUuxExVkZRRN7N/s/sefXXH6Iz8RCwoM5daoW/settings/portal-settings/roles-and-rights/individual-permissions-for-employees) {% endcontent-ref %} ### Next One more way to organise people: [Groups](/classes/admin/groups.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://hub.equipme.io/classes/admin/roles-and-permissions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.