Skip to main content

Automations in Apps

Connect an automation once, then use it from a button, a request card, a form or another custom App interface. The connection belongs to the App and is independent of how its data is displayed.

Connect an automation​

  1. Add a Manual trigger to the automation and activate it in the intended workspace.
  2. Open the App in Operations Studio and choose Automations in the editor toolbar.
  3. Choose Connect automation, select the workflow and give the App action a useful name.
  4. Add an action button, choose App automation, and select the connected action.
  5. Add any fixed inputs the button needs. The editor supports text, numbers, yes/no values and structured JSON.

Connecting and configuring never starts a workflow. Studio previews keep execution disabled. Save and publish the App, then test it as the intended user with agreed test data.

Renaming an App action keeps its logical ID. Disconnecting keeps the automation and its past runs; replace references in configured buttons and custom code before publishing. Publication checks that connected workflows are active, have a Manual trigger and belong to the same workspace.

Run and inspect​

A button starts the workflow and opens its progress. Completion, running, approval, waiting, failure and uncertain outcomes have distinct statuses. Refresh progress loads the current receipt. Recent runs reopens your own runs for that action in the current published App version.

If a response is lost, Check and retry recovers the same intended run. It does not create a new request. Use Resume workflow only when the run offers it; approval and external-result recovery continue through the existing workflow controls. A workflow that is waiting for an event or timer continues through its normal background worker.

Run history is private to the invoking user and published App version. Republishing does not delete stored runs, but the new version has its own run list. Connected workflows remain subject to current permissions and activation state.

Use live input from custom interfaces​

Konnie can build an interface that sends values from a form, a selected table record, a card or another interaction. Ask it to discover the real automation, connect a named App action, and trigger that action from the intended user interaction. Data queries alone do not trigger workflows.

The same Blueprint can use App data sources to query, create, edit or delete table records and use the connected workflow action for the next step. Keep table changes and workflow receipts separate so the interface can recover a partial result without repeating completed work. See Combining records and workflows for an authoring example.

Code authors use the logical action ID with the governed SDK:

const pending = {
  invocationKey: ennea.automations.createInvocationKey(),
  input: { requestId: selectedRecord._id, priority: "urgent" },
};
const result = await ennea.automations.trigger("review_request", pending);
const run = result.data.run;

Keep pending unchanged if the request's outcome is uncertain. Reuse it when retrying that same intent, and generate a new key only for a distinct request. Disable duplicate submissions while pending. After receiving a run, inspect it with readActionRun(actionId, runId) or listActionRuns(actionId); do not trigger again merely because it is still running. resumeActionRun(actionId, runId) is available for eligible runs.

Inputs are bounded JSON objects: up to 64 KiB, 1,000 values and 10 nesting levels. Send only the values the workflow needs. Workflow conditions and supported dynamic node mappings can read payload.appInput.<inputName>. Inputs cannot override platform identity, scope or App authority. Retired Form-specific table-write bindings cannot be used for new input flows; use the App Table SDK for ordinary record CRUD.

Use explicit buttons (type="button") for SDK actions. Native browser form submission is blocked by the App sandbox. Confirmed automation changes refresh nearby native data views; custom interfaces can requery their own data after the returned run completes.

The current user needs the relevant App and automation permissions. Run inspection returns progress metadata rather than private workflow inputs, outputs or underlying business records. Public event feeds and default AI-provider event context exclude App input; explicitly configured workflow actions keep their existing permissions and data-handling controls.