CRM module

The CRM module manages contacts, accounts, deals, and the pipeline. Like every module in CCD-Suite, its entities are first-class knowledge graph nodes — so the agent can reason about them alongside content, analytics, and any other module.

Entities

Entity	What it represents
Contact	A person. Has email, phone, role, account link, engagement signals.
Account	An organization. Has industry, size, contact list, deal list.
Deal	An opportunity. Has stage, amount, expected close, primary contact, account.
Activity	An interaction log entry — email sent, call, meeting, note.
Pipeline stage	A column in the pipeline kanban (Discovery, Proposal, Negotiation, Closed-Won, Closed-Lost).

All five are stored as graph nodes with their own dedicated tables. The trigger layer mirrors writes into the knowledge graph so semantic search treats them uniformly with non-CRM entities.

The pipeline view

The default CRM dashboard centers on a kanban pipeline — columns are stages, cards are deals. Drag to advance, click for detail. Standard fare; the difference is what's annotated on each card:

Stuck indicator — small chip if the deal hasn't moved in 14+ days.
Engagement icon — last contact activity color-tone (green recent, yellow stale, red dormant).
Source citation — which Today card or Inbox action last surfaced this deal (so you remember why you opened it).

Agent-driven moves

Deals advance one of two ways:

You drag it. Standard CRM behavior.
You confirm an agent-proposed advancement. The agent identifies a deal that has met advancement criteria (e.g. proposal sent + customer accepted), proposes a planned action to move it, and you confirm in the Inbox.

Path 2 produces an audit-friendly trail: "Agent proposed advancing deal X based on signal Y, user confirmed at time Z." Useful for sales managers reviewing how deals progressed.

Activity logging

Every contact interaction the platform sees becomes an Activity entity:

Emails (via Gmail/Outlook integration)
Calendar events (via Calendar integration)
Manually logged notes
Agent-executed actions (sent email, scheduled call)

Activities link to the contact + account + deal they're about, so the engagement signals across each are fresh.

Forecast vs commit

Two roll-up cards on the dashboard:

Forecast — agent's best estimate of close probability, based on deal stage, days-in-stage, activity recency, and historical cohort patterns. Shown as a $ range.
Commit — what the team has said they'll close. Set manually by sales leaders.

The variance between the two is informative — agent forecast much higher than commit means there's unrealized upside; commit much higher than forecast means there's risk.

Cross-module insights

Where CRM gets interesting is its overlap with other modules:

CRM × Content: "Deals that closed touched on average 4.2 pieces of content during the sales cycle." That's the pipeline_to_content_attribution Today card.
CRM × Analytics: "Win rate by lead source over the last quarter, segmented by industry." Available via the Analytics module's custom queries.
CRM × Email: "Stuck deals whose primary contact hasn't opened our last 3 emails." Automatic surfacing via the inbox follow-up loop.

These work because everything lives in the knowledge graph; the agent doesn't have to know about module boundaries.

Importing data

Settings → Tenant → Imports → CRM. CSV upload for contacts, accounts, deals. Required headers documented in the upload UI; unmapped columns become custom fields visible in the entity drawer.

Imports are processed in the worker — large imports (10k+ rows) show a progress bar and notify on completion. Embeddings are generated for each new node as part of the import.

You can also stream data in via the REST API POST /api/crm/contacts etc., or via webhooks from your existing CRM (HubSpot, Salesforce) using the OAuth integrations layer.

Permissions

CRM entities are tenant-scoped (every member sees everything in the tenant). Cloud-edition tenants on Enterprise can add row-level permissions ("only the deal owner + their manager can see this deal") via Settings → Tenant → Permissions; not available on Starter/Scale.

Self-host treats every member as having full access (single-tenant install). See Security model.