Plugin Workspace Guide

Overview

1. Developers will set up their Actions (API calls) in the Action Library.

   

2. Developers will chain these Actions together using a Compound Action Syntax (written in YAML, using DSL & MW Data Mappers for conditions & mapping) in the Workflow Library.

   

3. Developers will promote that Compound Action to a Plugin (providing utterances & launch rules) by clicking the kebab menu (3 dots) in Compound Action Library.

   

4. Developers will be able to test their Plugin in their copilot. Missing slots will automatically be collected and users can edit any of their provided values through a pop-up form.
5. Developers will be able to debug the execution of their Plugin in the bot by filtering & viewing Logs.

   

1. Setting up Actions

1. Head over to the Actions tab and click CREATE

   

2. Here you can import an HTTP request via IMPORT CURL or set one up manually. Your HTTP Request is made of 2 parts:
   1. Connector Config — This includes the base URL & all of the Auth information. Once being creating, it can be reused across any number of Actions.
      1. See our in-depth Connector Configuration Guide for all of the auth types we support & how to set them up.
   2. HTTP Config — This includes the URL Path, Headers, Params, Body, & Input Variables
      1. See our in-depth API Configuration Guide for how to setup an HTTP Request.

1. Click  TEST  in order to kick off a Request with the example data you inputted in the  Input Variables  tab.

   

   You will see the request response on the left side and the generated output schema on the right. You have the ability to add keys that are missing or remove keys that not going to be used in the output schema. All of the keys in the output schema will be available for you to use in your compound action.

2. Repeat for an HTTP Request you need to set up

2. Building Compound Actions

1. Head over to the Compound Actions tab and click CREATE

   

2. Give your Compound Action a Name and Description , then click Next
   1. Note: Name only letters, numbers, and underscores. We suggest using snake case or camel case formatting (e.g. Workflow_name or workflowName )

   

3. Click on Input fields tab and click the +Add button. Here you will define the slots that you want to collect from users through the conversation and trigger your Workflow with. Each slot requires:

   

   1. Required — This determines if the slot has to be provided or not
      1. If Required is left uncheck, then Example Value will be used if left empty by the user
   2. Name — This is the name you will use to reference the slot in the Compound Action Syntax. It can also be show to the end user if you choose to confirm slots with end user.
   3. Description — This is a description of what the slot is and how it should be collected. This is passed to the LLM so it can understand how to collect the slot.
      1. Example: If the slot is start_date , the Description could be “This is the start date of the end users PTO, make sure the date is collected in MM-DD-YYYY format”
   4. Example Value — This is used as a default value if the user does not provide a slot & Required is left unchecked.
   5. Data Type — This is the data type of the slot that is collected.
      1. See our reference on Slot Types to view what Data Types are supported.
4. Click on the Script editor tab. Here you will be able to build your compound action using the YAML syntax. At a high-level, this syntax provides actions (HTTP Request, APIthon Scripts) and workflow logic (switch statements, for each loops, return statements, parallel, try/catch). See the Compound Action Syntax Reference for more info.

   This is an example workflow that takes a github file, decodes the contents, edits the contents, encodes the contents, and then submits the update:

steps:
  - action:
      action_name: get_sha_data
      output_key: get_sha
  - action:
      output_key: decoded_content
      action_name: decode_sha_data
      progress_updates:
        on_complete: the initial content that was pulled was - {{data.decoded_content.result}}
      input_args:
        base64_to_decode: data.get_sha.content
  - script:
      output_key: final_plain_content
      input_args:
        content: data.decoded_content.result
        new_line: data.new_content
      code: content + "/n" + new_line
  - action:
      action_name: encode_string
      input_args:
        string_to_encode: data.final_plain_content
      output_key: final_encoded_content
  - action:
      action_name: get_sha
      input_args:
        file_sha: data.get_sha.sha
        content: data.final_encoded_content.result
      output_key: final_result
  - return:
      output_mapper:
        link: data.final_result.content.html_url

3. Publishing Plugins

1. Head over to the Compound Actions tab and click on the kebab menu ( ︙ )

2. Next, click on Publish as Plugin
3. First, verify your Plugin Name & Short description . This is autofilled from the name & description of your compound action.

![image.png]

1. Next, decide if you want to check the User consent required before execution? checkbox. This will ask the user to confirm all of their slot values before executing to plugin and is considered a best practice to enable.

![checkbox in Plugin Workspace]

checkbox in Plugin Workspace

End user experience

1. Click Next and set up your positive and negative triggering examples. This ensures that the bot triggers your plugin given a relevant utterance.
   1. See our guide on Triggering
2. Lastly, click Next and set the Launch Rules you want your plugin to abid by.
   1. See our guide on Launch Rules

4. Testing & Debugging

After clicking the final Submit button, your plugin will be published to the bot and triggerable based on your Trigger setup and Launch Rules.

You should wait up to 5 minutes after making changes before trying to test in your bot!

If you run into an issue:

1. Check our troubleshooting Guide — Not available for ER2
2. Understand your issue using Logs
3. Reach out to Support

5. Limitations

If you need any of the following capabilities for your plugin or you're not a Moveworks Copilot user, we recommend building in Paths, Queries, or Events.

• No polling (proactive notifications). Customers still need an iPaaS at the launch of Plugin Workspace to support Events API use cases.
• No content actions. Unlike Paths, you can’t return Text Response, Articles, or Forms. You can only execute actions.
• No branching. Unlike Paths, you can’t “branch” to multiple possible actions, asking different questions along the way.
• Less reasoning controls. Unlike Paths, you can’t disable slot extraction for sensitive questions. Unlike Queries, you can’t provide structured slot extraction examples.
• Less slot resolvers. Unlike query-triggered paths, you can’t build slot resolvers for any business object (e.g. “lookup account in salesforce → change owner”). We only support Users.