Apps and integrations
Find apps, interpret route and action readiness, and identify the connections required before a workflow can move beyond a draft.
Apps and integrations
Apps and integrations describe which systems Workflow Agent can recognize and how a draft might reach them. Use the directory to discover app relationships, then inspect route, connection, and execution states before relying on an action. Recognition, draftability, simulation, and live execution are separate capabilities.
Discover apps
The app directory is built from the currently loaded app and app-pair source. Workflow Agent prefers a production Zapier-derived CSV and can use a smaller fixture when that source is absent. The directory therefore changes with the environment; do not treat a visible count as a permanent platform total.
Search or browse for the source and destination involved in your workflow. A pairing indicates that the data foundation knows about a relationship between the apps. It may provide sample capabilities, route suggestions, or a template starting point. It does not create a connection or prove that an action can be executed.
When an app is missing, first determine whether the loader is using the fallback source. A missing entry can be a catalog limitation rather than a statement that the product will never support the app. Keep the workflow description, but do not invent a connector or substitute another app silently.
Supported actions
An action is meaningful only when its state and route are understood. The integrations data can include native connectors, generated connectors, bridge providers, webhook or HTTP concepts, and MCP configuration. Some of these exist solely as definitions or previews.
Use these questions to interpret an action:
| Check | Meaning |
|---|---|
| Is the action described? | The catalog or draft can name the operation. |
| Can a draft include it? | canDraft is true for the current relationship. |
| Can it be simulated? | canSimulate allows a no-write preview. |
| Is it executable? | canExecute and all route, credential, policy, and approval gates would need to permit it. |
Generated connector cards can explicitly set canExecute: false. Bridge entries may be dry-run ready, config-preview only, live-blocked, or disabled. A native label in the route data should still be read with the current connection and environment state.
App readiness
Route status describes the maturity of the path; execution route names the mechanism that might carry it. For example, bridge_available can pair with a specific bridge route, while api_mcp_possible can identify an API or MCP option that still lacks configuration.
The canonical route statuses are suggested_only, bridge_available, api_mcp_possible, native, and coming_soon. Candidate execution routes include native, named bridges, webhook, HTTP API, MCP, generated connector, and none. Because UI labels may shorten these terms, preserve the underlying value when documenting a result.
Readiness can also depend on loaded credentials, connector review, simulation results, and approvals. A configured credential is not proof that the app is reachable. A successful dry run does not authorize live work. A coming-soon route should remain unavailable even if the app appears in a template.
Connection requirements
Connections associate a workflow route with the configuration or identity needed to reach an app. The integrations surface groups credentials, bridge providers, generated connectors, native connectors, MCP servers, and webhook or API-route concepts so that their states can be inspected together.
A draft may be useful before a connection exists. When a step reports needs-setup, identify the route it expects and open the matching integration area. If a credential is marked expired, replace or renew it through the supported connection process before relying on another simulation. Exact labels and rotation controls remain subject to interface review.
Never paste a secret into the workflow description or step input. App-directory evidence does not establish a complete public contract for credential encryption, retention, or deletion, so those topics remain under security review.
Limitations
The current directory cannot be used as a universal support matrix. App availability depends on the loaded source, and an app pair may be present only for suggestion or drafting. Live webhooks, outbound webhook delivery, MCP calls, automatic connector activation, and universal app coverage are not verified.
The product can expose route candidates before the route is usable. It can also show a connection while execution remains blocked by policy, review state, or missing provider setup. Preserve the most restrictive state when several indicators differ.
Counts from seed data, example accounts, and recent-item cards are illustrative. Do not publish them as guarantees. The authoritative outcome for a specific draft is the readiness and gate information shown for that draft in the current environment.
Troubleshooting
| Symptom | Likely cause | Action |
|---|---|---|
| App is absent | Production source was not loaded, fixture is limited, or the app is not represented. | Confirm the source state and keep the draft unresolved. |
Pair appears but route is suggested_only | The relationship is known without an execution path. | Use it for planning; do not claim simulation or execution. |
| Route exists but simulation is blocked | Credentials, policy, approval, or connector review is incomplete. | Open integrations and address the named gate. |
| Connector says config preview or live blocked | The connector definition is inspectable but not executable. | Review configuration only; stop before activation. |
| MCP or webhook tab is visible | The surface exists, but live behavior may be disabled or unverified. | Follow the dedicated boundary guide rather than attempting a live setup. |
When two surfaces disagree, retain the blocked or less mature interpretation and record the inconsistency. Workflow Agent is designed to show uncertainty explicitly; bypassing a readiness warning would make the draft less reliable, not more complete.
Directory source and freshness
The directory should be treated as a view of the source loaded for the current environment. When the loader uses the production-derived CSV, app and pair coverage reflects that file. When it falls back to fixtures, the directory is intentionally smaller. Neither source provides a promise that every app action is current or executable.
A newly discovered pairing can improve draft quality without changing connector readiness. Conversely, an existing connection can become unusable when a credential expires or a bridge is disabled. Review the directory and integrations state together when returning to an older workflow.
Route status examples
native means the data model identifies a native path; it does not waive configuration and policy checks. bridge_available means a supported bridge concept exists, but the bridge can still be dry-run only. api_mcp_possible names a possible family of routes and requires further configuration. suggested_only is useful for design but cannot be treated as a simulation guarantee. coming_soon is unavailable.
Execution-route values provide more detail. A named bridge, HTTP API, webhook, MCP, or generated connector should match the integration panel that reports its state. If the builder and integrations page display different route labels, preserve the blocked result and add a consistency review rather than choosing the more optimistic label.
App-action review
App cards and seed data can list actions that describe the intended relationship. Confirm that the action needed by your draft is present and that the connection has the right direction. Reading from an app may require different permission from creating or updating data. App-directory evidence does not verify a universal permission catalog, so avoid documenting exact scopes unless the current integration shows them.
Direction and action semantics
A pairing can exist in both directions, but the supported actions may differ. Reading records from an app, creating an item, updating an item, and sending a message can require different routes and permissions. Confirm the action attached to the exact step rather than treating the app name as sufficient evidence.
If the directory shows only a general relationship, describe the desired action in the draft and leave its execution status unresolved. Integration-source evidence does not provide a universal action schema for every app.
Generated connector review
Generated connectors can expose metadata and review cards while keeping execution disabled. canExecute: false is a hard boundary. Review the intended request and response shape, credential need, and policy impact without describing the connector as installed or activated.
A review-complete label would not automatically make the route live unless the executable connector store and product state confirm it. This distinction protects against turning generated code or metadata into an operational integration claim.
Bridge-provider states
A bridge provider can be dry-run ready, configuration-preview only, live-blocked, or disabled. Dry-run readiness supports a simulation of route shape, not an external transaction. Configuration preview supports setup review. Live-blocked and disabled require the draft to stop.
Returning to an existing draft
Recheck app and route readiness whenever a draft is reopened. The loaded source, provider configuration, credential state, or connector review may have changed. A previous simulation result records the earlier environment and should not be treated as current availability.
Availability language
Use “represented,” “draftable,” “simulatable,” “configured,” and “executable” precisely. An app can be represented without a route, draftable without a connection, and simulatable through a dry run while live execution remains blocked. This vocabulary prevents a directory entry from becoming an accidental support promise.
When to stop
Stop when the required action has no route, the route is coming soon, the connector cannot execute, or the security model is unverified. Record the exact limitation in the draft rather than substituting a different integration silently.
Directory changes
An app or route can appear, disappear, or change state when source data is refreshed. Existing drafts should therefore be revalidated before review. A prior directory screenshot cannot establish current readiness, and a changed count does not by itself indicate a product defect.