Control tower checks

Every check the Control tower runs, what it asserts, and what turns it red, orange, or blue. The checks are grouped into three blocks and evaluated in that order, because each block depends on the one above it.

Check results

Result	Meaning
Passing	The check is satisfied. Passing checks fold into a single “N checks passing” line.
Warning	It works, but not completely. Worth a look; nothing downstream is blocked. Warnings are numbered alongside the blockers.
Missing	A blocker. Work downstream of it cannot run. These are numbered as fix 1, fix 2, and so on, in dependency order.
Heads-up	Worth knowing, but not a setup error and not something a settings screen can close. The row is tagged Heads-up, nothing to fix, takes no fix number, and does not count towards the gaps in the banner.
Could not be checked	The check could not run this time. Neither a pass nor a failure; a notice at the top of the page offers a Retry.

A missing check that is missing only because no CRM is connected is not counted as a blocker of its own. Those checks grey out and read “waiting for a CRM connection”, so a disconnected CRM shows as one problem rather than five.

The distinction between a warning and a heads-up is the one worth learning. A warning says something in your setup is half-done and you can finish it. A heads-up says the workspace noticed something you should know - an optional agent has nothing to work with, a CRM channel went quiet - where the answer might legitimately be “that is fine, we do not use that”. Heads-ups keep their button so you can act if you want to, but they never make the page read as broken.

01 CRM and ownership

CRM, ownership, and the book of records. Everything below feeds on this. The block header reads “Make sure CRM data arrives smoothly. These checks flag when it stops.”

Check	What it asserts	Missing when	Warning when	Heads-up when	Where the button goes
CRM connection	At least one CRM integration is connected and active.	No active integration.	-	-	Integrations
Field mappings	Account and contact fields are mapped on every active integration.	Either entity is unmapped.	-	-	Integrations
Sync toggles	Accounts, contacts, activities, and deals all have sync switched on.	-	Sync is off for one or more of them.	-	Integrations
CRM seats	Every user in the workspace is matched to a CRM seat.	No user is matched.	Some are matched, some are not.	-	CRM user mapping
Activity arriving	Calls, meetings, and emails are still arriving from the CRM.	-	Nothing at all has arrived in the sync window.	Activity arrives, but a channel that used to arrive regularly has stopped.	Integrations
Ownership rules	At least one ownership rule is active.	No rule exists: a new record stays with whoever added it or ran the workflow, so nothing is shared out across the team.	Rules exist but every one is paused.	-	Ownership rules
Book of records	The workspace holds accounts and contacts, and they have owners.	No accounts and no contacts.	Accounts exist but not one has an owner.	-	Accounts

The summary line on each of these names the specifics in plain words: which entities are unmapped and on which CRM (“Fields not mapped for HubSpot contacts”), how many users have no seat, which channel stopped arriving and on what date, how many accounts and contacts you hold and how many have no owner.

Activity arriving is the one check whose worst result is a warning, not a blocker. Neither “nothing is arriving” nor “one channel went quiet” is something a settings page can fix - either nobody is logging that channel in the CRM, or the sync needs a look - so the check says both possibilities out loud rather than sending you to a screen that cannot help. A channel that has simply gone quiet is a heads-up; silence across the board is a warning.

02 Agents ready

Everything your agents need before they can start working.

Check	What it asserts	Missing when	Warning when	Heads-up when	Where the button goes
Ecosystems	At least one ecosystem exists, and each one has verticals.	No ecosystem.	An ecosystem has no verticals.	-	Verticals in the Agent Training Center
Personas	At least one persona card exists.	No personas.	-	-	Personas in the Agent Training Center
Qualification agents	At least one qualification agent exists, and each ecosystem has one.	No qualification agents at all.	An ecosystem has none.	-	Verticals in the Agent Training Center
Research agents	At least one research agent exists, and each ecosystem has one.	No research agents at all.	An ecosystem has none.	-	Verticals in the Agent Training Center
Play agent	At least one play is ongoing for the play agent to draft on.	-	-	No play is ongoing.	Plays
Account planning agent	At least one Account plan agent is saved for the account planning agent to generate from.	-	-	None saved.	Account plan agents in Agent Hub

