Operations is the layer underneath the rest of the platform. Almost every department depends on something configured here, which is why a problem that shows up in Sales or Finance often has its fix in Operations.
This article is the map.
What Operations Provides To Each Department
| Department | Depends on Operations for |
|---|---|
| Sales | Custom fields on deals and contacts, imported data, automations on deal events, meeting frameworks like MEDDPICC |
| Finance | Imported invoices and payments, approval automations, overdue reminders, custom fields on invoices |
| People | Imported employee records, onboarding automations, 1-on-1 and review meeting frameworks, careers inbox |
| Support | The support inbox address, chat intents behind the web widget, escalation automations, SLA-driven triggers |
| Marketing | Marketing lists, campaign email templates, campaign frameworks, consent-gated sending |
| Comms | The phone provider, the inbound addresses, the message templates every channel sends |
| Web | The chat widget configuration and the intents behind it |
| Projects | Custom boards, issue-creating automations, imported issues from Jira or Linear |
The Common Diagnoses
When something is wrong in another department, this is usually where it lives.
"The field we need does not exist." Custom Fields.
"Nobody was told." Two possibilities. The notification rule is in Settings; the automation that should have fired is here. Check Automation Health first - it tells you which.
"Mail to our support address vanished." Email and Domains. Check forwarding, then the alias, then whether the department has a manager to own the queue.
"The booking page shows the wrong hours." Not Operations - hub business hours, in Settings. Booking availability derives from them.
"The import made a mess." Data Management queues.
"The customer got the same email four times." An automation testing state rather than transition. See Conditions and Branching.
"The AI said something wrong on our website." Chat Intents - either the priority ordering or a KB-grounded intent with no article behind it.
What Operations Does Not Own
Worth knowing so you look in the right place:
- Who can do what - Settings, Permissions.
- Which events notify whom - Settings, Notifications.
- Business hours and legal entities - Settings, Hubs.
- Pipelines and stages - Sales, Pipeline Settings.
- Answering conversations - Comms and Web.
- Compliance and system health - run by NearSync, not tenant-configurable.
The Dependency Order
The reason setup order matters is that these dependencies run one way:
Custom fields → everything that stores data Hubs and pipelines → everything that files data Imported data → everything that reports on data Templates → everything that sends Automations → everything that happens without a person
Nothing further down works properly until the things above it are right. See Setting Up Operations In Order.
Keep in mind
When something is broken in another department and nobody can find the cause, ask what Operations configures for it. The answer is in this table more often than not.
Common Questions
Who should own Operations? Someone who understands how the business actually works, not necessarily the most technical person. Most of the decisions here are process decisions.
Should everyone have access? No. Changes here affect everyone. Give access to the people who configure, and let the rest use what they configure.
Where do I start if I have inherited a messy workspace? Data Management queues, to see the damage. Then Automation Health, to see what is running. Those two tell you the state of things faster than anything else.
Did this answer your question?
No, ask a person