Workspace Databases

Keep structured records, enforce business rules and work with live views in chat. Share databases with colleagues and give agents scoped access.

Also in Sluis Workspace: the Workspace overview and Mail and calendar.

What databases are

A database holds tables, typed fields and records for work you keep over time, such as cases, contracts or tasks. Each database needs a plain-text description on one line, from 1 to 280 characters, explaining what it holds and who uses it.

Open Databases in the sidebar at /workspace/databases. A new database is private. Databases are not custom app screens: there is no app builder, Edit mode, Full screen or executable view handler. The Sluis Workspace desktop and mobile apps are separate products.

Create and change a database

Ask any chat model for a database or a schema change. It hands the request to the coding builder, sluis/code, which must be allowed by your organisation's model policy. Only that builder or a configured Agent with the databases tool group authors schema and rules. Ordinary chat models work with records and request schema changes, rather than authoring them.

Source is JSON lines: a database header, collection lines, optional script functions, trigger lines and pinned view lines. The fence is sluis-database. Components and handlers are not supported. A Skill can include a database.sluis template at the root of its archive.

Install a Skill's template through POST /chat/skills/{skill_id}/install-database with your member session.

Versions retain the author and date. Manage access can publish and restore schema versions; restoring creates a new current version rather than erasing history. It does not restore a snapshot of record data.

Live and pinned views

Ask for a table, board, chart, calendar, timeline, total, form or individual record. A sluis-view block describes the view, not a copy of the records. It loads live with each reader's own permissions, and shared changes refresh the view.

Manage access can pin a view to the database or remove a pin. Pinned views sit above the data. Filtering, sorting and paging run on the server. Forms use the table's fields and rules; computed fields are read-only. A view cannot bypass visibility or write rules.

```sluis-view
{"database":"<database UUID>","table":"contracts","view":"table","columns":["title","expiry"],"order":"expiry"}
```

Records and rules

Fields support text, number, bool, date, JSON, file, person and references to another table. Person and reference fields show names or labels. Record history shows field changes and their author. Records are encrypted; keyed indexes support equality and word-prefix search on label and searchable text fields without storing their plaintext. Search results and reference labels respect record visibility.

Indexed search matches all supplied word prefixes, case-insensitively, with at least two alphanumeric characters per word. It is not arbitrary substring search. Free-text results are capped at 200 and report truncation. Broad residual queries over 25,000 candidates or reference-label matches over 500 IDs return 422: add an indexed filter. A missing or stale index must finish rebuilding before reads resume.

Field rules: required, unique, min/max, options, default and pattern. A pattern is a whole-text mask: # is a digit, A an uppercase letter, a a lowercase letter and * any character, not a regular expression.
Computed fields use sandboxed Rhai expressions, are recalculated on writes and stored, and cannot be set by the caller.
Status rules define states, an initial state and permitted transitions, with required fields and a minimum Records, All data or Manage level.
Server triggers run on create, update or delete. They can insert, update or remove records in the same database, reject a write or notify a member. Record effects use the writer's rights and commit atomically with the original write. Any rejected effect rolls everything back. Trigger writes do not fire more server triggers; notifications are sent after commit.
Forms, data edits, chat tools, import, webhooks, batch AI and automation writes all use the same rules. A rule refusal returns 422 with field-level reasons.

Import CSV or Excel with column mapping and a preview, up to 20,000 rows. An invalid row cancels the whole import. Export CSV, Excel or JSON with All data access. Files up to 25 MiB are malware-scanned and encrypted: PDF, Word, Excel, PowerPoint, text, Markdown, CSV, JSON, PNG and JPEG. Access follows the record and deleting the record removes its files. The databases.file_text tool extracts text, including scans through Sluis OCR, with the reader's rights.

Use Share for Private, Specific people or Organisation. Records access adds records and changes or deletes the member's own visible records. All data also sees and changes every record and exports. Manage also publishes schema, rules and pinned views. Sharing, deletion and administrative settings remain reserved to the owner or the administrators of an organisation-wide database; a Manage grant is not ownership.

For Records access, each table can show all records, only the member's own records, no records, or records whose chosen person field names the member. All data and Manage can see all records. Changing a schema version does not reset the saved visibility settings. Removing access also ends live access.

Chat and agent access

Chat tools list, search and read accessible databases, read attached files and show views. Mention a database with @, or enable Searchable in chat to include its description and tables in chat context. That setting affects discovery, not permissions. The list tool remains available even when there are no databases yet.

Per database, agent_write is ask by default: each create, update or delete record action waits for a confirmation card. allow runs those actions without a card; read_only refuses them. Approval does not grant extra rights, and changed records, schema or policy can require a new request.

Attach specific databases to an Agent with read or write grants. Every call intersects the live grant with the running member's access. The databases tool group additionally enables schema tools, but does not grant access to every database. Unattended runs cannot answer approval cards: record writes require both a write grant and the database's allow policy.

