Tessra
Build your own action
How actions are structured and how Tessra maps them to your system — not a from-scratch rebuild guide.
Custom actions are currently set up with Tessra during early access.
If you want to define one for your system, reach out: [email protected]
How it fits together
A custom action is a named key, a JSON shape for parameters, ordered policy bands that decide allow / require approval / deny, and an executor (typically a webhook) Tessra calls when the path is approved. You define the business mapping; Tessra owns the governed path around it.
Keys use a single dot namespace (for example customer.credit_issue). First run without custom keys: Quickstart. Full procedure signatures and field semantics: API / SQL reference.
Register the action (UPSERT_ACTION_DEFINITION)
CALL APP.UPSERT_ACTION_DEFINITION(
'customer.credit_issue',
'Customer credit',
'Goodwill or recovery credit',
'user',
PARSE_JSON('{"type":"object","properties":{"customer_id":{"type":"string"},"amount":{"type":"number"},"currency":{"type":"string"}},"required":["amount","currency"]}'),
NULL,
TRUE
);Rules and simulation
SIMULATE_ACTIONevaluates policy without creating a durable enforce-mode intent.- Human approval always happens in configured channels (Slack or email), not through a SQL approve procedure.
Policy, executor, and request
Policy rows are ordered bands per action and environment (for example: small amounts auto-allow, mid-range require approval, large amounts deny). You point execution at your downstream host with CONFIGURE_EXECUTOR. A call to REQUEST_ACTION validates params against your schema, evaluates those rules, opens approval when required, and returns an intent id you can poll with GET_ACTION_STATUS.
Tessra handles approval, execution tracking, and receipts automatically — you only define the action and how it maps to your system.
Copy-paste SQL examples for UPSERT_ORG_POLICY_RULE and REQUEST_ACTION live in the reference so this page stays oriented on structure, not a full recipe.