Troubleshoot a connected integration that does not work

When a connected app isn't doing what you expect, work through these in order.

1. Is the action actually added?

Each app's actions are added one at a time — checking availability, booking, rescheduling and cancelling are separate. Anything you didn't add is something the agent can't do.

Open the call flow, click Add next to Functions, and open your app under Connectors to see which of its actions are enabled.

2. Is the app connected at all?

The Connectors section only lists apps that are already connected. To connect a new one, use Connect a new app, which opens Advanced Settings → Integrations. See the Integrations page for what's available to your workspace.

If an app you expect isn't there, it may not be available on your plan or in your workspace — contact support rather than assuming it's broken.

3. Did the connection finish?

Apps that connect by signing in need the call flow saved first, and they take you away to the app's own sign-in page. If you were interrupted, the connection may look started but not be finished — reconnect and complete the sign-in.

Apps that connect with a key need the key pasted exactly, with no spaces. If a key is rejected, generate a fresh one in the app rather than retyping the old one.

4. Is the right resource selected?

Some apps load a list for you to choose from — a calendar, a staff member, a queue. If the list is empty, reconnect the app and open it again.

Others need an ID typed in. There's no list to reload, so an empty result almost always means the ID is wrong. Copy it again from the app rather than typing it.

5. Test it and read the call record

Run a test call and ask for the thing the action does. Open the call record and look at what the action returned. A failure there tells you whether the request reached the app at all, which separates a connection problem from a configuration one.

6. Check inputs, authentication, and the live result

1. Check the account, tenant, environment, and permissions associated with the connection. A rejected or expired credential requires the account owner's help; keep the endpoint's authentication requirements in place while investigating.
2. Compare every required input with the provider's schema. For custom field mappings, use the provider's exact field identifiers and expected types. A friendly display label or a value that only exists after the call can leave an in-call action without the data it needs.
3. Confirm the action's instructions say when to use it, and compare the draft or published version and calling channel used in the failed call. A successful editor test or simulated evaluation does not establish that the live action ran.
4. Reproduce once with synthetic details and a destination your team controls. A test can send a message or change an external record, so choose that destination before starting.
5. Inspect the action's returned result and the external system. Search by the returned record reference, or by the test details and time. An agent saying it succeeded does not establish that the provider created the record.
6. Before retrying a write, check for a partial result, such as a contact created before a booking failed. A timeout can happen after a write succeeds; another attempt may create duplicates.

For a booking, compare the selected calendar, staff member, date, duration, and timezone with the external record. If the slot was taken before booking finished, check availability again. Distinguish a request awaiting office approval from a confirmed appointment.

For a webhook or workflow failure

Check whether the trigger occurred, a run or action started, and the destination accepted the request. Ask the endpoint administrator to inspect the logs at the call time and compare the received fields with the expected payload. If an editor test works but the real event fails, compare their observed requests and calling channels.

Check the configured webhook fallback and retry policy before assuming another delivery will occur. An in-call API action and a post-call webhook are separate operations. See Configure call webhooks for delivery settings and Create a custom API action for request and response mapping.

When to contact support

Include:

• The call reference, date, time, and timezone.
• The workspace, agent, app, connected account, and destination resource. Keep private account references in the private support request.
• The exact action, required input values, calling channel, and draft or published state.
• A short synthetic reproduction and whether the action never ran, returned an error, or reported success.
• The expected result, redacted error or action result, and what the external system actually shows, including partial records.
• Whether the issue repeats, and any redacted external record reference.

If the action is unavailable, describe that as an availability question: an operation supported by the provider's own API may not be exposed by this integration. Never send passwords, credentials, API keys, tokens, or unredacted request headers.