> For the complete documentation index, see [llms.txt](https://docs.carto.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.carto.com/carto-user-manual/connections/sharing-a-connection.md).

# Sharing connections

Sharing a connection lets other people in your organization use its data in CARTO to build maps, run workflows, and explore data, without having to create their own connection. You can share a connection with specific users, with specific groups, or with your entire organization, using the same access model as maps and workflows.

To share a connection, go to the *Connections* section of the Workspace and click *Permissions and sharing* on the connection card. This opens the sharing dialog.

<figure><img src="https://3029946802-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FybPdpmLltPkzGFvz7m8A%2Fuploads%2Fgit-blob-1522244f67eca731899aa2aefa70934fdc41fbd3%2Fimproved-connection-sharing.png?alt=media" alt=""><figcaption><p>Sharing a connection with specific users and groups</p></figcaption></figure>

## Who can use a connection

A connection has two sharing modes:

* **Restricted:** only the people you add can use the connection. Use the *Add members* field to grant access to specific users or [groups](/carto-user-manual/settings/users-and-groups/managing-user-groups.md), and set the role for each. A newly created connection starts as *Restricted* with no one added, so it is private to you until you share it.
* **Entire organization:** everyone in your organization can use the connection.

Only the connection owner can edit its sharing settings. What recipients can actually reach through the connection depends on its credential type, described below.

{% hint style="info" %}
You can still create public maps using private connections and connections that require viewers' credentials. The public map retrieves the data it needs without exposing any credentials.
{% endhint %}

## What recipients can do with a shared connection

What a recipient experiences when they use a shared connection depends on the credential type of the connection, and the sharing dialog states this before you share:

* **Connections with static credentials** (BigQuery service account, Snowflake username and password or key pair, Databricks Personal Access Token and OAuth M2M, PostgreSQL, Amazon Redshift, and Oracle): recipients access the data through the identity configured in the connection, with no extra setup on their side. Everyone uses that same identity and its permissions, so share the connection only with people who should reach the underlying data.
* **Connections with dynamic credentials** (BigQuery OAuth and Workload Identity Federation, Snowflake OAuth, and Databricks OAuth U2M): each recipient authenticates with their own warehouse credentials, so they access the data with their own identity and see only what their own permissions allow. This is described below.

## Require viewers' credentials

When you share a connection that uses dynamic credentials, each recipient authenticates with their own credentials to access it. This lets you leverage policies such as Row-Level Security, or collaborate on maps while everyone uses their personal credentials. It applies to:

* [BigQuery OAuth connections](/carto-user-manual/connections/bigquery.md) (using "Sign in with Google")
* [BigQuery Workload Identity Federation connections](/carto-user-manual/connections/bigquery.md#using-workload-identity-federation)
* [Snowflake OAuth connections](/carto-user-manual/connections/snowflake.md)
* [Databricks OAuth U2M connections](/carto-user-manual/connections/databricks.md)

Once such a connection is shared, users accessing data through it, when consuming maps, running workflows, or navigating the data explorer, are prompted to authenticate with their own credentials. After authenticating, they use the connection as usual, in accordance with the access policies set in the Data Warehouse.

<figure><img src="https://3029946802-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FybPdpmLltPkzGFvz7m8A%2Fuploads%2Fgit-blob-176aeb22890b8e3b1e91cca6d49cc60c139fa530%2FUntitled.png?alt=media" alt=""><figcaption><p>A user being prompted to authenticate before using a shared BigQuery connection</p></figcaption></figure>

{% hint style="success" %}
For BigQuery Workload Identity Federation connections, users automatically use their own identity and do not need to provide any additional information.
{% endhint %}

### Adding your individual credentials

Users can add their individual credentials to a connection that requires viewers' credentials in three places:

* **Data explorer:** opening a shared connection that requires viewers' credentials prompts the user to authenticate.
* **Map builder:** opening a map that uses such a connection prompts the user to authenticate.
* **Connection card:** click the three dots on the connection card and select *Add my credentials*.

Individual credentials are stored for as long as they remain valid, so users do not need to re-enter them each time they use the connection.

{% hint style="info" %}
Cache management is specific to each user when viewers' credentials are required. One user can never access another user's cached data.
{% endhint %}

<figure><img src="https://3029946802-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FybPdpmLltPkzGFvz7m8A%2Fuploads%2Fgit-blob-62490e848d59eb79fc66b39afacaa163bca6916e%2FScreenshot%202024-09-03%20at%2018.41.13.png?alt=media" alt=""><figcaption><p>Adding individual credentials from the Data Explorer</p></figcaption></figure>

<figure><img src="https://3029946802-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FybPdpmLltPkzGFvz7m8A%2Fuploads%2Fgit-blob-a445ad1eb918d0f76fb810e8a4fdceadfd30ec27%2FScreenshot%202024-09-04%20at%2017.05.38.png?alt=media" alt=""><figcaption><p>Adding individual credentials from the connection card</p></figcaption></figure>

<figure><img src="https://3029946802-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FybPdpmLltPkzGFvz7m8A%2Fuploads%2Fgit-blob-e1dba488711e400843cb85a539da6632ec9d7c3f%2FScreenshot%202024-09-03%20at%2018.43.24.png?alt=media" alt=""><figcaption><p>Adding individual credentials from the map builder</p></figcaption></figure>

### Removing your individual credentials

Individual credentials can be removed at any time, from two places:

* **Map builder:** click the three dots at the top right corner and select *Remove credentials.*
* **Connection card:** click the three dots on the connection card and select *Remove my credentials*.

To reintroduce credentials (because they changed or expired, for example), remove them first and then reauthenticate.

<figure><img src="https://3029946802-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FybPdpmLltPkzGFvz7m8A%2Fuploads%2Fgit-blob-c72cda992d6a0e8c2462fdb9207ab2e26eeebf27%2FScreenshot%202024-09-04%20at%2017.11.32.png?alt=media" alt=""><figcaption><p>Removing individual credentials from the map builder</p></figcaption></figure>

<figure><img src="https://3029946802-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FybPdpmLltPkzGFvz7m8A%2Fuploads%2Fgit-blob-baea4593fd11ad98cc0774e06a776ed70b3d0df3%2FScreenshot%202023-07-13%20at%2014.04.31.png?alt=media" alt=""><figcaption><p>Removing individual credentials associated with a shared BigQuery connection</p></figcaption></figure>

### Row-level security and other policies

Requiring viewers' credentials on a connection makes it possible to leverage security policies set in the database, such as Row-Level Security policies.

<figure><img src="https://3029946802-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FybPdpmLltPkzGFvz7m8A%2Fuploads%2Fgit-blob-3c58d165c7141f6d4967ed00ddececd0ccb846a3%2FScreenshot%202023-07-13%20at%2013.30.03.png?alt=media" alt=""><figcaption><p>A map using a connection that requires viewers' credentials, effectively implementing Row-Level Security</p></figcaption></figure>

With Row-Level Security policies, two different users can see two different versions of the same table, depending on the role-based permissions set by the organization. This way, control remains centralized in the Data Warehouse.

We recommend setting security policies at the database level. For more information, see the following resources:

* [Google's introduction to Row-level security](https://cloud.google.com/bigquery/docs/row-level-security-intro)
* [Snowflake's introduction to row access policies](https://docs.snowflake.com/en/user-guide/security-row-intro)
* [How to filter sensitive table data using row filters and column masks in Databricks](https://docs.databricks.com/en/tables/row-and-column-filters.html)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.carto.com/carto-user-manual/connections/sharing-a-connection.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.