Batch AI fills selected fields of matching records, at most 200 records per job, with progress, failures and cancellation. It runs with the initiating member's rights and the normal model policy, data protection and token budget. Record text is data, not instructions. Database views cannot call Knowledge, documents, recordings or connectors as UI capabilities; use configured Agents or automations for that work.

Automations and webhooks

Automations can react to record creation, updates to selected fields or a status transition. Time triggers run at intervals of at least 15 minutes, daily, weekly or before a date field, with a timezone. Actions run an Agent, notify members or call an approved MCP connector. Runs show results and cost; activation shows an estimate and asks for confirmation from €5 per month.

An automation runs as its configured owner and is limited to its database and the Agent's current grants. Matching writes by members, webhooks and other agents can start it, but its own run cannot start it again and chained runs cannot revisit an automation. Import and batch AI do not start record automations. At most 200 runs are queued per database per day. Member notifications use the Workspace inbox, push and the member's email preference, at most 20 per member per day.

Inbound webhooks are off until an owner or admin enables Database webhooks. Manage access can create one endpoint per table at POST /hooks/databases/{database}/{collection}, without a session or bearer token. The whsec_ secret is shown once on creation or rotation. An optional IP allow-list accepts up to 20 addresses or CIDRs.

Send one JSON object of at most 16 KiB. Unknown fields are dropped and file fields ignored; the remaining values obey all record rules. Sign the exact body with HMAC-SHA256: X-Sluis-Timestamp is Unix seconds within five minutes, and X-Sluis-Signature is sha256= followed by the lowercase hex signature of timestamp, a dot and body bytes. An accepted signature cannot be replayed. Retry 402, 429 or 5xx only within the timestamp window; 429 includes Retry-After. Redis unavailability fails closed with 503.

Responses: 201 created; 400 invalid object; 401 bad, stale or replayed signature; 402 credit blocked; 403 IP refused; 404 unknown or disabled endpoint or feature; 413 body or storage limit; 422 invalid record; 429 rate limit; 503 unavailable. Rule failures include error and issues with field, rule and message; other ingress responses have no body. Limits are 120 deliveries per minute per endpoint and 600 per organisation, plus a sender limit. Deliveries are audited, with rejection sampling under abuse, and the last 20 appear in webhook management. Signing examples follow.

SECRET='whsec_...'   # shown once when the endpoint is created or rotated
URL='https://gateway.sluis.ai/hooks/databases/DATABASE_ID/COLLECTION'
BODY='{"title":"Printer jammed","priority":"high"}'
TS=$(date +%s)
# HMAC-SHA256 over "<timestamp>.<exact body bytes>", lowercase hex
SIG=$(printf '%s.%s' "$TS" "$BODY" | openssl dgst -sha256 -hmac "$SECRET" -hex | sed 's/^.* //')
curl -i -X POST "$URL" \
  -H 'Content-Type: application/json' \
  -H "X-Sluis-Timestamp: $TS" \
  -H "X-Sluis-Signature: sha256=$SIG" \
  --data-binary "$BODY"

import { createHmac } from "node:crypto";

const body = JSON.stringify({ title: "Printer jammed", priority: "high" });
const ts = String(Math.floor(Date.now() / 1000));
const sig = createHmac("sha256", process.env.SLUIS_WEBHOOK_SECRET)
  .update(`${ts}.${body}`)
  .digest("hex");
const res = await fetch("https://gateway.sluis.ai/hooks/databases/DATABASE_ID/COLLECTION", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-Sluis-Timestamp": ts,
    "X-Sluis-Signature": `sha256=${sig}`,
  },
  body, // send exactly the string you signed
});
console.log(res.status); // 201 when the record was created

Limits and billing

Source is limited to 256 KiB, 20 tables and 100 fields per table; a record to 16 KiB. Rules run in a bounded sandbox without network or arbitrary file access. Owners and admins can disable Databases in console feature settings without deleting stored databases.

From the announced billing start date, storage costs €5.15 per GB per month for text and data and €0.0803 for files, attachments and recordings (1 GB = 1,000,000,000 bytes). The start date is announced seven days ahead. Unattended Agent and automation runtime costs €0.005 per minute, counted per started second; interactive chats have no runtime charge. AI tokens are metered separately.

The storage limit is 100 GB or 5,000,000 objects per billing root, including sub-organisations. Owners and admins can set a monthly storage spend limit. An empty balance pauses storage-adding writes and unattended work, not reading, downloading, export or deletion. Existing data is not deleted. Schema, sharing and administrative changes are audited; record history is separate from the operator audit log.

Session storage-limit refusals return HTTP 413 with error.code storage_full; oversized requests do not carry that code. PUT /chat/settings preserves database_webhooks_enabled when omitted or null. Send true or false to change it explicitly; new settings default to off.

→ Sluis Workspace

Mail and calendar →