> 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/adding-a-user.md).
# Adding a user
## Adding a user
**Menu path:** `Administration -> System -> Users`
Adding a user creates a new account in the Aquila Flex backend. The account can have assigned locations, one or more roles and additional attributes required by the client's processes. This function is used by administrators, service desk teams and selected operational roles, for example a `Shop manager`, if they have the appropriate permissions.
### When to use
Use this procedure when a new person should get access to the backend or when an operational account is required according to the organization's process.
### Steps
1. Open `Administration -> System -> Users`.
2. Click `ADD`.
3. Complete the basic user data.
4. If needed, complete advanced data.
5. On the `Locations` tab, assign the locations where the user can work.
6. On the `Roles` tab, assign roles that define the permission scope.
7. On the `Attributes` tab, add required attributes if they are used in the given implementation.
8. Click `SAVE`.
9. Check whether the user appears on the list.
### User data
In the basic data section, complete the login, password, login availability and information whether the system should force a password change. Forced password change applies to backend login. For POS login, the system does not force a password change. The advanced data section contains descriptive information, for example first name and surname. The scope of fields may differ depending on environment configuration.
### Locations tab
The `Locations` tab defines in which locations the user can work. Location affects the data context, for example documents, warehouses, reports and processes visible after login or after changing the work location. A user can have more than one location assigned. Assigning a location does not mean assigning a separate role for that location.
### Roles tab
The `Roles` tab defines the user's permissions. A user can have multiple roles, for example `Cashier` and `Senior Cashier`. Roles are assigned to the user account, not separately to each location. This means that on one account it is not possible to configure a situation where the same person is a manager in location A and a cashier in location B. If the organisation needs this kind of distinction, the handling method should be agreed during implementation or permission administration. Access to assigning roles may be limited by the permission hierarchy. This means that the user performing administration, for example a `Shop manager`, may see only the roles they are allowed to assign. If the expected role, for example an administrative role, is not on the list, the most common reason is missing permissions of the person performing the change.
### Attributes tab
The `Attributes` tab is used to store additional user information. Attributes are defined by the Aquila team according to the client's requirements and may differ between implementations. Example: in some countries, every cashier must have an assigned tax identifier, and that identifier should be printed on receipts. In that case, the identifier can be stored as a user attribute.
Example user attributes:
| Attribute | Example use |
| ----------------- | ------------------------------------------------------ |
| `POS user name` | User name used in the sales system. |
| `User tax number` | User tax identifier, if required by local regulations. |
| `User code` | Internal employee code. |
| `User PIN` | PIN used in operational processes. |
| `User email` | User e-mail address. |
| `Cashier number` | Cashier number used in reports or sales documents. |
### What to watch out for
* Before creating an account, make sure the correct roles exist.
* Roles are assigned to the whole user account, not to a single location.
* The list of roles visible when adding a user may depend on the permissions of the person performing the operation.
* Add attributes only when they result from implementation configuration or a business process.
* After saving the account, check whether the user has correct locations, roles and login availability.
### Related pages
* [Editing a user](/aquila-store-user-manual/users-and-permissions/editing-a-user.md)
* [Creating a role](/aquila-store-user-manual/users-and-permissions/creating-a-role.md)
* [Changing work location](/aquila-store-user-manual/getting-started/changing-work-location.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/adding-a-user.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.
