> For the complete documentation index, see [llms.txt](https://docs.ninox.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ninox.com/ninox-scripting/automate-your-workflows/work-with-functions/users-and-roles.md). # Users and roles User and role functions help you personalize workflows and protect sensitive actions. You can read the current user’s details, check roles, detect admin status, and adapt behavior to the current app, language, and workspace context. In this chapter, you will learn how to: * Read details about the current user. * Check roles before sensitive actions. * Detect admin users and admin mode. * Adapt scripts to the current app and language. * Inspect workspace, database, and table context.
Function (A-Z)Task
clientLang()Return the current client language
isAdminMode()Check whether the UI is in admin mode
tableId()Return the internal ID of a table
user()Return the current user
userEmail()Return the current user’s email
userFirstName()Return the current user’s first name
userFullName()Return the current user’s full name
userHasRole()Check whether the current user has a role
userId()Return the current user’s ID
userIsAdmin()Check whether the current user is an admin
userLastName()Return the current user’s last name
userName()Return the current user name
userRole()Return the current user’s primary role
userRoles()Return the current user’s roles
users()Return all workspace collaborators
## Read the current user’s details Use these functions when you want to personalize messages, store user references, or show who performed an action. ### Get the current user with `user()` Use `user()` when you need the current user or want to look up a specific workspace user. Use it when you want to: * Reference the current user directly. * Pass the user into another function or comparison. * Build user-aware workflow logic. * Compare the current user with a user field. `user()`\ `user(string)` * `string`: the user name you want to look up `user()` returns a user value. If the given name does not match a workspace member, `user(string)` returns no value. #### Let’s take a look at some examples: ```ninox user() ``` Returns the current user. ```ninox user("Jane Doe") ``` Returns that user if the person is a workspace member. Otherwise it returns no value. ```ninox user() = user("Max Mustermann") or user() = user("Maria Garcia") ``` Returns `true` if the current user matches either user. ```ninox user() = assigned_to ``` Returns `true` when the current user matches the value in the `assigned_to` user field. ### Read user identity fields Use these functions when you need a specific part of the current user’s identity. Use them when you want to: * Show a personalized greeting. * Save who triggered an action. * Use the user’s email in sharing or messaging workflows. `userId()` returns the current user’s internal ID.\ `userId(user)` returns the internal ID of the user stored in the `user` field.\ `userName()` returns the current user’s display name.\ `userName(user_name)` returns the display name of the user stored in the `user_name` field.\ `userEmail()` returns the current user’s email.\ `userEmail(user)` returns the email address of the user stored in the `User` field.\ `userFirstName()` returns the current user’s first name.\ `userFirstName(user)` returns the user's first name stored in the `user` field.\ `userLastName()`returns the current user's last name.\ `userLastName(user)` returns the user's last name stored in the `user` field.\ `userFullName()` returns the current user's full name.\ `userFullName(user)` returns the user's full name stored in the `user` field. #### Let’s take a look at an example: ```ninox alert("Welcome " + userFullName() + "!") ``` Shows a short greeting for the current user. Tips: * Use `userFullName()` for readable labels and messages. * `userName(user)` returns the display name stored in the user profile. * Use `userEmail()` when a workflow shares files or sends notifications. * `userEmail(user)` returns the workspace email address for the given user. * `userFirstName(user)` uses the first name stored in that user’s profile. * `userLastName(user)` uses the last name stored in that user’s profile. * `userFullName(user)` combines the first name and last name from the user profile. * `userId(user)` returns the internal alphanumeric ID of the given user. * Store `userId()` when you need a stable internal reference. ### Return all collaborators with `users()` Use `users()` when you need all collaborators from the current workspace as an array. Use it when you want to: * Loop through all workspace users. * Build a list of collaborator names. * Reuse all users in filtering or assignment logic. `users()` `users()` returns an array of user values. #### Let’s take a look at an example: ```ninox users() ``` Returns all collaborators from the current workspace. Tips: * Use `users()` when you need all collaborators, not only the current user. * Loop through `users()` when you need to check or reuse each collaborator individually. ## Check roles and admin access Use these functions when you want to control access or show different behavior for different users. ### Check roles Use `userRole()` and `userRoles()` to inspect the current user’s role setup. Use `userHasRole()` when you only need a direct yes-or-no check. Use them when you want to: * Restrict access to admin or manager actions. * Show role-specific buttons or pages. * Guard exports, deletes, or approval workflows. `userRole()`\ `userRole(user)`\ `userRoles()`\ `userRoles(user)`\ `userHasRole(string)`\ `userHasRole(user, string)` * `string`: the role name you want to check with `userHasRole()` * `user`: the user you want to check #### Let’s take a look at some examples: ```ninox userRole() ``` Returns the current user’s first role, such as `admin` or `editor`. ```ninox userRole(user) ``` Returns the first role of the user stored in the `user` field. ```ninox userRoles() ``` Returns all roles of the current user. ```ninox userRoles(user) ``` Returns all roles of the user stored in the `user` field. ```ninox if userHasRole("Manager") then "OK" else "No access" end ``` Checks whether the current user has the role `Manager`. ```ninox userHasRole(created_by, "admin") ``` Checks whether the user stored in a field "Created\_by" has the role `admin`. Tips: * `userRole()` returns only the first role of a user. * `userRoles()` returns a list of role names. * Use `userRoles()` when you need to inspect all assigned roles. * Use `userHasRole()` for permission checks in buttons and scripts. * Check access early so restricted actions stop immediately. ### Check admin status Use `userIsAdmin()` to check whether the current user has admin rights. Use `isAdminMode()` to check whether the interface currently runs in admin mode. Use them when you want to: * Guard sensitive maintenance actions. * Show admin-only pages or controls. * Adapt the UI to the current admin context. `userIsAdmin()` returns a boolean.\ `isAdminMode()` returns a boolean. #### Let’s take a look at some examples: ```ninox userIsAdmin() ``` Returns `true` if the current user has admin rights. ```ninox isAdminMode() ``` Returns `true` if builder mode is active. ```ninox if not userIsAdmin() then alert("Admins only.") else openPage("Admin") end ``` Shows a short warning for non-admins and opens the admin page for admins. {% hint style="info" %} Combine role checks with `dialog()` before sensitive actions such as delete, export, or bulk updates. {% endhint %} ## Adapt scripts to app, language, and workspace context Use these functions when your script should behave differently depending on the language or current environment. ### Detect the current language with `clientLang()` Use `clientLang()` to read the current language set in the browser or app. Use it when you want to: * Localize messages. * Switch labels by language. * Show different text to different users. `clientLang()` `clientLang()` returns a string such as `en`, `de`, or `es`. #### Let’s take a look at some examples: ```ninox if clientLang() = "es" then "Hola" else "Hello" end ``` Returns `Hola` when the client language is set to Spanish. Tips: * `clientLang()` reflects the language set in the current browser or app. * Users can use different languages on different clients. * Keep localized messages short. * Test language-specific scripts with real client language settings. ### Inspect workspace and structure with `tableId()` Use this function when you need internal identifiers for logging, diagnostics, integrations, or environment-aware logic. Use them when you want to: * Log where a script runs. * Build API requests. \ `tableId(record)`\ `tableId(string)` * `record`: a record from the table * `string`: the table name #### Let’s take a look at some examples: ```ninox tableId(this) ``` Returns the internal ID of the current table. ```ninox tableId("Invoices") ``` Returns the internal ID of the `Invoices` table, for example `B`. Tips: * Use `tableId()` as an identifier in API calls when you need the internal table ID. * Keep them out of labels or messages unless a technical workflow needs them. ## Common user and role recipes These short patterns cover common ways to personalize and protect workflows in Ninox. ### Restrict access to admins ```ninox if not userIsAdmin() then alert("Admins only.") else openPage("Admin") end ``` Blocks non-admin users and routes admins to the admin area. ### Restrict access by role ```ninox if userHasRole("Manager") then "OK" else "No access" end ``` Checks whether the current user has the role `Manager`. ### Localize a short message ```ninox if clientLang() = "de" then "Willkommen" else "Welcome" end ``` Returns a short greeting based on the current client language. Use this chapter together with navigation and file functions: * Use role checks before exports, deletes, or page changes. * Use user details to personalize alerts, logs, and shared content. * Use app and language checks when behavior depends on the client environment. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.ninox.com/ninox-scripting/automate-your-workflows/work-with-functions/users-and-roles.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.