Apps

An app is a collection of Nintex Apps pages, connections, tables, workflows, documents, files, and permissions that make Nintex Apps software available to end users.

Apps and their pages are accessed using specific URLs within the Nintex Apps site. In addition to providing a central area for managing resources, apps are the primary way to deploy all of an application's required resources from one Nintex Apps environment to another.

Jump to: 

App-centered development and primary concepts

When building applications with Nintex Apps, it's best practice to adopt an app-centered development mindset, which means to build and work primarily in the context of a single app and its detail screen. The app should be seen as the primary means of organizing all the resources needed for a collection of Nintex Apps pages to operate.

It's important to keep this app-resource relationship in mind because connections, design systems, and files exist at the site level. It's possible to create resources outside of the context of an app—such as in the Connections screens.

Deployment is one of the key benefits of app-centered development. Creating resources as needed within the app you are working on automatically creates app-resource relationships, which ensures a smooth deployment process:

  • When deploying an app to end users, the app-resource association is often used for more advanced permissioning through app permission sets. If a user does not have permission to access a resource, like a connection, it will not load, and the end user could encounter unexpected behaviors.
  • When deploying an app to another environment, any resources not associated with an app will not deploy as part of that app. For example, if deploying an app from a sandbox environment to a production environment, any pages, connections, or files not associated with the app will be missing when the app arrives in the destination environment. It's still possible to deploy these resources individually instead of as part of an app, but this is not best practice.

To safeguard against referencing unassociated resources, Nintex Apps tries to associate resources automatically. When adding existing pages to an app, Nintex Apps will try to associate all necessary resources referenced in the page with the app. Nintex Apps's Page Designer will automatically associate some resources whenever they are selected while working on a page—for example, selecting a model's connection or a Page Include component's page.

With these safeguards in place, and by practicing app-centered development, the many parts that make up your applications stay organized and easily managed. If you begin to see issues with certain resources not appearing correctly for your end users, be sure they are associated with all the apps they are used within.

Access apps

  • In the Nintex Apps navigation bar, click Apps.

    This displays all apps configured in the current Nintex Apps environment, with ordering and search options for navigating existing apps.

  • From within the Apps screen, click the All pages tab.

    This displays a list of pages in all your apps, with ordering and search options for navigating existing pages.

Create apps

Set an app's design system

Setting an app's design system includes the following:

  • It associates the design system as an app resource. This ensures it is deployed with the app across various environments.
  • It sets the design system as the default for the app's pages, so newly created pages automatically use it.

Apps can only have one associated design system. However, it's still possible to add pages that use a different design system to an app. When adding pages with a different design system, a warning is displayed, but Nintex Apps will not change the page's settings. A page's design system is never automatically updated because existing style variant display logic could break within the page. You'll need to manually update a page's design system to match the app. If you're deploying your app to other environments and it includes pages that use different design systems, you'll need to manually deploy those design systems as well.

Be cautious when changing an app's design system after pages have already been added. Existing pages won't automatically update to match the new design system. If you need to change the design system later, you'll have to manually update each page in the app to reflect the new system.

Design your app

  • To design your app and manage its assets in a single and unified workspace, see App Designer.

Create pages

Set page URLs

Page URLs are the web addresses that end users visit to access a Nintex Apps page and consist of the app's URL followed by one or more URL path elements:

https://sub-domain.skuidsite.com/app-url/page-url

Once a URL is added and activated, end users can access the page if they have app access. Pages can have more than one active URL.

Apps aren’t accessible to end users until their pages have active URLs and user permissions are granted. For more information, see Permissions in Nintex Apps.

Test and edit your app's pages at their configured URLs until they are fully functional. Your users won't be able to access the app until they have the correct permissions.

Note: Principal pages serve as structural templates for their dependent pages and cannot function independently, so you cannot assign URLs to them.

Path elements determine the structure of page URLs and are used to provide information about the context of the page. They can explain where the page sits in a site's hierarchy or provide data for the page to use in its components. You can define each path element as either a text string or a dynamic parameter.

Text path elements are static descriptors for the app's logical hierarchy. You can define how related pages are grouped using them.

For example, in example.nintex.app/marketing/dashboard:

  • The app's URL is example.nintex.app/marketing.

  • The page's single text path element is dashboard.

However, it's possible to have dynamic URLs using a parameter path element. These path elements function as variables. They are commonly used for passing in model condition values, such as record IDs, to the page. For more information, see Model Conditions.

For example, in example.nintex.app/marketing/promotional-materials/{materialId}:

  • The app's URL is example.nintex.app/marketing.
  • The page's first path element is the text promotional-materials.
  • The page's second path element is the parameter materialId.

In this case, materialId is used to set the record Id of the promotional material item the user is viewing. The parameter element is what passes in the necessary information to the detail page.

A parameter is only optional if it is the final path element, as a missing path element cannot appear in the middle of a URL.

Whether text or parameter, a path element’s value can only use URL-acceptable characters, such as letters, numbers, underscores, and dashes.

Depending on the structure of your app, you may have many path elements for a single page. Text elements are useful for setting the hierarchy of your app, while parameters provide important contextual information.

For example, consider an HR app that allows users to submit paid time off (PTO) requests and then review their requests as a list.

  • This app is available at example.nintex.app/hr.
  • The page used to submit and review requests is located at example.site.com/hr/pto/request.
    • This URL uses two text path elements. Because of these two path elements, users can understand how the page they are on relates to other areas of the app.

The user may also want to review the details of a single request. To do so, there's a separate page that shows the details of a single request available at example.site.com/hr/pto/request/{requestId}.

  • This URL includes the two previous text path elements.
  • It also contains a parameter element in addition to the previous two text elements. Using the requestId parameter in a model condition allows the page to query the correct details. By placing that after the previous two elements, the user still understands where they are in the app.

Depending on your page's setup, this could also be a good use case for an optional last parameter. To do so, the page would need to contain detail view components that conditionally render if a requestId page parameter exists. For more information, see Display logic.

With this setup, you can render the detail-related components of your page when that parameter is available. If it isn't available, only the "list" view components render. This may or may not work for your particular use case, but it is possible.

  1. In the App Designer, click next to the page for which you want to access the URL.
  2. Click Settings and go to Page URLs.

  1. In the App Designer, click next to the page to which you want to add a URL.

  2. Click Add URL.

  3. Select the first path element's type.

    The following options are available:

    • Text

    • Parameter

    For more information on the types of path elements, see Path elements in page URLs.

  4. Type a value for the path element.

    Note: If you want to add more path elements, click Add path element and type a value for each.

  5. Click Apply.

Troubleshooting

Data access issues that occur within a specific app are caused by one of the following:

  • Permissions: Ensure that users have the appropriate permissions. For more information, see Permissions in Nintex Apps.
  • Connections: Verify that your model and connection settings are configured correctly. For more information, see Connectors.