Permissions in Nintex Apps

Permissions determine what workspaces, apps, and data a user can access in a Nintex Apps environment. You assign these permissions by creating and assigning permission sets.

There are two types of permission sets:

  • App permission sets (Primary): Apply only within a specific app. Users can have multiple app permission sets that provide granular control for different roles or groups within an app.

  • Site permission sets (Legacy): Apply site-wide, across all apps a user visits. Each user can only have one.

Important:  Site permission sets are deprecated and will be removed in a future release. All new implementations should use app permission sets only. Existing site permission sets will continue to work, but are not recommended.

Jump to:

App permission sets (Primary)

App permission sets are additive. You can assign multiple app permission sets to users within the same app to grant different levels of access. Each permission set defines access to the app’s resources and ensures users interact only with the parts of the app they are authorized to use.

A user can have one or more app permission sets, so their access can vary between apps. For example, a user may have access to a connection in one app, such as HR-related data in the HR app, but not to the same data in a different app, such as the Marketing app.

You can assign app permission sets to grant additional access to specific users only within designated apps. For example, you can assign HR administrators a permission set that provides read and write access to sensitive HR data only when they are using the HR app.

App permission sets support granular control over app behavior. You can use them to:

  • Conditionally enable, render, or style elements.

  • Control access to actions or components.

  • Use permission values as variables to control element behavior and data.

For more information, see Use app permission sets.

Note:  Access permission cannot be more granular than the app-level, so per-page access rules cannot be set.

Every user must have at least one app permission set to access an app at runtime. You can assign app permission sets to:

  • Users: Assign directly to one or more users.

  • Groups: Assign to one or more groups. All users in the group inherit the assigned permission sets, making it easier to manage access for multiple users at once. When a new user is added to the group, they inherit the same permissions. Create groups in Nintex Workflow and use them within Nintex Apps. For more information, see User Management.

  • Public (unauthenticated users): Assign permissions for users who access the app without logging in. For more information, see Configure public access in Permissions page.

Note:  Use groups to assign access to app permission sets. Grouping users into Platform groups and assigning each group the correct app permission set ensures consistent and centralized access control across your tenant.

Create app permission sets

Assign app permission sets

Delete app permission sets

Configure public access

Disable public access

Use app permission sets

You can use app permission sets in the following ways:

You can add display logic to a component and configure it to use app permission set conditions. These conditions control when and how the component and its elements render, enable, and style. For more information, see Running user has app permission under Properties in Display logic.

Add Model Conditions to return records when the value of a field in the model matches the value of an app permission set. For more information, see Running user attribute under Value in Properties.

Add data source object Conditions that use app permission sets to limit incoming data whenever a connection is queried or to set specific field values. For more information, see Connections.

Use app permission set parameters in Branch action formulas and functions. For more information, see Formula and Function Reference. Insert these parameters using the Insert variable panel to check if the logged-in user ID matches the app permission set and control the Action flows.

Example of a Branch action formula that uses app permission set parameters: ISBLANK({{$User.appPermissions.f914a566-a636-4dd1-9a38-d9926f33dec3.id}})

You can add the attributes of the app permission set as variables. In the Insert variable panel, go to User > App Permissions. For more information, see Access the Insert variables panel. You can add the following attributes:

  • id: The unique identifier of the app permission set.

  • ntx_asset_id: The identifier of the app permission set that remains the same across the application lifecycle and is used in XML. It also serves as the third token in the Merge syntax: $User.appPermissions.ntx_asset_id.

  • name: The display name of the app permission set.

For more information, see Variables.

Use app permission sets in Field Metadata Overrides to define a field’s name, display type, and usage. For more information, see Running user attribute under the Default items tab in Properties.

Site permission sets (Legacy)

Site permission sets apply across the entire site, and users have these permissions in every app they access. Each user can have only one site permission set.

These sets remain available for existing implementations but are deprecated and not recommended for new setups. In legacy configurations, site permission sets provide broad access based on general user roles.

For example, a sales user site permission set may allow access to core sales apps and connections, but does not provide full access to all organizational data.

System site permission sets

Each Nintex Apps environment includes three system site permission sets: Admin, Standard, and Public, which you can modify but cannot delete.

All site permission sets must be created by cloning an existing permission set, so these three provide a starting point for your site’s permission setup.

Each system site permission set has a purpose:

  • Admin: For builders that manage the Nintex Apps site. Grants access to create apps and configure the backend.

  • Standard: For end users. Provides no workspace, app, or data access by default.

  • Public: For all unauthenticated users. Permissions here apply when someone visits a page without logging in. Use with caution to avoid granting access to sensitive apps or data. This permission set cannot be cloned.

Create a site permission set

  1. Go to Settings > Site Permission Sets.

  2. Click Create.

  3. Select an existing site permission set to clone from, which could be a system site permission set or a previously created permission set.

  4. Type a Name.

    Important:  Site permission set names cannot be changed once they are created. Ensure that your name is accurate and typed correctly.

  5. Click Create.

