Four different connector states
A connected account is only the first layer of an integration. CloseSpan reports the remaining layers separately so an operator can tell whether source records have actually arrived and whether any write action is available.
- Authorization
- The provider account has completed a hosted connection flow and is associated with the workspace
- Import
- CloseSpan can request supported records and persist normalized workspace data
- Synchronization
- A background process keeps supported source records current without a manual pull
- External action
- A provider write is implemented and remains behind the required review and approval
Feedback sources
Feedback sources bring customer evidence into the CloseSpan inbox. Authorization alone does not populate feedback.
- Zendesk
- Pipedream authorization and a bounded manual ticket pull are implemented. Continuous sync and Zendesk writes are not implemented.
- Intercom
- Pipedream authorization is implemented. Conversation import, continuous sync, and Intercom writes are not implemented.
Engineering destinations
Engineering destinations receive or enrich approved product work. They are not treated as customer-feedback sources unless a separate import capability is implemented.
- GitHub
- Pipedream authorization is implemented. Repository ingestion, live issue creation, pull-request creation, release sync, and approval-bound writes are not implemented.
Managed authorization
CloseSpan uses Pipedream Connect for multi-tenant provider authorization. Each CloseSpan organization maps to a Pipedream external user, while Pipedream stores provider credentials and hosts the connection interface.
Workspace members should still review the exact provider account and permissions shown during authorization. CloseSpan connector pages describe intended data use, but the provider authorization screen is the source for the scopes presented by the configured app.
Unsupported and custom sources
The authenticated product also contains a custom webhook intake path for systems without a supported native importer. Use of that path should be scoped around a documented payload, signed request verification, and only the customer evidence needed for the workflow.
Additional catalog entries may appear inside the application before their import or action adapters are complete. The detailed connector status, not the presence of a catalog card, determines whether a capability is live.