Action Sequences

Action Sequences let you define sequences of actions at a page level. These sequences can then be reused in Action Framework scripts for model, row, global, and mass actions in Skuid pages (including master pages), or set to listen to specific events.

Properties

The following properties can be found in the Sequence - New Sequence properties pane:

  • Type: Determines whether the sequence will be reusable or triggered.
  • Sequence Name: Give the action sequence a descriptive name.
  • Description: Identify the purpose of the sequence.

Working with Action Sequences

Create a new action sequence

Action sequences can be created within the Action Sequences tab:

  1. From the App Elements pane on the left side of the App Composer, click fa-cogs Action Sequences.
  2. Click fa-plus-circle Add Action Sequence to create a new sequence.
  3. Select the sequence’s Type, which can be:
  4. Add a Sequence Name and Description to identify the sequence.
  5. Add the desired actions.

Note

As your library of action sequences grows, a descriptive name and useful identification of the sequence’s purpose will help you locate the sequence you require.

Edit an action sequence

Edit an action sequence from the fa-cogs Action Sequences pane. Click the sequence name, and then add, delete, or move actions.

Warning

Once changes are made to a reusable action sequence, those changes become part of that sequence wherever it is used.

Clone an action sequence

To make a copy of an action sequence, select its name in the fa-cogs Action Sequences pane, and click fa-code-fork Clone. Rename the sequence and edit the actions.

Reusable Action Sequences

A sequence of action types—available at the page level—that can be called from any other Action Framework script within the pages. Change the sequence once—and those changes ripple through all instances where the sequence is used.

Create Reusable Action Sequences from Existing Actions [[]]

  1. On the Actions tab in a component’s properties pane, click fa-sitemap Convert to Action Sequence to turn any existing list of actions into an action sequence.

    Note

    All actions listed in the action script will be converted into a sequence. It is not possible to pick and choose from the actions to build the sequence.

  2. Name and describe the action sequence. The sequence will now be listed under that name in the Action Framework, and in the fa-cogs Action Sequences pane.

Break down a reusable action sequence instance for editing

If you invoke a reusable action sequence using the Action Framework, but realize you don’t need all the actions in the sequence, the sequence can be broken down into its constituent actions—effectively serving as a template for individual action scripts.

Select the action sequence in the Action Framework and click fa-sitemap Break up into individual actions. This, in effect, changes this instance of the sequence into a script of individual actions, while the original action sequence remains intact. Edit these individual actions as needed.

Inputs

Inputs provide the flexibility to have different properties in each instance of a reusable action sequence. With properly configured inputs, a general set of actions can be configured into a sequence. Then each time the action sequence is called, the various inputs it requires to run can be set at each instance, allowing for incredibly flexible, reusable action sequences.

To add inputs to an action sequence:

  1. Click the fa-cogs Action Sequences pane.
  2. Click the reusable action sequence.
  3. Click the Inputs tab in the Properties pane.
  4. Click fa-plus-circle Add Input.

Properties

  • Name: The name that Skuid displays as an input property on the action sequence wherever it is called. Multi-word names may be used.

    Warning

    • Do not use periods in input names.
    • Whenever possible, do not change input names after their action sequence is used in a page. If you change the names of your inputs, you may need to set them again within each action or dependent input in the action sequence, as well as any individual action sequence instance.
  • Type: Determines where the input property can be used within various action types.

    • Value: For use within any arbitrary value properties.
    • Model: For use within any model properties.
    • Model Field: (Requires a Model type input) For use within any model field properties.
    • Model Condition: (Requires a Model type input) For use within any model condition properties.

Using input values in a sequence

To use the value of an input within the action sequence—for example, to use a Value-type input within a Model Condition-type input—use the name of your input, namespaced within the $Input merge variable, in merge syntax.

For example:

{{$Input.TheInputToUse}}

Note

Ensure that $Input is capitalized.

Whenever the reusable action sequence is called within another action script, the various inputs will appear.

Note

To see an example of inputs in action, see the Inputs How-To: Activate and Set a Condition and Requery Model topic.

Event-triggered Sequences

Within the Action Sequences tab it is possible to create event-triggered sequences, action sequences that will execute when their particular event is published.

Each event-triggered sequence has the following properties:

  • Sequence Name (optional): Plain language name for the sequence.
  • Event Name: The name of the event to listen for.
  • Listen for Events published from: Determines how “far” from the Skuid page this event subscription should listen for events.
    • All active pages and Lightning Components
    • All active pages
    • Only this page (default)
  • Channel: Sets the channel—another event property to further narrow scope—where Skuid listens for events.

Note

If an identically named event is published on a channel other than the one listed in the subscription, that subscription action script will not activate.

Default Published Events

  • Skuid Page: Rendered: Published when a Skuid page has finished rendering. Can be used for page load actions that should occur whenever end users visit the page.
  • Network: Connected: Published when the end user establishes or reestablishes connection to the internet.
  • Network: Disconnected: Published when when the end user loses connection to the internet—potentially triggering offline mode.

The following events are only relevant if offline mode is enabled.

  • Offline Syncing: Started: Published when the offline syncing process begins.
  • Offline Syncing: Conflicts Detected: Published when the end user’s page data conflicts with data on the server.
  • Offline Syncing: Cancelled with Conflicts: Published when the end user cancels an offline sync that would overwrite conflicting data on the server.
  • Offline Syncing: Approved with Conflicts: Published when the end user initiates an offline sync that will overwrite conflicting data on the server.
  • Offline Syncing: Successful: Published when the end user’s changes have been successfully synced to the server.
  • Offline Syncing: Failed: Published when the end user’s changes do not successfully sync to the server.

