PurpleSuite Build Reference

PurpleSuite provides mock enterprise SaaS APIs and seeded data for Agent Studio development. This reference assembles the feature-request capability you built throughout the masterclass.

The completed build contains:

PurpleSuite connector
  ├── List feature requests HTTP action
  ├── Get feature request HTTP action
  ├── Update feature request HTTP action
  ├── Feature request dynamic resolver
  ├── Status static resolver
  ├── Update feature request compound action
  ├── Conversation process
  └── Conversational plugin

Explore the Live API Contract

Select Community, then inspect the instance-based GET /feature_requests, GET /feature_requests/{id}, and PATCH /feature_requests/{id} operations.

The catalog and operation schemas come from the current PurpleSuite codebase, so new systems and fields can appear without rewriting this page.

Move <a live feature request name> to Planned.

Phase 0: Create a PurpleSuite Instance

Complete PurpleSuite Setup to:

1. Create an instance with sample data.
2. Copy the temporary PAT and instance ID.
3. Create an API-key connector.
4. Verify the connection with a read-only request.

You can use either connector boundary:

https://marketplace.moveworks.com

/api/purple-suite/community/feature_requests

The narrower base URL reduces the destinations compatible actions can reach. The broader connector is convenient when one build intentionally uses several PurpleSuite systems.

Phase 1: Build the Read Actions

Create an HTTP action named List PurpleSuite feature requests.

PurpleSuite list operations return a structured envelope:

{
  "data": [
    {
      "id": "FR-1042",
      "name": "Bulk edit requests",
      "currentStatus": "New",
      "productArea": "Admin"
    }
  ],
  "nextCursor": null,
  "total": 1
}

Keep the list envelope in the HTTP action’s response schema. The dynamic resolver will transform response.data into candidate values in the next phase.

Create another HTTP action named Get PurpleSuite feature request:

Checkpoint

The list action returns the documented { data, nextCursor, total } envelope. The get action returns one requested record.

Phase 2: Build the Resolvers

Dynamic Feature Request Resolver

Create an object slot named selected_feature_request.

Configure a dynamic resolver that:

1. Calls List PurpleSuite feature requests.

2. Maps the resolver output directly to a candidate list:

   MAP():
     items: response.data
     converter:
       id: item.id
       display_name: item.name
       current_status: item.currentStatus
       product_area: item.productArea

3. Configures cardinality to interpret the output as a list of candidate values.

4. Uses display_name as the useful display field.

5. Preserves id, current_status, and product_area.

The user can refer to a request naturally while the selected slot retains the exact record ID.

Static Status Resolver

Create an object slot named target_status.

Use a static resolver based on the current currentStatus enum shown in the live OpenAPI schema. Do not copy an older list from another quickstart without checking the spec.

Add a DSL validator when your business flow allows only a subset of transitions.

Checkpoint

Test:

• One exact request name.
• An ambiguous phrase that matches several requests.
• A phrase with no matching request.
• Each allowed target status.
• A status excluded by your business rule.

Phase 3: Build the Write Action

Create an HTTP action named Update PurpleSuite feature request.

Configure the request from the live PATCH /feature_requests/{id} schema.

Endpoint:

/api/purple-suite/community/feature_requests/{{{feature_request_id}}}

Example body shape:

{
  "currentStatus": "{{{new_status}}}"
}

Keep the exact property name and enum values defined by the current OpenAPI schema.

Checkpoint

Test the action against non-production sample data. Confirm that the selected record changes and the action returns a useful updated object.

Phase 4: Compose the Backend Workflow

Create a compound action named Update and verify feature request.

Declare:

feature_request_id:
  type: string
new_status:
  type: string

Add steps:

Example return:

- return:
    output_mapper:
      feature_request:
        id: data.verified_feature_request.id
        name: data.verified_feature_request.name
        status: data.verified_feature_request.currentStatus
        product_area: data.verified_feature_request.productArea

Checkpoint

The compound action exposes one result. The internal write and verification responses do not leak into the caller’s contract.

Phase 5: Build the Conversation Process

Add:

1. selected_feature_request object slot with the dynamic resolver.
2. target_status object slot with the static resolver and validation.
3. Confirmation before the write.
4. An action activity that calls the compound action.

Input mapping:

feature_request_id: data.selected_feature_request.id
new_status: data.target_status.value

Output mapping:

updated_feature_request:
  id: response.feature_request.id
  name: response.feature_request.name
  status: response.feature_request.status
  product_area: response.feature_request.product_area
display_instructions_for_model: >-
  Confirm the feature request name and new status.
  Include the product area. Do not mention internal implementation steps.

Checkpoint

The process collects both values, confirms once, performs the backend sequence, and returns one concise result.

Phase 6: Publish the Conversational Plugin

Use:

Add at least five varied positive triggering examples and negative examples for nearby project-management or ticketing capabilities.

Launch to a test group and try:

Move <a request returned by your resolver> to Planned.

Optional Phase 7: Reuse the Backend as an Ambient Agent

Create a separate plugin with a webhook or scheduled trigger. Map an event body containing feature_request_id and new_status directly into the same compound action.

This variant demonstrates reuse:

• Same connector.
• Same HTTP actions.
• Same compound action.
• Different trigger and no conversational slots.
• No automatic meta_info.user.

Add notify only when the result must reach a resolved user.

Lab Review

You have built one capability from modular contracts:

API schema
  → connector trust boundary
  → focused HTTP operations
  → resolvers and typed slots
  → deterministic compound workflow
  → user-facing conversation process
  → plugin retrieval and launch

Continue to Test and Operate.