Single-account escalation
High confidence
Checkout failures for STARK-44’s enterprise team align with a misconfiguration: the enterprise-only customer_org claim on their account is not configured, while other core claims are enabled; prior orders for this account did succeed, suggesting a recent regression surfaced this gap.
What Nirna found
-
Account STARK-44 is on the enterprise plan, status active; claims show email=enabled, name=enabled, customer_org=not_configured.source ↗
-
Order ord_a6c8139fab16 for STARK-44 shows status placed (successful).source ↗
-
Order ord_705e75a37232 for STARK-44 shows status placed (successful).source ↗
-
Order ord_f8e4b7df9150 for STARK-44 shows status placed (successful).source ↗
What this means
Enterprise checkout commonly gates billing/tax/org policy off an organization-level claim; for STARK-44 that claim (customer_org) is not configured while other identity claims are enabled, so the enterprise checkout path likely attempts to read org context and fails, surfacing as a 500. Prior successful orders indicate checkout has worked for this account, and the missing customer_org configuration would explain why enterprise-only paths are now erroring for multiple users. Enabling the customer_org claim for STARK-44 should restore the expected org context and stop the 500s.
Who’s affected
Accounts affected
1
isolated so far
First seen
Jul 25 · 02:19 UTC
Also affects: STARK-44
Recommended fix
Ops change
In the admin console, update STARK-44’s claims configuration:
- Navigate: Accounts > STARK-44 > Claims.
- Change customer_org from not_configured to enabled.
- Save the change.
- Invalidate active sessions for STARK-44 so new tokens include the updated claim (Sessions > Search: STARK-44 > Invalidate all).
- Sanity check: run checkout preflight for a STARK-44 user (e.g., u_stark001) and confirm HTTP 200 on preflight instead of 500.
- Monitor for new checkout attempts from STARK-44 to confirm recovery.
Suggested replies
Copy-paste ready. Your engineer edits and sends.
Customer reply
Thanks for the reports — we do see a clear pattern. Your enterprise account (STARK-44) is missing the customer_org claim that the enterprise checkout flow relies on. We’re enabling that claim on your account now (no action needed on your side) and will invalidate existing sessions so new tokens pick it up. We’ll confirm once our preflight checks pass; after that, a quick sign-out/sign-in should clear any cached sessions. If you can retry checkout once you see our follow‑up, that would be helpful.
Internal note
Remediation steps:
1) Admin console > Accounts > STARK-44 > Claims: set customer_org = enabled (it’s currently not_configured per e1). Save.
2) Sessions > filter by account STARK-44 > Invalidate all, to force fresh tokens with the claim.
3) Verify by running checkout preflight as u_stark001 and confirm 200 (orders for this account previously placed per e2–e4).
4) Post-confirmation, monitor logs for STARK-44 checkout to ensure 500s stop and close the incident if clean for 30 minutes.
Why Nirna reached this conclusion
Verdict — Single-account escalation. Only this account is affected; the evidence points to account configuration mismatch.
Confidence — High. Several checks came back strong: account matched from ticket text, recent deploy touched failing path, account configuration mismatch.
Who fixes it — Ops change. Your ops team can fix this without a deploy — the cause is configuration, an entitlement, or a stale cache they already control.
Who’s affected. Only the reporting account is affected in this window.
| Signal | Score |
|---|---|
| Account matched from ticket text | 0.95 |
| Recent deploy touched failing path | 0.96 |
| Account configuration mismatch | 1.00 |
| Code change in the failing path | 0.00 |
| Feature-flag rollout mismatch | 0.00 |
| Patterns matched in your data | 1.70 |
| Similar recent tickets | 0.00 |
| Different accounts affected | 0.00 |
Was this triage right?
Corrections apply the same day. A wrong-account correction with a domain hint updates the routing rules for the next ticket automatically.