Open Decisions

This page tracks decisions that haven't been explicitly made yet — either because they were never asked, or because the current behavior might be fine but hasn't been confirmed. Each item should get an owner and an answer before it's considered resolved; don't let "it seems to work" stand in for an actual decision.

1. Ungated routes: fix now or accept the risk?

/bookings/new, /estimate, /workbench/:proposalId, most /admin/* pages, and /csr-intake can be reached by any signed-in user via direct URL, regardless of role. Decision needed: gate these before wider rollout, or explicitly accept the risk for a defined period with a hard deadline to fix it. See /help/permissions/known-gaps.

2. Should Communications and Training really be open to everyone?

Both pages currently have no role restriction. This may well be correct — company-wide comms and training arguably should be broadly visible — but it was never explicitly confirmed as a decision. Decision needed: confirm as intentional, or scope down.

3. Executive vs. Admin: same UI, different server rules

Executive and Admin see an identical sidebar because both bypass all page gates. The real distinction — only Admin can invite users or edit permission sets — is enforced on the server and isn't visible in the UI. Decision needed: either make this distinction visible in the UI (e.g., disable/hide the invite and permission-set-edit controls for Executives) or make sure it's clearly documented and communicated so Executives aren't confused when blocked.

4. /approvals not in the sidebar

The manager approvals queue works but has no sidebar link. Decision needed: add it to the sidebar (and for which roles), or confirm it should remain a direct-link-only page for a specific reason.

5. Legacy /csr-intake page

Predates /bookings/new, still works, still ungated. Decision needed: remove it, redirect it to /bookings/new, or keep it intentionally with a reason.

6. Naming consistency

Decision needed on enforcement, not just definition:

• Use Necessary Components, never "adders," everywhere including internal conversation with customers overhearing, training material, and any customer-facing text.
• SAD = Site Assessment Deposit — spell it out on first use per screen/doc.
• Pipeline stage labels shown in the UI (e.g., "Sold") don't always match internal database keys engineers use (e.g., a differently-named status column). Decide whether to rename the database keys to match, or maintain a documented mapping so support conversations don't get lost in translation. See /help/rollout/naming-conventions.

7. Permission sets are underused

Almost nobody currently has a permission set granted beyond their role defaults. Recommendation: define and adopt one standard permission set per role as a baseline template (e.g., a standard "CSR+" set for CSRs who occasionally need Price Book access), rather than continuing to hand-grant pages one at a time. Decision needed: who owns building these templates, and by when.

8. Demo data flag

The app has a demo-data mode. Decision needed: confirm who is responsible for verifying it's off for every production account before go-live, and how that gets checked (one-time audit vs. ongoing monitoring).

9. No staging environment

All testing currently happens in the same environment used in the field. Decision needed: prioritize a staging split, or accept the risk short-term with a plan to add it.

10. ServiceTitan "Door / slab" bucket blocked

SKU 39723877 was deleted in ServiceTitan; the Door/slab material bucket can't push until a replacement is mapped in /admin/servicetitan-mapping. Decision needed: who owns picking and mapping the replacement SKU, and what should sales/PM staff do with affected jobs in the meantime (hold, manual entry, or something else).

Recommended role segmentation

These are recommendations, not final rules — but they should be explicitly adopted or rejected rather than left ambiguous:

• Phil — stay on door_expert. Don't promote to manager unless he specifically needs manager-level oversight (e.g., approvals, team-wide visibility) beyond his own deals.
• Danielle — stay on csr. Add dispatcher only if she is actually scheduling site assessments herself, not just handling intake/booking calls.
• Sergio — stay on project_manager. Add reconciler only if he's doing scope-validation work himself, not just running the PM side of a project.
• Installer access should remain strictly read-only and kept separate from any Project Manager write access — don't combine the two roles on one account even for a "trusted" installer.
• Prefer permission sets for one-off, individual expansions (e.g., "this one CSR occasionally needs Price Book") instead of stacking extra roles onto an account, which tends to over-grant access broadly.

Ownership

Each item above needs a named owner and a target date. Until that happens, treat this list as unresolved — don't assume "someone's on it."