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.

Nintex Apps Glossary

Actions

Actions are sets of commands that can create popups, alter model data and conditions, run custom snippets of both Javascript and Apex, and much more. Actions can be used as part of the Action Framework.

Action flows

(See also Table Action and Model Action )

Useful in many components within Nintex Apps, action flows allow you to configure "actions" and the events that trigger them at runtime. The power and versatility of actions eliminates the Admin or Developer's need for most code and simplifies the process of creating efficient pages for the end user.

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 the Action Framework article .

For a list of actions, see the 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 best aggregations are built from all records within a data object. To achieve this, the Max # of records field in the model properties pane must be made blank.

Why use aggregate models? Aggregate models are created on the "server-side," which allows them to combine large data sets into practical groupings without running into Apex heap limit errors or SOQL query limits.

See the Aggregate Models topic for more information.

API

An API—or application programming interface —is the way one interface or service talks to another. A generalized term, it can mean many different things depending on the context it's used in.

Some common examples within the Nintex Apps world 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 the document.querySelector() API in a Nintex Apps custom component to retrieve an element within the web page.
  • REST APIs: These APIs are used to access external services, in contrast to interacting with a particular web page. Requests are made by a client to particular endpoints—which are URLs on a server—for specific types of information. SOAP APIs also common and similar to REST APIs, though 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.

Page Designer

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

The Page Designer consists of the following main areas:

  1. Elements pane
  2. Properties pane
  3. Global page actions
  4. The canvas

For more information, see the Page Designer topic.

The Page Designer as a whole is made up of these four separate pieces. The Properties pane, Elements pane, and global page actions all reside at the top of the screen, while the canvas resides at the bottom of the page.

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

Auto-Save

Auto-saves are page revisions that are generated when you click the Save button while working on an app page. "Auto-save" is a slight misnomer: despite the name, app pages do not automatically save as they would in a productivity app, like Microsoft Word or Google Docs. What is automatic about the process is that each individual saved session becomes a separate page revision.

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

Before Load Actions

(see also Action Framework, Model Action, Table Action )

Before Load Actions refers to actions used before a drawer or popup is loaded. Generally, these actions are used to activate and set the values of model conditions, and to query models to ensure that the contextually-relevant data will display in the drawer or popup.

For more information, see Add Nested Rows to your Table with Drawers .

Conditions

Nintex Apps uses the term "condition" in several places within the app.

In models

Model conditions determine the appearance of data. Used to limit the records that are returned via a model, they let models know which data to request (or not request) by checking the fields of the model's connection against parameters and values specified in the condition. That value can be a variety of things, including a specific string or variable, URL parameters, running user attributes, fields from other models, results of a sub-query, or even a blank value.

Conditions let you easily create record detail pages in Nintex Apps, while also displaying relevant data from other data objects—conditions can also filter data on the fly. When set to Dynamic (Default off), conditions wait to receive values from components via filters or actions. Using the Condition Location property, choose whether the condition is applied server- or client-side.

In components

Component display conditions determine the appearance of components. These are criteria that determine whether or not the component or element displays or is activated so that end users can interact with it. This is a type of If/Then scenario: If this set of conditions is met, then the element displays ( conditional rendering ) or users have access to it ( conditional enabling ). If the condition is not met, the element does not display on the page ( conditional rendering ) or it displays but cannot be accessed by the user ( conditional enabling ).

This type of conditional display logic allows a builder to hide or disable content until it is needed.

Within context relationships

Context conditions ensure that the data initially selected in one component correlates to the data subsequently displayed in an associated element (like a drawer, or a visualization drilldown or on-click action.) For example, drawers require the builder to set a context condition for each data component within the drawer, to ensure that the field clicked in the original table matches the field displayed within the drawer's component.

Similarly, when using on-click actions or drilldowns in visualizations, the user clicks a chart item to open a popup or sliding panel with additional information, or opens a second chart with more information on the selected item. Nintex Apps passes a context parameter—a specific value for the data that was clicked—from the original chart into the next-level charts or components, to ensure that the contextual data drives the subsequent display.

To learn more, see context.

Container Page

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

For example, if an Account detail page contained a Page Include component referencing a Contacts detail page, the Account detail page would be the container page.

Data Model versus 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 connection is where your data is held and managed. Anything related to the way your data interacts within the database is part of your data model: your objects, their fields, their relationships to one another, validation rules, workflow rules, Apex triggers, and more.

Nintex Apps also employs models, using them as tools to retrieve 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 stores no 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.

