Platform Modules
NearSync is organized into HQs — focused modules that share one tenant, one identity model, and one permission system. A tenant's plan and system_manifest decide which HQs are enabled, so the platform any given org sees is a subset of the whole.
This page is a concept-level map of what each HQ is for. Step-by-step product walkthroughs live in-app (contextual help) and the NearSync Academy — not here. For programmatic access to a module's data, see the API Reference.
| HQ | What it's for |
|---|---|
| Sales | CRM — companies, contacts, deals/pipelines, tasks, and sales analytics. |
| Finance | Invoices, payments, subscriptions, expenses, budgets, accounting (chart of accounts, journals, reports), and billing. |
| People | HRMS — employees, onboarding, attendance, leave, payroll, performance (KPIs, reviews, goals), and policy. |
| Comms | Unified communications — team chat, voice, WhatsApp, and email across shared and per-record inboxes. |
| Support | Ticketing and service workflows over the shared pipeline/stage model. |
| Projects | Delivery and project management — requests, phases, and handover. |
| Operations | Cross-functional execution, workflow automation (Nexus), and operational health. |
| Marketing | Campaigns, content, and marketing analytics. |
| Web | Website, knowledge base, blogs, and embeddable widgets. |
| Intelligence | AI features — assistants, drafting, and the AI provider/spend layer. |
| Dashboards | The declarative analytics layer — metrics, widgets, and reports surfaced across HQs (and via the analytics API/MCP). |
How the modules fit together
- One tenant, one identity. A user's role and hub grants determine which HQs and records they can see — the same model the API and MCP enforce (see Security).
- Shared primitives. Pipelines/stages, custom fields, the manifest, and the automation engine are shared across HQs rather than reimplemented per module.
- Multi-tenant by
org_id+ RLS. Every module's data is org-isolated; see Multi-tenancy.