A data component, the Queue displays a list (or “queue”) of record items, formatted using merge syntax in a template to control how the items render. This component allows end users to employ on-click actions from the Queue items to launch actions in other components on the page.

Using the Queue Component

While typically used with the Action Framework to update Page Includes located elsewhere on the page, the Queue can be used for a variety of purposes.

One common use case is a Queue (often located in one section of a Responsive Grid) that lists records by name. When a name is selected, data from a different Skuid page is displayed via a Page Include (in another section of the grid).


The content below assumes you have a Skuid page and at least one working model.

Add a Queue component to the page, then:

  • Ensure that the Queue is accessing the correct model and name the Queue (if desired). (List tab)
  • Choose whether to include a search box. (Filters and Search tab)
  • Style the Queue’s list items. (Item Display tab)
  • Add Interactions that allow end users to launch action when they select a Queue item.

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

  • Header
    • the Queue’s title
    • a search box
  • Footer
    • an indicator of which set of rows are showing

The component’s header and footer can be hidden using properties in the List tab.

Filtering a Queue

You can add a filter to the Queue using either the Filter Set component, or the filter option on the Queue itself (Add Features > Add Queue Filter). Learn more about creating filters.


When you add a Queue to the page, there are several properties you can modify:

List tab [[]]

  • Model: The Queue will draw and display data from this model.

  • Title: The title that displays above the Queue. (If left blank, the Queue does not have a title.)

  • Unique Id (optional): Skuid automatically generates an alphanumeric Id for the component; if preferred, give it a practical name.

  • CSS Class (optional): Assign a CSS class to the component’s DOM element.

  • Hide Header: If checked, the Queue header does not display.

  • Hide Footer: If checked, the Queue footer does not display.


    Hide Header/Hide Footer supersedes any settings for individual elements in the Header or Footer. For example, if Show Search Box is checked in the Filters and Search tab, but Hide Header is also checked, the search box (which sits within the header) will not display because the header is hidden.

Filters & Search tab [[]]

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, Skuid displays the Apply and Cancel buttons. The changes will not be applied until the end user selects Apply.


      This is particularly useful when employing multiple filter criteria.

    • Show Filters and Search by default: If checked, the container that holds the search box and filter options is displayed


      To display the Search Box within the Filters and Search container, the Show Search Box property under Search Properties must be checked.

  • Search Properties:

    • Show Search Box: If checked, Skuid 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.


        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.

    • Tokenize Search Terms: If checked, each word typed into the search bar is “tokenized” — meaning each word is searched for individually. A tokenized search for “George Washington” returns any record with “George” and “Washington”. For example, “George Washington,” “George Michael Washington,” and “George is headed to Washington”. An untokenized search for “George Washington” returns only records with “George Washington” exactly.

    • Search box placeholder text: The text that appears in the search box before the end user starts a search. (The default is “Search.”)

    • Empty Search Behavior lets you determine what happens when the search box is emptied.

      • Re-query for Model Data (default): The data displayed in the component returns to the state it was in when you first loaded the page.

      • Remove all Model Data: The data is removed from the component and its associated model (but not from the data object).


        Why do this? If you want to use a component to display the list of search results—handy when you have a lot of search results—you need to have an empty component each time you do a new search, so you can display the newly returned results in it. Without this property, the component’s model will be re-queried when the text is cleared from the search box.

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


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

    • Use SOSL to improve search performance (Salesforce data sources only): SOSL quickly can search multiple objects at a time within a single search query. SOSL does not directly search the database, but instead queries an index of Salesforce text fields. Individual search fields may not be added when this property is enabled.


      Because the search is against the index, results are limited to what is present in the index, and will not include data that may have been recently updated in the database. The index updates very quickly, but expect a delay of up to 30 seconds between changes made to the database, and their appearance in the search results.


      SOSL can search Text fields (including Long Text fields), but not Picklist fields and Reference fields.

      • Fields to Search: Sets which Types of fields to query with SOSL. The options are:

        • Name Fields (default)
        • All Text Fields
        • Email Field
        • Phone Fields
        • SideBar Fields (Name, Phone, Email, External Ids)

        Searches on Salesforce data sources can use one of two query languages: SOQL or SOSL. SOQL can only search one object at a time in a single query, but searches all searchable fields in that object in real-time.

    • Fields: Skuid searches on searchable fields by default. Search can be narrowed to individual fields by clicking fa-plus-circle Add new Search Field, and then using the field picker to select the field.


      • (Salesforce data sources 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

Skuid SFX [[]]

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.

Item Display tab [[]]

There will be different options, depending upon the Item Renderer Type:

  • Template:

    • Render Template: Use the field picker to select the model fields that will display in the queue.


      The field picker will only display fields that have been added to the model. If you don’t find the desired field in the field lookup, return to the model and add it.

      The template field will accept HTML, allowing you to style the row’s display. A few options:

      • Add spacing between the fields, or use a comma or a dash to separate them:

        {{Selectedfield}} - {{SecondSelectedField}}

      • Make add bold or italics for emphasis:

        <b>{{Selectedfield}}</b> <i> {{Selectedfield}}</i>

      • Put the fields on separate lines:

        <b>{{Selectedfield}}</b> <br>{{Selectedfield}}

    • Icon (optional): Click the field picker to include an icon next to each queue item.

  • Snippet: Use the Snippet Item Renderer Type to apply a custom render defined by a code snippet. Learn more about snippets.

    • Render Snippet: Enter the name of an installed Snippet.
    • Render Template: Use the field lookup to select the model fields that will display in the queue. HTML styling is available (see note, above).

Interactions tab [[]]

  • Action/Interaction Types: Choose from three possible interactions:
    • Click—best for desktop as well as mobile
    • Swipe—best for mobile
    • Press—best for mobile

Click fa-plus-circle Add Action on the selected interaction type to add actions, then edit the Action Types:


Using a Page Include with your Queue? There’s a specific action for that:

  • Action Type: Update Page Include
  • Skuid Page: The name of the associated page.
  • Page Include Component Id: Click to select the Page Include from the list. (If you have given the Page Include a unique name, it will appear here). When a Page Include is selected, a flashing yellow outline will indicate the chosen item within the canvas.
  • Query String: Use id={{Id}}. This tells the the Page Include to load the record whose Id matches the Id of the record the end user clicked.

Display Logic tab [[]]

Conditional rendering allows you to display or hide the Queue, based on defined data conditions.