Note: Nintex Apps data centers are located in West US and Australia (AUS). In-region processing of Nintex Apps data is only available in these regions.

Permissions in Nintex Apps

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

There are two types of permission sets, and they apply to the user in different ways:

Site permission sets: These permissions apply site-wide, in every app an end user visits. Every user must have a site permission set, and they can only have one.

These are configured by navigating to Settings > Site Permission Sets.

App permission sets: These permissions apply only in the context of a specific app. A user can have as many app permission sets as needed.

Because of this, app permission sets can be granular, tailored to meet the needs of specific groups of users when they use a specific app.

These are primarily managed in each individual app's Permissions tab.

Understanding the types of permissions you can assign and how these types of permissions sets work together is immensely important in ensuring your environment's apps and data are secure.

How permission sets stack

Permission sets are additive in nature. They designed to grant additional access, with the only exception being the use of object conditions for Nintex Apps database and SQL connection. With site permission sets at the site-level and app permission sets at the app-level, it's important to keep in mind how these permissions stack as users navigate from app to app.

Site permission sets determine a foundational level of user access, because they travel with users across the site and apply in every app. These permissions are the only consistent powers a user has as they navigate from app-to-app. Because of this, site permission sets are often more general—setting up basic access that is never conditional or needs to change.

And because a user can have as zero-to-many app permission sets, they can do different things depending on which app they are working in. It's possible to have access to a connection in one application—like HR-related data within an HR app—but not have access to that same data within a different app—like a marketing app.

Connection access can be very nuanced in a Nintex Apps environment. Site permission sets can grant a base set of data access permissions—perhaps everyone can access the connection storing sales information. However, for more private data, stacking app permission sets atop a site permission set, you can grant certain users additional access only when they are in certain apps. For example, granting HR administrators read/write access to sensitive data only when they are working within the HR app.

Site permission sets

Site permission sets are the first step in permissioning a user; each user must be assigned a site permission set when they are created. As their name implies, permissions assigned here are carried by the user to any app they may visit in a site. Each user may only have one site permission set, with other permissions layered on through app permission sets.

Every user in a site must receive a site permission set, so each permission set should be designed as a "foundation" for access, meant to serve a wide range of users. Because of this, these permission sets are typically based around user roles.

For example a "Sales user" site permission set that provides access to the primary sales apps and connections, but does not have carte blanche access to all organizational data.

System site permission sets

Each Nintex Apps environment comes with three system site permission sets: Admin, Standard, and Public. These permission sets can be changed, but they cannot be deleted.

All site permission sets must be cloned from an existing permission set, so these initial sets provide a starting place for your site's permissioning.

Each of these permission sets has an intended use case:

Admin: This permission set is intended for builders who will be managing your Nintex Apps site. It provides the ability to create apps and configure the backend of your environment.
Standard: This permission set is meant for the end users who will be using your apps. It has no workspace, app, or data access permission by default.
Public: This permission set applies to all unauthenticated users. If a user visits a page within your Nintex Apps site while not logged in, then any permissions granted within this permission set apply.

While this permission set is useful for portals and public-facing sites, be careful of the permissions you grant. Ensure that this permission set has no app, data, or other permissions you would not want the entire Internet having.

This permission set cannot be cloned.

Creating a site permission set

Navigate to Settings > People > Site Permission Sets.
Click Create.
Select an existing site permission set to clone from, which could be a system site permission set or a previously created permission set.
Give the permission set a name.

Important: Site permission set names cannot be changed once they are created. Be absolutely sure that your name is accurate and entered correctly.
Click Create.

Once a permission set is created, you'll be taken to its detail screen where you can configure its permissioning.

Assigning a site permission set

Site permission sets are assigned to users whenever they are created in the Nintex Apps environment. How this assignment occurs depends on how the user is created:

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 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'll can either select a single Default Site Permission Set which applies to all imported users or create a column specifying each users site permission set.

To see which site permission set an existing user has, or to change a user's site permission set:

Navigate to Settings > Users.
Click dots-vertical More Options > Details beside the user.
Click Security Settings.

You can then select a new permission set In the Site permission set dropdown.

Configuring a site permission set

Because each user must have a site permission set assigned to them, they cover a variety of permission concerns and are split into several tabs.

General settings

These settings relate to the admin access permissions of the site permission set, determining what owners of this permission set can and cannot do:

Configure Site: Determines whether or not users can access the admin UI backend of the Nintex Apps environment. Users with this permission effectively have permissions to do anything in a site. Be sure this permission is granted only to the appropriate admins.
Configure Self: Determines whether or not users can configure their personal settings—such as username, locale, and connection credentials.

App access

This tab lists all apps configured within the Nintex Apps environment. Beside each tab is an Allowed toggle, which determines whether or not users can access the app.

While app permission sets can be used to grant app access, configuring access on the site permission set can be helpful for assigning app access to a specific, but large group of users all at once.

