> ## Documentation Index > Fetch the complete documentation index at: https://deepline.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Integrations > Provider access, workspace connections, source ingestion, and destination actions. An integration connects Deepline capabilities to a provider or external system. It can supply source data, expose operations, or receive approved changes. Examples include enrichment providers, CRMs, sequencers, ad platforms, and customer-owned databases and warehouses. [Tools](https://deepline.com/docs/tools.md) describes the operations available for these systems. Integrations determine how Deepline reaches the intended account and what access that account grants. One provider can support several operations with different inputs, scopes, and effects. ## Managed access and workspace connections Managed access uses provider credentials held by Deepline where the selected operation supports that access mode. You do not need to connect a separate provider account for those operations. Their applicable pricing is expressed in Deepline credits. A workspace connection uses your provider account. Depending on the provider, an owner or admin authorizes OAuth or supplies an API key or other required credential fields. The connection belongs to the selected workspace, so its members can use the available account access within their permissions. Bring your own keys, or BYOK, is the credential mode that uses your provider account. The provider can bill that account directly. Applicable Deepline usage depends on the selected action and other work in the Play. BYOK does not mean that every part of a workflow is free. Some operations require a customer connection. Others support optional BYOK or managed access only. The tool's current access and pricing contract explains which mode applies. The [credential reference](https://deepline.com/docs/features/bring-your-own-keys.md) describes supported connection forms. ## Permissions and connection state Workspace owners and admins manage connections, including credential changes, enabling, disabling, and disconnecting. Members can use available workspace connections subject to the action's requirements. Provider-side permissions also apply: a CRM connection can only reach records and actions allowed by its account and authorization scopes. Connection state answers whether Deepline has usable account access. An action contract answers what Deepline exposes through that access. Saving credentials does not establish that a particular record exists or that every provider action is available. Available integrations can differ by workspace. Beta integrations require workspace enrollment before their tools and connection options become available. Provider credentials do not grant that enrollment, and enrollment does not expose hidden or internal actions. The web app's [Integrations page](https://code.deepline.com/dashboard/integrations) is the main place to manage account access. Supported CLI, SDK, and API paths use the same workspace permissions. [Connect integrations](https://deepline.com/docs/integrations.md) explains setup and verification. ## Source data and ingestion A direct read retrieves records for an operation. Supported ingestion maintains selected source objects in the workspace Database. Ingestion can have its own object selection, backfill, incremental updates, and status. Connecting an account and configuring those data flows are separate parts of setup. Monitors handle supported provider event feeds, such as job openings. Their events can become source rows for later Plays. A provider connection, an ingestion subscription, and a Monitor each have their own purpose and lifecycle. A [funding poll](https://deepline.com/docs/recipes/poll-funding-updates.md) uses a different pattern: a scheduled Play queries a funding tool and keeps a checkpoint between polls. For example, a team can query ingested CRM accounts in the Database, combine them with new source evidence, and retain enrichment proposals for review. The Database holds those working records independently of any one lookup. [Database](https://deepline.com/docs/data-lifecycle.md) explains the storage boundaries. ## Destinations and write APIs Connected systems can also be destinations. Supported tools can update CRM fields, add recipients to a sequencer, or upload an audience to an ad account. Each action uses the destination's own object IDs, field schema, and permissions. An enrichment result does not automatically change a connected record. A Play must contain the destination operation and the rules that select accepted values. For example, a CRM repair Play can retain a proposed job title and its evidence before applying an approved field update. Writes can also have downstream effects. Adding a recipient to a running campaign may start outreach. The [CRM repair guide](https://deepline.com/docs/guides/crm-data-quality-automation.md) and [sequencer guide](https://deepline.com/docs/features/email-sequencer-integration.md) explain those destination-specific decisions and read-back checks. ## External databases and warehouses A connected warehouse remains in your account. Its connector queries that system using the connected credentials. It is separate from Deepline's workspace Database, which stores Deepline working data. Some database connectors support mutations as well as reads. A read-only database role enforces a read-only boundary where needed. Warehouse semantic queries instead select named metrics and dimensions through the [Semantic layer](https://deepline.com/docs/features/semantic-layer.md). The selected connector's action reference defines its SQL and access behavior. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.