Note: Nintex Apps is in beta release.

Context

Context refers to the data passed into a component or action by another component or action. This can include component, model, row, and other data. Using context, it's possible to display data related across objects, update fields on user-selected rows, and build other nuanced interactions based on the end user's activities.

When working in Nintex Apps, context is typically used to work with a record (or set of records). When data is used like this, it is "in context." And when data is provided to actions and other components, it enables displaying related data within context containers like modals and drawers, or navigating to a detail page by passing an Id as a URL parameter.

There's a variety of ways to use context:

• With components, such as the Table, context is used so that when the user clicks a record, that record is passed into associated drawers, modals, or sliding panels.
• With buttons in the Button Set, which allows you to set model- or row-specific actions that are triggered by the button.
• With Chart and Geochart, to ensure that drill down and on-click actions access the correct data.
• With actions in action flows and in merge syntax.

Some components and actions do not need—or use—context. In these cases, the Context tab does not display on the property pane.

Show in-context values with merge syntax

Merge syntax provides a way to display field values provided by context. If a row is available in context, field data can be displayed by wrapping the field name in curly brackets, like {{Name}} . The available context determines which variables are available to you.

For example, when including a template on a specific component with model or row context, use a merge variable like {{Name}} to access the name field of the record in context. Learn more about context in Merge Syntax.

Note:  Global merge variables, such as {{$Model.OpenTasks.data.0.Id}} do not rely on context as they declare an explicit path to data.

Context in action flows

When using action flows, context is passed first from any initiating event or component to the first action in the action flow. For actions that deal with data, it's important to keep in mind that context is generally received as either all rows within a model or specific rows of data.

Row actions

When dealing with a row action on a Table or another row-dependent action trigger, context contains the specific row where the user clicked the row action.

Note: Row merge variables are available if you have a specific row in context.

Global actions

Global actions and buttons are not dependent on individual rows, and thus do not receive a specific row in context. Due to this, any row dependent actions or merge variables will refer to the first row in the model. Because of this behavior, it's advised to use global merge variables, which declare an explicit path to their data and do not rely on context, within these actions.

Mass actions

Mass actions allow an end user to select one—or more—rows and perform an action on them. All selected rows are passed as an array within a property named rows.

Context between actions

After an action flow begins, each action also passes context from itself to the next action. Some actions can change the context within an action flow. This is important to keep in mind for flows that may initially use an end user's selected row as context, as later actions may shift context to other rows—like ones created or updated by the action.

Be wary when using the following actions as, depending on their properties, they may change context to a different row or set of rows than at the start of the action flow:

• Query models

• Create new rows

• Update rows

• Adopt rows into model

• Remove rows from model

• Remove all rows from model

• Evaluate formula fields on model

Context containers and context variables

Surfaces and certain component subelements are context containers. A context container is an area that—due to it being nested within or called from another component—can be passed information about the data the user is interacting with in a given moment:

• Drawers know which row they've been accessed from.

• Deck cards and Carousel slides know which record they represent.

• Modals and sliding panels can be called from action flows, which can be passed information about the component or interaction that triggers the action flow.

However, to limit the data within a context container's components to the relevant records, you must create a context condition, which maps a component field to a context variable—a named placeholder value.

Context variables are often passed an Id field, which is then mapped to a correlating Id field via the context condition.

For example, consider a Table component with a drawer. The Table shows account information, while each row has a drawer that shows related opportunities in a List component. In that example, the following context features are at work:

• The Table's drawer is a context container.

• When the drawer is opened, information about the row is passed in as context. By default, the row's Id is passed in as a context variable named drawer_context.

• The List within that drawer has a context condition where the opportunity's AccountId field is mapped to the drawer_context variable.

• Because of the above context condition, the List is limited to only showing opportunities related to the account the end user selected.

Surfaces must use context variables due to reusability

Context variables are particularly important for surfaces since they are reusable. For reused surfaces, hardcoding specific Id values isn't viable; instead, context variable values are set within each action that calls a surface. This functionality makes surfaces reusable because it can adapt to whatever context is passed into it at runtime.

For example, consider a modal that displays details about an Opportunity. The modal’s context variable might be named OpportunityId. Each time the modal is opened—perhaps by clicking a Table's row action—an action sets the OpportunityId context variable to the Id of the selected row. The modal then filters its data models by that Id, displaying only the relevant Opportunity details.

Which field to pass as a context variable

Because the most useful field to map is often the record Id, most context conditions should be set to a pair of matching Id fields. However there are instances where using other fields may be useful.

Imagine a pie chart displaying current sales opportunities. An on-click action launches a modal with a Table component showing the accounts associated with those opportunity records. If the record Id for the opportunity is passed in, the Table won't know which accounts to display, because the Id is for opportunity records, not account records.

But if the context condition is changed so that the Id passed is not the Id for the opportunity, but the Id for the account (for example, a field labeled "AccountId "), then this can be matched to the record Id on the account object attached to the table.

Best Practices

• Be aware that, when you have a row action that creates a new row on the Table, context switches from the one with the row action to the new row. If the row action includes an action flow after the creation of the new row, any follow-on actions that require context will take their context from the new row.
• When using a button to trigger a named action sequence, consider using inputs rather than context because it's easier to track the inputs through the sequence, giving you more precision.

Properties

When context is needed, a Context conditions tab is displayed on the Properties panel.