Start Free Trial

Platform Documentation

Administration

Administration controls who can use your account and what they can do. An Account is your organization, and Applications are workspaces inside it. Users can have an account-wide role, a role in one or more applications, or both. Account and application permissions are separate.

Scope diagram. A single Account sits at the top. Below it are several Applications, each a separate workspace. A user can be granted an account-level role that applies across the whole organization, or an application-level role that only grants access inside one application, or both. Account permissions use an account: prefix and application permissions use an app: prefix.
Two scopes of access: account-wide roles, and per-application roles. A user can have either or both.
There are two administration areas. The main sidebar’s Administrator item opens account-wide settings. Inside an application, Application Administrator controls that application’s members and roles.

The Account Model

Applications divide an account into separate workspaces, and each application shows only the endpoints, devices, dashboards, alerts, and members assigned to it. Sub-accounts exist in the permission model but not in the self-service UI.

Accounts and sub-accounts

Some plans and permission lists mention sub-accounts. They cannot currently be created or managed through the self-service UI.

Applications

An Application is a scoped workspace. Endpoints, devices, dashboards, alerts, and members all belong to an application. A user added to an application gets a per-application role that decides what they can do in that workspace only, independent of any account-wide role.

  • Default application. One application in the account is flagged as the default. Screens that are not opened from inside a specific application (for example Alert History) fall back to scoping their data to this default application.
  • Access to every application. The account permission account:manage:applications grants full access to every application, regardless of the user’s application roles. Grant it carefully.

Account Settings

Open Administrator from the main sidebar to reach Account Settings. The page shows your own role at the top (“My role”), then up to four tabs. You only see a tab if your role grants the matching view permission.

Account Settings page. A line at the top reads My role followed by the current user's role name. Below it are vertical tabs: General, User Management, Roles Management, and Billing. Each tab only appears if the user holds the relevant view permission.
Account Settings. The tabs are permission-gated, and your current role is shown above them.
Tab What it does Permission to see it
General View and edit the account’s name. account:read:settings or account:update:settings
User Management Invite, edit, and delete users in the organization. account:read:users
Roles Management View roles; create, edit, duplicate, or delete custom roles. account:read:roles or account:update:roles
Billing View the current plan, switch plans, and manage payment. account:read:billing

If your role grants none of these, the page shows an Access Denied message instead of the tabs.

General: the account name

The General tab holds account-wide settings. Today it has one: the Account name. Edit the field and click Save changes. Its helper text notes the name “appears in the account selector and headers”, so renaming the account updates it everywhere it is shown. The field is read-only unless your role grants account:update:settings.

Account Settings General tab with an Account name text field, helper text reading This name appears in the account selector and headers, and a Save changes button. The field is disabled for users without the edit-settings permission.
The General tab. Rename the account; the new name shows in the account selector and headers.

Users

User Management lists everyone in your organization. Search by name or email, invite users, and manage their details and account roles from the table. The Account (Role) column shows each organization a user belongs to and their role there.

User Management table. Columns are Email (with an avatar), First Name, Last Name, Status, and a combined Account (Role) column. A search box sits above the table with a Clear button, and each non-Owner row has an actions menu offering Edit and Delete.
User Management. Search by name or email, and use the row actions to edit or delete.

How sign-in works

Sign-in starts with a magic link. The login screen emails a link to the address you enter. Use password instead switches that screen to password entry. New users verify their email address during signup, so every user you invite needs a working email address.

Staying signed in

  • A short connection failure does not immediately end the session. NEQTO.ai retries the token refresh and keeps the local session if the platform cannot be reached.
  • Each browser or device keeps its own session. Signing in or out on one device does not sign the user in or out on another. A browser refresh also does not end the session.

Inviting a user

Invite User dialog. An Email field at the top. If the email is already registered, a hint says the email is already registered and to assign organizations and roles below. If it is new, First Name, Last Name, and Phone fields appear. Below that, a row pairing an Organization picker with an optional Role select.
Enter an email first. New users also need name details; existing users do not.
  • 1
    Enter the email. If the address already belongs to a platform user, you only assign organizations and roles. If it is new, you also fill in First Name, Last Name, and an optional Phone (E.164 format, for example +1234567890).
  • 2
    Pick an organization (account). The Role next to it is optional. Leaving it blank invites the person as a member of the account with no account-wide role, which is the right choice when they should only get access through a specific application.
  • 3
    Send the invite. The user receives an email and, once verified, can sign in. App-scoped roles can be added later from the Edit User page or from an application’s own user screen.
The Owner role is never offered here. The organization role picker deliberately hides the system Owner role, so you cannot invite or reassign someone as Owner. See Roles below.

