Using Fields

Creating a model to call and hold content is only the first step to accessing the content in an external service’s data object. With some Skuid components, you need to indicate which of the object’s fields to display.

How do fields fit into the picture?

  • Most objects collect records related to a specific data category or topic, for example, business contacts, a company’s accounts, technical service cases, a folder of business documents and spreadsheets.
  • Records are related information about a single entity within that object: a specific company in the list of accounts; an individual contact; a single service request.
  • Fields are pieces of data that have specific values. Collectively, records contain one—and usually more—fields. A particular contact record, for example, has name, address, and phone fields containing values for that contact. A record for a different contact has the same fields, but the values for name, address, and phone are different.

Field Origin

Some objects have predefined fields—fields that are standard (and in many cases cannot be deleted from the object). Even if a field is predetermined by the database’s schema, builders are not required to use it in their Skuid pages.

Custom fields are builder-defined within the object and usually created to address specific data needs. (These fields can be deleted from the external object.)

Field Types

Depending on the external service, the model will have access to the fields types such as the following:

  • Picklist fields and multi-select picklists

The Salesforce data source type [[]]

When using dependent picklists with the Salesforce data source type, be sure to include the controlling field in the model.
  • String fields
  • Date and datetime fields
  • Number/integer, and currency fields
  • Address and phone fields
  • Text and textarea fields
  • URL fields
  • Boolean fields
  • and many more …

Specialized fields

In addition to standard fields like those indicated above, Skuid uses the following specialized field types:

Reference fields

Reference fields (sometimes called “lookup” fields) represent a relationship between different objects. For example, individual contacts, opportunities, or service requests are usually associated with a client company; that company has a record in the account object. So, an accountID field included in a contact, opportunity, or service case object connects those objects to the record for the associated account in the account object. That accountID field the contact object is a reference field: it “references” the account’s record in the account object.


Because reference fields provide a list of values from other objects, users can access and select from those values at runtime. For example, a user adding a contact can click the new record’s empty Account field and start typing; Skuid autofills from the list of available accounts. (Users can also click the magnifying glass within the field to see a popup listing all account values, and select the correct account there.)

Reference fields also allow builders to:

  • Add search capabilities within the field, which allows end users to search for content from within the model.
  • Use the reference field as a link to the referenced record’s detail page.
  • Create filters to limit the searched and returned content from reference fields.
  • Use display logic to determine conditions under which the reference field values display.

Template fields

Template fields—much like the Template component—provide a way to display text or HTML alongside field data. Template fields are “containers” that allow builders to combine two (or more) fields into a single field entity using merge syntax. This saves space, and can also be used to establish relationships.

For example, to create a column in a table that displays both the record’s creator and the date created (two separate fields) in that single column, add a template field to the table that displays CreatedById and the CreatedDate fields, separated by a comma and a space: {{CreatedById}}, {{CreatedDate}}.


Template fields can be useful for:

  • consolidating address fields into a single (template) field
  • incorporating html into display fields

For additional information, see the Template component topic.

Adding template fields

Add template fields to a Table or Field Editor component from the Add Fields dropdown on the component.


You can only select fields that are already included in the model.

Then adjust the Template’s properties:

  • Use the field picker on the Template property to select fields to combine within the template. The fields selected display in the property surrounded by double curly brackets {{field selected}}.

    • Make any spacing adjustments (add spaces, dashes, or commas).
  • If desired, modify the field’s Label. This will re-name the field label (or the column heading in a Table component).

Template fields in runtime

Users can double-click on a template field to open a popup where they can see the fields the template includes and edit them (if applicable).

UI-Only Fields

UI-Only fields (“user interface-only”) are builder-determined “container” fields for “as-needed” data. These fields work with values that are input by users in runtime, values that result from data queried by the user, or values predetermined by the builder.

Think of UI-Only fields as “temporary”: the data in UI-Only fields is not stored in a data object, and if the page is refreshed, the data in a UI-Only field does not persist.

To learn more, see UI-Only Fields and Models.

Field Metadata

Metadata is data about data, information that describes the data itself. Think of field metadata as a kind of “summary” of what the field’s data is. Every field has standard metadata properties. Learn more in Field Metadata Overrides.


Once fields are added to the Table or Field Editor component, each has a specific set of properties. These properties vary, depending upon the component and field type. Click on the field within the table to reveal and edit its properties.

