Skip to main content

​
What is the Data Model page?

Every workspace has a Data Model page: a curated view of the workspace’s connection that:
  • Selects which tables and columns are available
  • Describes fields with human-readable annotations
  • Secures data with row-level security rules
The Data Model is the foundation of your agent’s knowledge — the other context pages (System Prompts, Golden Assets, Skills, Knowledge Base, User Memory) build on top of it.
A workspace's Data Model page: tables on the left, column list with descriptions and Selectable toggles on the right, and a Test RLS as user picker
You don’t create a data model on its own — it comes with the workspace. Create a workspace on a connection and the system fetches all tables and columns from that connection automatically.
Workspaces replaced separate data models and agents. A workspace is its data model: there is one schema and one agent in each workspace, and they are versioned and published together.

​
Why Curate the Data Model?

  1. Simplify for AI - Only expose relevant tables so the agent isn’t overwhelmed
  2. Add context - Descriptions help AI understand what columns mean
  3. Control access - Data Security rules ensure users see only their data

​
Selecting Tables and Columns

By default, all tables are selected. To customize:
  1. Open your workspace’s Data Model page
  2. Uncheck tables you want to hide
  3. Expand a table to uncheck specific columns
Less is more here. An agent scoped to 5 relevant tables with clear descriptions will significantly outperform one with access to 50 tables it has to guess about.

​
Adding Descriptions

Help AI and users understand your data:
  1. Click into a table and add a Table Description
  2. Add a description to any column from its row in the column list
  3. For columns with categorical values users might filter by (region, status, owner), turn on Selectable — the agent can then enumerate valid filter values at query time
See Data Model & Schema for a full guide on what makes a good description and when to mark a column selectable.

​
Data Security

Data Security controls which rows of data each user can access. You can define Global Security Rules that apply across all tables, or configure per-table rules for specific needs.

​
Understanding Data Security

The Data Security system uses SQL-based filtering with dynamic variables:
  • {{user.*}} - Access properties of the currently authenticated user
  • {{organization.*}} - Access properties of the user’s organization
For example, to filter an orders table so users only see their own orders:

​
Global Security Rules

Global Security Rules let you define filtering logic once and apply it to all applicable tables automatically. This is ideal when you have consistent patterns like:
  • Multi-tenant data separated by tenant_id
  • User-owned data filtered by user_id
  • Schema-based isolation (each tenant has their own database schema)

​
Accessing Global Rules

  1. Open your workspace’s Data Model page
  2. Click the Global Data Security tab, alongside Tables
  3. You’ll see the Global Rules editor, with + Add Rule above any rules that already exist

​
Rule Types

Schema Rules - Dynamic schema prefixing for multi-tenant databases where each tenant has their own schema:
The Schema Rule form with Schema Property set to user.source, and an Example Output line showing every query prefixed with that schema
This generates SQL like:
Column Rules - Automatic WHERE clause filtering based on column names:
The Column Rule form filtering the country column on user.country, with the Optional Rule toggle on, a Tables Affected summary, and the generated WHERE clause
This generates SQL like:

​
Creating a Global Rule

  1. Click the Global Data Security tab
  2. Click Add Rule
  3. Choose Schema Rule or Column Rule
  4. Configure the rule settings
  5. The rule is automatically enabled
The Add Global Rule dialog offering Schema Rule and Column Rule, each with a one-line description

​
How Rules Are Applied

  • Schema rules affect all tables - they change where data is fetched from
  • Column rules only affect tables that have the specified column - tables without the column are unaffected
  • Multiple rules are combined with AND logic
  • Rules are applied in priority order (lower priority number = applied first)
Applying the rules opens a preview first: the SQL each table will be given, a count of how many will be filtered, and — because a manual override always wins — how many will be skipped.
The Apply Global RLS Rules preview, listing the SQL each table will be given, with a count of the tables to be filtered and those skipped for having a manual override

​
Per-Table Data Security

Selecting a table gives it its own Data Security tab — distinct from the workspace-wide Global Data Security tab — showing how the global rules apply to that one table.
A table's Data Security tab managed by the global rules, its Applied Rules list empty because this table has no column the rules match, above the read-only generated query

​
Manual Overrides (Break Glass)

Sometimes you need custom logic for a specific table. You can override global rules:
  1. Select the table
  2. Go to its Data Security tab
  3. Click Edit manually
  4. Confirm the warning dialog
  5. Edit the SQL directly
The Switch to Manual Security dialog, listing that the generated SQL is copied to the editor, the table stops inheriting global rules, and later global changes will not reach it
Once in manual mode, you have full control over the SQL:
The same tab in manual override mode: an amber manually-edited banner with Reset to global, an editable query, and the user and organization properties available to it

​
Resetting to Global Rules

To return a table to global rule management:
  1. Click Reset to global
  2. Confirm the dialog
  3. Your manual edits will be replaced with the auto-generated SQL
The Reset to Global Security dialog, listing that the manual SQL is deleted, the global rules are re-applied, and later global changes will affect the table again

​
Testing Data Security

You can test your security rules to see exactly what data a specific user would see:
  1. Open your workspace’s Data Model page
  2. Select a project user from the Test RLS as picker at the top of the page
  3. Click Test Query
  4. View the filtered results
Test RLS Policy run as a supplier manager whose user.country resolves to Canada and Mexico, showing the query sent to the database and the 18 rows it returned
Testing uses your actual database connection and shows real data filtered by the security rules. This helps verify your configuration before deploying.

​
Versioning and Production

You don’t manage versions on the Data Model page — they belong to the whole workspace:
  • Changes to the schema, its descriptions and its security rules autosave to the draft
  • Publish stages a new workspace version, capturing the schema and the agent’s context together
  • Promoting a version to production is what makes it live — see Workspaces

​
Syncing with Connection Changes

If your database schema changes:
  1. Open your workspace’s Settings and go to the Connection tab
  2. Refresh the connection’s schema
  3. New tables/columns will appear in the Data Model (you can select them)
  4. Missing tables/columns will show warnings

​
Data Model Errors

If the production version has errors (e.g., missing tables), you’ll see a warning banner. This typically happens when:
  • A table was dropped from the database
  • A column was renamed or removed
  • The connection credentials changed

​
Next Steps