Put simply: a data model is the logic and structure of data within a connection; a Nintex Apps model is a tool for interacting with data inside a connection. Hence, the data model governs all the ways that Nintex Apps models interact with data.

Data Objects and Databases

A data object exists in 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

See Object.

Event

A backend alert that is published—or "fired"—whenever something has occurred on a page, which can be a variety of things. A common Nintex Apps example would be the model.saved event being published when a Nintex Apps model is successfully saved, though custom events can be published using an action. They are a very common concept in JavaScript.

Events are always firing off in the background (while users work 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.

Filters

Filters are powerful component features that help you analyze information quickly by narrowing down to what is relevant. Filters make use of model conditions to intuitively limit data based on field values. Primarily used within the Filter Set component and the Table component.

Global Merge Variable

Merge variables that are available in any context; they always begin with a $. For example: {{$Param.accountId}}, {{$Api.Session_Id}}

(see also Merge Variable, Merge Syntax, Page Parameter, URL Merge Variable )

Included page

A page that is included within a separate page by being referenced in a Page Include component.

For example, if a Contact detail page were referenced by a Page Include component within an Account detail page, the Contact detail page would be the included page.

Merge Syntax

The formatting syntax—i.e. curly brackets--used to pass information between models and pages in Nintex Apps.

(see also Merge Variable, Page Parameter, Global Merge Variable, URL Merge Variable )

Merge Variable

A piece of data "merged" into another location through the use of merge syntax. These variables may be context-dependent or globally available.

(see also Global Merge Variable, Merge Syntax, Page Parameter, URL Merge Variable )

Model Action

(see also Action Framework, Before Load Actions, Table Action )

Model actions trigger actin 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, cancelled, or if similar events happen to that model's rows. Builders can create model actions by clicking the red + on the Actions item inside the Page Designer's Models tab.

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.

Object

External services use two terms, sometimes interchangeably: an entity is an abstract concept often represented by a table in a database schema. An object generally refers to in-memory data structures.

While Nintex Apps acknowledges the nuanced differences between these terms, for consistency and readability, we use object throughout our content to refer to the data elements retrieved by models.

Operators

Nintex Apps conditions use comparison operators to demonstrate 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 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 Parameter

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

(see also Merge Variable, Merge Syntax, Global Merge Variable, 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 the Responsive Grid topic.

Runtime

Runtime refers to when users are actually on the Nintex Apps page itself, creating and modifying data. Whether a user is simply previewing the page or they have fully deployed their Nintex Apps pages, they are at runtime.

Nintex Apps Model

Models are the tools Nintex Apps uses to retrieve data, the building blocks of every Nintex Apps page. Each model requests one data object from one connection. This data can then be displayed and modified in one or more components on a Nintex Apps page. The power of models comes in their granularity. Builders can configure their models to match their needs: selecting which data fields to request, setting conditions that limit the data requested, configuring model actions for a variety of situations, and more.

Nintex Apps models may have basic —with the attributes described in the paragraphs above—or aggregate behaviors.

Nintex Apps Page

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

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

Sizing measurements

Many Nintex Apps components allow you to specify size using a variety of sizing units:

  • px (pixels): fixed size units; one pixel equals one screen dot. (A precise measurement.)
  • em (ems): a unit equal to the font-size CSS property of the current element. So if the element's font-size is set to 16px—the default for most browsers—then one em equals 16px, 2em equals 32px, etc. (A relative measurement; scalable for mobile devices.)
  • rem (root ems): a unit equal to the font-size of the root HMTL 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 simplifies code at the expense of some modularity. (A relative measurement; scalable for mobile devices.)
  • % (percent): 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 will fill the full height of the viewport; using 50vh would cause the element to fill half the viewport. (A relative measurement, useful to ensure that the element resizes if the browser window is resized.)
  • vw (viewport width): a ratio of the width relative to the viewport. An element with a width property of 100vw will fill the full width of the viewport; using 50vw would cause the element to fill half the viewport. (A relative measurement, useful to ensure that the element resizes if the browser window is resized.)

Table Action

(see also Action Framework, Model Action )

Tables have additional areas 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 in a broader sense without regard to records: the creation of new records, the display of a dashboard, a popup with helpful hints about the current page, or as a trigger to change values on a page. The key idea here: a Global action does not have a " context," like a Row or Mass action does.
  • Mass Actions: Lets you 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, if you wanted to change the Billing State of a dozen records from CA to TN). Rather than do this one record at a time, select the records and use a Mass Action based on updating fields in a record to change the field value.

For more information, see the Action Flows topic.

URL Merge Variable

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

(see also Global Merge Variable, Merge Syntax, Page Parameter, Merge Variable )