Tenant Scoping

✓ functional

Configure the multi-tenant missing-filter guard: whether it runs, the tenant column, and the tenants table.

Configure SQLly's multi-tenant missing-filter guard for the current database. Four modes: Off, Allowed (recognize tenant filters, never nag), Warn (the default - a tenant-scoped table queried without its tenant predicate gets a validation warning), and Required (that omission becomes a blocking error and Run refuses). It is how you teach SQLly what "forgot the tenant filter" means for your schema.

Leave the tenant column blank and the guard uses the usual conventions - TenantId, AccountId, OrganizationId and their underscored forms - or name your own column to narrow detection. Optionally point it at the tenants table itself, with its id and display-name columns. Changes save on every keystroke and apply to the next validation; the settings live per server-and-database in a plain local file, like the rest of your SQLly configuration.

A guard, not a rewriter. Tenant Scoping never injects a WHERE clause or edits your SQL. It only checks what you wrote - and even in Required mode it blocks solely on a confirmed missing-tenant-filter diagnostic, failing open rather than guessing.

SQLly Tenant Scoping configuration — Tenant Scoping: enable the guard for a database and name the tenant column and tenants table.