Overview
Starting with Etlworks 10.0.8, Simba can run as a regular flow. The Run Simba Prompt flow type executes a saved Simba task unattended — manually, on a schedule, from a webhook, or as a step in a nested flow or Composer workflow — and keeps the result in execution history, optionally emailing a formatted report.
Typical uses: a scheduled morning report on failed executions, a resource-incident summary generated from a webhook, or a validation step inside a workflow whose true/false answer decides what runs next.
Each run counts as agentic AI usage. Customer-provided OpenAI keys keep provider-direct billing. If AI is disabled for the identity or the usage limit is reached, the task fails — it does not fall back to a tool-free answer.
Create a Run Simba Prompt flow
Who can create it: a Super Admin or a user with the Administrator (Tenant Admin) role. Editor access and ACL grants are not enough.
Click + on the Flows page and search for Run Simba Prompt (groups: Automation and Orchestration, AI). Parameters:
- Prompt (required, up to 64,000 characters): describe the task and the expected report. The task runs with the current user's permissions, further restricted by the explicit grants below. Configure email recipients below or in the schedule — writing an address in the prompt does not send mail.
- Timeout (seconds): 30 to 3,600 (default 900). Stops model requests and prevents further tool calls at the deadline; a tool already executing may take time to stop.
- Email result to: optional comma-separated addresses (up to 20). Sends the captured output after each run, including partial output on failure, as formatted HTML with execution details in a footer. A delivery failure after a completed task is only a warning.
- Allow changes (off by default): explicitly authorize Simba to create and edit resources during this flow. Grants and executed actions are audited; user access rights still apply.
- Allow destructive and operational actions (off by default; requires Allow changes): authorizes deletion, imports/restores, arbitrary code/SQL, flow execution, stopping/restarting, file writes, and other operational actions without another confirmation.
- Disable manual flow execution: prevents ad-hoc manual runs.
Grants are saved, bounded authorization. Changing the permission checkboxes writes a simba.flow.permissions audit event (flow, tenant, approver, grants, timestamp). Execution logs record the permissions used, the tools invoked, the first 1,000 authorized CLI command names, the session ID, model, token counts, output, and failure details.
Who the task runs as
- Manual runs use the invoking user.
- Scheduled runs use the schedule creator, resolved to a currently enabled user on every run. A disabled or deleted owner, or revoked execution access, fails the run.
- Webhook runs use the administrator who last saved the webhook's Simba target.
A prompt cannot choose a different identity or change billing. Runtime variables are passed to the task as a detached read-only JSON snapshot with the sections globals, flow, values, and unavailable.
Results, reports, and history
- The report is stored with the execution audit in the app database, visible from any app node and from the flow's execution statistics and Log (tail-flow-log also reads it). Partial text is checkpointed while the run is active.
- Limits: up to ten model rounds per run (the last is reserved for the report); report text is capped at 1,000,000 characters — exceeding the cap fails the run and keeps the partial output.
- Reports are data: a completed external effect (something Simba created, changed, or executed) is not rolled back by a later failure or cancellation.
Scheduling
Schedule the flow like any other flow — overlap prevention, retries, history, and notifications all apply. Each retry starts a new agent turn and may repeat changes that already completed, so grant change permissions carefully on retried schedules.
Turn a Simba conversation into a scheduled task
In the Simba chat panel, click the calendar icon (Create scheduled Simba flow) — available for your own chats with messages, after the current response has finished. The dialog proposes:
- Flow name (from your first message) and a Reusable prompt built from the conversation (edit it: remove setup requests and use relative periods such as "the last hour" — previous answers are context, and future runs gather fresh evidence);
- Schedule (interval in seconds, for example 3600 = hourly, or a cron expression in the server timezone), Email result to, Timeout (seconds), Enable schedule, and the two permission checkboxes (off by default).
Create flow and schedule creates a Run Simba Prompt flow and a schedule (named "<flow name> - Schedule", scheduler success/failure emails off — result delivery belongs to the flow's Email result to), with links to open both. The original chat is preserved; each scheduled execution starts a fresh task. Edit the flow and schedule afterward in their normal editors. Retrying the same conversion reuses the matching flow and schedule. You can also simply ask Simba in chat to schedule the task.
Run from a webhook
In the webhook editor, administrators can set Run Simba task to a Run Simba Prompt flow in the same tenant. The webhook then triggers the flow using the approving admin's identity and the flow's permissions; results are stored in flow execution history, and result emails are configured on the flow.
- Saving forces POST with application/json, and a webhook with a Simba target cannot also deliver to URL/email — use a separate webhook for that.
- Delivery history records a 202 status and an X-Etl-Simba-Audit-Id header. The event payload is capped at 64,000 characters.
- Duplicate deliveries do not start a second run, and an overlapping run is rejected ("Simba webhook task was not started"). Simba-generated events do not trigger other Simba targets.
Use in nested flows and Composer
Add the flow as a normal step. A typed boolean result can drive flow control: check Use Simba result as condition on the step's Go to step or End nested flow action — see Branch on a Simba result. A failed Simba step follows the normal exception-handler and Go to on exception rules.
App-only execution: Run Simba Prompt must run on the app — neither the Simba flow nor any parent that contains it can run on an Integration Agent.
Cancellation and recovery
- Use the regular Stop action: cancellation markers are shared across app nodes, the model request is disconnected, and further tool calls are blocked. Timeouts use the same mechanism. A tool already executing may take time to return, and completed side effects are not rolled back.
- A run in progress is not moved to another node; abandoned work is canceled after its lease expires (about 60 seconds) and is not replayed.
Multi-node deployments
- All app nodes must share the same PostgreSQL database/schema and the same Redis database and key namespace.
- The load balancer must preserve the X-Etl-App-Flow-Token header; sticky sessions are not required. The engine must be able to reach the app's Home URL; if needed, set the app property app.flow.bridge.url to an absolute base URL including the context path.
Related: Simba — Etlworks AI Agent, Create and Manage Webhooks.