Common Patterns

This guide provides implementation recipes for common nativeMsg experience patterns. Each recipe follows the format: Problem → Normative approach → Complete JSON example → Notes.


1. Greeting Workflow with Quick Replies

Problem: Display a welcome message with tappable reply options when a user initiates conversation.

Normative approach: Define a workflow with the greeting intent and a send action containing a message with a quickReplies array. The welcomeMessageExecute property at the root SHOULD reference this workflow so it also fires on channel invitation.

{
  "name": "Greeting Pattern",
  "welcomeMessageExecute": "greeting",
  "workflows": [
    {
      "name": "greeting",
      "intents": ["greeting"],
      "expressions": ["hello", "hi", "hey", "start", "help", "menu"],
      "actions": [
        {
          "name": "send-greeting",
          "send": {
            "message": {
              "text": "Hi! I am the Acme assistant. What would you like to do?",
              "quickReplies": [
                {
                  "type": "text",
                  "title": "Track an order",
                  "payload": "track_order",
                  "execute": "order-tracking"
                },
                {
                  "type": "text",
                  "title": "Start a return",
                  "payload": "start_return",
                  "execute": "returns"
                },
                {
                  "type": "text",
                  "title": "Store locations",
                  "payload": "store_locations",
                  "execute": "find-stores"
                }
              ]
            }
          }
        }
      ]
    }
  ]
}

Notes: Quick reply chips disappear after the user selects one. Limit titles to 25 characters or fewer. Up to 11 quick replies are allowed per message.


2. Collecting User Input with waitFor and Attribute Storage

Problem: Prompt the user for a specific piece of information and store it for use in subsequent steps.

Normative approach: Use a send action to prompt, then a waitFor action to pause execution until the user responds. Set content to the attribute name. Add a validation action after capture to verify the format.

Notes: The content attribute name MUST match ^[a-zA-Z][a-zA-Z0-9_]*$. Values captured by waitFor are immediately available as {attributeName} placeholders in subsequent actions.


3. Conditional Branching with conditions and goto

Problem: Execute different actions depending on the value of an attribute or the channel type.

Normative approach: Add conditions to each guarded action. Use goto to transfer control to a named action or workflow when a condition is met. Actions without a matching condition are skipped; execution continues with the next action.

Notes: Once a goto fires, remaining actions in the current workflow are not evaluated. Use execute when you need to invoke a sub-workflow and then continue in the caller.


4. Calling an External API with send.request and Mapping the Response

Problem: Retrieve data from an external service and surface the response values in subsequent messages.

Normative approach: Use a send.request action with a response mapping object. Keys in the mapping are JSON response field names; values are the attribute names in which to store them. Specify a fallback workflow for error handling.

Notes: The response mapping object maps top-level JSON response keys to attribute names. For nested structures, use send.populate after storing the raw response to an attribute.


5. Multi-Step Form Using Sequential waitFor Actions

Problem: Collect multiple pieces of information from the user across several turns.

Normative approach: Chain send + waitFor pairs sequentially within one workflow. Each waitFor stores its result in a uniquely named attribute. After all captures, submit or confirm.

Notes: Accepting both "text" and "quick reply" in the data array allows users to either tap a chip or type a free-text response. Each waitFor blocks execution until the user responds or the timeout fires.


6. Transferring to a Human Agent Using updateSettings

Problem: Escalate a conversation to a live agent when the user requests it or when automated handling fails.

Normative approach: Set conversation priority to "high", assign routing tags, send an internal note for context, and confirm to the user. Disabling the experience via updateSettings.rcsExperience.enabled: false stops further automated responses.

Notes: Setting rcsExperience.enabled to false prevents further automated responses, leaving the conversation open for a human agent. Re-enable it programmatically via the nativeMsg API when the agent session ends.


Problem: Display a horizontally scrollable set of products, each with an image, description, and action buttons.

Normative approach: Use a send.message with a carousel array. Each entry is a RichCard with title, description, media, and up to 4 buttons. A carousel MUST contain 2–10 cards.

Notes: Each card supports up to 4 buttons. mediaHeight controls the image area: SHORT (~112 dp), MEDIUM (~168 dp), TALL (~264 dp). Carousels are RCS-specific; use a list or sequential text messages as fallback on non-RCS channels.


8. RCS Rich Card with Channel Fallback

Problem: Send a visually rich message on RCS channels while delivering a plain-text fallback on channels that do not support rich cards.

Normative approach: Use the action channel property to restrict rich-content actions to RCS, and define parallel actions restricted to other channels for graceful degradation.

Notes: The channel property on an action restricts execution to that channel type string exactly. Only one of the three actions above will fire per conversation turn, depending on the active channel. This pattern avoids duplicating entire workflows for channel-specific content.

Last updated

Was this helpful?