Interacting with other contexts

Through event-triggered action sequences and the Publish Event action type, it’s possible to set a communicative structure to Skuid pages, allowing them to speak with each other. If using Skuid on Salesforce, you can also use this action type to publish standard Lightning Experience events and communicate with custom Lightning components.

Hotkey-triggered Sequences

Hotkeys, sometimes called shortcut keys, decrease the number of clicks it takes to perform an action. Called at a page level, and configured in the Hotkeys tab of the sequence, hotkey-triggered sequences start a series of actions when a predefined combination of keys are pressed.

Properties

  • Modifiers (optional): The key or keys to be pressed in combination with a standard key, to execute a specified action or set of actions. Though modifier keys are optional, it is best practice to pair a modifier with a standard key to avoid accidental activation of a hotkey-triggered sequence. Modifer keys include:
  • Alt
  • Control
  • Command
  • Shift
  • Key: The standard key that is paired with the modifier to start the action sequence. Standard keys include:
    • Letters A-Z
    • Any arrow key
    • Any function key (F1-F12)
    • Backspace/Delete
    • Delete Right
    • End
    • Home
    • Page Down/Up
    • Tab
  • Ignore Hot Key if end user is typing in input element: If checked, the action sequence will not activate if the user’s cursor is within an input field, such as a Table or search form. This ensures the action sequence is not triggered accidentally and prevents a hotkey from potentially overriding a system-level hotkey combination, like copy/paste or arrow keys.

Voice-triggered Sequences

As their name implies, these action sequences are used to allow voice interactions within the Skuid page. Before using them, it’s best to review several common terms when dealing with voice data systems:

  • Chatbot: The container for the different configurations (intents and slots) that enable voice-based interaction. Chatbots are not typically freeform, and instead are configured with a set of intents to respond to voice input within a given context. A chatbot may be named AccountHandler because it is tailored with intents to update and handle accounts, as opposed to handling opportunities and contacts.

  • Intent: An intent represents the actual intent attached to a phrase spoken by the end user. Searching a model is one intent while creating a record within a model is another. It can be helpful to visualize intents as forms, with lists of fields asking specific questions in order to accomplish a goal.

  • Slot: A slot represents a variable for user input within an intent. If visualizing an intent as a form, then a slot is a field within that form. Slots are commonly written within curly braces to denote their nature as variables.

    For example, a chatbot may ask “Which {model name}?” In that instance, {model name} is the slot.

You’ll need to configure each of the above elements within your voice data system before working in Skuid.

Within Skuid, each voice-triggered sequence is assigned to a specific intent within the page’s selected chatbot, allowing for a specific set of Skuid actions to occur after the chatbot processes a user’s input. Once the end user’s input is processed, the user’s spoken words trigger an action sequence.

For example, a chatbot on a voice data system is configured to process the following vocal phrases as separate intents:

  • Create a new record in {object}
  • Update name on {record} in {object} to {input}

These input scenarios would be facilitated in a Skuid page by separate voice-triggered sequences. Their actions may look like the this:

Skuid will begin listening for vocal input whenever a Listen for a Voice Command action occurs.

These action sequences can be used in different places and can utilize inputs, making them useful and flexible anywhere within a page. However, the features of your action sequences heavily rely on the configuration of your voice data system’s chatbots. Ensure that your chatbots and their intents match their use within the Skuid page.

Properties

  • Sequence Name (optional): Plain language name for the sequence.
  • Intent: The chatbot intent that governs when this action sequence is called. This dropdown list is populated with intents configured within the chatbot selected in the Voice tab of the Page properties pane.

Inputs

Slots are the variables within a user’s spoken phrase expected by the chatbot for an intent, and inputs provide a way to match those slots with a field type Skuid understands.

Once an intent is chosen for a voice-triggered sequence, Skuid generates inputs based on the slots available within that intent. These imported inputs have Name properties that are read-only. However, you must manually set the Type properties of the inputs to match what they represent within a Skuid page.

For example, if you have slot in your chatbot defined as ModelName, then its input’s Type property should be Model. A slot for a ModelField requires its input’s Type be Model Field, a SearchString input’s Type should be Value, and so on.

Properties

  • Name: A read-only field that indicates the slot represented by the input.
  • Type: The Skuid field type the slot relates to, which will affect how it is interpreted. Can be set to one of the following:
    • Value: The slot is a wildcard value meant to match whatever an end user may say as interpreted by the voice data system.
    • Model: The slot is intended to match a model within a page.
    • Model Field: The slot is intended to match a field on a model within the page.
    • Model Condition: The slot is intended to match a condition on a model within the page.

Example Commands

Example commands provide guidance on which phrases to speak to properly activate a chatbot’s intent. When an intent is selected for a voice-triggered sequence, Skuid will import several example commands if some are configured within the voice data system. While these example commands mirror whatever is set within the voice data system, their text can be tweaked within the voice-triggered sequence’s Example Commands tab.

Whenever the Listen for a Voice Command action occurs, the Skuid UI will prompt the end user for input and display a random selection of example commands for all voice-triggered sequences on the page.