Basic tab [[]]

  • Field ID: The API name of the selected field.

  • Label /Custom Label: Replaces default field label with custom text. Use the field picker to select a field to use as the column label.


    This feature lets you choose another field’s name and re-label the column with it, to shorten or clarify the column’s identity or purpose for users.

  • Allow Sorting: Check this box to display buttons that allow users to sort the table by this column’s values, both ascending and descending.


    Columns with sorting allowed have clickable triangles: up-pointed triangles sort the column in Ascending (Z to A) order; down-pointed triangles sort the column in Descending (A to Z) order.


    To retain record cohesion, sorting an individual column simultaneously reorders the rest of the table. For this reason, sorting should be used judiciously. It is also recommended not to use more than one sorted column per table.

  • Placeholder: Text or prompts that appear inside editable sections within the component. Commonly used to provide instruction for more complex field requirements, this field is compatible with merge syntax.

  • Read-only: If checked, text fields are read only and cannot be edited by users. This setting does not persist across Skuid pages.


    Skuid automatically respects the validation rules and field-level security from your data source.

  • Required: If checked, text input is required.This setting does not persist across Skuid pages and will not override existing data model settings within the data source.


    Skuid automatically respects the validation rules and field-level security from your data source.

  • Max Characters to Display: Determines the number of text characters to display within the column when the table is in Read mode; does not affect Edit mode, where the full length of the field’s value displays.

  • Column Width: The width of the column, in percentages (indicated as %) or pixels (indicated as px).

  • Column Width (Fixed): The fixed width of the column, in percentages (indicated as %) or pixels (indicated as px).


    Do not mix the use of percentages and pixels across columns. Choose one measurement format and stick with it.

  • Horizontal Alignment: Adjusts alignment of text or value within a field to left (default) or right.

  • Field Renderer: Determines how the column will actually display at runtime. All fields have the option of:

    • Standard: Use standard Skuid field renderers, which are based on the type of field selected. (Default setting.)

    • Password: Marks the field as a password input—hiding all characters as asterisks both in Read and Edit mode for all records in the table.

    • Custom (run a Snippet): Use custom-coded table field renderers to take advantage of Skuid’s JavaScript API.

      • Render Snippet Name: The name of the snippet that serves as the renderer.

    Certain field types have different field renderer options:

    • Radio Buttons: (Picklist fields) Renders the field as a set of buttons.


      For multi-select picklists, Skuid renders a multi-select list of checkboxes instead.

    • Auto-Complete: (Reference fields) The default for reference fields, this renderer tries to autocomplete entries based on the options available for this field.

    • Picklist: (Reference fields) Renders the reference field options as a picklist.


      This feature is best used by advanced builders to solve specific user experience needs regarding data display.

  • Allow Users to Show/Hide Column: Check to allow users to choose whether to show or hide this specific column through fa-sliders Table Settings.

  • Show Column by Default: If Allow Users to Show/Hide Column is marked true, this field determines whether a column is shown or not on page load. For large tables with many columns, consider unchecking this field for discretionary columns to give users more flexibility in the data they wish on page load, and prevent flooding the page with columns.

  • Column Summaries: (Number fields) Add summaries to the bottom of each column: Sum, Average, Min, Max, or Median.

  • # of Decimal Places: (Currency and measurement fields) Choose the number of decimal places. Options: 0-8 or use the field’s metadata to determine the number of decimal places.

  • None Option Label (Picklists fields) : In a picklist field, there is a “none” item for instances when the user doesn’t choose any of the picklist’s options. This property changes the label for that “none” item.

  • Limit # values to: For reference fields rendered as picklists, restricts the number of allowed values on the picklist.


    The default behavior displays all values for the field. However, if the field includes a large number of distinct values, the page may need to query a lot of data, resulting in a slow page load. Limiting the number of picklist options reduces the query and load time.

  • Show Length Counter (Textarea fields): When the field is in Edit mode, it displays a character countdown (“25/ 128”) indicating the number of characters used and how many total characters are allowed.


    • The counter is enabled by default for standard textarea fields.
    • The counter is not available for Salesforce rich text area fields.
  • Rows to Display (Textarea fields): Controls number of visible lines of text in a text area field. If blank, text area will auto fit.

  • Template: (Template fields) Specifies which fields the template field should include by either selecting them from the field picker, manually entering their merge variables, or using custom text.

  • Allow HTML: (Template fields) If checked, allows the builder to use standard HTML markup in the template field.

  • Sort Field: (Template fields) When sorting is enabled for the table, specifies which of the template’s fields to use for sorting.

  • Delimiter: (Child relationship fields) To increase readability when using multiple child relationship fields in a column, separates the fields with punctuation. Common delimiters include:

    • Comma (,)
    • Semicolon (;)
    • Dash (-)
    • Period (.)
    • Pipe (|)
    • Slash (/)

Search tab [[]]

(For reference fields)

The Search tab is available for reference fields on the Field Editor and on the Table component when the Table or Field Editor is in Edit mode. Search allows end users to search for content from within the model (or from a selected model) when editing a reference field.

