Employees and access administration
Employees (/users) is an administrative surface. Changes affect access to tasks, CRM, documents, and history.
List and search
The default list shows active users. Search by name, login, email, phone, or title with at least two characters; shorter terms may return no result. A link to a person can open the matching record. Pages contain up to 50 records. If search is temporarily unavailable, retry later and check the person's status in the card.
Use active/inactive, people/bots, department, and other available filters.
The header also reports separate active and disabled counts. Each row shows its
status, relative last-login time (or Never logged in), and department; when a
user belongs to several departments, the remaining memberships appear as +N.
The birthday badge is shown only on the person's birthday and follows the user's
personal birthday setting, not a company-wide policy.
A link to a person highlights the matching row and opens the user's card after the record is loaded; if it is outside the current result, widen the filters or search first.
Employee card and profile
Before editing, verify name, contacts, department, role, language, time zone, and activity. If someone is temporarily away, disabling activity usually preserves history better than deleting the account. Review linked tasks, documents, CRM records, and comments first. If the person owns active recurring-task templates, disabling can be rejected: open the recurring templates page, hand the templates to another owner or archive them, then retry.
Bulk actions
Bulk enable, disable, and remove actions require a checked selection. Bot removal is blocked: in a mixed selection only people are removed and bots remain. If some owners have active recurring templates, the bulk operation may apply partially; reload the list and verify. Keep a reason and exclude integration accounts, owners of active work, and administrators unless the change is intentional. After the change, verify several records, their tasks, and workspace access.
Password reset and MFA step-up
Password reset is sensitive and may require a staff MFA step-up. Never send temporary passwords, MFA codes, tokens, or recovery codes through chat or documentation. Ask the user to replace a temporary secret at first sign-in.
The row's More menu also lets an administrator reset that user's MFA. This is separate from a password reset: confirm the action and complete the staff MFA step-up with your own account. Recovery codes are not displayed and must not be copied into chat or documentation. After a reset, provide the user with an access path through a trusted channel and ask them to replace the temporary secret at first sign-in.
Roles and access
An admin role is not a substitute for department, project, or module policy. After changing a role, verify access in a safe test profile and check project membership, department membership, personal policies, and module restrictions. If the person sees too much or too little data, correct those memberships and policies before considering an admin role.
Safe examples
Use synthetic people and bots, neutral titles, and training contacts. Do not show real emails, phones, avatars, secrets, internal IDs, client data, or mixed-language labels. Keep examples for this list free of financial data.
Related pages