Skip to main content
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.
Only admins can manage data source access.
See 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.
The Access section of the Acme warehouse with its schema tree on the left and its grants on the right, where Everyone has no access, Finance, Marketing, and Sales can view, and Alex Kim can edit

​
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: 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.
The annual_salary column selected in the access tree, overriding its table so that only the Finance group can access it while everyone else has no access
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 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 and Update data source access.

​
FAQ

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 hides objects from everyone in the organization, mostly to keep clutter away from the AI. Row-level security filters rows inside a table with Postgres policies.
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”.
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.
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 signs people in as members, so their own access applies.
Yes. Automations run with the access of the member who created them. Insights are only shown to members who can query the data behind each post.
  • Data visibility controls – Hide tables, schemas, and columns from everyone in the organization.
  • Row level security – Control which rows users can see in a Postgres data source with database policies.
  • Security – Overview of access controls and security in Basedash.