Nintex Apps glossary

Actions

Actions are sets of commands that can create pop-ups, modify model data and conditions, run custom snippets of JavaScript, Apex, and more. Actions can be used as part of Action flows.

Action flows

Action flows are used across many components to configure actions and the events that trigger them at Runtime. They provide a flexible way to automate behavior, reduce the need for custom code, and simplify building efficient pages.

Note:  While actions for the desktop are often triggered by clicking on an item on the page, some components allow you to configure action scripts for additional interactions—which are particularly useful for mobile applications—such as Swipe or Press interactions.

For more information, see Action flows, Table action and Model action.

For the list of actions, see Actions reference.

Aggregate model

An aggregate model requests multiple rows from your data object and generates summaries of the combined values for those multiple rows in a specified field. For example, a sum aggregation of the Amount field adds up all Amount field values from all rows requested by the aggregate model.

Aggregations can be displayed in separate groupings based on fields within the object and are similar to the groupings in the standard Salesforce report wizard. They can also use conditions and model actions.

The most effective aggregations are built from all records within a data object. To achieve this, the Max # of records field in the model's Properties panel must be left blank.

Why use aggregate models

Aggregate models are created on the server side, allowing large data sets to be combined into practical groupings without running into Apex heap limits or SOQL query limits.

For more information, see Aggregate models.

API

An API (Application Programming Interface) is the way one interface or service communicates with another. It is a general term that can refer to many different types of interfaces depending on the context.

Some common examples within Nintex Apps include:

• Nintex Apps JavaScript API: JavaScript objects and functions that can be used to interact with models, components, and other elements of Nintex Apps. These APIs are an essential part of customizing Nintex Apps with code, whether through snippets or custom components.
  • Example: Using skuid.model.getModelsList() within the browser console, on an app page, to see a list of models printed in the console.
• Web APIs: While this term can be used for server-side APIs, it usually refers to the common JavaScript APIs that can be used to construct and modify web pages, most often through the Document Object Model (DOM). While some of these APIs are used to make requests to servers, they are most often used for interacting with the web page itself, especially within the context of Nintex Apps.
  • Example: Using skuid.model.getModelsList() in a Nintex Apps custom component to retrieve an element within the web page.
• REST APIs: APIs used to access external services rather than interact with a web page. Requests are sent from a client to specific endpoints (URLs on a server) for specific types of information. SOAP APIs are also commonly used and are similar to REST APIs, but they use an older protocol.
  • Example: Sending a GET request to https://www.googleapis.com/drive/v2/files within a Nintex Apps REST model to receive a list of Google Drive files.

App

An app is a cloud-based application that enables users to create interactive user experiences connected to external data sources and services. Apps are built using a drag-and-drop interface that allows users to design responsive applications, display and manage data, apply custom styles, and integrate workflows without writing code.

For more information, see Apps.

App Designer

The unified workspace where builders configure apps, design pages, and manage app assets.

The App Designer consists of the following main areas:

• Elements panel

• Configuration panel

For more information, see App Designer.

Auto-save

Auto-saves are Page revisions generated when you click Save while working on an app page. Although the name suggests automatic saving, app pages do not save automatically like productivity applications such as Microsoft Word or Google Docs. Instead, each saved session is stored as a separate page revision.

Note: To ensure your work on pages is not lost, click Save regularly.

Before-load actions

Before-load actions are actions that run before a drawer or pop-up loads. These actions are used to activate and set model conditions and query models and to ensure that contextually relevant data is displayed in the drawer or pop-up.

For more information, see Drawers, Action flows, Table action and Model action.

Component

A component is a reusable building block in Nintex Apps used to construct the structure, functionality, and visual elements of a page. It can display and interact with data, manage page layouts, collect user input, and present visual elements such as charts and images. A component is connected to models to access data from external systems.

For more information, see Components.

Conditions

Nintex Apps uses conditions in the following contexts:

Connection

A connection is a configured link between Nintex Apps and a specific external data source or service. Connections use connectors and authentication settings to access external systems and define the objects, fields, and metadata that models use within apps.

For more information, see Connections.

Connector

