feat: Add defaultChatflowId to OrganizationConfig for org-level default chatflow override

[diecoscai]

Feature Description

Add a defaultChatflowId field to the OrganizationConfig interface so admins can update the default chatflow for their entire organization through the existing config API — without needing direct database access or server-wide env var changes.

Problem Statement

When an organization needs to change the default chatflow (shown in the Chrome extension and used on login), there are currently only two options:

1. Direct database manipulation — update user.defaultChatflowId for every user in the org
2. INITIAL_CHATFLOW_IDS env var — server-wide setting, not per-org, and still requires clearing per-user DB records to take effect

Neither option is suitable for production org management. There is no self-service, org-scoped way to change the default chatflow template.

Proposed Solution

1. Extend OrganizationConfig in packages/server/src/types/guardrails.ts to include defaultChatflowId?: string

2. Update findOrCreateDefaultChatflowsForUser middleware in packages/server/src/middlewares/authentication/findOrCreateDefaultChatflowsForUser.ts:

   • After the early-exit check for latestUser.defaultChatflowId, read the org config
   • Compare the org config's defaultChatflowId against the user's existing chatflow's parentChatflowId
   • If they differ (template changed), re-clone the new template for the user and update user.defaultChatflowId
   • Fall back to INITIAL_CHATFLOW_IDS env var if no org-level override is set

3. No new API endpoints needed — the existing GET/PUT /api/v1/organizations/:id/config endpoints already handle reading and writing organizationConfig.

Desired Flow After Implementation

1. Admin calls PUT /api/v1/organizations/:id/config with { "defaultChatflowId": "new-chatflow-uuid" }
2. On next user login, findOrCreateDefaultChatflowsForUser reads org config, detects the template has changed (via parentChatflowId comparison), re-clones the new template for the user
3. User's defaultChatflowId is updated to point to their new clone
4. No direct DB manipulation or env var changes required

Key Files to Modify

• packages/server/src/types/guardrails.ts — add defaultChatflowId?: string to OrganizationConfig interface (line 282)
• packages/server/src/middlewares/authentication/findOrCreateDefaultChatflowsForUser.ts — wire in org config lookup and template-change detection

Files for Reference (No Changes Needed)

• packages/server/src/services/organizations/index.ts — getOrganizationConfig / updateOrganizationConfig services already exist
• packages/server/src/routes/organizations/index.ts — GET/PUT /api/v1/organizations/:id/config routes already exist

Acceptance Criteria

• OrganizationConfig interface includes defaultChatflowId?: string
• findOrCreateDefaultChatflowsForUser reads org config and uses defaultChatflowId when present
• If the org config defaultChatflowId differs from the user's current parentChatflowId, the new template is cloned and user.defaultChatflowId is updated on next login
• Falls back to INITIAL_CHATFLOW_IDS env var when no org-level override is configured
• Existing behavior is fully preserved when neither org config nor env var is set
• No new database migrations required (uses existing organizationConfig JSONB column)
• No new API routes required (uses existing /api/v1/organizations/:id/config endpoints)

[mittayrmalak-boop]

Thanks for the detailed proposal and breakdown. We'll review this and see how it fits into the current org configuration workflow.

…

On Mon, Mar 30, 2026, 10:23 AM DiegoC ***@***.***> wrote: *diecoscai* created an issue (FlowiseAI/Flowise#6085) <#6085> Feature Description Add a defaultChatflowId field to the OrganizationConfig interface so admins can update the default chatflow for their entire organization through the existing config API — without needing direct database access or server-wide env var changes. Problem Statement When an organization needs to change the default chatflow (shown in the Chrome extension and used on login), there are currently only two options: 1. *Direct database manipulation* — update user.defaultChatflowId for every user in the org 2. *INITIAL_CHATFLOW_IDS env var* — server-wide setting, not per-org, and still requires clearing per-user DB records to take effect Neither option is suitable for production org management. There is no self-service, org-scoped way to change the default chatflow template. Proposed Solution 1. *Extend OrganizationConfig* in packages/server/src/types/guardrails.ts to include defaultChatflowId?: string 2. *Update findOrCreateDefaultChatflowsForUser middleware* in packages/server/src/middlewares/authentication/findOrCreateDefaultChatflowsForUser.ts : - After the early-exit check for latestUser.defaultChatflowId, read the org config - Compare the org config's defaultChatflowId against the user's existing chatflow's parentChatflowId - If they differ (template changed), re-clone the new template for the user and update user.defaultChatflowId - Fall back to INITIAL_CHATFLOW_IDS env var if no org-level override is set 3. *No new API endpoints needed* — the existing GET/PUT /api/v1/organizations/:id/config endpoints already handle reading and writing organizationConfig. Desired Flow After Implementation 1. Admin calls PUT /api/v1/organizations/:id/config with { "defaultChatflowId": "new-chatflow-uuid" } 2. On next user login, findOrCreateDefaultChatflowsForUser reads org config, detects the template has changed (via parentChatflowId comparison), re-clones the new template for the user 3. User's defaultChatflowId is updated to point to their new clone 4. No direct DB manipulation or env var changes required Key Files to Modify - packages/server/src/types/guardrails.ts — add defaultChatflowId?: string to OrganizationConfig interface (line 282) - packages/server/src/middlewares/authentication/findOrCreateDefaultChatflowsForUser.ts — wire in org config lookup and template-change detection Files for Reference (No Changes Needed) - packages/server/src/services/organizations/index.ts — getOrganizationConfig / updateOrganizationConfig services already exist - packages/server/src/routes/organizations/index.ts — GET/PUT /api/v1/organizations/:id/config routes already exist Acceptance Criteria - OrganizationConfig interface includes defaultChatflowId?: string - findOrCreateDefaultChatflowsForUser reads org config and uses defaultChatflowId when present - If the org config defaultChatflowId differs from the user's current parentChatflowId, the new template is cloned and user.defaultChatflowId is updated on next login - Falls back to INITIAL_CHATFLOW_IDS env var when no org-level override is configured - Existing behavior is fully preserved when neither org config nor env var is set - No new database migrations required (uses existing organizationConfig JSONB column) - No new API routes required (uses existing /api/v1/organizations/:id/config endpoints) — Reply to this email directly, view it on GitHub <#6085?email_source=notifications&email_token=CAXJWKQWLYIAEXWLE2UYEVT4TKGQPA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NBRG4YTMNZYGM3DBJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CAXJWKVN3S7YJXVPSSU6ZA34TKGQPAVCNFSM6AAAAACXGK4332VHI2DSMVQWIX3LMV43ASLTON2WKOZUGE3TCNRXHAZTMMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>