Create and configure models¶

Create a model¶

Create a model

You can create as many models as the application needs—even multiple models that point to the same external system.

1. Click Models in the Elements panel.
2. Click the Add a model.
3. Fill out the model’s basic properties:

• Under Model Id, give the model a practical name, one that is distinctive enough to distinguish it from others on the page.

  Note

  This Model ID is not visible to end users. Use Model description for additional details.

Customize a model¶

Customize how the model behaves by using model properties, fields, conditions, and actions.

• Model properties control essential model behaviors, like which object to query.
• Fields specify which record attributes are available in the model.
• Model conditions limit or filter the specific records that are pulled into the model.
• Model actions trigger action flows that run automatically when model-level events occurs.

Manage models¶

Change the order of models on the models list

Click, drag, and drop models to reposition them within the Elements panel.

Create Form

1. Click Models in the Elements panel. This displays the models list.
2. Click More options > Create Form next to the model you want to use. A Form is added to the bottom of the canvas.
3. Click Add fields.
4. Select the fields you want to add to the Form.
5. Click Done.

For more information, see Form.

Create Table

1. Click Models in the Elements panel. This displays the models list.
2. Click More options > Create Table next to the model you want to use. A Table is added to the bottom of the canvas.
3. Click Add fields.
4. Select the fields you want to add to the Table.
5. Click Done.

For more information, see Table.

Duplicate a model

Duplicating makes an exact copy of the model (including properties, fields, conditions, and actions). This is useful when you have a model that you want to duplicate and revise, without affecting the original model.

1. Click Models in the Elements panel. This displays the models list.
2. Click More options > Duplicate next to the model you want to duplicate.

The duplicate appears at the bottom of the models list. Duplicated models default to the name of the original model with a “1” appended. For clarity, remember to assign duplicated models a unique name to help distinguish between it and the original model.

Delete a model

1. Click Models in the Elements panel. This displays the models list.
2. Click More options > Delete next to the model you want to delete.
3. Click OK. The model and associated components are removed from the page.

Dependent and principal models¶

Models can only go one “layer” deep within a response returned by a connection to provide rows to components. But by using another model—a dependent model—nested array data can be accessed as rows.

A dependent model is used to access data within array fields and child relationships on the object of a principal model. The principal model is the model containing the array or relationship a dependent model is made from. Dependent models appear nested in a tree-like visual beneath their principal model in the Models tab.

A dependent model may also be the principal model for a further nested dependent model. The maximum dependent model “depth, ” the amount of nested data that can be accessed, varies by connector.

Consider this example response detailing an account record, with contacts provided as an array field on that account:

{
  "name": "Example business"
  "industry": "Technology"
  "contacts": [
    {
      "name": "Alan",
      "preferredComms": "email"
    },
    {
      "name": "Alice",
      "preferredComms": "phone"
    },
  ]
}

A typical model could only access the name and industry fields shown above. But by creating a dependent model on the contacts array, the additional records can be used within the page.

Dependent models can be used much like any other model—with data, condition, and model action options all available. However, these models are “dependent” on the data within the principal model, only retrieving rows from arrays within the principal. This is because dependent models rely on the network requests of the principal model, so using them does not require additional network traffic.

Because of this, dependent models cannot be queried independently of their principal models. Anytime a principal model is queried, it updates the available rows within the dependent model. In the same way, If you require only certain data from the dependent model appear, consider using conditions.

Best practices¶

• When creating models, consider both the data users need to access and the experience you want to offer those users.

• Model order matters: Models load in the order they’re arranged in the models list: models at the top of the list load first. When a model is dependent on another for data, ensure that dependent model loads after the primary model. If necessary, re-order the models.

• If much data is needed from a particular object, consider creating different copies of the model for particular components or usage on the page.

• Set a Max # of records to a smaller number: Generally, users only really need to see around 10 records at a time; more records may present too much information to process, and in many cases they can load more records using pagination options.

• Uncheck “Query on page load” to load models only when needed. Unchecking this property allows components and user action to determine when model data is loaded. This prevents all of the page’s models from loading at the same time during the initial page load, which is especially valuable for pages with numerous models.

• Don’t specify Fields to order records by. If you need to use this feature, only specify indexed fields. Ordering by a non-indexed field will make the page run slower.

  Note

  Some databases support the creation of indexes for fields. To determine if the database you are using supports field indexing, see the database’s documentation.