A connector is a Nintex Apps integration framework that enables communication between Nintex Apps and external systems or services. Connectors provide the logic required to interact with specific platforms, APIs, or databases, and retrieve and manage external data.

For more information, see Connectors.

Container page

A page that contains a separate page within it using a Page Include component.

For example, if an Account detail page contains a Page Include component that references a Contacts detail page, the Account detail page is the container page.

Data model and Nintex Apps model

Data model refers to the structure of your data inside an external connection, such as Salesforce, Oracle, or other data platforms. This includes how data is stored and managed, including objects, fields, relationships, validation rules, workflow rules, Apex triggers, and more.

Nintex Apps also uses models as tools to retrieve and work with data. Each model requests one data object from one connection (Salesforce, Oracle, or others) to be displayed and modified in components on a Nintex Apps page. Since Nintex Apps does not store data, it relies on the integrity of the data models of your connections to work properly. Well-structured data models across all connections provide more flexibility when creating Nintex Apps pages.

Nintex Apps models serve as temporary containers for data retrieved from a connection, such as Salesforce. The data model of that connection determines how the components on your Nintex Apps page can interact with the data retrieved.

A data model is the logic structure of data within a connection, while a Nintex Apps model is a tool for interacting with the data inside a connection. Hence, the data model governs how Nintex Apps models interact with data.

Data objects and databases

A data object exists within a database such as Salesforce, SharePoint, Oracle, and others, and contains data, such as records and fields. A database is essentially a collection of data objects. Nintex Apps models access these data objects to provide data to page components.

Entity

For more information, see Object.

Event

A back-end notification that is published or triggered whenever something occurs on a page. Events can be triggered by a variety of actions. A common Nintex Apps example is the model.saved event, which is published when a Nintex Apps model is successfully saved. Custom events can also be published using an action. Events are a common concept in JavaScript.

Events are always triggered in the background (while users interact with Nintex Apps) and have no direct effect on the user experience unless an event subscription is in place. These subscriptions wait for a certain event to be published and initiate a sequence of actions. Event subscriptions can be created declaratively as action sequences or programmatically using JavaScript as EventListeners.

Filter

A filter is a powerful component feature used to analyze information quickly by narrowing data down to what is relevant. It uses model conditions to limit data based on field values and is mainly used within the Filter Set and Table components.

Global merge variables

Global merge variables are available across all contexts and are denoted by a $ prefix. For example, {{$Param.accountId}} and {{$Api.Session_Id}}.

For more information, see Merge variable, Merge syntax, Page parameter, and URL merge variable.

Included page

A page that is displayed within another page through a Page Include component.

For example, if an Account detail page contains a Page Include component that references a Contact detail page, the Contact detail page is the included page.

Merge syntax

The formatting syntax, using curly brackets, that is used to pass information between models and pages in Nintex Apps.

For more information, see Merge variable, Merge syntax, Page parameter, and URL merge variable.

Merge variable

A piece of data that is inserted (merged) into another location using Merge syntax. These variables can be either context-dependent or globally available.

For more information, see Merge variable, Merge syntax, Page parameter, and URL merge variable.

Model action

Model actions trigger action flows based on specific events occurring on a Nintex Apps model. It is helpful to think of events as an interaction between the end user and the UI. An event can also be the result of a field value or model property meeting a predetermined value or range of values in a model action's configuration. Examples of events include when a model is saved, queried, or cancelled, or when similar events occur to that model's rows.

When triggered, model actions can have multiple scripted action types within them. They are especially useful when you want interactions or field values on one model to trigger actions on another model.

For more information, see Model Actions, Action flows, Before-load actions, and Table action.

Object

External services use two terms, sometimes interchangeably:

• Entity: An abstract concept often represented as a table in a database schema.

• Object: An in-memory data structure.

In Nintex Apps, the term object is used for consistency and readability to refer to the data elements retrieved by models.

Operators

Nintex Apps conditions use the following comparison operators to show the relationship between two values:

• =
• !=
• >
• <
• >=
• <=
• includes
• excludes
• starts with
• ends with
• contains
• does not contain
• does not start with
• does not end with

Nintex Apps formulas use the following transactional operators to define formula relationships:

