Bug: Manually-added domains missing from dashboard invite flow dropdown

[geneticallymodifiedfoodforthought]

Problem

The domain dropdown in the dashboard invite members flow is not showing domains where source: manual, only showing domains sourced directly from WorkOS.

This means org admins cannot invite team members via the dashboard UI even when their primary domain is correctly set and verified.

Reproduction

1. Org has a primary domain with source: manual (added via manage_organization_domains or admin tooling, not via WorkOS OAuth)
2. Org admin goes to dashboard invite flow
3. Domain dropdown does not show the manually-added primary domain
4. Admin cannot complete the invite

Example

• Org: LoopMe (org_01KEC0X42PGV55T5N0GTQDAC6X)
• Primary domain: loopme.com — verified, source: manual
• WorkOS domains: loopme.ai, platform.loopme.ai (source: workos)
• Result: loopme.com missing from dropdown; loopme.ai and platform.loopme.ai presumably appear

Root cause hypothesis

The invite flow dropdown is likely querying domains directly from WorkOS rather than from our DB, which contains both WorkOS-sourced and manually-added domains. The fix should pull from the DB (or merge both sources) so all verified domains for an org appear regardless of source.

Fix

The domain dropdown should include all verified domains for the org from the DB, not only those with source: workos.

Workaround (for affected members now)

Admin can manually add the team member via add_member_to_org tool without requiring the UI invite flow.

Related

• Escalation Add comprehensive org details tool and improve prospect management #475 (May Lyn Tan / LoopMe)

[bokelley]

Flag: root cause requires hands-on reproduction — stated mechanism does not match the code

Two independent expert reviews found that the bug mechanism described here does not match the implementation. Before any code change, someone with dashboard access and DB access needs to reproduce the failure.

---

What the code actually does (not broken as described)

The /team invite modal has three fields: a free-text email input, a role selector, and a seat-type selector — there is no domain dropdown. The backend endpoint accepts any email address and routes it through a state machine regardless of the address's domain.

GET /api/organizations/:orgId/domains queries organization_domains directly with no source filter, returning all verified domains. The UI is already DB-sourced, not WorkOS-sourced.

Where the real failure is likely occurring

The state machine in server/src/routes/organizations.ts calls workos.userManagement.sendInvitation(...) for addresses whose domain is associated with a WorkOS organization. If the affected org's domain was added via admin tooling rather than through the DNS-TXT verification flow, it may be stored as source: manual in organization_domains — meaning WorkOS does not recognize it as a verified domain. In that case, sendInvitation may return an error that is not handled gracefully, producing a silent failure or a generic error in the UI.

---

Reproduction steps needed (for someone with dashboard + DB access)

1. Log into the dashboard as an admin for the affected org and attempt to add a member with an @[org-domain] address using the "Add member" form on /team. Record the exact error or behavior.
2. Query organization_domains for this org: check source, verified, and is_primary for the domain in question.
3. Check the WorkOS console to confirm whether the domain is registered there or is DB-only.

If step 1 succeeds, the failure may be transient or already resolved (the Addie workaround and the UI invite path call the same backend). If step 1 fails, the error from the API response will identify the actual root cause.

---

If reproduction confirms a real code bug — likely fix

The sendInvitation call site should handle rejection for domains that are DB-verified but not WorkOS-registered, and fall back to the direct membership creation path rather than surfacing a generic error. This is a bounded, non-breaking change confined to server/src/routes/organizations.ts.

⚠️ The source-based guard on the primary domain promotion endpoint is a deliberate security control and must not be relaxed as part of any fix here.

Risk flag: Acting on the stated root cause (adding a domain source dropdown or merging domain sources) would modify code that is already working correctly and would not address the actual failure point.

---

Triaged by Claude · Bucket: admin / ops tools · Experts: internal-tools-strategist, dx-expert · Priority: P1

---

Generated by Claude Code

[bokelley]

Production verification on 2026-07-18 found no active defect:\n\n- The reported primary domain is verified in the local organization record, and WorkOS now also reports it as verified.\n- The current team invite UI has no domain dropdown.\n- The backend invite state machine does not gate on the local domain source.\n- This organization has successful historical invitations.\n\nThe reported source-based failure is therefore stale or non-reproducible against current production. Closing this incident. If it recurs, please reopen with the exact UI/API error and timestamp so we can trace the failing state-machine branch.