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.

Deck

For every record in a model, the Deck component will create an individual card, each a template that can be configured within the Page Designer. These cards visually highlight a model's data and allow you to set interactions.

Using the Deck component

In contrast to a standard list view, which provides a catalog of all data, or a detail view, which lets end users drill down into any one record, the Deck component allows you to surface important information and place it prominently on the page.

Fill the Deck

The Deck formats every record in a model as a card. Once you Add a Deck component to your page, you can drag and drop components into that Deck to configure the format of the cards.

Note:  Add a component to the first card in the deck and it will populate the other cards.

  • Ensure that components within the Deck are accessing the correct model to receive the target data.
  • Modify the components' properties, and add any desired actions to the components.

Experiment with components to determine which work best to display the selected data. Good options include:

  • Header component: Provides a title for each of the cards, typically based on record's Name field.
  • Form component: Since each card is an individual record, the Form component is best suited for editing data in cards.
  • Image component: if your object has image fields (for example, company logos, or pictures of contacts), use this component to display those images in the deck.

Note:  Add an interaction to the component that opens a modal with more information when the end user clicks or swipes the image.

Every Deck includes a header and a footer. These sections include:

  • Header
    • the Deck's title
    • the Save and Cancel buttons
    • a search box
    • a button for opening a sort builder
  • Footer
    • a picklist to set number of records displayed per page
    • an indicator of which set of rows are showing and links to jump to the next or last increment

The component's header and footer can be hidden using properties in the General tab.

Filtering a Deck

You can add a filter to the Deck using either the Filter Set component, or the filter option on the List itself ( Add features > Deck filter ). Learn more about creating, configuring, and conditionally rendering filters.

Sorting a Deck

You can give end users the ability to sort records in the Deck component by adding the Sort Builder to the header of the Deck.

How to limit data in the Deck

There are many ways to take advantage of the Deck component, but it offers fewer ways to limit incoming data. If you're using the Deck to surface a subset of information found elsewhere on the page—for example, from a model used in another component—adding a condition to that model will limit the records for both components.

Want to limit only the data coming into the Deck?

  • Duplicate that model using the Clone button next to the model name, and give the model a new name.
  • Add a condition that limits the data to the subset for the Deck component.

Use this new model exclusively with the Deck.

Component actions

Component actions are available using Run component action.

Go to page

Navigates to the Target page in the component.

  • Target page:
    • First page
    • Last page
    • Previous page
    • Next page

Properties

Component properties

  • Model: The model the Deck component uses to create its separate cards. Every record in the selected model that meets the model condition will have a card.

  • Title: The title that displays above the Deck. (If left blank, the Deck does not have a title.) Can also contain rendered HTML if Allow HTML in title is enabled.

    Note:  This is the title for the deck as a whole, not the title of the individual cards. Titles can be added to the card layout using a Header component.

  • Allow HTML in title: Determines HTML rendering behavior for Title contents. When enabled, any HTML syntax will be rendered. When disabled, HTML syntax is displayed as plain text. For example:

    Enabled:

    This text is important

    Disabled:

    <strong>This text is important</strong>

  • Show save and cancel buttons: Check to display Save and Cancel buttons for the deck. (Default: unchecked).

  • Visible rows: Controls how many rows of cards are visible. This property's value can be one of the listed choices (which includes showing all available rows) or a custom number. The default setting is 10 rows. This property can be particularly useful if the amount of cards in the Deck is causing an unexpected amount of empty space.
    • 5
    • 10
    • 25
    • 50
    • Show All
  • Show page size dropdown: If checked the number of visible rows is displayed at the bottom of the Deck and can be overridden by the end users, who can also navigate through the "pages" of records.
  • Always reset pagination after save or query: Click to reset to the first page after any edits or queries to the model.
  • Unique ID (optional): Nintex Apps automatically generates an alphanumeric ID for the component; if preferred, give it a practical name.
  • Column gutter size: Set the distance between cards.
  • Row gutter size: Set the distance between rows of cards.

  • Row actions on left: By default, Row Actions are displayed on the right. If checked, they will be displayed on the left.

  • Show "Load more" button: If the Max # of records property on the model is set to a limiting number, checking this allows the end user to load additional records.

  • Show header: If checked, the Deck header is displayed.

  • Show footer: If checked, the Deck footer is displayed.

    Note:  Hide Header/Hide Footer supersedes any settings for individual elements in the Header or Footer. For example, if Show a save and cancel button is checked—which displays the Save and Cancel buttons—but Hide Header is also checked, the Save and Cancel buttons (which sit within the header) will not display because the header is hidden.

