> For the complete documentation index, see [llms.txt](https://docs.distro.so/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.distro.so/data-and-integrations/availability.md).

# Integration availability

A workflow step is ready only when your workspace, connection, and selected provider operation are ready.

Use the connected-resource pickers and **Validate** to identify configuration problems before publishing.

## Check the prerequisites

| Feature                   | What to check                                                                    |
| ------------------------- | -------------------------------------------------------------------------------- |
| CRM matching and writes   | Connected CRM, supported object, property access, and read/write permissions.    |
| CRM triggers              | Event/subscription access, selected object, and start conditions.                |
| Ownership scheduling      | CRM-to-Distro identity mapping and a usable host calendar.                       |
| Slack                     | Connection, destination access, and user mapping for mentions.                   |
| Email                     | Sending setup and recipients.                                                    |
| Enrichment                | Provider key, account usage, permitted scope, and selected chain.                |
| AI Prompt                 | A connection for the chosen model provider.                                      |
| Web Research              | Connected research provider and supported operation.                             |
| Sequence enrollment       | Provider connection, sequence access, sender/mailbox, and operation permissions. |
| Zoom webinar registration | Webinar-capable permissions and a host with the required licence.                |

Some operations need provider access beyond the main CRM or conferencing connection.

## Sequence and webinar dependencies

**HubSpot sequence enrollment** requires the provider's sequence access and an eligible sending user. A standard CRM connection may not carry those permissions.

**Outreach** requires Distro's OAuth app setup for the deployment as well as a workspace connection. Contact Distro support if connection is disabled.

**Zoom webinars** require webinar access and the relevant licence. A connection used for ordinary Zoom meetings does not prove webinar registration is available.

If publication reports a missing capability, resolve it with your admin or Distro support before relying on the step.

## Configuration versus live verification

Validation confirms the configured resources and contracts it can inspect. Simulation checks paths with samples.

Neither proves a real request succeeds against your connected provider. Use a controlled live test and check the actual destination.

If an action is unavailable or disabled, choose a working follow-up action while your admin resolves access.

## Reconnects and changed resources

After replacing credentials, changing scopes, or removing a provider resource, reopen the affected steps, review their connection and selected resources, and validate again.

A previously published workflow can still fail if its live provider access has changed. Use Logs to distinguish missing configuration from a rejected provider request.

## Provider setup guides

Use [Integrations](/integrations.md) for provider-specific credentials, identity mappings, verification behavior and troubleshooting. Check [Provider support by surface](/data-and-integrations/provider-support.md) before sharing a chain between Workflows and Records.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.distro.so/data-and-integrations/availability.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.