feat: Trigger execution of a graph from dashboard

[NiveditJain]

Trigger a new execution from UI while adding all necessary inputs and store.

Motivation

1. Accessibility – Enable users to trigger graph executions without writing code or using API tools.
2. Rapid testing – Allow developers to quickly test graph configurations and changes directly from the dashboard.
3. Operational convenience – Enable operations teams to manually trigger workflows for troubleshooting, ad-hoc runs, or emergency operations.
4. Input validation – Provide real-time validation and guidance for required inputs and store values before triggering.
5. Visibility – Make it easy to see what inputs and store values are needed for each graph.

Current State

What Exists

Component	Location	Purpose
Graph Templates	Dashboard "Graph" tab	View and edit graph templates
Runs Table	Dashboard "Runs" tab	View execution history
Graph Template Detail Modal	Dashboard	View graph template configuration
Trigger API	State Manager	Programmatic graph triggering via API/SDK

Current Limitations

• No UI option to trigger graph executions
• Users must use Python SDK or API directly to trigger graphs
• No visibility into what inputs/store values are required before triggering
• No validation feedback in UI before triggering
• Cannot easily test graph changes without leaving the dashboard

Proposed Solution

Trigger Graph Dialog/Modal

Add a "Trigger Graph" feature that allows users to:

• Select a graph template to execute
• Provide inputs for the root node
• Provide store values (required and optional)
• Set optional start delay
• Validate inputs before triggering
• See immediate feedback on success/failure

Key Features

1. Graph selection – Choose from available graph templates in the namespace
2. Input form – Dynamic form based on root node's input schema
3. Store configuration – Form for required and optional store values
4. Validation – Real-time validation of inputs and store values
5. Default values – Pre-fill store defaults from graph configuration
6. Start delay – Optional delay before execution starts
7. Success feedback – Show run ID and link to execution view

User Experience

Access Points

1. From Graph Template Detail Modal:

   • "Trigger" button in the graph template detail view
   • Opens trigger dialog pre-populated with selected graph

2. From Graph Templates List:

   • "Trigger" action button for each graph template
   • Opens trigger dialog with selected graph

3. From Runs Table:

   • "Trigger New Run" button at top of runs table
   • Opens trigger dialog to select graph and trigger

Trigger Dialog Flow

1. Graph Selection (if not pre-selected):

   • Dropdown/select showing available graph templates
   • Filter by namespace
   • Show graph validation status (only valid graphs can be triggered)

2. Root Node Inputs Section:

   • Dynamic form fields based on root node's input schema
   • Show field names and types
   • Mark required fields
   • Help text showing example values or descriptions
   • Support for store references: ${{ store.key }} (read-only, shows resolved value)

3. Store Values Section:

   • Required keys: Clearly marked, must be provided
   • Optional keys: Shown with default values (if configured)
   • Default values: Pre-filled from graph's store_config.default_values
   • Add custom keys: Allow adding additional store keys beyond required/optional
   • Validation: Real-time check that all required keys are provided

4. Start Delay (Optional):

   • Input field for delay in milliseconds
   • Helper showing human-readable equivalent (e.g., "5000ms = 5 seconds")
   • Default: 0 (immediate execution)

5. Validation & Trigger:

   • "Trigger" button (disabled until valid)
   • Real-time validation feedback
   • Error messages for missing/invalid inputs
   • Loading state during trigger request
   • Success message with run ID and link to execution

Visual Design

• Modal/Dialog: Centered modal with clear sections
• Form sections: Collapsible sections for Inputs, Store, and Advanced (delay)
• Required indicators: Red asterisks or "Required" badges
• Validation feedback: Inline error messages, field highlighting
• Success state: Green checkmark, run ID prominently displayed
• Error state: Red error message with details

Use Cases

Use Case 1: Quick Test of Graph Changes

Scenario: Developer just updated a graph template and wants to test it immediately.

User action:

