feat(logs): add workflow trigger type for sub-workflow executions

[waleedlatif1]

Summary

• Add workflow trigger type so sub-workflow executions show "Workflow" instead of "API" in logs
• Add blue-secondary badge variant and filter option for the new trigger type
• Update workflow executor tool to send triggerType: 'workflow'

Type of Change

• New feature

Testing

Tested manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[cursor]

PR Summary

Low Risk
Low risk: adds a new allowed trigger enum value and updates UI labeling/coloring plus the workflow executor request payload, with minimal behavioral impact beyond log categorization/filtering.

Overview
Adds a new workflow trigger type so sub-workflow executions are logged and displayed as Workflow instead of API.

Updates logs UI/filtering to recognize workflow as a core trigger (badge variant/color mapping and trigger filter options), and changes workflowExecutorTool to send triggerType: 'workflow' (with tests updated accordingly).

^{Written by Cursor Bugbot for commit 79b935b. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 13, 2026 1:32am

[greptile-apps]

Greptile Summary

This PR adds a dedicated 'workflow' trigger type for sub-workflow executions so that logs display "Workflow" rather than "API" when a parent workflow invokes a child. The change is well-scoped: the executor tool sends triggerType: 'workflow' in the request body, CORE_TRIGGER_TYPES is extended to pass API route Zod validation, a new blue-secondary badge variant is mapped for display, and a filter option is wired up. All 15 tests are updated to match.

Key findings:

• The new 'workflow' trigger type is not handled in execution-core.ts's executionKind derivation (line 228), causing it to fall back to 'manual' instead of 'api'. This silently broadens which start blocks sub-workflows can use (SPLIT_MANUAL and EXTERNAL_TRIGGER become valid start blocks), which is a behavioural side-effect not mentioned in the PR description.
• The filter dot color #1e40af (blue-800 family) is inconsistent with the blue-secondary badge variant's sky-family colors (#bae6fd / #0369a1), creating a subtle visual mismatch in the logs filter UI.

Confidence Score: 3/5

• Safe to merge for the logging/display goal, but carries an unintentional behavioural side-effect in sub-workflow start block resolution that should be reviewed.
• The display changes are correct and all tests pass. However, the unhandled 'workflow' case in execution-core.ts silently changes sub-workflow execution behaviour (manual and external trigger blocks become valid start points), which is a logic side-effect that falls outside the stated scope of the PR.
• apps/sim/lib/workflows/executor/execution-core.ts (not modified in PR but affected by the triggerType change)

Important Files Changed

Filename	Overview
apps/sim/tools/workflow/executor.ts	Core change: triggerType in the request body is switched from 'api' to 'workflow'. The change is clean and isolated. Indirect behavioral side-effect exists in execution-core.ts (not modified here) where 'workflow' falls through to 'manual' executionKind.
apps/sim/tools/workflow/executor.test.ts	All 15 test cases updated from triggerType: 'api' to triggerType: 'workflow' to match the new executor behavior. Changes are mechanical and complete.
apps/sim/stores/logs/filters/types.ts	Adds 'workflow' to CORE_TRIGGER_TYPES. This is necessary for Zod validation in the execute API route (z.enum(CORE_TRIGGER_TYPES)) to accept the new trigger value.
apps/sim/app/workspace/[workspaceId]/logs/utils.ts	Maps 'workflow' trigger to the 'blue-secondary' Badge variant. The blue-secondary variant is confirmed to exist in the Badge component. Change is correct.
apps/sim/lib/logs/get-trigger-options.ts	Adds 'workflow' filter option with color #1e40af. Minor visual inconsistency: the filter dot color (dark blue-800) doesn't match the sky-family colors used by the blue-secondary badge variant.

Sequence Diagram

sequenceDiagram
    participant PW as Parent Workflow
    participant WET as workflowExecutorTool
    participant API as /api/workflows/[id]/execute
    participant EC as execution-core.ts
    participant Log as LoggingSession

    PW->>WET: execute sub-workflow block
    WET->>API: POST { triggerType: "workflow" }
    API->>API: Zod validate (CORE_TRIGGER_TYPES includes "workflow" ✅)
    API->>EC: executeWorkflowCore({ triggerType: "workflow" })
    EC->>EC: executionKind = "manual" (falls through, not "api")
    EC->>EC: findStartBlock(blocks, "manual") — broader block match
    EC->>Log: log with triggerType="workflow"
    Log-->>PW: logs show "Workflow" badge (blue-secondary) ✅

Loading

Comments Outside Diff (1)

1. apps/sim/lib/workflows/executor/execution-core.ts, line 228 (link)

   Unhandled workflow trigger type in executionKind derivation

   execution-core.ts line 228 derives executionKind as follows:

   const executionKind =
     triggerType === 'api' || triggerType === 'chat' ? (triggerType as 'api' | 'chat') : 'manual'

   With the new triggerType: 'workflow' sent by the executor tool, this falls through to 'manual'. This changes which start blocks are eligible for sub-workflow execution:

   • Before (executionKind = 'api'): resolves UNIFIED → SPLIT_API → SPLIT_INPUT → LEGACY_STARTER
   • After (executionKind = 'manual'): resolves UNIFIED → SPLIT_API → SPLIT_INPUT → SPLIT_MANUAL → LEGACY_STARTER → EXTERNAL_TRIGGER

   Sub-workflows that contain manual-only trigger blocks will now be found and executed when called as a child, which was previously not possible. While this is more permissive, it is an unintentional side effect of the labelling change. If the intent is to preserve the API-like block selection for sub-workflow executions, execution-core.ts should be updated to explicitly handle 'workflow':

   const executionKind =
     triggerType === 'api' || triggerType === 'workflow'
       ? 'api'
       : triggerType === 'chat'
         ? 'chat'
         : 'manual'

_{Last reviewed commit: 79b935b}