> For the complete documentation index, see [llms.txt](https://docs.aquiladynamics.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aquiladynamics.com/aquila-store-user-manual/users-and-permissions/module-overview.md).
# Module overview
## Module overview
The users and permissions module is used to maintain user accounts and roles that define the scope of access to backend and POS functions. In practice, it is one of the most important administrative areas because it determines who can log in to the system, work on the sales workstation and what operations they can perform.
### Menu paths
* `Administration -> System -> Users`
* `Administration -> System -> Roles`
### Users
The `Users` screen allows authorised users to search, add, edit, lock and unlock user accounts. A user can be a person working in the backend and/or on POS, for example an administrator, service desk user, cashier, senior cashier or `Shop manager`. From this screen, an authorised person can check, among other things, the login, role and account status.
### Roles
The `Roles` screen allows users to create roles, edit their description and permissions, copy permissions from another role, delete roles and review role details. A role works as an access template that can be assigned to one or many users.
### When to use
Use this module when you need to:
* create an account for a new user,
* change data for an existing account,
* lock or unlock a user,
* check why a user cannot see a function or cannot log in,
* create a new role,
* change the permission scope of a role,
* copy permissions from an existing role,
* delete a role that is not used.
### Key dependencies
| Element | Meaning |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| User | Account of a person working in the backend and/or on POS. This may be an administrator, service desk user, cashier, senior cashier or `Shop manager`. |
| Role | Permission template assigned to a user. A role defines which functions are available in the backend or POS. |
| Location | User work context that affects data and operation visibility. A location does not grant a separate role for a given place of work. |
| Account status | Information whether the user is active and can log in to the system, or inactive and should not have account access. |
| Permission | A single right to a function or operation in the system. |
### What to watch out for
* Changing a role affects all users who have that role assigned.
* Locking a user limits the ability to work on the account, but keeps history and audit links.
* If a user cannot see a function, check the role, location and account status together.
* Do not grant broader permissions than required for the work of a given person or group.
### Related pages
* [User roles in the system](/aquila-store-user-manual/introduction/user-roles-in-the-system.md)
* [Backend access requirements](/aquila-store-user-manual/getting-started/backend-access-requirements.md)
* [Adding a user](/aquila-store-user-manual/users-and-permissions/adding-a-user.md)
* [Creating a role](/aquila-store-user-manual/users-and-permissions/creating-a-role.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://docs.aquiladynamics.com/aquila-store-user-manual/users-and-permissions/module-overview.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.
