Test before enabling

Prepare a representative record#

Save the Action as a draft, then open it to see Test before enabling. Use inputs that your endpoint can actually resolve. For private operations, the admin test accepts a test customer email directly; normal visitors must verify their own address through the widget.

For an order lookup, choose an existing order with a known email and a second record owned by someone else. For a write, create a disposable record in a sandbox and decide how you will clean up or reverse the operation. Do not use a test to discover whether a refund or purchase endpoint has side effects.

Use a fixture with a known expected result. If the test order has an unknown fulfillment state, a plausible card cannot tell you whether the endpoint returned the right record or mapped the right field.

Run the exact saved revision#

Enter the defined fields and, when required, the test email. A write test includes a separate checkbox acknowledging that it will submit a real request. Select Run test only when the destination and inputs are safe to use.

Test requests are identified separately in activity. Reesponder claims a test run once and preserves its result for repeated requests with the same test identifier. Do not interpret a browser timeout as permission to create another write. Inspect the run and destination first.

Once the portal has received a completed test result, another Run test starts a new attempt. A newly completed write test can therefore create another real operation. The earlier test's replay protection is not a blanket guard against deliberate new tests.

Inspect the result rather than only the status#

A successful test must return the intended customer fields. Check spelling, currency, dates, references and links. Confirm that internal notes, contact addresses and provider credentials are absent. An endpoint can return valid JSON while a mapping points to the wrong field; use a record whose expected output you know.

Check a missing record and an unauthorized record too. Neither should disclose someone else’s information. Confirm your server rejects missing or incorrect service credentials. For writes, replay the same idempotency key in your endpoint’s own integration test and verify that it returns the prior result without another mutation.

Review ordinary negative business outcomes too, such as an unavailable appointment or a return awaiting review. The result should match the provider's actual state, not force every normal answer into either “success” or an unexplained technical error.

Enable only after the current test succeeds#

A successful run marks the current saved revision as tested. Select Enable action to make it available for that website. A later save pauses it and requires another test. This includes changing the description, inputs, result mappings, credential or endpoint.

The runtime also checks active plan access and website state when it executes. An old successful test does not override a later plan change, archived website or paused definition. If the Enable control is unavailable, inspect the current revision’s latest test rather than relying on a screenshot of an earlier success.

If the destination changes without changing the saved Action, your old test cannot predict the new provider behavior. Review and retest after relevant adapter or provider releases even when the portal configuration itself has not changed.

Verify the actual widget journey#

After enabling, ask a realistic question from the installed website. Confirm the assistant selects the intended task, collects the required fields, asks for email verification when needed and presents a clear write confirmation. Cancel one proposal and verify that it creates no external operation.

Complete an allowed read or a disposable confirmed write, then inspect Actions → Activity & requests. Match the run reference with the destination. Test records are removed after 24 hours; visitor records follow conversation retention. A portal test is a connection check, not proof that every possible customer request or provider permission works.

Private test in the website workspace is a separate Knowledge preview. It does not replace these Action tests or prove live email verification, customer confirmation and destination behavior.

Worked example: release an order lookup#

Prepare a controlled order with a known reference, owner email, payment state and delivery state. Save the lookup draft and run a portal test with the matching email. Compare every returned field with the real order. This verifies destination access and mappings using an administrator-supplied identity.

Run the same reference with a different controlled email. The native adapter should return order_not_found; a custom adapter should return its authorized non-disclosing outcome. Test a nonexistent reference separately so staff know that a not-found result is not always an infrastructure failure.

After enabling, open the installed public storefront, ask for the order status, enter the reference and complete the code verification with your own mailbox. Check that the assistant selected the intended task and that the resulting activity belongs to the correct website. This covers the actual visitor path, which the portal test intentionally does not reproduce.

Keep a short record of these cases and repeat them when the endpoint, credential, mapping or provider connection changes. Use the expected fixture to detect a genuine regression rather than relying on an earlier successful screenshot.

What must be true before enablement#

The current saved revision has a successful test with known output; ownership and failure cases behave correctly; the provider contract is documented; and writes have a tested replay guard. Your team knows where to find the real destination result and how to handle unknown outcomes.

Then verify live task selection, customer input collection, code delivery and confirmation. Record any remaining unsupported route or provider limitation. Do not enable a broad operation merely because the one fixture that you happened to try worked.

Use a small, deliberate acceptance matrix#

Create one row per behavior you need to prove. Include the fixture, expected result, actual result and whether you checked the destination. A useful read matrix covers valid owned records, wrong owners, missing records and unavailable providers. A write matrix additionally covers cancellation, duplicate replay and an uncertain reply.

For field validation, include a blank required value, a missing optional value and a string that your endpoint rejects on business grounds. For output mapping, include a response with an absent field or a nonscalar value. These cases show whether the contract is deliberate rather than merely tolerant of one happy-path object.

Keep transport tests separate from business tests. A timeout, invalid JSON and a normal “not eligible” result have different implications. Use disposable fixtures and controlled endpoint behavior to test failures, particularly when a write could otherwise affect a real customer.

Some checks belong in your developer's automated adapter tests, such as concurrent requests with one idempotency key. The portal proves the saved Action can use that contract; the storefront proves the supported customer journey. Use all three levels rather than asking one portal result to establish every property.

Plan write tests and cleanup before pressing Run#

A write test uses the real saved provider and submits a real request after its acknowledgement checkbox. If your endpoint points to production, the test can affect production. Use a sandbox adapter or a disposable record with explicitly understood consequences. An Action label saying “test” does not change the destination's business behavior.

Decide how you will remove or reverse the fixture if that is supported. A return-request test may need a staff resolution; a booking test may need a provider cancellation; some operations cannot simply be undone. Avoid using money, stock or customer communications casually as test data.

If the portal loses the response, inspect the existing run and destination reference before changing inputs or starting again. The same pending attempt can retain its test identifier for a lost response, but a new completed attempt has a new identifier. It can make a second mutation if you press Run again.

After checking the recorded outcome, clean up through the owning system's supported process. Test activity is removed after twenty-four hours, which does not remove or reverse a destination record. Keep the evidence you need in your controlled release record without copying secrets or unnecessary private data.