Verify an Integration Action

Verify a configured integration action from authorization through target acknowledgement, including rejection, ambiguous delivery, and test cleanup.

Use this guide after First Verified Conversation to verify work outside the conversation. The example is a synthetic appointment change against a scheduling test system. Your integration owner supplies the target contract and fixture; Concurrence does not define one universal appointment-write payload for every scheduling system.

Prerequisites

Have a configured test service, a test integration and endpoint, credentials limited to synthetic records, and permission to inspect the operation's evidence. Choose one fixture appointment, record its starting value, and document how the target can be read back and restored. The integration owner must verify that the selected endpoint has no production side effects.

Decide whether the test uses direct execution or approval-gated integration writes. Approval policies and connector write-back review are different paths. The Review Queue is a separately enabled preview; it is not a prerequisite for every integration action.

Approval authorizes a supported call. Only destination evidence establishes the external outcome.

1. Establish the Contract and Access

Use Integrations to inspect the configured endpoint and its input schema. Verify that the test service exposes the intended tool and that its principal has the required access. Tool Testing explains resolution and the separate integration-endpoint test operation.

Record the service configuration, integration/endpoint identifiers, synthetic target record, proposed old-to-new change, and external read-back method. A test label or a generic dry-run flag is not a universal guarantee that nothing will be written.

2. Test the Action in Isolation

Invoke the integration endpoint's dedicated test operation using the fixture payload that matches its schema. Save the returned result and inspect the target record independently. Classify the result as confirmed, rejected, failed, or unresolved.

A returned success from a tool can describe request acceptance rather than a committed target change. If the target processes requests asynchronously, use its documented completion/read-back procedure. Do not invent a retry or idempotency contract where the integration does not provide one.

3. Exercise the Conversation Path

Start a new test conversation with the configured service and request the same bounded change. Inspect the selected tool, its input, the result, and the resulting agent statement through Conversation detail with tool-call metadata requested where supported.

For an approval-gated call, verify that the target remains unchanged while the write is parked. Review the exact pending payload, record an approval or rejection through the supported decision operation, and exercise the next supported turn. A granted decision alone is not target acknowledgement. Voice approval behavior is not implied by the text/SMS path.

4. Prove the Failure Boundary

Case	Evidence required before passing
Missing or unauthorized input	The action is refused and the target remains unchanged
Reviewer rejects a parked write	No external write; the agent communicates the rejection accurately
Target rejects the request	The actual error is recorded; the agent does not confirm a completed change
Connection fails after submission	The result remains unresolved until target read-back or reconciliation establishes the outcome
Successful target change	Read-back confirms the intended record and value; the agent's statement matches that evidence

An approval consumption can precede an interrupted external call. Verify the destination before any manual retry. Repeating a conversation turn is not proof that a target write will be deduplicated.

5. Save Evidence and Clean Up

Use the evaluation packet to record each case, configuration, conversation, operation, target acknowledgement, and reviewer decision. Restore the synthetic appointment using the target's supported process, close test conversations, and reconcile any unresolved writes before deleting test evidence.

You are ready to extend the workflow when both normal and failure cases have target evidence. Move to managed SMS testing for channel behavior or troubleshooting when the evidence stops at an intermediate stage.