> ## Documentation Index
> Fetch the complete documentation index at: https://basedash.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Data source access control
> Control who can query each data source, and which schemas, tables, and columns they can see
Data source access control decides who can query each data source and what they can see inside it. Access works at two levels:
* **Data source access** controls whether a member can query a data source at all, and whether they can view or edit it.
* **Schema, table, and column rules** narrow what a member can see inside a data source they already have access to.
> [!NOTE]
>
> Only admins can manage data source access.
See [Members and roles](/docs/administration/members-and-roles) for what each role can do.
## Manage access
You can open a data source's access settings in two places:
* Open the command menu with Cmd/Ctrl K, select the data source, and choose **Access**.
* On the **Data** page, open the data source and go to its **Access** section.
The access editor shows the data source at the top, followed by a tree of its schemas, tables, and columns. Select any item in the tree to see and change who has access to it. Use the search box to find an object, and use **View as** to preview what a specific member or group can see.
## Data source access
At the data source level, you can give access to everyone in the organization, to groups, or to individual members. Each grant has one of these levels:
| Level | What it allows |
| - | - |
| **Can view** | Query the data source in charts, dashboards, chat, the SQL editor, and exports. |
| **Can edit** | Everything in **Can view**, plus AI can run write queries on databases that support them. Each write needs approval. |
| **No access** | Available for **Everyone** only. Members can't query the data source unless a group or member grant gives them access. |
A member gets the highest level from any grant that applies to them: the **Everyone** grant, a group they belong to, or a direct member grant. Admins always have edit access to every data source.
When a data source has no grants, everyone in the organization can view it.
To restrict a data source to specific people:
1. Open the data source's **Access** settings.
2. Set **Everyone** to **No access**.
3. Click **Add member or group** and choose the groups or members who need access.
4. Set each one to **Can view** or **Can edit**.
Changes take effect immediately. Members without access no longer see the data source in pickers and can't run queries against it.
## Schema, table, and column rules
Inside a data source, you can allow or block access to individual schemas, tables, and columns. Each rule applies to everyone, a group, or a single member, and sets the object to full access or no access.
Members can't see objects they don't have access to, either in Basedash or in what the AI knows about your schema. Queries that use those objects are blocked.
### How rules are evaluated
Basedash checks rules from the schema down to the table and then the column:
1. An object with no rule for the member inherits its parent's access. With no rules at all, everything is accessible.
2. At each object, a rule for the member takes precedence over group rules.
3. If the member is in several groups with rules on the object, the most permissive group rule wins.
4. Group rules take precedence over the **Everyone** rule.
Rules apply to every role, including admins.
> [!TIP]
>
> To limit a schema to one team, set **Everyone** to no access on the schema and
> give that team's group full access. New tables added to the schema later
> inherit the same rules.
### Connectors in Basedash Warehouse
Every connector synced into [Basedash Warehouse](/docs/data-sources/warehouses/basedash-warehouse) has an **Access** section on its connector page. It shows the same editor, limited to the schemas and tables that connector syncs. Rules you set there are stored on the warehouse, so they also appear in the warehouse's access settings.
### Stale rules
If a schema, table, or column is renamed or dropped in your database, its rules stay in place and the editor marks them as stale. Remove stale rules from the editor once you no longer need them.
### Write queries
When a data source has any schema, table, or column rules, AI won't run write queries on it, even for members with **Can edit**.
## Where access is enforced
Data source access and object rules apply everywhere queries run:
* Charts and dashboards
* AI chat, including chats from Slack and the MCP server
* Automations, which run with the access of the member who created them
* The SQL editor
* Data exports, such as table record exports
* Chart variables, where only accessible data sources appear in the variable editor
## Manage access with the API
Admins can read and update data source access, including schema, table, and column rules, with the public API. See [Get data source access](/docs/api-reference/data-sources/get-data-source-access) and [Update data source access](/docs/api-reference/data-sources/update-data-source-access).
## FAQ
> **How is this different from data visibility and row-level security?**
>
> Access control decides which members and groups can query a data source and
> which schemas, tables, and columns each of them can see. [Data
> visibility](/docs/administration/data-visibility) hides objects from everyone in
> the organization, mostly to keep clutter away from the AI. [Row-level
> security](/docs/administration/row-level-security) filters rows inside a table
> with Postgres policies.
> **What do members see on a dashboard with charts they can't access?**
>
> The chart stays on the dashboard but shows a message instead of data, such
> as **No access** when the query uses a table or column that's blocked for
> them, or "You don't have access to query this data source".
> **Can I hide a column from admins?**
>
> Yes. Admins always have access at the data source level, but schema, table,
> and column rules apply to them too when they query. They still see every
> object in the access editor so they can manage the rules.
> **Whose access do public dashboards use?**
>
> The dashboard creator's. Anyone with a public link sees what the creator can
> see, with the creator's schema, table, and column rules applied. If the
> creator is removed from the organization, the dashboard's charts stop
> loading. Full-app [embedding](/docs/developers/embedding) signs people in as
> members, so their own access applies.
> **Do automations and insights respect these rules?**
>
> Yes. Automations run with the access of the member who created them.
> [Insights](/docs/features/insights) are only shown to members who can query the
> data behind each post.
## Related features
* [Data visibility controls](/docs/administration/data-visibility) – Hide tables, schemas, and columns from everyone in the organization.
* [Row level security](/docs/administration/row-level-security) – Control which rows users can see in a Postgres data source with database policies.
* [Security](/docs/administration/security) – Overview of access controls and security in Basedash.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.