Workflow action to run another workflow (RUN_WORKFLOW)

[abhinavapasok]

Scope & Context

Workflows cannot call other workflows. Every workflow is a self-contained graph, so shared logic (notify the owner, post to Slack, enrich a company, log an activity) has to be rebuilt step by step in each workflow that needs it, and kept in sync by hand when it changes.

This ticket proposes a RUN_WORKFLOW action that starts a run of another workflow, in fire-and-forget mode only. Waiting for the child run and reading its result back is deliberately out of scope (see "Not in this change").

Current behavior

There are 20 action types in WorkflowActionType (packages/twenty-shared/src/workflow/types/WorkflowActionType.ts); none starts another workflow.

The closest workarounds are:

• Duplicate the shared steps into every workflow (the current default).
• HTTP_REQUEST to the workspace's own webhook trigger URL. This works but requires the callee to expose a webhook trigger (a public, unauthenticated URL), and pays an HTTP round trip through the public endpoint for an in-process operation.

Expected behavior

A RUN_WORKFLOW action available in the action picker ("Run workflow"), with settings:

• workflowId: the workflow to run, picked from the workspace's workflows.
• input: an object mapped by the user from the parent's variables, passed to the child as its trigger payload.

At execution time the action:

1. Resolves the callee's active version (fails the step with a clear message if the workflow has no active version).
2. Calls WorkflowRunnerWorkspaceService.run({ workflowVersionId, payload, source }), with source built with FieldActorSource.WORKFLOW and the parent workflow's name, the same way WorkflowTriggerJob does today.
3. Returns { workflowRunId } as the step result so downstream steps can reference the child run.

The child run is a normal workflowRun record: it shows up in the callee's run list, throttling applies, retry and stop work as for any other run.

The parent run does not wait for the child.

Guards

• The callee must have an active version. Rejected at execution time with WorkflowStepExecutorException, and the step editor should warn when the selected workflow is not active.
• Recursion: a workflow calling itself (directly or through a chain) should be capped. Proposal: carry a runDepth in the trigger payload metadata alongside the existing WORKFLOW_TRIGGER_METADATA_KEY and fail the step above a fixed depth (for example 5). Open to a different mechanism if the team prefers.

Not in this change

• Waiting for the child run to finish and resuming the parent with the child's result. This needs a parent link on the run (parentWorkflowRunId / parentStepId) and a completion hook in endWorkflowRun, which the pendingEvent + resume-job pattern used by DELAY could support later. Since the run entity's relations are still being rewired for the core workflow tables (feat(workflow): read and dispatch workflow versions from core everywhere #24830, feat(workflow): dispatch workflow triggers on core ids #25104, feat(workflow): add workspaceWorkflowId to core workflows #25723), I'd keep the initial PR free of entity changes.
• Passing the whole parent context implicitly. The input mapping is explicit, like other actions.

Implementation notes

Server:

• WorkflowActionType.RUN_WORKFLOW in twenty-shared.
• workflow-executor/workflow-actions/run-workflow/ with the action, guard, settings type and module, following delay/.
• Register in workflow-action.factory.ts, workflow-action.type.ts, and defaults in workflow-version-step-operations.workspace-service.ts.

Front:

• RunWorkflowAction.ts in workflow-actions/constants/actions/, added to FlowActions.ts.
• WorkflowEditActionRunWorkflow.tsx with a workflow picker and the input mapping form.
• getActionIcon.ts, getActionIconColorOrThrow.ts, WorkflowDiagramStepNodeIcon.tsx, WorkflowStepDetail.tsx, WorkflowRunStepNodeDetail.tsx, computeStepOutputSchema.ts (output: workflowRunId).

Size should be comparable to the DELAY action (#14915).

Happy to take this on if the scope above works for you. The main thing I'd like a call on before writing code is the recursion guard.

[twenty-eng-sync[bot]]

This is a feature request, not a bug.

Restated: The request is to add a workflow action that can trigger another workflow (RUN_WORKFLOW), enabling reusable logic and reducing duplication.

Severity: UNDEFINED, as this is a feature request (the current behavior is as designed; no defect or regression).

Root-cause: Not applicable; this would require new features in both server (packages/twenty-server/src/engine/workflow-executor/workflow-actions/) and frontend (packages/twenty-front/src/modules/workflows) and changes to shared definitions in packages/twenty-shared/src/workflow/types/WorkflowActionType.ts.

The report is clear and complete for a feature proposal; no missing info.

[BOHEUS]

@thomtrp I recall similar issue in core-team-issues but can't find it at all

[abhinavapasok]

A PR implementing this is up: #26032 — adds the RUN_WORKFLOW action (server + front + tests) per the scope above (fire-and-forget, explicit input mapping, runDepth-capped recursion guard, no entity changes to the workflow run tables). Happy to take feedback there.