Plugin Workspace Guide
Overview
-
Developers will set up their
Actions
(API calls) in the
Action
Library.
-
Developers will chain these
Actions
together using a
Compound Action Syntax
(written in YAML, using DSL & JSON Bender for conditions & mapping) in the
Workflow Library.
-
Developers will promote that
Compound Action
to a
Plugin
(providing utterances & launch rules) by clicking the kebab menu (3 dots) in
Compound Action Library.
- 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.
-
Developers will be able to debug the execution of their Plugin in the bot by filtering & viewing
Logs.
1. Setting up Actions
-
Head over to the
Actions
tab and click
CREATE
-
Here you can import an HTTP request via
IMPORT CURL
or set one up manually. Your HTTP Request is made of 2 parts:-
Connector Config
— This includes the base URL & all of the Auth information. Once being creating, it can be reused across any number of Actions.
- See our in-depth Connector Configuration Guide for all of the auth types we support & how to set them up.
-
HTTP Config
— This includes the URL Path, Headers, Params, Body, & Input Variables
- See our in-depth API Configuration Guide for how to setup an HTTP Request.
-
Connector Config
— This includes the base URL & all of the Auth information. Once being creating, it can be reused across any number of Actions.
-
Click
TEST
in order to kick off a Request with the example data you inputted in theInput 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.
- Repeat for an HTTP Request you need to set up
2. Building Compound Actions
-
Head over to the
Compound Actions
tab and click
CREATE
-
Give your Compound Action a
Name
and
Description
, then click
Next
-
Note: Name only letters, numbers, and underscores. We suggest using snake case or camel case formatting (e.g.
Workflow_name
orworkflowName
)
-
Note: Name only letters, numbers, and underscores. We suggest using snake case or camel case formatting (e.g.
-
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:-
Required
— This determines if the slot has to be provided or not
- If Required is left uncheck, then Example Value will be used if left empty by the user
- 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.
-
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.
-
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”
-
Example: If the slot is
- Example Value — This is used as a default value if the user does not provide a slot & Required is left unchecked.
-
Data Type
— This is the data type of the slot that is collected.
- See our reference on Slot Types to view what Data Types are supported.
-
Required
— This determines if the slot has to be provided or not
-
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:
- action: action_id: 508ffb89-667a-43bb-ba4b-8370b843ff53 output_key: get_sha - action: output_key: decoded_content action_id: 450cd6ce-4a66-4c57-8acf-73cdafa13522 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_id: 33bdfb15-5ce4-4f2e-8176-ea6362696ae0 input_args: string_to_encode: data.final_plain_content output_key: final_encoded_content - action: action_id: d8a1cb71-a5a5-4380-91d0-6ed2ba57e974 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
-
Head over to the
Compound Actions
tab and click on the kebab menu (
︙
)
-
Next, click on
Publish as Plugin
- First, verify your Plugin Name & Short description . This is autofilled from the name & description of your compound action.
![image.png]
-
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
-
Click Next and set up your positive and negative triggering examples. This ensures that the bot triggers your plugin given a relevant utterance.
- See our guide on Triggering
-
Lastly, click
Next
and set the Launch Rules you want your plugin to abid by.- 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:
- Check our troubleshooting Guide — Not available for ER2
- Understand your issue using Logs
- 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.