Row actions, status, and delete

Each non-Owner row has an actions menu (the Owner’s own row shows no menu). The menu offers two items:

  • Edit (needs account:update:users) opens the Edit User page, where you change the person’s details and their per-organization roles.
  • Delete (needs account:delete:users, and is hidden on your own row) removes the user after a confirmation that warns it cannot be undone and that the user will lose access to the system.

The Status column shows each user as Active or Suspended and can be filtered. The current row menu has no action for changing that status.

Roles and Permissions (RBAC)

Access is granted through roles, and every role is a bundle of permission slugs. Permissions come in two scopes that never mix: account-scope (the whole organization) and application-scope (one workspace).

Account roles and Application roles

Roles Management splits its list into two sub-tabs: Account roles (the account: scope) and Application roles (the app: scope). The two system roles always live under Account roles. The application roles (Admin, Operator, Viewer) you assign to per-app members are custom app:-scope roles that live under the Application roles tab and are shared across the account.

System roles vs custom roles

Each account ships with two locked system roles, plus any number of Custom roles you build. The Roles Management table tags each role’s Type as Owner, Admin, or Custom, and shows a lock icon on the system ones.

Roles Management table with Account roles and Application roles sub-tabs. Columns: Role name with a small lock icon next to system roles, Users count, Type showing an Owner badge, an Admin badge, or the word Custom, and an Actions menu. The Owner row has Edit, Duplicate, and Delete all disabled. The Admin row has Edit enabled only for the Owner, Duplicate allowed, and Delete disabled. Custom rows allow Edit, Duplicate, and Delete.
Roles Management. Owner and Admin are system roles; everything else is Custom.
Role What it is Editable?
Owner Full permissions. Each account has one Owner, who automatically passes every permission check. No. Cannot be edited, duplicated, deleted, or reassigned through the UI.
Admin Granted the full permission catalog at account creation. Editable only by the Owner. Cannot be deleted.
Custom Any role you create, with exactly the permissions you toggle on. Yes (with the right roles permission). Create, edit, duplicate, delete.

The two permission scopes

Permission slugs are formatted scope:action:resource, for example account:create:users or app:read:devices. The scope prefix decides which slug set is checked: account-scope slugs come from your account-level role, application-scope slugs come from your role in the application you are currently viewing.

Scope Covers these resources Example actions
Account (account:) Users, Roles, Billing, Settings, Applications, plus account-side Devices, Tags, Device Endpoints, Integrations, and Attributes. Most resources support read, create, update, and delete. Billing and Attributes support read and update only.
Application (app:) Dashboards, Widgets, Alerts, Chatbot, the Simulator, plus app-side Users, Devices, Tags, Device Endpoints, Integrations, and Attributes. Most resources support read, create, update, and delete. Chatbot uses one manage permission, Simulator uses read and execute, and Attributes use read and update.
Same word, two permissions. “Devices” exists in both scopes as account:read:devices and app:read:devices. Holding one does not grant the other. A user may see Devices from the main sidebar but not inside an application, or the reverse.

Editing a role’s permissions

Open a Custom role (or Admin, if you are the Owner) to get the permission editor. Each permission is a plain-language toggle, such as Invite users to this account or View devices in this application. Toggles are grouped by feature. A Select all switch at the top grants every permission in that scope.

Create Role permission editor scrolled to the Integrations group. Permissions are grouped under feature headings (Devices, then Integrations, then Roles). Under Integrations, View integrations has an on/off toggle, while Create integrations, Edit integrations, and Delete integrations are dimmed with a Requires: View integrations note beneath each label, showing that the create, edit, and delete actions stay locked until View integrations is granted.
The permission editor. Permissions read as plain actions, grouped by feature; some toggles stay locked until their prerequisites are granted.
Some permissions require others. Inviting, editing, or deleting account users requires permission to view both users and roles. Creating a device requires permission to view devices and to view, create, and edit Device Endpoints. Changing an integration requires permission to view integrations, and changing billing requires permission to view billing. A disabled toggle shows what it requires. Turning off a prerequisite also turns off the permissions that depend on it, and the editor will not save an invalid combination.

Who can manage roles

  • Create / duplicate a role needs account:create:roles.
  • Edit a custom role needs account:update:roles. The Admin role can only be edited by the Owner; the Owner role cannot be edited at all.
  • Delete a custom role needs account:delete:roles. System roles (Owner, Admin) can never be deleted.

Application Roles and Members

Inside an application, the Administrator area has its own user screen. This controls who belongs to that one workspace and what they can do there, separately from their account-wide role.

