fix(workflows): get random workflow color when none provided on create

[TheodoreSpeaks]

Summary

• Mothership/copilot-created workflows were always blue — the server-side create path never passed a color, so the stored value was null and the display layer fell back to hardcoded #3972F6
• Defaulted the color centrally in performCreateWorkflow (params.color ?? getNextWorkflowColor()) so any caller omitting a color gets a random palette color
• UI-created workflows unchanged (they still pass their own color via the contract)

Type of Change

• Bug fix

Testing

Tested manually. bun run lint and bun run check:api-validation:strict both pass.

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)

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		May 29, 2026 12:13am

[cursor]

PR Summary

Low Risk
Single-path default in workflow creation with no auth, security, or data-model changes; explicit params.color still wins.

Overview
Server-side workflow creation now assigns a palette color when callers omit color, instead of persisting null and relying on the UI’s hardcoded blue fallback.

In performCreateWorkflow, the change resolves color as params.color ?? getNextWorkflowColor() and uses that value for the DB insert, audit metadata, and the returned workflow object. Callers that already pass a color (e.g. the UI) are unchanged.

^{Reviewed by Cursor Bugbot for commit 0c9364b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Greptile Summary

This PR fixes a bug where workflows created server-side (e.g. by Mothership/Copilot) always displayed as blue because no color was passed to performCreateWorkflow, leaving the DB value null and triggering a hardcoded #3972F6 fallback in the display layer. The fix adds params.color ?? getNextWorkflowColor() once at the top of the function and replaces the three downstream params.color references with the resolved color variable.

• Bug fix in workflow-lifecycle.ts: a single ?? default at line 216 ensures any caller that omits color receives a randomly selected palette color from WORKFLOW_COLORS.
• The getNextWorkflowColor() helper uses a cryptographically secure randomItem call over a non-empty as const array, so no edge-case risk of undefined or an error.

Confidence Score: 5/5

Safe to merge — the change is a minimal, well-scoped default-value addition with no side effects on existing callers that already supply a color.

The diff touches a single function in one file, resolves the null-color storage issue at the right abstraction level, and uses an already-tested utility (randomItem over a non-empty as const array). Existing UI-created workflows are unaffected because they still pass params.color. No error-handling paths, schema migrations, or concurrency concerns are introduced.

No files require special attention.

Important Files Changed

Filename	Overview
apps/sim/lib/workflows/orchestration/workflow-lifecycle.ts	Adds a getNextWorkflowColor() fallback via ?? in performCreateWorkflow so server-side callers that omit params.color no longer store null and display blue; change is applied consistently to all three downstream uses of the color value.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[performCreateWorkflow called] --> B{params.color provided?}
    B -- Yes --> C[Use params.color]
    B -- No --> D[Call getNextWorkflowColor]
    D --> E[Pick random item from WORKFLOW_COLORS]
    E --> C
    C --> F[Insert workflow to DB with color]
    C --> G[recordAudit with color]
    C --> H[Return workflow object with color]

Loading

_{Reviews (1): Last reviewed commit: "fix(workflows): default workflow color w..." | Re-trigger Greptile}