Manage Leads (route /leads in Signal, Power Digital's internal BI web app) is the screen where Team Leads and above declare who actually works on each client, department by department, and how each client's monthly revenue is credited across those people. It lists every revenue-bearing client (from Vena, the finance contract system), shows the team currently on each department (auto-detected from Nova's staffing history until a manager takes over), and lets managers add/remove/reorder people, set custom revenue-split percentages, assign Consulting roles (Sr. AD / AD / AM / PM), and set the client-level Account Director and Senior Account Director. It answers: "Who owns this account this month, and how much revenue should each person be credited with?" Team membership and split percentages are saved to Signal's own records (entered by users in Signal); the Account Director / Sr. Account Director chips write directly into Nova (the ops platform) as of July 2026. These saved assignments feed every per-employee revenue metric in Signal (employee MRR books, RPE, seat counts, capacity views).
Field | Value |
Route | /leads |
Access | Team Lead and above (TeamLeadRoute guard; Admin, Gandalf, and Sauron tiers implicitly qualify). Base-tier members and non-elevated users are redirected to /summary |
Nav section | People (link "Manage Leads", flagged teamLeadOnly) |
Primary data sources | Vena (client/department monthly revenue, contract type, division); Nova (staffing history for auto-detected teams, employee roster, client metadata, live AD/Sr. AD designations via Nova's GraphQL API); Signal's own records — entered by users in Signal (saved team assignments, revenue-split overrides, consulting-role snapshots, managed-client decisions, multi-division assignments, change history) |
Writes | Signal's own records: team_assignments, revenue_split_overrides, consulting_roles, managed_clients, change_history, multi_division_assignments; Nova (directly): client Account Director / Sr. Account Director via POST /api/nova/assignments (Nova updateClient GraphQL mutation), plus a server-side Nova push of the reconciled AD after Consulting team saves |
Key code refs | src/views/ManageLeadsView.tsx, src/utils/allocation.ts, src/utils/multiDivision.ts, src/context/DataContext.tsx (updateAccountLeads, setNovaDirectorAssignment), src/services/supabase.ts (replaceTeamAssignments, saveAllOverridesForAccount), src/App.tsx (route + nav), server/index.ts (/api/assignments, /api/team-assignments, /api/nova/assignments*, /api/client-account-directors*, /api/managed-clients, /api/assignments/backup, /api/auth/ensure-provisioned), server/vena-kpi-engine.ts (getAssignmentsData), server/nova-queries.ts, server/nova-mutations.ts, server/multi-division-assignments.ts, docs/designs/nova-graphql-migration.md |
Last verified | staging @ 98df0c4, verified 2026-07-07 |
Purpose
Manage Leads exists because no single upstream system reliably answers "who owns this account today, and how much revenue should each person be credited with?" Vena (Power Digital's finance contract system) knows how much revenue each client pays per department; Nova (the ops platform) has a staffing record that can be stale or incomplete. Manage Leads closes the gap: it shows every active client, its departments, and each department's monthly revenue (from Vena), pre-fills the team from Nova's staffing history, and lets managers assert the real team — who leads, who supports, what Consulting role each person plays, and (when the default split rules don't fit) the exact percentage of revenue each person should be credited. Manager-confirmed team assignments are stored in Signal's own records and become the authoritative staffing picture for that client and month. Every downstream Signal metric that says "this employee manages $X of MRR" — employee books, Revenue Per Employee (RPE), seat counts, capacity views — traces back to what someone saved on the Manage Leads screen. Since July 2026, the client-level Account Director and Senior Account Director chips additionally write straight into Nova itself, so Nova and Signal agree on the AD of record.
Access & visibility
The Manage Leads view at /leads is wrapped in TeamLeadRoute (defined in src/App.tsx): any user whose isTeamLead flag is false is redirected to /summary. The nav link "Manage Leads" sits in the People section of the left sidebar and carries the teamLeadOnly flag, so users below Team Lead never see the link either.
How the Team Lead flag is granted (mechanics verified in src/context/AuthContext.tsx and server/index.ts as of Jul 2026):
The flag lives in Signal's own records: column is_team_lead on the app_users table. is_admin and is_gandalf users implicitly count as Team Leads (effectiveTeamLead = is_team_lead OR is_admin OR is_gandalf), and Sauron super-admins (a hardcoded email allowlist in code) get every flag automatically.
Automatic grant: on every sign-in the frontend calls POST /api/auth/ensure-provisioned. The server creates the user's app_users row if missing and auto-sets is_team_lead = true when the user's email appears as an active Account Director (Nova field executive_sponsor_id) or Group Director (group_director_id) on any Nova client (email set cached server-side for 1 hour). The endpoint never downgrades the flag from true to false.
Manual grant: an Admin/Gandalf user can set is_team_lead on the General Access screen (/users), which edits the same app_users records.
Role flags are cached in the browser's sessionStorage so a slow database check never demotes a user mid-session; sign-in itself is Google OAuth restricted to the company email domain.
Data sources & lineage
Never treat the transport (data warehouse, caches) as the source — origins below are the systems where the data is authored.
On-screen element | Origin system | Code path | Refresh | Caveat |
Client list, department rows, monthly revenue / MGP / outsource cost per row | Vena (finance contract system; Vena writes, Signal reads only) | DataContext → GET /api/assignments (server/index.ts) → getAssignmentsData() in server/vena-kpi-engine.ts → FINAL_VENA_CONTRACTS (one row per blueprint × department × service × month) | In-memory server cache, 4-hour default TTL (server/vena-cache.ts, code constant) | VABO rows are displayed but excluded from seat/revenue rollups; the "nova" department row is revenue-tracked but cannot be staffed |
Auto-detected team per department (shown until a manager adopts or starts blank) | Nova (client staffing history) | Same GET /api/assignments — seat rows from getSeatAssignmentsQuery() in server/snowflake-only-queries.ts reading Nova's CLIENT_ACCOUNT_ASSIGNMENT_HISTORY + USERS + DEPARTMENTS | Same 4-hour server cache | Only used for clients not yet "managed" in Signal; once a client has saved assignments or a managed decision, the saved team always wins |
Client metadata: tier, vertical/industry, division, churn status pill, Priority (P1–P3) | Nova (client records) + Vena-side feature table | GET /api/clients → Nova CLIENTS/DIVISIONS + FINAL_FEATURES (PRIORITY_TIER, tier, industry) | 1-hour server cache | Priority tier is null for clients missing from the feature table |
Employee picker (Add dropdown, AD / Sr. AD search) | Nova (employee roster) | GET /api/employees → Nova USERS + job titles + departments | 1-hour server cache | Terminated employees and junk/test names are filtered out |
Month being edited | Derived from Vena | GET /api/months → computeMonths() over FINAL_VENA_CONTRACTS date range | 30-minute server cache | The global MonthSelector drives it; edits always persist to the latest selected month |
Saved team assignments (chips that override the auto-detected team) | Signal's own records (entered by users in Signal) | getAssignmentsForMonth() in src/services/supabase.ts, which prefers GET /api/team-assignments (service-role read, paginated) with a direct database read as fallback | Live read per month switch; optimistic updates on save | The service-role read path exists because browser-side reads intermittently return empty |
Managed-client state (drives the first-edit "adopt vs. start blank" confirmation) | Signal's own records | GET /api/managed-clients → managed_clients registry (client_id + decision) | Live; re-read before each data build | A client with any saved assignment rows is treated as managed even if the registry read missed it |
Custom percentage splits on chips | Signal's own records | getOverridesForMonth() / saveAllOverridesForAccount() in src/services/supabase.ts → revenue_split_overrides | Live | When no override exists, percentages come from in-code rule tables in src/utils/allocation.ts (see Metrics & definitions) |
Consulting role badges (Sr. AD / AD / AM / PM) | Signal's own records, with Nova roles as fallback | loadConsultingRoleOverrides() → consulting_roles snapshot; fallback to the employee's Nova role | Snapshot refreshed server-side after every Consulting team save | Table value wins for display |
AD / Sr. AD chips (client-level, non-Consulting clients) | Nova (live) merged with a cached copy in Signal's own records | GET /api/client-account-directors + GET /api/client-senior-account-directors (cached tables, 1-hour TTL) merged with GET /api/nova/assignments (Nova GraphQL clients.executive_sponsor / .senior_account_directors, 5-minute server cache) in DataContext | Nova payload cached 5 minutes server-side; re-reconciled once accounts load | Since Jul 2026 (staging PR #97), live Nova WINS over the cached copy for non-Consulting single-division clients; Consulting and multi-division clients keep Signal-side values with Nova only filling empty slots |
Per-division assignments on multi-division clients | Signal's own records | GET /api/nova/assignments?month= → multi_division_assignments enrichment in server/multi-division-assignments.ts; multi-division universe determined from Vena revenue (clients with active revenue in 2+ divisions for the month) | 5-minute Nova-cache + per-request enrichment | Nova cannot model per-division splits; these ~10 clients live only in Signal's records |
Save history ("Log" modal) | Signal's own records | getChangeHistory() → change_history (entity_type team_assignment) | Live on modal open | Shows the last 200 entries (code constant) |
Nova-side assignment audit (not yet surfaced in this view) | Nova | GET /api/nova/assignments/client/:id/history and .../at/:date → Nova client_account_assignment_history via GraphQL | No server cache | Point-in-time reads are only valid for dates on/after 2026-07-01 (cutover constant in server/nova-history.ts); earlier dates must use the frozen team_assignments records |
Assignment backup (invisible safety net) | Signal's own backend | POST /api/assignments/backup → server/assignment-backup.ts store on the app server | Fire-and-forget on every team save | Not user-visible; disaster-recovery fallback only |
Metrics & definitions
All figures on the Manage Leads view are monthly amounts for the latest selected month (or a sum across selected months in the client summary row).
Monthly Revenue (per department row) — the client's contracted revenue for that department and month. Origin: Vena (FINAL_VENA_CONTRACTS.MONTHLY_REVENUE, summed over blueprint/service rows). Not editable in Signal.
Revenue (client card summary) — sum of the client's department-row revenue for the selected months. Origin: Vena.
Seats (client card summary and "N Total Seats" header) — count of team chips across the client's department rows, plus one extra per "+2nd Seat" dual-role person. VABO and "nova" department rows are excluded (code rule in countRenderedSeats, src/views/ManageLeadsView.tsx). Origin: Signal's own records (saved assignments) or Nova auto-detection for unmanaged clients.
Depts (client card summary) — number of distinct revenue-bearing departments on the client for the month. Origin: Vena.
Allocation % (on each chip) — the share of the department's monthly revenue credited to that person. Basis: a custom override if one is saved (Signal's own records, revenue_split_overrides); otherwise the in-code default rule tables in src/utils/allocation.ts (code constants as of Jul 2026, explicitly commented as placeholders pending final values from leadership):
Consulting (uses total client revenue, not just the Consulting department row): 1 person = 100%; 2 people (AD + AM) = 60/40; 3 people (AD + AM + PM) = 50/35/15; 4+ people (Sr. AD + AD + AM + PM) = 30/35/25/10.
All other departments: 1 person = 100%; 2 = 60/40; 3 = 50/30/20; 4+ = 30/30/20/20 (position 4's share is split evenly among everyone beyond the fourth).
When some chips have custom percentages, the remaining un-overridden people share the leftover evenly (calculateAllocationsWithOverrides).
Allocated $ (on each chip) — Allocation % × the revenue base (department monthly revenue; total client revenue for Consulting). Derived client-side.
L / S badge (non-Consulting chips) — lead vs. support. The first chip in the row order is "lead"; everyone else is "support". Order is set with the ↑/↓ arrows and stored with the assignment.
Sr. AD / AD / AM / PM badge (Consulting chips) — the person's Consulting role, from Signal's consulting_roles snapshot (falling back to the person's Nova role). Determines the Consulting allocation waterfall above. "×2" marks a dual-role second seat (seat count +1, revenue credit unchanged).
N Clients (header) — number of client cards after filters. Multi-division clients appear as one card per division ("Client – Division"), each counted separately.
Active / Churned pill — derived from the client's churn date in Nova client records.
How it's used
Bring a new client under management. A client signs; Manage Leads shows the team auto-detected from Nova's staffing history. The first time a manager edits any of that client's teams, a confirmation modal lists the full detected team and asks whether to Adopt & manage (seed every department's detected team into Signal's own records) or Start blank (ignore Nova's record and build from scratch). From then on, Signal's saved record — not Nova auto-detection — is the source of truth for that client's teams. (As of Jul 2026 this choice appears only as the first-edit modal; there is no longer a standing banner with Adopt/Start-blank buttons on the card.)
Monthly assignment review after rollover. On the 1st of each month a scheduled job copies the previous month's team assignments and split overrides into the new month (Render cron, 13:00 UTC on the 1st; a startup safety check also seeds the month if it is empty). Team Leads then filter to their division/department and correct stale names — people who rolled off, churned clients — so RPE, MRR books, and capacity numbers start the reporting month clean.
Staff a team change. Someone rolls off an account: click × on their chip (an Undo toast gives a 5-second window), click Add, search the replacement, and reorder with ↑/↓ so the true lead sits first (the lead receives the largest default revenue share). Adding/removing people saves immediately; a per-row indicator shows "Saving… → Saved" or "Couldn't save — Retry".
Fix revenue attribution with custom splits. When the default split misrepresents reality (one person does 80% of the work), click each chip's percentage, type the real number, and press the row's Save button — the view blocks totals above 100%. The ↺ button returns the row to rule-based defaults. Custom splits flow into the per-employee MRR math used by the Employees view (computed client-side from the same overrides).
Correct Consulting roles and seats. On a Consulting row, click a person's role badge to reassign them among Sr. AD / AD / AM / PM (this changes the allocation waterfall) or toggle "+2nd Seat" when one person covers two roles. After every Consulting team save on the latest month, the server recomputes the client's Consulting-role snapshot and Account Director and pushes the resulting AD into Nova; a failure surfaces as "Saved in Signal, but Nova sync failed".
Set the client-level AD / Sr. AD. On non-Consulting clients, the AD and Sr. AD chips in the card header assign or clear the client's Account Director / Senior Account Director. As of July 2026 these chips write directly into Nova (Nova's updateClient GraphQL mutation — AD maps to Nova's executive_sponsor field), and Nova automatically records the change in its own assignment history. These designations drive who is on the hook in Signal's Pulse submission/coverage modules.
Find and close coverage gaps. Check Unassigned Only to list every revenue-bearing department row with nobody assigned — revenue nobody is credited with is invisible in employee books and capacity plans. Decide per row: data gap to fix, or genuinely unstaffed account to escalate.
Audit and report. The Log button opens the save history (who changed which team, when — last 200 entries); Export XLSX produces one row per client × department × employee with role, allocation % and allocated dollars for finance/ops. Export is disabled until saved assignments finish loading so it never exports the raw auto-detected fallback by accident.
What users can change here
Manage Leads is one of Signal's heaviest write surfaces. Where each write lands (verified in code at staging commit 98df0c4):
Team membership per department per month → Signal's own records, team_assignments (one row per client × department × month × employee, role lead/support, optional division). Write mechanics: upsert new rows first, then delete stale rows, then read back and verify, with 2 automatic retries (replaceTeamAssignments in src/services/supabase.ts). Side effects of every team save: an audit row in change_history; a fire-and-forget backup to the app server (POST /api/assignments/backup); and — for Consulting teams on the latest month — a server-side recompute of the consulting_roles snapshot and of client_account_directors, followed by a push of the reconciled AD into Nova (updateClientAccountDirector mutation). Assignments are month-scoped; editing a past month rewrites that month's record (a yellow warning banner appears when a historical month is selected).
Custom revenue-split percentages → Signal's own records, revenue_split_overrides (client × department × month × employee × percentage). Requires the explicit per-row Save button; totals above 100% are blocked. Overrides are cleared automatically when the team composition of the row changes. This save path does not write a change_history row.
Consulting role per person and "+2nd Seat" dual roles → routed through the team-save path; roles land in the consulting_roles snapshot (Signal's own records), dual seats are stored as extra support rows in team_assignments.
Client-level AD / Sr. AD (non-Consulting clients) → Nova directly: POST /api/nova/assignments calls Nova's updateClient GraphQL mutation (executive_sponsor_id for AD; senior_account_director_ids for Sr. AD). Nova auto-writes its own client_account_assignment_history audit rows for every such change. The Signal UI updates optimistically and reverts on failure. Note (code as of Jul 2026): this chip write does not pass a division to the backend, so on a multi-division client's per-division card the AD/Sr. AD chip still writes client-wide in Nova; the per-division override path (multi_division_assignments in Signal's own records via the same endpoint's division parameter) exists server-side but is not wired to these chips.
Adopt & manage / Start blank decision (first edit of a new-in-Signal client) → Signal's own records, managed_clients registry; adopting also seeds the entire detected team into team_assignments (seeded rows attributed to an auto-seed actor, the decision attributed to the confirming user).
All Signal-side writes record the editing user's email. Nothing on this screen writes to Vena, Google Sheets, Deel, or payroll systems.
Caveats & data quality
The assignment store is mid-migration (July 2026). Per docs/designs/nova-graphql-migration.md (approved plan in the repo), Signal is cutting assignment reads/writes over from its own cached records to Nova's GraphQL API. As of staging commit 98df0c4: the AD / Sr. AD chips already write directly to Nova; department team membership still writes to Signal's own team_assignments; the plan's later phases would move team saves to Nova and freeze the Signal-side tables as a pre-2026-07-01 historical archive. Expect this section of behavior to change.
History cutover date 2026-07-01 (code constant in server/nova-history.ts). Point-in-time "who was assigned on date X" lookups use Nova's client_account_assignment_history for dates on/after 2026-07-01 and Signal's team_assignments records for earlier dates. Pre-cutover assignments never re-touched in Nova are invisible to the Nova history path by design.
Default allocation percentages are code constants, not configuration. The split tables (60/40, 50/30/20, Consulting 30/35/25/10, etc.) are hardcoded in src/utils/allocation.ts with a comment that they are "placeholders — John will determine final values" (as of Jul 2026). An older allocation_configs concept survives only as an entity type in the change-history typings; no table read remains in the code. Treat the numbers in the on-screen "Allocation Rules" tooltip as current but tunable.
Custom split percentages are applied client-side only. revenue_split_overrides is read by the browser (Manage Leads display, the XLSX export, and the per-employee MRR/allocation math in DataContext/Employees view) and copied forward by the monthly rollover job. The server-side KPI engine (server/vena-kpi-engine.ts, server/kpi-queries.ts, server/predictions.ts) does not read revenue_split_overrides (verified by search at commit 98df0c4) — server-aggregated KPIs use seat membership, not custom percentages.
Per-division AD chips write client-wide in Nova. On multi-division clients the header AD/Sr. AD chip save omits the division parameter (code as of 98df0c4), so the write lands on Nova's single client-level field even though the card is division-scoped. Per-division role assignments are stored in Signal's multi_division_assignments table via a server path that this view's chips do not yet call.
Auto-save vs. explicit Save differs by action: adding/removing/reordering people and role changes save immediately; percentage edits require the row's explicit Save button.
Scheduled-job cadences that affect this view (defined in render.yaml, deployment-tunable): monthly team-assignments rollover on the 1st at 13:00 UTC (staging and prod); weekly Nova→Signal AD cache sync Wednesdays 13:00 UTC (manual assignments never overwritten); weekly Consulting AD cleanup Mondays 09:30 UTC. A server-startup check also seeds the current month only if it has zero rows. Alerting on job failure is not defined in the app repo.
Cache staleness windows: Vena revenue/assignment payload up to 4 hours; client metadata and employee roster up to 1 hour; Nova live-assignments payload up to 5 minutes; AD auto-grant email set up to 1 hour. All are in-memory server caches that reset on deploy.
Historical-month edits are permitted (with a warning banner). Whether any downstream report snapshots months — which retroactive edits would distort — is not defined in the app repo.
Resilience behaviors are intentionally invisible: service-role reads (because browser reads intermittently return empty), the server-side assignment backup, add-before-delete write ordering, and per-row retry chips. They exist; users don't need to manage them.
Related views
Employees (/employees) — reads the same saved team assignments and allocation math to show each person's client book and MRR; custom splits saved in Manage Leads change the numbers there.
Staffing (/staffing) — a local-only "what-if" simulator over the same assignment + revenue data; nothing there writes back, and its baseline reflects what was saved in Manage Leads.
Company Capacity (/capacity) and portfolio-style views — inherit the seat picture from saved assignments.
Analytics / KPI computations — server-side RPE, MRR-by-person, and seat counts (server/vena-kpi-engine.ts, server/kpi-queries.ts) depend on the team membership saved in Manage Leads (not on the custom percentages, which are client-side).
Pulse Submission / Pulse Coverage (/pulse/submit, /pulse-coverage) — the client Account Director set in Manage Leads (chip or Consulting reconcile) determines which AD is expected to submit for a client.
Audit Log / Corrections views — read the same change_history store that Manage Leads writes on every team save.
FAQ
Q: Why doesn't the revenue here match what I see in Vena? A: Manage Leads shows monthly revenue per client-department row exactly as it lands from Vena's contract data (FINAL_VENA_CONTRACTS), but the server caches that payload for up to 4 hours, so a same-day Vena change can lag. Also check the month selector: the view shows the latest selected month (or a multi-month sum in the client summary), VABO amounts are displayed but excluded from rollups, and negative-revenue rows are dropped. If numbers still disagree after those checks, flag it via the data-corrections flow.
Q: Who can see Manage Leads, and how do I get access? A: Manage Leads requires the Team Lead tier or above. The flag (is_team_lead in Signal's user records) is granted two ways: automatically at sign-in if you are an active Account Director (executive sponsor) or Group Director on any client in Nova, or manually by a Signal admin on the General Access screen. Admin, Gandalf, and super-admin users qualify automatically. If you believe you should have access, ask your team's Signal admin.
Q: Where does the team shown on a client come from if nobody ever edited it? A: From Nova's staffing history (CLIENT_ACCOUNT_ASSIGNMENT_HISTORY) — Signal auto-detects the team from Nova's records. That auto-detected team is only a starting point: the first time a manager edits the client, a confirmation modal asks whether to adopt the detected team into Signal's own records or start blank. After that decision, the saved record in Signal always wins and Nova auto-detection is no longer consulted for that client's department teams.
Q: What do the default percentages mean and can I change them? A: When no custom split is saved, Signal applies standard rule tables based on team size: for most departments 1 person = 100%, 2 = 60/40, 3 = 50/30/20, 4+ = 30/30/20/20; for Consulting the split is role-based (Sr. AD+AD+AM+PM = 30/35/25/10; AD+AM+PM = 50/35/15; AD+AM = 60/40) and is computed on the client's total revenue, not just the Consulting row. These are code constants as of Jul 2026 (documented in the on-screen "Allocation Rules" tooltip) and are expected to be finalized by leadership. You can override any row's percentages by clicking a chip's percentage, typing a number, and pressing Save — overrides are stored per client × department × month × person in Signal's own records.
Q: Do the custom percentages I set here change the KPIs everywhere in Signal? A: Partially. Custom splits change the allocation shown in Manage Leads, its XLSX export, and the per-employee MRR/book figures computed in the browser (Employees view). Server-aggregated KPIs (the KPI engine's RPE and MRR rollups) use team membership only and do not read the custom percentages — verified in the server code as of Jul 2026. If a report seems to ignore your split, this is why.
Q: When I change the AD chip, does Nova get updated? A: Yes. As of July 2026 the AD and Sr. AD chips on non-Consulting clients write directly into Nova via Nova's own update API (AD maps to Nova's "executive sponsor" field), and Nova records the change in its assignment history automatically. For Consulting clients there is no chip — the AD is derived from the Consulting team you save, and the server pushes that reconciled AD into Nova after each save; if that push fails you'll see "Saved in Signal, but Nova sync failed".
Q: My save failed or is stuck on "Saving…" — is my data lost? A: No. Saves write new rows before deleting old ones and verify by reading back, with automatic retries; a stalled save surfaces as "Couldn't save — Retry" and clicking Retry safely replays it. Every team save also sends a backup copy to the server as a disaster-recovery net. If you removed the wrong person, an Undo toast gives you 5 seconds to restore the previous team.
Q: What happens to assignments at the start of a new month? A: A scheduled job on the 1st of each month (13:00 UTC) copies the previous month's team assignments and custom split percentages into the new month, and a server-startup check seeds the month if the job hasn't run yet. Assignments are stored per month, so the expected workflow is: rollover happens automatically, then Team Leads review and correct the new month. Nothing is copied if the month already has rows, so manual edits are never overwritten by the rollover.
Q: Can I edit a past month, and should I? A: The view allows it — pick an earlier month in the global month selector and a yellow banner warns "changes here will modify historical assignments". The edit rewrites that month's stored record, which changes any Signal metric recomputed from it. Whether any downstream report has already snapshotted that month is not tracked in the app, so coordinate with the report owner before editing history.
Q: Why does a client appear twice, like "Client – B2B" and "Client – Lifestyle"? A: That client has active revenue in two or more divisions for the month (per Vena), so Manage Leads renders one card per division and teams are assigned per division. These multi-division clients (roughly 10) are special: Nova cannot represent per-division assignments, so their division-scoped team data lives only in Signal's own records. Note that the AD/Sr. AD chip on such a card currently still writes a single client-wide AD in Nova, not a per-division one.
Q: What does "Unassigned Only" show and why does it matter? A: It filters to department rows that carry revenue this month but have no team assigned. Every such row is revenue credited to nobody — invisible in employee books, RPE, and capacity plans. It's the fastest way to find attribution gaps after a month rollover or a staffing change.