> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/guides/merchant-portal/manage-your-account/user-management.md).
# User Management
Use User Management to control who can access the Merchant Portal and what they can do there.
Authorized merchant administrators can manage user accounts in line with the role-based access control model configured for the service. The exact actions available to you depend on your assigned permissions.
### What User Management is for
User Management helps you assign Portal access according to your internal operating model.
Use it when you need to:
* create or deactivate Portal users
* assign or update user roles
* define which Portal functions a user can access
* review whether a user is active or inactive
This is useful when different team members need different levels of access, for example for agreement management, payment operations, reporting, or supervisory tasks. The service supports one or more predefined roles per user.
***
### Roles and access rights
Access in the Merchant Portal is role-based.
That means a user only sees and can use the functionality that has been explicitly assigned to their role. Roles determine access to Portal sections and operational capabilities, so a user with a limited role may only see part of the Portal.
Use roles to align Portal access with your internal security and segregation-of-duties policies. For example, the person who reviews payments does not necessarily need the same access as the person who manages account settings or user permissions.
***
### View registered users
The User Management interface gives you visibility into registered users and their role assignments.
This makes it easier to confirm who has access, what role they have, and whether access needs to be changed when responsibilities shift.
***
### Track user activity
User activity in the Portal is logged.
Role changes and operational actions are recorded in system logs to support traceability and auditability.
This is especially useful when you need an audit trail for security reviews, internal controls, or operational investigations.
***
### Best practices
Keep Portal access limited to the people who need it.
Review user access regularly, especially when team members change roles or leave the organisation. Remove or restrict access promptly when it is no longer needed.
Assign roles according to your internal policy, not just convenience. A well-designed access model reduces operational risk and makes it easier to separate duties across payment operations, reporting, and administration.
***
### When a user cannot see or do something
If a user cannot access a Portal area or action, it usually means one of the following:
* the action is not included in their role
* the user does not have sufficient permissions
* the functionality is not enabled for the merchant account
* access is restricted by your internal user-management policy
***
### Frequently Asked Questions
Why can a user see only part of the Merchant Portal?
Because access is controlled by roles and permissions. Users only see the Portal sections and actions that have been explicitly assigned to them.
---
# 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.ecommerce.seb.ee/guides/merchant-portal/manage-your-account/user-management.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.