Properties¶

Models for some data source types may have unique properties not documented here. These properties are detailed in the topics for those respective data source types.

• Model ID: The unique name by which components refer to this model. Each model must have a unique name within one Skuid page. If other pages are included within that page—such as through the Page Include component or dependent pages—then the models in those pages must also have unique names.

• Data source type: The data source type <data/> to use for this model, which narrows the selectable options in the Data Source property.

• Data source: The data source <data/>—a connection to a system that has been configured by the Skuid builder—that the model uses to access records.

• Model Object / Entity: The data object to pull data from. The label for this property can vary based on data source type, but they all mean the same thing:

  • External Object Name
  • Model Entity
  • Salesforce Object Name

• Model behavior: Some data sources allow the builder to select a specific type of model behavior:

  • General: The default Skuid model.
  • Aggregate: A model that collects, groups, and summarizes multiple data records into a single end result, such as a sum or a count.
  • Read-only: (REST data sources) A model that can only query (and not update) data.
  • Read/Write: (REST data sources) A model that can use multiple data source URLs for different data operations.

• Query on page load: If unchecked, no data rows are loaded into the model when the page initially loads. Uncheck this box to use this model to create new records, or to load this model later via the Action Framework (for example, opening it in a drawer, popup, or tab).

• Allow Page Render Before Query Completes: Controls whether Skuid must finish loading the metadata for the model before rendering the Skuid page. (Only available if Query on page load is checked.) By default, Skuid loads metadata for every model prior to rendering a page, even those without visible UI components. A model containing a picklist with hundreds or thousands of values could extend page load times, especially if there are many models on a page. Use this property to tailor which models have a higher priority, giving users access to the most meaningful data and UI elements first.

  • When unchecked, the model is considered synchronous—meaning it is given priority and its query must complete before the page renders.

  • When checked, the model is considered asynchronous, and the page will render even if its query is not yet finished.

    Note

    This model property is unavailable for server-side models.

• Max # of records (limit): The maximum number of records that will be pulled in to this model when it is queried. The smaller this number is, the faster your page will load, but the less data available within the page.

• Fields to order records by: Determines how records are sorted in the model using a field name and a sort command. To order records:

  1. Click Add fields
  2. Select fields to sort by.
  3. Click Apply.

  After selecting the fields, choose one of two available sort commands to arrange each field by:

  • Ascending: Records with higher values, either alphabetically or numerically, appear at the bottom of the record list. If no sort option is specified, ascending is assumed.
  • Descending: Records with higher values, either alphabetically or numerically, appear at the top of the record list. You can use sort statements on each field, which are applied in the order they are listed.

  For example, to sort a model’s rows alphabetically in ascending order by the Name field and then in descending order by the Number field, enter:

  • Name: Ascending
  • Number__c: Descending

  If used on a Salesforce model, this property supports the NULLS FIRST and NULLS LAST syntax.

• Create default row if model has none: When checked, a new record will automatically be created if there are no records within the model on page load. Useful for “Create New Record” pages.

• Prevent users from leaving page if this Model has unsaved changes: When checked, a dialog box will appear to prevent users from leaving the page if there are unsaved changes in this model. If unchecked, users can leave freely but may potentially lose data changes within this model, so determine the best behavior for your use case.

• Model label: If the model’s selected object does not have a singular label—such as Account—this property can be used to specify one. However, if a label is specified for the object within the data source this property has no effect. (Correlates with the {{Model.label}} merge variable for a model.)

• Model plural label: If the model’s selected object does not have a plural label—such as Accounts—this property can be used to specify one. However, if a label is specified for the object within the data source this property has no effect. (Correlates with the {{Model.labelPlural}} merge variable for a model. Commonly appears at the bottom of paginated components—like Tables or Decks—and in Page Title components.)

• Defer rendering: When checked, fields specified by the data source type or marked in the Fields to Defer property will load asynchronously—meaning all other fields in the model may load and display in any components as soon as they are loaded. Deferred fields display placeholder text while they load and do not prevent other fields from rendering. Useful for fields that may incur longer load times, such as image fields or other binary files.

  Note

  While some data source types allow for deferred fields to be specified, some will not. For data source types that do not, the Fields to Defer property will not appear.

• Fields to defer: Available for some data source types, this property sets which fields should load asynchronously. Requires Defer Rendering to be checked.