This tab lets you format the field search experience. (Looking for standard Search properties? See the Filters and Search tab.)

Search Properties [[]]

  • Option Source:

    • Automatic: Searches for and lists possible content options from within the object the reference field is referencing.

    • Model: Searches for and lists possible content options from any model on the page.

      • Option Model: If using “Model” as the Option source, the name of the model.
  • Display Template: Determines how the reference field’s selected value is displayed. Configure the template with fields (via merge syntax), text, and formatting.

  • Search Template: Deterines how the reference fields display in the search dropdown. Configure the template with fields (via merge syntax), text, and formatting.

  • Visible Rows: Determines the amount of results available from the model (5, 10, 25, 50, Show all)

  • Tokenize autocomplete search: 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 Fields [[]]


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.

  • Use Default Ordering: If checked, no additional sorting is applied to the result of the search.

    • Fields to order records by: If Use Default Ordering is unchecked, sets how the returned items will be ordered using the field name and the order instructions. For example, Name ASC orders the list by name, from A to Z; Name DESC orders the list by name, from Z to A.

If Use SOSL to improve search performance is not checked, Search can be narrowed to individual fields by clicking fa-plus-circle Add New Search Field and then configuring the search parameters

  • Field: The field to use in the search. Use the field picker to select.


    • (Salesforce data sources only) SOQL can search picklist fields and Reference fields, but not long text fields. To search long text fields, use SOSL.
    • Return field in query results: Returns field data, even if the field isn’t searched, and makes that field data available for merge variables
    • Show field in Search Popup: Show a field in the search popup, even if the column that contains the field is hidden on the table.
    • Custom Label: Displays a custom header for the column being searched in the popup.

Search using Salesforce fields [[]]

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.

Filters tab [[]]

(For reference fields)

In partnership with the settings in the Search Tab, the Filters tab lets you create Lookup Filters to limit the search/display content provided when editing reference fields.

Click fa-plus-circle Add New Lookup Filter and set the following properties for Lookup Filter conditions:

Set the following properties for Lookup Filter conditions:

  • Field: The field in the current model to use as a filter for the searchable reference field.

  • Operator: The relationship between the field and its filter content.

  • Content: The type of value used to filter the reference field’s data.

    • Single specified value: Returns records that meet the specified value.

      • Value: Indicate the value to filter by.
    • Multiple Specified Values: Returns records that meet at least one of the several specified values.

      • Values: Indicate the values to filter by; for each separate value, click Add Another Value.
    • Field from another model: Use a field from another model as the filter for the Lookup field.

      • Source Model: The name of the model.

      • Source Field: Field on the source model.

      • If no row in Source Model, then …

        • Deactivate this Condition
        • Abort this Model’s Query
    • Page/URL Parameter value (Skuid SFX): Returns records that meet the specified Salesforce Lightning page or URL parameter, for example, the id parameter.

      • Parameter: Indicates the specific parameter to filter by.

      • If this Parameter is not provided, then …

        • Set its value to Blank
        • Deactivate this Condition
        • Abort this Model’s Query
    • Running user attribute: Returns records if the value of a field on the model matches the value of a field on the current user’s record.

      • Userinfo Property: The value on the current user’s record to be used as a filter, usually an Id property. Options include:

        • Default Currency
        • First Name
        • Last Name
        • Email
        • Locale
        • Name
        • Organization Id
        • Organization Name
        • Profile Id
        • Profile Name
        • Session Id
        • User Id (default)
        • User Name
        • Use Rowl Id
        • User Type
        • Is Multi Currency Org
    • None - blank value: Returns records only if the specified field is empty.

    • Another field from row: Returns records only if the field on the referenced record matches a separate field on that same record.

      • Depends On: Select the field to compare with.

Advanced Tab [[]]

(For date- or time-related fields)

  • Show Month Picker: If checked, a Month picker is displayed during Edit Mode, to make it easy to jump to a specific month.

  • Show Year Picker: If checked, a Year picker is displayed during Edit Mode, to make it easy to jump to a specific year.

    • Year Picker Lower Bound and Year Picker Upper Bound: Sets the upper and lower boundaries of the list of possible years. Options include:

      • “Selected” measures from a date selected on the Date Picker. Increments are 1-10, 20, 30 40, 50, 60, 70, 80, 90, and 100.
      • “Today” measures from the current date. Increments are 1-10, 20, 30 40, 50, 60, 70, 80, 90, and 100.
  • Show Today Button: If checked, the month/year pickers include a Today button that allows users to quickly jump to the current date.

  • Minute Picker Increment: For editable date-time fields, select the minute increments (1, 5, 10, 15, 20, 30) for the displayed Time Picker.

Display Logic tab [[]]

Standard display logic options are available.