Chat¶

Chatting with an AI service¶

To use the Chat component as an interface with an AI service, you must:

1. In Skuid’s admin UI, create a data source for that service.

2. In the Composer, set the component’s Chat source to Data source response.

   Note

   Skuid only shows data sources that support Chat component use; not all data sources appear.

3. Select the appropriate data source.

4. Select the appropriate language model.

Once configured, end users can enter messages, which are then sent to the AI service for processing. The messages returned by that service are displayed as replies within the component.

Chatting with model records¶

The Chat component can render model records as if they were real-time messages. This is intended for objects that have message field, sender name and ID, and date/time fields available. Otherwise the component cannot parse the necessary information to render messages.

Configuring the component’s appearance¶

In addition to the basic interface to send and receive messages, the Chat component has several configurable elements that can appear at runtime:

• Welcome messages: An initial message displayed within the component that appears to come from the AI service. This message is not actually sent from the service and it isn’t sent to the service either.
• Custom error messages: Custom error messages that appear instead of any errors returned by the data source or model network request
• AI display name: The name that appears beside the AI chatbot
• Loading indicator: An ellipses-styled icon to indicate that a message is in transit.
• Avatars: Small images representing the speakers of the conversation—these are determined by the end user’s profile photo. These can be shown by activating the Show avatar property and then configured within the Default avatar (for model-sourced components) or AI avatar (for data source response-sourced components)

General¶

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

• Chat source: Determines where messages are sent to and received from.

  • Data source response: Messages are sent to and from a data source directly—with the data source’s responses displayed as replies.
  • Model: Messages are queried from and stored as model records.

• AI display name: The name that appears beside the responses from the AI service.

• Welcome message: Determines the initial message displayed within the component—appearing to be received by the end user.

• Custom error message: Determines the message to display to the user in lieu of errors returned by the data source or model.

• Disclaimer footnote: An optional label that appears beneath user input providing usage disclaimers. Typically notes a language model’s limitations and the potential for mistakes in its responses.

  For example: <Service> can make mistakes. Check important info.

• Show avatar: Determines whether or not avatars appear beside at runtime. When enabled, avatar properties are available in the Default Avatar/AI avatar tab.

If chat source is set to data source response, then the following properties appear:

• Data source: The data source to send messages to and return responses from.
• Language model: If multiple language models are available from the data source, the one to send messages to.
• System prompt: A prompt to determine how the LLM should behave in each response—typically used to designate desired behaviors, domain expertise, and tone of the LLM. The end user is typically unaware of the system prompt’s contents.

If chat source is set to model, then the following properties appear:

• Model: Determines which model to use.

• Message field: Determines which model field to use as the message body.

• Role field: Determines which model field declares the role of the sender in each message. AI services typically use values like user to represent the end user and assistant to represent the AI service.

• Date/Time field: Determines which model field to store sent/received time stamps in.

• Sender role: Determines the value set for the Role field for each message sent by the end user from the component.

  Defaults to user. If using an AI service, consult the service’s API docs to determine what this value should be set to.

Avatars / AI avatar¶

This tab appears as Avatars for model-sourced components or AI avatar for data source response-sourced components.

• Image source: Determines where to source the image file from.

  • URL: Displays the image available at the specified URL

    • Image URL: The URL of the image to display

      Note

      You may also use merge syntax in the URL field. If a merge model is specified, you can reference fields with standard merge variables like {Name}. If no merge model is specified, you can still use global merge syntax.

      For example, if you host an account’s logo image at a particular URL—perhaps based on account name—and you want it displayed next to a record, you could use a URL like www.YourSite.com/{{$Model.Account.data.0.Name}}

      If you choose to do this, ensure that the variable pulled in by the merge syntax is URL encoded—no spaces.

  • Attachment: Displays an image that has been uploaded and attached to a record within a model.

    Note

    This option only accepts lookup relationship fields that have File as the related object.

    The object must have a custom attachment field created on it.

    • Image field: Click the field picker to select the attachment image’s ID field.

      Note

      You may need to click next to the image field’s name to access and select the actual attachment field ID. You need to select this, not the reference field, for the image component to work

      If the image field is a Photo URL field, use URL as the image source.

    • Static resource: Displays an image stored as a static resource.
      • Resource name: If the file has been correctly uploaded, when you start typing the filename, Skuid will autocomplete.

• Merge model / Model: The selected model provides values for merge syntax or record options for attachments.

Layout¶

• Height Strategy: Sets the way height is determined. Values are set using a number and a sizing unit.

  • Fit to Content: Height adjusts based on what’s needed to fit nested elements.

    • Min height (optional): The minimum height, even when accounting for nested elements.
    • Max height (optional): The maximum height, even when accounting for nested elements.

  • Fixed Height: Sets an absolute height.

    • Height: The absolute height to render at.

• Width strategy: Sets the way width is determined. Values are set using a number and a sizing unit.

  • Fill available space: Width stretches horizontally to the edge of the next parent container—whether that be another component or the entire page

    • Min width (optional): The minimum width, even when accounting for nested elements.
    • Max width (optional): The maximum width, even when accounting for nested elements.

  • Fixed width: Sets an absolute width.

    • Width: The absolute width to render at.

• Overflow x-axis and Overflow y-axis: Determines how to handle nested elements that overflow from within horizontally (x-axis) and vertically (y-axis). These properties and their values mirror their CSS property equivalents

  • Auto: Elements that overflow are clipped and scrollable, but scrollbars only display when elements overflow.

  • Scroll: Elements that overflow are clipped and scrollable, and scrollbars display regardless of whether or not elements overflow.

    Note

    macOS may hide scrollbars regardless of this value, depending on the user’s operating system settings.

  • Hide: Elements that overflow are clipped and inaccessible to the user.

  • Visible: Elements that overflow spill outside of the component without adding a scrollbar.

Display logic¶

Render conditions¶

These conditions govern when an element or component will display.

• Render if…: The conditions that must be met to enable the element’s display.

  • ALL conditions are met
  • ANY conditions are met
  • Custom logic is met
    • Condition logic: The custom logic for grouping and applying one or more conditions.

• If hidden, model field changes should be: (only available on Field rendering tabs) If the field is hidden by conditional rendering, this property determines whether any changes made to this field (via Action Framework or JavaScript) are saved in the model, or canceled.

  Note

  Depending on the needs of your org, it could be bad user experience to update fields without direct user input especially when that user may be unaware of they are doing so.

  • Retained in model (the default)
  • Cancelled

Style variant conditions¶

These conditions govern which style variant is applied and displayed on a component or element.

• Use this Style Variant if…: The model conditions that must be met to enable the styling.

  • ALL conditions are met
  • ANY conditions are met
  • Custom logic is met
    • Condition logic: The custom logic for grouping and applying one or more conditions.
  • Style variant: The style variant to be rendered if condition(s) are met.