Application Administrator, Application users screen. A member list table with Email, name, Status, and an Application role column showing each member's per-application role. A search box and an add-member button sit above. Row actions allow editing a member's application role and removing them from the application.
Application users. Membership and role here apply to this workspace only.

Application roles

Application roles are shared across the account. New accounts include three: Admin has full feature access and can manage application members, Operator has full feature access but cannot manage members or roles, and Viewer has read-only access. Custom application roles may also appear. The add-member dialog defaults to Operator. An application Admin role does not grant the account-wide Admin role.

Adding an application member follows the same email lookup as inviting an account user. An existing user can be added directly. A new email shows name and phone fields only if you can invite users with account:create:users, app:create:users, or Owner access. Otherwise, you can add only registered users.

Add member to application dialog titled Add member to application. An Email field at the top resolves the address as you type: if it is already registered, a hint invites you to set their application role; if it is new and you are allowed to invite, First Name, Last Name, and Phone fields appear. An Application role select sits at the bottom, defaulting to Operator.
Add a member and choose their application role. New members default to Operator.

Who can manage application members

Application permissions, account permissions, and the account-wide application override can all grant access. The required permission depends on the action:

Action Permission
View application members app:read:users, account:read:users, or account:update:users
Add a member app:create:users or account:create:users
Change an application role app:update:users or account:update:users
Remove a member app:delete:users or account:update:users

The Owner and users with account:manage:applications can perform all of these actions.

Application administrators cannot change account roles. Without account:update:users, they can change only a member’s role in the current application. Removing a member from an application removes access to that workspace but leaves the user in the organization.

Billing and Plan Limits

The Billing tab shows your current plan, its renewal or time limit, and a pricing table you can expand to compare and switch plans. Payment runs through Stripe.

Billing and Subscription page. A Plan Summary card shows the plan name as a colored badge, the price per month or year, and either a renewal date or, for trials, a days-left countdown. Buttons let the user view all plans, change the plan, change the payment method, or cancel.
The Plan Summary card. Trials show days left; paid plans show a renewal date.

The plans

The pricing table has three plan columns, labeled Starter, Professional, and Scale. Starter is the free 14-day trial, Professional is the paid monthly plan, and Scale is the top tier whose price reads “Enterprise / Custom” with a Contact Sales button (a mailto to the sales contact) rather than a self-service checkout.

Expanded pricing table with three columns, Starter, Professional, and Scale, and feature rows for Max Users, Devices, Device Endpoints, Dashboards/Widgets, and Data Retention. The current plan's button reads Your plan; others read Change Plan; the top tier offers Contact Sales.
The pricing table, expanded. The current plan is marked “Your plan”.
Feature Starter Professional Scale
Price Free for 14 days Paid, monthly Custom (contact sales)
Users 1 user Up to 5 users Up to 10 users
Devices Up to 5 Up to 25 Up to 50
Device Endpoints 1 2 Not listed on the plan card (contact sales)
Dashboards & Widgets Unlimited Unlimited Unlimited
Data retention 14 days 90 days 12 months
Check Billing for your current limits. The table above summarizes the standard plan cards. Your Billing tab shows the prices and limits that apply to your account.

Account status and the grace period

An account moves through a small set of states that the Billing screen reflects with badges and banners.

State What it means
Trial The free Starter trial. A days-left countdown appears under “Time Limit” and turns red in the last 5 days.
Active A paid plan in good standing, with a renewal date.
Grace period The subscription has lapsed. The account has view-only access for a limited number of days before suspension. An orange “Grace Period Active” banner shows the days left.
Expired / Blocked The subscription has fully lapsed and access is blocked. A red “Account Blocked” banner directs the user to contact support to reactivate the account.

Changing the payment method and canceling are gated behind account:update:billing; viewing the plan only needs account:read:billing.

How Permission Gating Shows Up

What happens when a permission is missing depends on what it controls. NEQTO.ai may hide the page or action, or show an Access Denied screen.

  • Pages. Opening a page without its required permission shows Access Denied.
  • Actions. Buttons, menu items, and sections that you cannot use are usually hidden. For example, a delete action is hidden rather than disabled.
  • Navigation. The main sidebar uses account permissions, while an application’s sidebar uses application permissions. A link may appear in one and not the other.

Good to Know

The Owner role and account:manage:applications both bypass per-application roles. Check who holds them before you grant new access.

  • Choose the Owner carefully. Each account has one Owner. The role has every permission and cannot be edited or reassigned in the UI.
  • Grant application-wide access carefully. account:manage:applications gives a user full access to every application, regardless of their application roles.

Start Free Trial