In this tab are properties that control whether or not you have a search box, and when search terms and conditions are applied.

In this tab are properties that control whether or not you have a search box, and when search terms and conditions are applied.

  • Filter & Search Behavior:

    • Apply filters and search immediately: If checked, all changes made to filters, or any text typed into the search bar, will be applied immediately. If unchecked, Nintex Apps displays the Apply and Cancel buttons. The changes will not be applied until the end user selects Apply.

      Note:  This is particularly useful when employing multiple filter criteria.

  • Search Properties:

    • Show search box: If checked, Nintex Apps displays a search box above the component.

    • Search method: Determines if a search will query the server and filter its data, or filter local data on the client.

      • Server (default): Returns search results from all data on the server.

      • Client: Returns search results from only the data that is currently loaded on the page. Large data sets may require lengthy time to filter. If end users commonly need to sort only the data they have loaded within the page—as opposed to every record on the server—this property may speed the filter process.

        Important:  If the server contains a large data set not yet loaded into the page, but Search Method is set to Client, the filter may return incomplete results because it's filtering incomplete data. This may result in unexpected omissions.

  • Search results: Determines which results are displayed based on the end user's search query.

    • Match exactly: Results are only shown for records that contain the search term verbatim.

      If the user searches for George Washington, only the records containing George Washington exactly as written—with no other terms in between—would be displayed.

    • Contain all terms: Results are shown for records that contain all of the terms in the query, even if they may appear in a different order or disconnected from each other.

      If the user searches for George Washington, any record containing George and Washington would be displayed, as long as both terms were anywhere within the record.

    • Contain at least one term: Results are shown for records that contain any of the terms in the query.

      If the user searches for George Washington, any record containing George or Washington would be displayed.

Specifies which fields will be searched against from the component's search bar.

  • Search fields: Specifies which fields will be searched against from the component's search bar.

    Note: 

    Depending on the connection used for the model attached to the component, this property may not be available.

    • Field: Nintex Apps searches on searchable fields by default. Search can be narrowed to individual fields by clicking add Add new Search Field, and then using the field picker to select the field.

      Note: 
      • ( Salesforce connections only ) SOQL can search Picklist fields and Reference fields, but not Long Text fields.
      • You can add multiple search fields.

      • Search operator: Select from the following logical operators:

        • =
        • starts with
        • Contains

By default, Salesforce Objects use SOQL. To ensure proper functionality, enable the Allow Search property on any Salesforce objects to be included in the search.

For more information on using these search options with Salesforce, check out Salesforce's SOQL and SOSL Reference Guide.

Sort properties

These properties determine the appearance and behavior of the Sort Builder.

  • Show sort builder: Check to display the Sort Builder in the component at runtime.
    • Button icon: The icon to display next to the label. Click the icon picker to select a different icon.
    • Button label: The label text that appears on the Sort Builder at runtime. Change the text to match what you want to say to your end users.
  • Sort client-side: Check to only sort on field values that are loaded into the page at the time the sort is applied. This means that the sort will be applied to data in the model, not to data still on the server.

Click add Add interaction then select:

  • Action type: Determines the type of user interaction that triggers the action script.

In the dots-vertical More Options menu on the selected interaction, click Add action, then edit the Action Type:

  • Style variant: Style variants are created and set in the Design System Studio. Some components have pre-defined variants for a specific aspect of a component's style. Also, Nintex Apps builders can style and customize elements to create their own themes within the DSS. These themes will dynamically populate as selectable values in the Style Variant dropdown menu.

    Note: 

    To refresh available style variant options, click refresh Refresh style variants.

    This is useful for when changes to the design system (like style variants or variable options) have been made in another browser window or by another user.

  • Margin: Sets a component's margin (the space around it) relative to other components on the page.

    • To set margins for all sides, click All.
    • To set margins for each side individually, click Separate.

    Margin values can be set to any configured spacing variable for the page's design system. Margin cannot be set an arbitrary value; it must use a design system variable.

Standard display logic options are available to display or hide the component or feature.