Client Dashboard

Favourites Hidden Salesforce Churning
Customers Ex-Clients Show

Select a client to view metrics

Favourites Hidden Salesforce Churning
Customers Ex-Clients Show

Sections

Loading…

Favourites Hidden Salesforce Churning
Customers Ex-Clients Show

Benchmarkable Metrics

Loading benchmarks…

Favourites Hidden Salesforce Churning
Customers Ex-Clients Show

Metrics

Show non-additive

Select a metric to compare across clients

Favourites Hidden Salesforce Churning
Customers Show

Archetype Filter

Select a region to view login archetypes

Favourites Hidden Salesforce Churning
Clients Ex
Clients New Clients Dormant
Clients Show

Usage Health

This tab reads several time windows at once, so the standard time-period filter does not apply here.

Loading recommended actions…

Reports

Select a report

Account Mappings

Authoritative Salesforce Account → Client Platform → CG Internal Account relationships. Imported Salesforce facts remain read-only; use Create a mapping at the top to link unmapped records in bulk, or Edit beside a Client Platform to revise one relationship. This tab is local-only and is not published to the S3 site.

Loading mappings…

Platform Groupings

Define families of Client Platforms that belong together even though they are separate databases, such as the Coca-Cola bottlers. Groups can have one level of sub-groups, and a platform can sit in more than one group. Benchmarks shows them under Rows: By Group. This tab is local-only; Publish Data shares the groups with the S3 site.

Loading groupings…

Cache Status

Health of the server-side cache and reference-data mappings. Mapping sections flag current clients without Salesforce or approved CG-account links, plus country values that still need ISO mapping. Expand a region, then click a row (or a status dot) to inspect a cache artifact.

Loading cache state…

Client Dashboard

Password change required

Cache & Deploy

Rebuild local cache

? Runs All Light + All Heavy in order, unattended. Both tiers are needed because neither is a superset of the other — light owns login insights, heavy owns the all-time queries. It opens each region's SSM database forward itself, immediately before the leg that needs it, so a connection only has to survive its own leg instead of the whole run. A forward you already have open is used as it is and left running; one this run opens is closed when it finishes. Nothing is started for a region that is already listening. The reports are regenerated once at the end, for the regions that actually refreshed, rather than after each leg — so a full run costs one Bedrock pass, not four. A region whose forward cannot be opened is skipped with a reason and keeps its existing caches and reports. Writes to data/ only. Nothing reaches S3 until you publish. Expect this to take a while; you can close the popup and reopen it to pick the run back up.

? Refreshes all three regions without running any all-time queries. Reloads login insights (archetypes and MAU), backfills daily history, re-derives the 31d / 92d / 365d windows from the existing all-time cache, then rebuilds the comparison bundles. Finishes by regenerating Cadence Assessments and Recommended Actions for every region it rebuilt. One job covers the whole estate, so there is nothing to split per region and one stamp describes it. Writes to data/ only. Nothing reaches S3 until you publish.

? Runs Heavy EU + Heavy US + Heavy AU in order, opening each region's database forward immediately before its leg. That per-leg opening is the reason this exists as its own button rather than three presses: pressing the three yourself leaves you watching for the second and third connections to expire while the first region runs. Each region stays an independent job, so a later region's connection cannot expire during an earlier one, and a region whose forward will not open is skipped with a reason while the others continue. Reports are regenerated once at the end for the regions that refreshed. Writes to data/ only.

? Runs the full all-time query pass for one region only, capturing and gap-filling daily history, then re-derives every rolling window and rebuilds that region's comparison bundles. Skips login insights — All Light owns those. Regenerates that region's reports afterwards. Needs that region's database forward already open. Local only.

Regenerate reports

? Pick a region beneath this unless you mean to spend the whole estate. These buttons do not read the region selector at the top of the dashboard — that one filters what you are looking at. The target is the one named on the button, and a region you do not choose keeps the queue it already has. Re-ranks the chosen region's _recommended-actions.json from the Cadence artifact already on disk plus the local comparison bundles, then asks Bedrock to assess every flagged record. The full deterministic queue — every urgency, position, citation and Why flagged paragraph — is built first and saved; where Bedrock answers, its priority is the one the row carries and the queue is ordered around it, with the fixed policy's own urgency kept beside it for comparison. It is shown the evidence and nothing about what we concluded from it — each source's own state, the ranked metric movements, the client's own feedback comments and the commercial context, but never the fixed policy's urgency, score or paragraph. So it reaches its own priority, confidence, citations and reasoning independently, and we derive the comparison afterwards: agrees, understated or overstated against the deterministic urgency, which stays on every record and is shown in the row overlay. The fixed policy still decides which accounts are asked — act now, review or monitor with cited evidence, so a none or data-check row is never sent — and the evidence, the citations and the graph plan are deterministic throughout. Where an answer is refused or times out, that row keeps the deterministic priority and paragraph and stores no verdict. Use this to see a ranking or policy change without a refresh. Cadence is not regenerated here — every refresh above rebuilds it — so a region whose _churn-assessments.json is missing or obsolete fails and keeps its previous queue. Refresh that region if that happens. Costs one model call per candidate record and needs Bedrock access in the DTA account. Nothing is published. npm run generate:recommended-actions is free, faster and byte-reproducible, but it is deterministic — it rebuilds the queue without asking anything, so every row carries the fixed policy's priority. Calls run one at a time, so a region takes minutes and all regions take tens of minutes — AU is the smallest and is the cheap way to check a prompt or policy change before spending EU. Progress is reported live at the top of this popup — records reviewed in the current region, the rate, and an estimate for that region. Reopening this popup mid-run resumes the report; closing the tab loses the summary, not the run.

Publish and deploy

? Runs Publish Data + Deploy App + Post Act Now, in that order. Data goes up before the app that reads it, and Slack goes last because it is the only step that cannot be taken back. It stops at the first failure. A failed publish or deploy means the Slack post is never attempted — announcing a queue to the channel while the data behind it did not reach S3 is worse than announcing nothing. You are asked to confirm once, up front, because of the Slack step. This makes everything live for S3-mode users.

? Uploads the query manifest, mappings, each region's tenant / archetype / MAU meta files, the current Cadence artifact and freshly rebuilt comparison bundles to S3, then invalidates CloudFront. This is what makes a refresh visible to S3-mode users. Blocked if a synchronized cross-client history gap is found; you will be asked before any override.

? Uploads layout.json, then runs deploy.js: builds the S3-mode bundle from src/ as it stands right now, syncs public/ to S3, invalidates CloudFront and rebuilds the local API bundle. Uncommitted frontend work goes live. Data is untouched.

? Posts every Act now account from the saved queues to the Slack channel: a run banner, then one message per account carrying both axes and what changed since the last queue, with the summary, the written analysis and the client's own words as thread replies underneath it, then a closing list of rows that left Act now. A Slack message cannot be unsent. The whole post is built and counted before the first one is sent, so a malformed record or an obsolete queue means nothing was posted rather than half of it. A run that fails partway stops there and rewrites its own banner to say how far it got. Reads the queues already on disk — it generates nothing and refreshes nothing, so a region whose _recommended-actions.json is absent or obsolete is named in the banner rather than silently left out. Roughly one message a second, so a full estate takes a few minutes. The banner also says when What changed? does not mean since-the-last-post — a queue regenerated since it was last posted, or the same queue posted twice. npm run preview:slack-act-now renders the identical post to your terminal and sends nothing; use it for anything about the wording.