Data Destinations

A destination is a PostgreSQL database you own and control — hosted on Supabase, AWS RDS, or your own infrastructure — that Decisimo reads and writes. A tenant has at most one of each kind:

• Decision archive — every decision this tenant executes is written to a table in your database, so historical execution data lives somewhere you manage.
• Case board — where cases live and run. You need one before any case type can execute.
• Outcome history — what happened after each decision. Decisimo creates the table and you fill it; analysis joins it to the archive inside your own database. See Production data and outcomes.
• Data cache — stored external data responses, needed before a step can cache. See Caching provider responses.
• List store — the entries of your block, allow, and watch lists. Only the execution node in your region reads it, and a list needs it before it can hold a value. See Lists.

They are all set up on the same page, and each starts with a connection.

1. Connect the database

Open Destinations and click + Data destination. You can either:

• Paste a connection string — most providers, including Supabase, give you a ready-made string in the form postgresql://user:password@host:port/dbname. Paste it into the box at the top and click Parse to fill in the fields automatically.
• Or fill in Host, Port, Database, Username, Password and SSL mode by hand.

Use Test connection before saving to confirm Decisimo can reach the database.

The account you give Decisimo needs permission to create tables in the target schema — Decisimo creates its own tables and never touches yours.

Supabase: use the pooler connection string, not the direct one

Supabase gives you several connection strings for the same database, shown in Project Settings → Database → Connection string:

• Direct connection (db.<project-ref>.supabase.co) — this hostname only has an IPv6 address. Decisimo's platform does not have outbound IPv6 connectivity, so this string will never connect from here, even though it works fine from your own laptop if your ISP supports IPv6.
• Session pooler or Transaction pooler (aws-0-<region>.pooler.supabase.com) — these are IPv4-compatible and work correctly with Decisimo. Use one of these.

If you paste or enter the direct connection host by mistake, Decisimo tells you immediately (at save time or when testing the connection) that the host is IPv6-only, and points you back to the pooler connection string. Simply switch to the Session pooler tab in Supabase's connection string panel, copy that string instead, and paste it into the same box — no other changes needed.

2. Say what the database is for

On the connection's page, under Destinations, click + Destination and choose:

• Decision archive — you also choose which schema and table to write to.
• Case board — nothing else to configure.
• Outcome history — you also choose the schema and table, as for the archive.
• Data cache — you also choose the schema and table.
• List store — you also choose the schema and table.

You do not name a destination; Decisimo names it, so there is nothing to get wrong.

One connection can carry several. If you want the same database to hold your decision archive and your case board, add both destinations to the same connection. They write to different tables and never collide, and one password rotation covers both. An outcome history has to sit on the same connection as the archive it belongs to, because analysis joins the two tables inside your database.

3. Prepare it and turn it on

Both steps are needed, and the order depends on which kind of destination it is, because the two schemas are created by different hands.

• Decision archive: prepare, then enable. Decisimo creates the table itself, over the connection you just tested. Create it first, so that when the destination starts taking writes there is somewhere for them to land.
• Case board: enable, then prepare. The case schema is created by an execution node, and a node only accepts a destination that is switched on. Preparing a case board while it is still switched off cannot succeed, however many times you press the button.

Prepare creates what the destination needs in your database:

• For a decision archive, the target table and its indexes.
• For a case board, the case schema, installed by the execution node so that it matches the version your case types were compiled against.
• For a list store, Prepare creates the entry table and its indexes, and the store is enabled after it is prepared, in the same order as a decision archive.

Preparing is safe to repeat. It creates only what is missing, and never drops or alters tables of your own.

Enabled is the step that hands the credential to the execution nodes, so it is the one most likely to have something to report. If the credential does not reach every node, Decisimo says so instead of reporting a clean save.

Is it actually working?

Each destination shows four checks, in the order you should work through them:

A decision archive shows them in that order. A case board shows Enabled third and Board schema last, for the reason given in step 3: its schema cannot appear until the destination is switched on.

The first check that is not satisfied is spelled out underneath, together with the button that clears it. Hover over any check to read what it found. The overall state reads:

• Ready: all four satisfied. Data is flowing.
• Not finished: a step is still waiting on you, such as a connection you have not tested or a destination you have not enabled yet.
• Blocked: something is failing and needs attention.

A database that answers a connection test is not the same as a destination that works. The credential still has to reach the execution nodes, and the tables still have to exist. That is why all four are shown rather than one overall status.

Press ⟳ on the strip to re-run the checks at any time.

What a case board's schema check can tell you

"Unused" destinations

An older setup may show a destination marked Unused. Nothing reads or writes it, so there is nothing to repair and nothing to fix. The only useful action is to delete it.

Rotating the password

If the database password changes on the provider's side, use Rotate password to update it in Decisimo without recreating the whole connection. The previous password remains valid for 24 hours after rotation to avoid a hard cutover, and every destination on that connection is updated together.

Deleting

Deleting a destination stops Decisimo writing to it. Deleting the whole connection removes every destination on it — the confirmation tells you what will go, and names the case board separately if one is attached.

Deleting a case board stops that tenant's cases from running. Decisimo keeps no copy of your case data, so there is nowhere else for it to go.