Three things about this block are easy to misread:

The sandbox does not count. An ecosystem used as a sandbox for trying agents out is excluded from all of these, and is never flagged for what it lacks. Trying an agent out there is not setting one up.
The play agent and the account planning agent are optional, so they are never blockers. Plenty of teams run qualification and research without using either. Where there is nothing for them to work with, the row reads as a heads-up - “The play agent needs at least one play to draft on. Add one if you use it” - and the wording is deliberate: if you do not use it, there is nothing to do. One ongoing play of any type is enough to satisfy the play check; it no longer asks for both an email and a call play.
Drafts do not count as running. The play check looks for ongoing plays. Where none are running, the summary adds how many are waiting in draft or review, which is usually the real answer: the work is done and nobody switched it on.

The account planning check counts the Account plan agents your team has saved, not the template library they can be started from - templates alone still read as a heads-up. The row’s own wording is “at least one account plan to generate against”, which means a saved plan definition, not a plan already written onto an account.

03 Credits

Credits to run the agents.

Check	What it asserts	Missing when	Warning when	Where the button goes
Credits	The workspace has credits left to spend.	The balance is at zero.	Credits remain but there is no active contract.	Top up credits

A workspace on unlimited credits always passes the Credits check and says so, rather than showing an empty meter.

Team readiness

Below the checks, a table of everyone active in the workspace, sorted problems first: no seat, then nothing owned, then inactive. The header carries a chip for each problem across the whole team - N no CRM seat, N no records, N inactive - so you can see the shape of it before reading a single row.

Column	What it shows
User	The person’s sign-in address.
CRM seat	Mapped next to your CRM’s mark, or a No seat chip. Blank when the CRM facts could not be read.
Accounts	How many accounts they own.
Contacts	How many contacts they own.
Last active	How long ago they were last in the workspace, or Never. An Inactive chip marks anyone with no activity in the last two weeks.
(last column)	The one thing to do for that person: Map seat, which opens CRM user mapping, or Add ownership rule, which opens ownership rules. Someone with a seat and records reads Nothing to fix. An inactive person reads Inactive user, nothing to set up, or, where they have no seat, a quiet Map seat link under the note Inactive here, map only if they own records in the CRM.

The fix offered is the first one that applies, in that order, because a seat has to exist before their activity can be attributed to them and before owning records means anything.

Inactive people are read differently, and on purpose. Somebody who has not been in the workspace for a fortnight is not a setup gap, so they sort below the real problems, they are not counted in the no-seat chip in the header, and they are never offered an ownership rule - a rule would route fresh work to somebody who is not there to do it. The seat is the exception: a rep who lives in their CRM and never opens Evergrowth still owns records there, and the seat mapping is what attributes those records to a person, so the link stays available with the reason spelled out. Map it if they own records in the CRM; otherwise leave them and deal with the people who are working.

The table is only shown to people whose role lets them see the workspace’s users; for everyone else the page simply ends at the checks.

Eva context: check names here are the customer-facing labels shown on the page, and the per-check sentence the page prints is generated from that check’s own evidence, so quote the page rather than reconstructing it. Two named counts are load-bearing and stable: inactive means no activity in fourteen days, and a lapsed activity channel means one that arrived regularly over the preceding lookback and not at all inside the current sync window - a team that logs a meeting a quarter is quiet, not broken. Qualification agents and research agents are the two kinds of criteria an ecosystem runs; the check counts them separately because a workspace with qualification but no research qualifies accounts and then knows nothing about them. The fifth result, heads-up, was added in September 2026 and is genuinely not a gap: it is excluded from the banner’s gap count, from the fix numbering, and from the blocker count on the sidebar dot, so a workspace showing only heads-ups is correctly set up. It replaced two earlier behaviours a customer may remember - the play check used to be a blocker demanding an ongoing play on both the email and the cold-call track, and a lapsed activity channel used to raise a warning. A separate play-permissions check also existed briefly and was removed: role permissions are governed in team settings, not here. Never present “could not be checked” as a pass, and never present a heads-up as a failure.