> ## 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. # Understanding provider access > How workspace connections, caller permissions, provider scope, and workflow policy interact. Provider access has several boundaries. A caller is authorized to use a Deepline workspace. The workspace may have a provider connection. That connection has the provider's permissions and supported actions. A workflow then chooses what data to request and what actions to perform. Treating all four as one key hides where an access failure or an unwanted change originates. ## Workspace access and provider access are different A Deepline API key authenticates a caller to the workspace's supported APIs. A provider credential authenticates requests under the relevant provider account. Setting a provider key in a local shell does not send that connection to the hosted workspace. Connections use the provider's supported form or OAuth flow. Some require multiple credential fields. Managed-only providers reject customer credential overrides. Connection creation is restricted to workspace owners and admins. These rules do not mean every authenticated operation has identical permissions. The endpoint and action contract still determine what the caller can do. ## Authorization is not a business approval A CRM connection may permit updating contacts. That capability does not decide which properties a particular Play should change. The provider's permission and the team's field policy are different controls. For example, a workflow might read contacts through a broad integration while allowing its own code to propose only a job-title change. That authored limit is meaningful, but it should not be described as a provider permission the connection does not actually enforce. ## Connection changes have workflow dependencies A credential can be revoked or lose scope while the Play source remains unchanged. The resulting failure is an access problem, not evidence that no matching customer data exists. A change can also affect several Plays or consumers that use the same provider. Dependency knowledge is therefore useful when changing access. Deepline does not make a replacement credential semantically identical merely because the provider identifier stays the same. ## Access mode belongs to the operation Supported managed and BYOK modes depend on the action. A connected account does not authorize an assumption that every action can use it, nor that every failure will switch to managed access. The distinction also affects cost evidence. A BYOK provider invoice belongs to the team's account; Deepline records its own applicable charges. Internal provider spend is not a customer-facing usage measure. ## Credential secrecy and result handling are separate Credentials should enter through the supported connection boundary rather than Play source or tool payloads. Runtime results and evidence have scrubbing contracts, but workflow authors should not treat logs as a secret-storage mechanism. Downstream data handling has its own policy. Successful access does not prove that every returned field should be copied into every destination. The team's use, retention, and write rules still govern that choice. ## Apply this understanding * [Connect an integration](https://deepline.com/docs/integrations.md): the supported connection procedure. * [Credential reference](https://deepline.com/docs/features/bring-your-own-keys.md): scope and authentication forms. * [Write Plays](https://deepline.com/docs/sdk-v2/plays.md): discover the live action before invoking it. * [CRM governance](https://deepline.com/docs/guides/crm-data-governance.md): permitted field changes. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.