The Default App toggle determines which app is displayed to users when they first log in—assuming they have not enabled the Land on last visited page after login option in their own settings. If no default app is set, then Nintex Apps attempts to navigate users to at least one app that they have access to.

Connection access

This tab lists all connections configured within the Nintex Apps environment. The Allowed toggle determines whether or not the owner of the site permission set can access the data at all.

If the connection uses connections then the settings Configure connection permissions appears beside the connection. Clicking this link will take the user to a page where field-level access can be configured for the site permission set.

Important: Even if your page does not contain models for certain connections, savvy users can create them dynamically using Nintex Apps's JavaScript API. Exercise caution when assigning each permission set's permissions, particularly for connections secured with implicit username/password.

This section determines how the site permission set can be used for 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.

Read below for a description of this tab's properties. To learn more about this process, see the custom user signup topic.

Enable user registration for this site permission set

Sliding the toggle to enable registration, then modify the following settings:

Registration slug: 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 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: Whitelist 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, then user signup requests must include a password along with other credentials (first name, last name, etc.) to successfully create a user account via the self-signup API.

Custom registration pages

Once you enable user registration, you can then slide the Custom registration pages toggle to select which pages to use.

This card 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: You can remove these pages by clicking Remove custom signup pages.

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

App permission sets

App permission sets exist only within a specific app, and their permissions only apply to a user when they are within the app. In contrast to site permission sets, every user can have as many or as few permission sets as needed.

All app permission sets grant access to the app they are created in, so assigning any app permission set to a user gives them access to the pages and files within that app—even if it does not grant other permissions. This means those users can freely navigate all of the Nintex Apps pages within that app.

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

Creating app permission sets

Within an app's detail screen, navigate to Permissions.
Click Create.
Fill out the permission set's basic details:
- Name: An easily referenced name for the permission set. It's best practice to summarize the intent and capabilities of the permission set here, for example Read/Write Marketing Data.
  
  Important: App permission set names must be unique across your entire site.
- Description: A fuller description of the permission set's purpose. Best used for notes on the set's capabilities as well as the intended users, for example:
  
  A read/write permission set for all marketing-related objects. Grants access to the necessary branding files as well as budgetary data.
Click Save and continue.
Click the toggle switch beside each connection the permission set should have access to. Toggling a connection will grant any permissions that are set up within that connection's system, following the security model configured there.

If a user with the permission set has read/write access within that system, they will have read/write access to it within the Nintex Apps page.
Note:
1. Clicking Allow all will grant access to all connections associated with the app. However, SQL connections will still require connection access configuration.
2. App permission sets can only grant access to resources that are already added to an app. If you are trying to grant connection access, but don't see the connection listed, check that the connection has already been added as an app resource. See the Apps topic for more information.
(If applicable) When granting access to SQL connections, you must also configure granular connection permissions.
Click Save and continue.
Click Configure for each connection to set connection access. When complete, click Back to the connection access to return to the SQL connection list.
Click Save and finish.

Configuring app permission sets

To update an app permission set, navigate to the Permissions tab of the app detail screen. Within that tab, click the permission set's row within the list or click the dots-vertical More Options icon > Configure.

Assigning app permission sets

From the app permission set's detail screen

To assign a single, specific permission set to one or more users:

Navigate to the Permissions tab of the app detail screen.
Click dots-vertical More Options > Edit beside the permission set you wish to assign.
Navigate to the Users tab.
Click Assign.
Select each user you wish to assign the permission set to.
Click Finish.

From the User tab in app detail screen

This Users tab in the app detail screen shows an overview of the permission sets each user has granting them access to the app. This screen shows if the user's site permission set grants them app access. It also shows all app permission sets assigned to the user within the context of the app.

This screen also allows you to add multiple users to an app, and assign them multiple app permission sets, at the same time:

Navigate to the Users tab of the app detail screen.
Click Add.
Click Add beside each user you wish to assign permission sets to.
1. Click Remove to remove the selected user from the assignment.
Click Next.
Select each permission set you wish to assign to all previously selected users.
Confirm your selections are correct then click Finish.

Unassigning an app permission set

App permission sets can be unassigned from the user's app detail screen or the permission set's detail screen.

To unassign a multiple permission sets from a single user:

Navigate to the Users tab of the app detail screen.
Click Add.
Click Add beside each user you wish to assign permission sets to.
1. Click Remove to remove the selected user from the assignment.
Click Select permission sets.
Select each permission set you wish to assign to all previously selected users.
Confirm your selections are correct then click Finish.

To unassign a single permission set from multiple users:

Navigate to the Permissions tab of the app detail screen.
Click dots-vertical More Options > Edit beside the permission set you wish to unassign.
Navigate to the Users tab.
Click dots-vertical More Options > Unassign permission set.
Confirm the unassignment by clicking Remove.

Deleting app permission sets

Within the permission set list tab: Click the dots-vertical More Options icon > Delete.

Within the permission set detail screen: Click delete the trash can icon in the header of the permission set's detail screen.

Note: You cannot delete an app permission set until it has been unassigned from all users.