Use cases

Five things teams build with it

Each example is a sequence you could follow today, written in the order that actually works. The commands are real; the table and key names are invented.

Build an internal tool on live business data

In plain wordsCreate the tables your app needs, publish them as an API, and give the app a key that can only touch those tables.

The situation. A team needs a small ordering tool. The data belongs in the company database, the app should not hold its own copy, and nobody wants to build an API layer first.

The sequence. Define the schema, expose the entities, restart the data API engine so they are published, seed any reference data, then mint a least-privilege key for the front end and restart once more so the key's role exists. Two restarts, not one.

Why a stored procedure. API writes are per statement, so an order header and its lines can half-succeed. Wrapping the write in a procedure makes it all-or-nothing and gives the app a single call.

$ dlake login --domain acme --profile acme
$ dlake tool get_active_schema --profile acme
# define
$ dlake admin create_table --tableName shop_orders --columns @orders.json --primaryKey OrderNo
$ dlake admin create_procedure --procedureName usp_PlaceOrder --parameters @params.json --body @proc.sql
# publish
$ dlake admin set_entity_exposure --entity shop_orders --expose true
$ dlake admin set_entity_exposure --entity usp_PlaceOrder --expose true
$ dlake admin restart_dab --confirm true
# least-privilege key for the front end, then publish its role
$ dlake admin create_api_key --keyName shop-web --expirationDays 180 --scope @scope.json
$ dlake admin restart_dab --confirm true

Give an AI assistant governed access to ERP and CRM data

In plain wordsLet an assistant answer questions from your business data, while deciding exactly which tables and fields it can reach.

The situation. Sales want to ask questions that span the ERP and the CRM. Nobody wants to hand an assistant unrestricted access to the database.

The sequence. Mint a key scoped to the entities the assistant may read, restart so the key's role is published, and connect it to the agent. Install the bundled skills so the agent knows the platform's rules rather than discovering them by trial and error.

What keeps it safe. The scope is enforced in the database, not in the assistant. Row-level security filters rows on top of that. Every call is audited, the key carries its own identity into the audit stamps, and revoking it takes effect immediately.

How agents connect and what governs them, and the 20 bundled skills.

# read-only on two entities, nothing else
[ { "entityName": "account", "canRead": true }, { "entityName": "orders", "canRead": true } ]
$ dlake admin create_api_key --keyName claude-analyst --expirationDays 90 --scope @scope.json
$ dlake admin restart_dab --confirm true
# teach the agent the platform rules
$ dlake skills install
# and if you change your mind
$ dlake keys revoke <id> --profile acme

Run Commercient SYNC from the terminal

In plain wordsCheck why records are missing in the CRM, turn a sync on or off, and see what the agent actually did, without opening the portal.

The situation. A customer reports that records are not arriving in their CRM. Three separate products could be responsible: the agent that extracts from the ERP, the sync that pushes to the CRM, or the writeback that comes the other way.

The sequence. Ask each product about itself. Readiness tells you whether the extract is even set up, including the parts the CLI cannot configure. The error views tell you why records were rejected. The log shows what the agent wrote.

These commands need a key belonging to an Admin user; otherwise they say so plainly and exit 3 without changing anything.

# is the extract even set up?
$ dlake normalsync readiness --profile acme
# did rows actually move?
$ dlake normalsync resync-status --profile acme
# why are records missing in the CRM?
$ dlake crmpro errors --profile acme
$ dlake crmpro log --grep "timeout" --tail 100 --profile acme
# and the writeback leg
$ dlake txdownloaderpro errors <processId> --profile acme

Automate checks and extracts in CI

In plain wordsScripts can read the data, pull files and watch the platform, and stop the build when something is wrong.

The situation. A nightly job needs a fresh extract, and someone should know within minutes if the platform stops answering.

What makes it scriptable. Every command takes --json, exit codes are stable, and arguments can come from files so no shell mangles them. dlake watch --once runs a single health cycle and exits non-zero if anything failed, which is exactly what a scheduler needs.

Keep the key in the environment rather than on the command line, and name the tenant with --profile so a job can never run against the wrong customer.

$ export DLAKE_PROFILE=acme
# fail the step on a permission problem (exit 3)
$ dlake export account --format parquet -o ./account.parquet --json
# one health cycle, exit 1 if anything is down
$ dlake watch --once --json --webhook "$SLACK_URL"
# pull a single number out for a dashboard
$ dlake tool aggregate --entity orders --json | jq '.value[0].sum'

Move data in and out as files

In plain wordsSend whole tables to an S3 bucket, and query files already in a bucket as if they were tables.

The situation. A data team wants last month's tables in their own bucket, and has parquet files from elsewhere that would be useful alongside the lake's own data.

The sequence. Register the connection once, then export server-side so the rows never travel through your laptop. Going the other way, preview what the platform would infer from a file, then attach it as an external table that SQL can query. Attaching needs SQL Server 2022 or newer.

Exports respect the key's scope, row-level security and impersonation, so a scoped key exports exactly what it could read.

$ dlake s3 connections add --name sales --region us-east-1 --bucket acme-sales
# server-side export straight into the bucket
$ dlake s3 export sales account --format parquet --profile acme
# the other direction: see what discovery infers, then attach
$ dlake s3 discover sales reports/q1.parquet
$ dlake s3 attach sales --table q1_report --location reports/q1.parquet

Start with whichever one is yours

Install the CLI, then follow the sequence. The command reference explains every group, and the setup page covers keys, profiles and the rules that catch people out.

Install the CLI Command reference