> This page is for Agent Studio.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.moveworks.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.moveworks.com/_mcp/server.

# Publish and Trigger the Plugin

The plugin is the deployable wrapper around the capability you built. It defines **when execution starts**, **what body runs**, and **which access dependencies execution requires**.

## Choose the Plugin Shape

#### Conversational Plugin

A user utterance starts the plugin.

Configure:

* Title and description.
* Positive and negative triggering examples.
* Triggering instructions when the capability needs contrastive guidance.
* A conversation process.
* Launch configuration and access.

#### Webhook-Triggered Plugin

An external event starts the plugin.

Configure:

* Webhook listener and verification.
* Event-to-plugin mapping.
* Trigger input mapping.
* An HTTP action or compound action body.
* Optional notify handoff.

#### Scheduled Plugin

A cron, interval, or calendar schedule starts the plugin.

Configure:

* Schedule and timezone.
* The trigger's **Active** toggle.
* Trigger body.
* An HTTP action or compound action body.
* Optional notify handoff.

## Configure Conversational Retrieval

The Manifest Generator uses plugin metadata to create the model-facing tool description. Write metadata that distinguishes the capability from similar plugins.

### Title

Name the business capability:

```text
Manage Product Feature Requests
```

Avoid implementation names:

```text
Purple Community PATCH Wrapper
```

### Description

Explain what the plugin can do, which records it works with, and important boundaries:

```text
Find a product feature request and update its current status.
Use this plugin when a user wants to view, triage, or move a feature request
to another supported status. Do not use it to create roadmap commitments.
```

### Triggering Examples

Add at least five varied positive examples:

* "Move the dark mode request to Planned."
* "Update a feature request's status."
* "Mark dark mode as delivered."
* "What status is the SSO reporting request in?"
* "Triage my product feedback request."

Add negative examples that clarify nearby capabilities:

* "Create a Jira issue."
* "Show the engineering sprint roadmap."
* "Approve this purchase request."

Examples shortlist relevant plugins. The reasoning engine still uses the description and context to choose among them.

## Bind the Conversation Process

Select the process that:

1. Collects or resolves the feature request.
2. Collects and validates the target status.
3. Confirms the write when required.
4. Calls the compound action.
5. Exposes a concise result.

Test the process directly before relying on plugin retrieval.

## Configure a System Trigger

For a webhook or schedule, map the trigger body into the action or compound action inputs:

```yaml
feature_request_id: data.event.feature_request_id
new_status: data.event.target_status
```

The exact root path depends on the trigger payload schema. Inspect the event in trigger logs and map only documented values.

> **No Automatic User Profile**
>
> A webhook or scheduled run has no conversational `meta_info.user`. Include required identity in the event, resolve it through an action, or run the operation with the connector's shared application identity.

## Use Notify as an Explicit Handoff

An ambient workflow can notify a resolved user and offer a button that starts a conversation.

```text
Webhook or schedule
        ↓
Resolve recipient
        ↓
Compound action notify block
        ↓
User receives notification
        ↓
User selects the action
        ↓
New conversation process starts with mapped inputs
```

The notify block does not retroactively add conversational user context to the ambient execution. User context begins in the new conversation after the user acts. Map ambient data through `conversation_action.input_args`; each key must match a declared slot in the target conversation process. Use `resources` separately when the model needs optional supporting context. Resources do not populate declared slots.

## Configure Launch Access

Check every dependency:

```text
Execution can start
        ↓
Plugin can use its configured body
        ↓
Conversational: process → action
System: HTTP or compound action
        ↓
Nested actions can use connectors
        ↓
Connector credentials can perform downstream operations
```

A failure at any layer can prevent execution.

#### Conversational Access

* Restrict the launch audience to a test group.
* Confirm dependency `Use` access through the process, actions, and connector.
* Confirm the downstream credential's roles and scopes.
* Use Activity Confirmation Policy for consequential writes.
* Test positive, negative, and ambiguous trigger examples.

#### System-Trigger Access

* Publish the plugin.
* For a scheduled trigger, enable its **Active** toggle.
* Confirm dependency `Use` access through the action or compound action and connector.
* Confirm the downstream credential's roles and scopes.
* Do not configure an end-user launch audience; audience settings do not apply to system triggers.
* If a write requires human review, design an explicit approval or notify handoff instead of assuming conversational confirmation exists.

For both shapes, verify that logs do not expose secrets or sensitive payloads.

## Build Along: Publish the PurpleSuite Plugin

Create a conversational plugin with:

| Field            | Value                                                |
| ---------------- | ---------------------------------------------------- |
| Title            | `Manage Product Feature Requests`                    |
| Body             | The PurpleSuite feature-request conversation process |
| Initial audience | A small development test group                       |
| Confirmation     | Required before the status update                    |

Use the description and triggering examples from this chapter, then add at least three nearby negative examples. Publish the plugin and test that:

1. A direct request to update a feature request retrieves the plugin and runs the resolver's list `GET`.
2. A vague reference produces resolver disambiguation.
3. A Jira or roadmap request does not retrieve it.
4. Rejecting confirmation performs no PATCH request.
5. Accepting confirmation runs one PATCH followed by one verification GET.
6. The assistant returns only the verified request name and new status.

Your checkpoint is a published, access-limited conversational plugin that retrieves for the intended language and rejects nearby capabilities.

## Trigger Design Checklist

* One plugin uses one trigger paradigm.
* The title names the capability, not the implementation.
* The description states supported outcomes and boundaries.
* Positive examples cover varied user language.
* Negative examples separate nearby capabilities.
* A conversational plugin binds one tested process.
* A system trigger maps its payload into explicit inputs.
* A scheduled trigger is published and **Active**.
* Ambient execution does not assume a user profile.
* Notify crosses into conversation through an explicit user handoff.
* Access includes every dependency; only conversational plugins use a launch audience.

## Deep Dives

* [Natural Language Triggers](/agent-studio/core-concepts/conversational-plugins/natural-language-triggers)
* [Manifest Generator](/agent-studio/core-concepts/agentic-automation-engine/manifest-generator)
* [Webhook Triggers](/agent-studio/system-triggers/webhook-triggers)
* [Scheduled Triggers](/agent-studio/system-triggers/scheduled-triggers)
* [Connect Ambient Agents to Conversational Agents](/agent-studio/core-concepts/ambient-agents/connecting-ambient-agents-to-conversational-agents)
* [Launch Configuration](/agent-studio/access-control/end-user-access-control/launch-configuration)

Next, compare your assets with the [PurpleSuite build reference](/agent-studio/guides/plugin-building-masterclass/purple-suite-build-lab).