orders.customer_id mapped as the client column, Acme’s session queries Acme’s orders and Northstar’s session queries Northstar’s orders.
What changed
Custom SQL filtering now preserves more existing query structures, including casts, aliases, and grouped conditions. Saved custom SQL metrics are read-only for embedded end users; workspace authors maintain their SQL.Before you start
You need:- A datamart configured for Table tenancy, linked to the workspace and embedding configuration you use.
- A customer reference table with a primary key and customer-name column.
- A client-column mapping on every table that contains customer-specific data.
- A Data App and an embedded dashboard or metric.
- Access to your application’s backend code that creates guest tokens.
Set it up
1
Configure customer identifiers in your datamart
Open your datamart’s tenancy settings. For Table tenancy, select the customer reference table and configure Primary Key, Primary Key Type, and Customer Name.Under Client Column Mapping, select the column that identifies the customer in each customer-specific table. Save your changes with Update when editing an existing configuration.
The value your application sends as
clientId must match these identifiers. See Configure tenants for the customer reference setup.2
Check the embedding configuration
Confirm that your workspace and embedding configuration use the intended datamart. Client-column mappings displayed in sharing and access settings are read-only; change them in the datamart configuration.
3
Enable automatic scope when creating the guest token
From your application’s backend, add Replace the example names and identifier with your own values. Keep any other token parameters your integration needs. The flag belongs under
isAllowAutoClientScope: true inside params.accessPermissions. Set clientId from the signed-in user’s authorized customer account.Example request body for the Create guest token API:params.accessPermissions, rather than the top-level permissions object.Use the returned guest token in your existing embed integration. Generate a new token with this setting to enable automatic scope for a session. Keep your Data App API key on your backend.4
Verify with two customer accounts
Load the same dashboard with a token for Acme, then with a separate token for Northstar. Check that each session returns the expected customer’s data.Also check the features you offer: table-backed filter dropdowns, CSV downloads, underlying data, dashboard download archives, and scheduled report attachments. Compare them with the dashboard’s customer context.
Use it day to day
Customers use the embedded dashboard as usual. They can adjust permitted filters and download data when those actions are enabled. Automatic scope applies in the background; customers do not select their own tenant in the embed. To schedule delivery, open Scheduled Reports in the embedded dashboard when enabled. Enter the Subject Line and Send to addresses, choose Charts to Attach, then set the frequency, delivery time, and timezone. Enable Share Download file and select a Download File Format if you want downloadable report files. Save the schedule. Embedded schedules retain the guest-token and embed context used to create them. Their downloadable data uses the token’s customer scope. For an existing schedule, check its saved token and embed context before relying on automatic scope; changing your token-generation code alone does not update the token already associated with that schedule. See Scheduled reports for end users for enabling scheduled reports and email settings for delivery setup.Existing SQL and other access rules
- Existing customer placeholders: Saved SQL that already uses a client equality condition such as
WHERE customer_id = 'client_id_variable'keeps that substitution path. Automatic scope does not add another set of customer filters to that query. Keep the existing customer conditions complete and correct. - Custom SQL without a placeholder: With automatic scope enabled, Databrain uses the datamart mappings to filter supported queries. A query that needs scoping but cannot be safely scoped returns an error. Some custom SQL result-based filter configurations still require an explicit customer placeholder; validate these filters with your query.
- End-user SQL editing: Embedded end users cannot edit saved custom SQL metrics. Ask a workspace author to change the SQL. Permitted filter interactions remain separate from SQL editing.
- Additional restrictions: Existing row-level security, application filters, and action permissions still apply. Automatic scope does not grant permission to download, view underlying data, or send reports.