1. Navigate to Graph Templates
2. Open the updated graph template
3. Click "Trigger" button
4. Review root node inputs (see what's needed)
5. Fill in required store values (or use defaults)
6. Click "Trigger"
7. See success message with run ID
8. Click link to view execution in real-time

Expected outcome: Graph execution starts, user can immediately see it in the runs table and monitor progress.

Use Case 2: Manual Workflow Execution

Scenario: Operations team needs to manually trigger a data processing workflow with specific parameters.

User action:

1. Navigate to Runs table
2. Click "Trigger New Run" button
3. Select graph from dropdown
4. Fill in root node inputs (e.g., user_id: "12345", batch_size: "100")
5. Configure store values:
   • Required: cursor: "0", batch_id: "batch_001"
   • Optional: retry_count: "3" (uses default if not provided)
6. Set start delay to 10 seconds (10000ms)
7. Review all inputs
8. Click "Trigger"
9. See confirmation with run ID

Expected outcome: Workflow starts after 10-second delay with specified inputs and store values.

Use Case 3: Testing with Different Store Values

Scenario: Developer wants to test how a graph behaves with different store configurations.

User action:

1. Open graph template
2. Click "Trigger"
3. See pre-filled default store values
4. Modify store values (e.g., change cursor from "0" to "100")
5. Add custom store key test_mode: "true"
6. Trigger execution
7. Repeat with different values to compare behavior

Expected outcome: Multiple test runs with different store configurations, easy to compare results.

Use Case 4: Triggering Graph with Store-Referenced Inputs

Scenario: Root node inputs reference store values (e.g., "cursor": "${{ store.cursor }}").

User action:

1. Open graph template
2. Click "Trigger"
3. See root node input field showing cursor: "${{ store.cursor }}"
4. Input field is read-only or shows resolved value
5. Fill in store section with cursor: "50"
6. See input field update to show resolved value "50"
7. Trigger execution

Expected outcome: Store values are properly resolved into root node inputs before execution.

Acceptance Criteria

Graph Selection

• Users can select a graph template from available graphs in namespace
• Only valid graphs can be selected/triggered
• Invalid graphs show appropriate message (e.g., "Graph is not valid")
• Graph selection can be pre-populated when accessed from graph detail view

Root Node Inputs

• Form fields dynamically generated based on root node's input schema
• Required inputs are clearly marked
• Input types are shown (string, number, etc.) or inferred
• Store references in inputs are shown and resolved
• Validation prevents triggering with missing required inputs
• Help text or examples shown for complex inputs

Store Configuration

• Required store keys are clearly marked and must be provided
• Optional store keys show default values (if configured)
• Users can add custom store keys beyond required/optional
• Default values from graph config are pre-filled
• Validation ensures all required keys are provided
• Store key constraints are enforced (no dots, non-empty)

Start Delay

• Optional delay field available
• Delay accepts milliseconds (integer)
• Human-readable equivalent shown (e.g., "5 seconds")
• Default value is 0 (immediate execution)
• Validation ensures non-negative value

Triggering & Feedback

• "Trigger" button validates all inputs before enabling
• Loading state shown during trigger request
• Success message displays run ID
• Link to execution view provided after successful trigger
• Error messages are clear and actionable
• Network errors are handled gracefully

UI/UX

• Modal/dialog is accessible and keyboard-navigable
• Form sections are clearly organized
• Validation feedback is immediate and clear
• Mobile-responsive design
• Consistent with existing dashboard design patterns

Non-Goals

• Bulk triggering – Single graph execution per trigger (bulk can be future enhancement)
• Scheduled triggering – One-time execution only (scheduling via cron triggers is separate)
• Input templates/presets – Manual input entry only (templates can be future enhancement)
• Import/export inputs – Manual entry only (import/export can be future enhancement)
• Trigger history – No saved trigger configurations (can be future enhancement)

Open Questions

1. Input schema discovery: How do we get the root node's input schema? From registered node metadata?
2. Store key discovery: How do we show which store keys are used by nodes? Parse input templates?
3. Input validation: Should we validate input types (string, number) or accept strings only (current API behavior)?
4. Default input values: Should graphs support default input values for root node, or only store defaults?
5. Trigger from run details: Should users be able to "re-trigger" a graph with same inputs from a previous run?
6. Input examples: Should we show example values or previous successful input combinations?
7. Store value types: Currently store values are strings only - should UI enforce this or allow other types with conversion?

Additional Notes

• This feature focuses on user-facing functionality and UI/UX, not implementation details
• Implementation should leverage existing trigger API endpoint
• Consider integration with feature-plan feat: Add UI based workflow builder #636 (UI workflow builder) - trigger could be accessible from builder
• Consider integration with feature-plan feat: delete graph and pending execution #608 (delete/cancel) - triggered runs should be cancellable
• Future enhancements could include: input templates, trigger history, bulk triggering, scheduled one-time triggers

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

_{You can configure auto-planning by selecting labels in the issue_enrichment configuration.}

🔗 Similar Issues

Possible Duplicates

• Add an option to trigger a graph from UI #441

Related Issues

• Stop execution of a graph from Dashboard #443
• feat: delete graph and pending execution #608
• Add documentation on Graphs & Triggering them #204
• Show Triggers in GraphTemplateView #439

👤 Suggested Assignees

• NiveditJain
• nk-ag

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!