• + Add
• - Subtract
• * Multiply
• / Divide
• = Equals
• != Does not equal
• > Greater than
• >= Greater than or equal to
• < Less than
• <= Less than or equal to
• && And
• || Or
• % Remainder (Modulo operation)

Page Designer

Note:  The Page Designer was formerly known as the App Composer.

The drag-and-drop workspace where builders create Nintex Apps pages.

The Page Designer consists of the following main areas:

• Elements panel
• Properties panel
• Global page actions
• Canvas

For more information, see Page Designer.

Page parameter

An arbitrary variable that allows for additional information to be passed into a Nintex Apps page.

For more information, see Merge variable, Merge syntax, Page parameter, and URL merge variable.

Responsive Grid

The Responsive Grid allows you to divide the page into side-by-side divisions that adjust their size to fit the size of the screen. Use this component to create sections in a page or add sidebars.

For more information, see Responsive Grid.

Runtime

Runtime refers to when users are actively using a Nintex Apps page to view, create, or modify data. This includes both previewing pages and working with fully published pages.

Nintex Apps model

Model is used in Nintex Apps to retrieve data and form the building blocks of every page. Each model requests one data object from a single connection. This data can then be displayed and modified in one or more components on a Nintex Apps page.

A model can be configured in detail, allowing builders to choose which data fields to retrieve, set conditions to filter data, and define actions for different situations.

Nintex Apps models can have either basic or Aggregate models.

Nintex Apps page

A Nintex Apps page is an arrangement of components, models, and other resources used to support one or more processes. In practice, Nintex Apps pages are configured to present meaningful experiences, such as helping end users find and manage the data needed to complete specific tasks.

Some Nintex Apps pages are simple, with one or two components and models, while others include multiple elements working together to support complex processes from a single location.

Sizing measurements

Many Nintex Apps components allow you to define size using the following sizing units:

• px (pixels): Fixed size units; one pixel equals one screen dot. (A precise measurement.)
• em (ems): A unit based on the current element’s font-size CSS property. If an element has a font-size of 16px (the default in most browsers), then 1em equals 16px, 2em equals 32px, and so on. (A relative measurement; adapts well for mobile responsiveness.)
• rem (root ems): A unit based on the font-size of the root HTML element, which defaults to 16px on most browsers. With rems, even if a child element's font-size is changed, 1rem will equal the font-size of the root element. This consistency makes layouts more predictable, though slightly less modular. (A relative measurement; well-suited for responsive design.)
• % (percent): A unit used to calculate a size based on a ratio of another size that the element has inherited. For example, setting the width of a div to 50% in a container that has a width of 500px will result in a 250px width. (A relative measurement especially with high scalability; useful for mobile devices and accessibility.)
• vh (viewport height): A ratio of the height relative to the viewport. An element with a height property of 100vh, fills the full height of the viewport; using 50vh would cause the element to fill half the viewport. (A responsive unit that adjusts when the browser window height changes.)
• vw (viewport width): A ratio of the width relative to the viewport. An element with a width property of 100vw, fills the full width of the viewport; using 50vw would cause the element to fill half the viewport. (A responsive unit that adjusts when the browser window width changes.)

Table action

Tables have additional options where actions can be configured, which are sometimes referred to as table actions:

• Row actions: Row actions initiate actions that use data from the table rows they are activated on.
• Global actions: Global actions are used more broadly without regard to records. They can be used for creating new records, opening dashboards, showing pop-ups with helpful page information, or triggering changes on a page. The key point is that a Global action has no Context, unlike Row or Mass actions.
• Mass actions: Mass actions allow builders to set up actions that will affect the selected records in a Table. Typically, this is used for actions such as flagging selected records for deletion or changing the value of a field in the selected records (for example, to change the Billing State of multiple records from CA to TN). Instead of updating each record individually, select the records and use a Mass action based on updating fields in a record to change the field value.

For more information, see Action flows and Model action.

URL merge variable

A merge variable within a URL used to pass information from one page to another.

For more information, see Merge variable, Merge syntax, Page parameter, and URL merge variable.

Variables in Design system

Variables in Design system are reusable design values used within the Design System Studio to define styling properties such as colors, typography, spacing, and sizing. They provide consistent styling across components and are used to create and manage component style variants.

For more information, see Design system.