A released case design does not run inside the portal. An execution node runs its tasks, and the cases themselves are stored in a database you own, connected as a destination with the purpose Case board. Both are set up once per account in the Admin center. Until both are in place, the Test section cannot start a scenario, and no live case can run.
Setup has two parts: choose the execution node that runs your cases, then connect the case board. The readiness checks on the destination show exactly which check, if any, is still blocking it.
- The execution node that runs cases
- The case board destination
- Readiness checks
- Common errors and fixes
The execution node that runs cases
Open the Admin center and select Execution nodes ("Choose which execution node runs your cases."). The page lists every execution node available to your account, along with its Title, API URL, and Runs cases radio button. The node your decision flows use by default carries a Default badge.
Exactly one node runs cases. Select its Runs cases radio button, and the choice is saved immediately. The portal confirms it with "Cases now run on this execution node." If the change cannot be saved, the selection reverts and the portal shows "The case location could not be changed."
When no node is selected, a warning appears above the table: "No execution node is set to run cases. Choose one below." Choose one before releasing a case design, because releasing pushes the release to the node that runs cases.
If the table is empty, the page says "No execution node is available for this account." An execution node is provisioned for you. If none is listed, contact support.
The case board destination
Cases are stored in a PostgreSQL database that belongs to you, such as a Supabase project. The portal connects to it through a connection, and that connection carries destinations describing what the database is used for. The case board is one such destination.
Open the Admin center and select Data destinations ("Manage the databases that receive your decision execution data."). To add a database, click + Data destination. The New connection form asks for a Name, Host, Port, Database, Username, Password, and SSL mode. If you have a connection URI, paste it into Paste connection string and click Parse. The fields fill themselves. Test connection checks the details before anything is saved ("Runs a one-shot SELECT 1 against the target. Nothing is saved."). Then click Create.
Open the connection from the list with Manage. Its detail page has two sections. Connection credentials contains the host and login details. When editing, leave the password blank to keep the stored one. Rotate password replaces it with a grace period ("The previous password is kept for 24 hours so in-flight workers can complete.").
The Destinations section is where you create the case board. Click + Destination and choose the purpose Case board ("Where cases live and run. Required before any case type can execute."). That is the whole form. The page confirms it: "Nothing else to configure. The case schema is created on this database when you prepare it." The connection above supplies the host and credentials. There is no table or schema to name, because the runtime installs its own schema when you prepare the destination.
Two things to know about the purpose:
- It is fixed once the destination exists. If you edit it later, the purpose appears as a badge with "Set when the destination was created."
- One case board serves the whole account. Deleting a connection that carries it shows the warning "This will also remove the case board."
Saving a destination also delivers the database credential to your execution nodes. If a node cannot be reached, the save still succeeds, but the portal warns: "Saved, but the credential did not reach every execution node", with a delivered count. The readiness checks below the row then show its status.
In the destinations table, the case board row shows the purpose, the database name as its target, and an Enabled checkbox. An inactive destination is ignored by the execution nodes.
Readiness checks
Under every destination row is a strip of checks that answers one question: will this destination actually work? Each check appears as a dot with a label. Hover over a dot to read its current message. The strip ends with a verdict, Ready, Blocked, or Not finished. When something is unmet, the first unmet check is highlighted, its message appears next to the verdict, and one button offers the action that clears it. The refresh button on the right runs the checks again.
For a case board, the four checks must be satisfied in this order:
- Reachable. Can the database be opened at all? On failure, the message is "Cannot connect to the database.", with the database's own error underneath. Before any test has run, it reads "The connection has not been tested yet." The button is Test connection.
- Credential. Do the execution nodes hold this database credential? "Some execution nodes do not have this credential yet." or "An execution node could not be reached." Both messages come with a delivered count such as 1/2. The button is Resend credential, which delivers the credential again. "No execution node is assigned to this tenant." means the account has no node at all. There is nothing to click here, so see the section above.
- Enabled. Is the destination switched on? When it is off, the message is "The destination is switched off." The button is Enable, which does the same thing as ticking the Enabled checkbox in the row.
- Board schema. Has the case schema been created on the database? A fresh board reads "The case schema has not been created on this database yet." The button is Prepare destination, which asks the execution node to install the schema. Success is confirmed with "Destination prepared". The check then reads "The case schema is installed.", along with the installed version.
Enabled comes before Board schema on purpose. An execution node refuses to touch a destination that is switched off, so the schema cannot exist before the switch is on. If you look at the schema check while the destination is off, it says exactly that: "Switch this destination on first. An execution node only accepts a case board once the destination is enabled."
Two more messages can appear on the schema check. "The execution node could not open this database." means the node failed to connect. The node's error appears underneath, with Test connection as the action. "Could not check the case schema." means no node could inspect it at all; the Credential check above it explains why.
From start to finish, choose the node that runs cases, create the connection, add the Case board destination, enable it, and prepare it. The strip then reads Ready. A destination that nothing writes to shows Unused instead of the checks, with "Nothing writes to this destination. It can be deleted."
Common errors and fixes
These messages appear in the Test and Cases sections of a case design when the runtime cannot serve a request.
"The case runtime database is behind this release and cannot be read. Release the case design again to migrate it." The case board's schema is older than the release expects. Release the case design again. The release push migrates the board to the current version. The Test section reports the same condition as "This case design needs to be released again before it can be tested."
"This tenant has no case runtime database connected, so nothing can run." There is no enabled case board. Create one as described in the case board destination, or check that the existing one is Enabled and its readiness reads Ready.
"No execution node is configured for this tenant." No node has Runs cases selected. The Test section words it as "No execution node is set to run cases for this tenant. Choose a case location in instance administration." Either way, the fix is the execution node section above.
"The execution node is not responding. Try again shortly." This indicates a transient failure between the portal and the node. Retry after a moment. If the problem persists, run the readiness checks on the case board. A red Reachable or Credential dot narrows down where the path is broken.
"The case runtime returned an error. The detail is in the execution node log." The node accepted the request and then failed on its own side. This cannot be fixed from the portal. Whoever operates the execution node can read the cause in its log.