Connection availability: the provider or integration is not visible, not enabled, or not available in the expected tenant or product surface.

Authentication or OAuth: the connection needs admin consent, user consent, reconnect, or a new authorization grant.

External permissions: the connected account can authenticate but does not have access to the requested mailbox, file, folder, ticket, object, or record.

Hatz permissions: the user may not have the Hatz role, group, feature, or shared-item access needed to use the integration.

Provider error: the external provider or API returns an error, times out, rate limits, or appears degraded.

Sync or freshness: a connected resource has not appeared yet, appears stale, or is missing after setup.

Confirm the integration is listed as supported or available in your Hatz tenant.

Confirm whether the integration uses per-user OAuth, tenant-wide authorization, a service account, or an API member.

Remember that sharing a Workflow or Agent does not necessarily share the creator's external credentials. Some integrations require each user, tenant, service account, or API member to own the connection used for that action.

Confirm the connected external account can access the resource directly in the provider product.

Reconnect the integration if the UI says authorization expired, consent is missing, or the account was changed in the provider.

Confirm the workflow, agent, or tool is using the same connection and tenant context you expect. If an App is involved, troubleshoot the underlying Workflow, Agent, or tool connection rather than assuming the App owns integration access.

Check the provider's status page when the symptom looks like a broad provider outage or degraded API.

Microsoft 365: Outlook, OneDrive, SharePoint, Teams, and admin consent can have different permission and resource-visibility behavior. Confirm which Microsoft 365 surface is involved before troubleshooting.

PSA connectors: ConnectWise, Autotask, Halo, and other PSA systems may depend on the API member, service account, security role, object permissions, and provider-side API availability.

Do not infer support from provider name alone: a provider can be listed, gated, package-dependent, beta, custom, or only supported for specific actions.

Workspace or tenant.

Integration or provider name.

Product surface: Chat, Workflow, Agent, Connections, Custom MCP, API, or another area.

Connection pattern if known: per-user OAuth, tenant-wide connection, service account, API member, Custom MCP, or provider key.

Connected account, service account, or API member involved, who authorized it if known, and whether the affected user is expected to use that connection.

Affected user and whether that user can access the same resource directly in the external provider.

Action attempted, expected result, and actual result.

Displayed error, provider error code, reconnect state, or screenshot.

Approximate time and timezone.

Whether reconnect was attempted and whether it changed the result.

Reconnect succeeds but the same supported action still fails.

The connected external account has provider-side access, but Hatz still cannot access the expected resource.

The same connector fails across multiple users, tenants, or workflows.

The issue includes a provider error, correlation ID, last-failure state, or repeated sync failure that cannot be resolved from setup checks.

You are asking whether an integration, MCP provider, or package-dependent connector is supported and the current docs do not answer it.

Provider availability, scopes, objects, sync intervals, and supported actions depend on the current integration docs and your account configuration.

Do not send raw provider request payloads, access tokens, tenant IDs, customer IDs, external ticket IDs, or secrets in support messages unless Hatz specifically asks for them through an approved path.

A provider error is not always a Hatz bug. Setup, permissions, provider status, and reproducible evidence all matter.