Once a permission set is created, the detail screen opens, where you can configure its permissions.

Assign a site permission set

Site permission sets are assigned to users when they are created in the Nintex Apps environment. For more information on how this assignment works, see Add users.

  • When manually created by an admin from the Settings > Users screen, the admin selects the site permission that applies to the user.
  • When a user registers via the custom user signup flow, the URL the user registers from determines which permission set they receive, and these URLs are configured within site permission set details.
  • When importing users via CSV, you can either select a single Default Site Permission Set, which applies to all imported users, or create a column specifying each user's site permission set.

To see which site permission set an existing user has:

  1. Go to Settings > Users.
  2. Click next to the user and click Details.
  3. Click Security Settings.

Configure a site permission set

Because each user must have a site permission set assigned, the sets include different permission areas and are organized into several tabs.

These settings relate to the admin access permissions of the site permission set. This tab determines what owners of this permission set can and cannot do:

  • Configure Site: Controls user access to the admin UI backend of the Nintex Apps environment. Users with this permission can perform any action in the site. Assign this permission only to the appropriate admins.
  • Configure Self: Controls whether users can manage their personal settings, such as username, locale, and connection credentials.

This tab lists all apps configured within the Nintex Apps environment. To grant a user access to an app, turn on the Allowed toggle next to it.

While app permission sets can grant app access, configuring access here helps assign apps to a large group of users at once.

The Default App toggle sets which app appears when users first log in, unless they have enabled the Land on last visited page after login option. If no default app is set, Nintex Apps navigates users to at least one app that they have access to.

This tab lists all connections in the Nintex Apps environment. To grant the site permission set owner access to a connection, turn on the Allowed toggle next to it.

If the connection requires additional configuration, click Configure connection permissions next to the connection to set field-level access for the site permission set. For more information, see Connections.

Important:  Even if a page does not include models for certain connections, users can create them dynamically using Nintex Apps JavaScript API. Assign each permission set carefully, especially for connections secured with implicit usernames and passwords.

Note: This feature is no longer available by default. If you require site permission user signups, request enablement from Support.

This section determines how the site permission set is used in custom user signup flows. When enabled, users can sign up for an account with this site permission set without contacting an admin. It does not allow you to assign permission sets to existing users.

User signup is activated at the site permission set level and each site permission set can have only one self-signup setup. However, you can create different signup experiences for each site permission set.

There are two aspects to user self-signup:

  • Enable user registration for this site permission set—make self-signup possible.
  • Create custom registration pages—format the pages where users perform self-signup.

For more information, see Manually Create a Custom Signup Workflow .

Enable user registration for this site permission set

To enable registration, turn on the toggle and modify the following settings:

  • Registration slug: App builders can select the slug used in the registration API endpoint URL. Developers can use this REST API endpoint to programmatically generate new user accounts.

For example, if you select "Admin" for the slug, Nintex Apps displays:

https://[your_site url]/users/signup/admin

Note: In action flows, Run Platform Action now includes a new action: Register New User. This allows app builders to declaratively initiate user self-signup as part of any Nintex Apps Page. For more information, see Manually Create a Custom signup Workflow.

  • Permitted Email Domains: Allowlist-specific email domains using a comma delimited format. If none are indicated, all domains are allowed.
  • Require Email Verification on Signup: Checked by default. If checked, after the user has completed the signup process, they will receive an email with a link inviting them to log into the app and configure a password for their new account. If unchecked, user signup requests must include a password along with other credentials, such as first name and last name, to successfully create a user account via the self-signup API.

Custom registration pages

Once user registration is enabled, to select which pages to use, turn on the Custom Registration Pages toggle.

This tab displays the full registration URL at the top.

  • Registration Pages: Choose from a default user signup experience, or create a custom-branded user signup experience. Once you make your selection, click Preview to see how the default or custom pages will look to the end user.

    • Default: If checked, Nintex Apps uses standard signup, confirmation, and verification pages.

    • Custom: If checked, click the search to choose from a list of Custom Nintex Apps Pages to use for the following registration pages:

      • Custom Signup Page
      • Custom Signup Confirmation Page
      • Custom Verify page

Note:  To remove these pages, click Remove custom signup pages.

The values the user submits are added to the list of that site permission set's users.

Best practice: Scale permissions with app permission sets

Site permission sets are usually assigned when a user is created in the system, and each user can have only one site permission set. These sets give users access to multiple apps and connections across the entire tenant. However, as the number of specialized roles increases, more site permission sets are required to support different configurations of app access. Over time, this can result in a large number of permission sets, making them difficult to manage and organize. Due to this constraint, it is recommended to use app permission sets for granular access control and to provide improved support for rendering conditions. They offer a simpler and more scalable way to manage access for each app.