Users — Registration and Access Identifiers

Managing access accounts should not require a ticket or a command line. On the Sistema›Usuários screen (?view=usuarios in the shell) you register, search and adjust each team member's profile and permissions in seconds, with validation before submission and clear messages whenever something does not add up. This page explains an account's three identifiers, how a person signs in, and what happens to accounts created before the login field existed.

Identifiers: name, e-mail and login

Each user has up to three identifiers, with distinct purposes:

Login rules

• 3 to 64 characters: letters, digits, dot, hyphen or underscore, starting with a letter or a digit (pattern ^[a-z0-9][a-z0-9._-]{2,63}$).
• Normalized to lowercase; uniqueness is case-insensitive and checked at registration time.
• Never contains @ — that is how the platform distinguishes e-mail from login in the same Usuário field of the "Entrar no DATTA" dialog.
• Required for local registration: without it, registration is refused with the message "Login é obrigatório". Users created through an external provider (Microsoft/Google) receive a login through the automatic fill described below, but keep authenticating through the provider.

Existing accounts get a login automatically

Accounts created before the field existed receive a platform-generated login with no action on your part, on the first startup after the update: a handle derived from the display name — lowercase, accents stripped, separators become dots ("José Rodrigo" → jose.rodrigo) — falling back to the e-mail prefix, with a numeric suffix on collision (jose.rodrigo2).

The routine is idempotent: it only fills accounts that have no login, and accounts that already have one are left untouched. It also establishes, in one go, the login uniqueness constraint. The assigned login appears in the user listing and in the platform's operation log, in the form Backfill de login: <email> → <login>.

Signing in with e-mail or login

In the "Entrar no DATTA" dialog, the Usuário field accepts e-mail or login — whichever the person prefers. The platform resolves the login to the account through a two-tier cache (process memory plus the distributed cache, with dedicated indexes by e-mail and by login — datta:auth:email:{email} and datta:auth:login:{login} — and a 15-minute lifetime), falling back to the datta system database (:Usuario node, login property) when the cache does not hold the account.

On a wrong credential the message is always the same ("Credenciais inválidas"), whether the identifier or the password was wrong — a deliberate protection against account enumeration.

Worked example — registering a new analyst

1. In Sistema›Usuários, open the Novo Usuário dialog.
2. Fill in the full name (e.g. "Juliana Silva"), the login (e.g. jsilva), the e-mail (e.g. juliana.silva@empresa.com) and the initial password, at least 8 characters long, and choose the base profile (role) — the account is created with it.
3. Confirm the registration. The screen itself validates before sending: a blank field, a malformed e-mail, a password outside the accepted length or an off-pattern login is flagged right away, with no round trip to the server. The server then repeats every validation — format and uniqueness — and, if something does not pass, returns the error field by field, shown in the screen's notice. An e-mail or login that already belongs to another account is refused with "Já existe um usuário com este e-mail ou login".
4. If you ticked permissions beyond the profile's, they are saved next as the account's direct permissions. Each profile is detailed in roles and permissions.

Who can register users. Creating a user requires the USERS_MANAGE_ROLES permission (the ADMIN profile already has it): the account is born with a role, and someone who only edits registration data (USERS_EDIT) cannot grant a profile. Without the permission the screen says so and nothing is created. Each registration emits the AUTHZ.USER_CREATED audit event, with who registered, the e-mail and the initial role — never the password. Registering through the screen does not depend on the login screen's anonymous self-registration, which is off by default in on-premises installations.

1. Optionally, fill in the Prompt padrão do usuário: instructions the AI follows in every conversation of that person (tone, language, format, focus). It is saved right after registration; if that step fails, the account is still created and the screen tells you to adjust it in the detail view.
2. Decide the Funcionalidades em preview switch: on, the person sees the features still under development (DATTA BI, DATTA Captain and the others marked (Preview)); off, they leave the menu, the Features screen and System, and the Captain button disappears from the top bar. The switch starts on for the Administrator profile and off for the others, and follows the chosen profile until you touch it. It is a display preference, not a permission: anyone with access who opens the screen by its address still gets in. Accounts created before the switch keep seeing preview features.

Changing the switch on an existing account. In the user detail, right below the access profile, the same Funcionalidades em preview switch shows the account's current state; change it and click Salvar Alterações. It requires USERS_EDIT, like the other registration data. The change takes effect at the person's next login, or when their session renews (within 8 hours): the access token is what carries the choice to the screen.

User's default prompt

Every registered user may have a default prompt — the text the platform appends to the system prompt in every interaction of that person with the AI, in chat and in the copilot. It is registration data, which is why it lives here:

• In the user detail view, the Prompt padrão do usuário section shows the current text, the counter (8,000-character limit) and the Salvar prompt button. Leaving it blank and saving removes the prompt.
• Permission: reading requires USERS_VIEW; writing requires USERS_EDIT (editing registration data). It grants no access, so it does not go through USERS_MANAGE_ROLES.
• Limit: above 8,000 characters the write is refused with the count in the message — never silently truncated.
• Audit: every write emits USER.PROMPT_UPDATED with actor, target, origin, length and whether it erased, without the text.

What the AI does with the text, the markers in the final prompt and the self-serve API path are in the user's default prompt guide.

Day-to-day management

• Search: the listing search filters by name, e-mail, login or job title.
• Check: the user detail shows the login next to the e-mail, when present.
• The login is final: it cannot be edited through the interface after registration.

Profiles and permissions in depth — including creating your own profiles — are covered in the roles and permissions guide. User registration, authentication and the administrative account operations (read, update, delete, setting the profile and granting direct permissions) are also available through the API for automated provisioning: see the API reference.