# Testing and publishing

Move from a saved draft to an enabled action with a verified customer workflow.

## Overview

A draft stores your configuration. Enabling publishes the action for the selected channels. Complete the checks for your action type before enabling, then verify the result from the customer's channel.

## Before enabling

| Action type | Requirements to review |
| --- | --- |
| Call API | Valid inputs and request, a passing test for the current request, response access, and supported channels. |
| Run client-side code | Input descriptions, the exact host registration, the website setup acknowledgment, and browser channels. |
| Call API + show widget | API requirements plus a linked widget and valid data bindings. |
| Show widget | A linked widget, any necessary inputs, supported channels, and valid automatic rules if used. |

## Run an API test

1. Save the request configuration you intend to use.
2. Open Test and supply representative values for the inputs.
3. Run the test and review its final status and response.
4. Resolve authentication, request, or response problems and repeat the test.
5. Select the fields the AI may read in Data access.

> **Tests can perform real work**: A test calls your configured endpoint. Use a test record or sandbox endpoint when a request creates or updates data.

A successful test is tied to the request configuration. If the editor asks you to retest after a change, do so before enabling. Example JSON is a configuration aid, not proof that the endpoint responds successfully.

## Enable the action

Use Save & enable after completing the required sections. If QwryAI asks for an approval policy for a write action, select a published policy that applies to the operation. Resolve any field or test errors and confirm the action's enabled state in My actions.

![An enabled action](/docs/screenshots/original/qwryai-action-live.jpg)

After Save & enable, My actions shows Read current page as Live on one channel.

## Test as a customer

| Scenario | Expected check |
| --- | --- |
| Matching request | The agent selects the intended action and shows the correct result. |
| Missing required input | The conversation obtains the needed information before proceeding. |
| Unrelated request | The action does not take over an unrelated conversation. |
| Unavailable service or failed handler | The customer receives a useful failure or next step without a false success claim. |
| Client action | The registered function runs on your embedded test page and returns data. |
| Widget action | The card shows the right values and its interactions work. |
| Automatic widget | Conditions, display limits, dismissal, and placement behave as configured. |
| Disabled action | A new matching conversation no longer uses the disabled action. |

## Troubleshooting

| Problem | Next step |
| --- | --- |
| Save & enable is blocked | Review all required fields, selected channels, website acknowledgment, widget association, and API test status. |
| Behavior policy must compile before publishing | Save the draft and reopen it after processing. If the error remains, contact support with the action name and the displayed error. A saved draft is not enabled. |
| The AI does not select the action | Check that it is enabled on this channel and give When to use a precise, relevant instruction. |
| The API responds but the AI lacks data | Review Full or Limited access and the selected response fields. |
| The widget is empty | Compare its input schema with the latest test response and bindings. |
| An automatic widget does not reappear | Check first-visit rules, total and per-visit caps, and dismissal state. |