Does RushDB replace my CRM?

No. RushDB is the memory layer your agents and apps read and write. Keep your CRM as the system of record and sync the account context you want recalled by meaning and relationship.

How do I keep recall on the right account?

Store account, opportunity, and rep identifiers on each interaction record, then add those fields to the where clause when you call ai.search so semantic recall stays scoped.

Do I need a separate vector database?

Not for interaction text kept in RushDB. Create a managed embedding index once and RushDB keeps new interactions searchable as reps log them.

Can multiple agents share the same account memory?

Yes. The account graph lives outside any one session, so different reps, assistants, and workflows continue from the same durable context.

How is this different from customer-support-memory?

Sales & CRM memory organizes account history around opportunities, objections, and commitments through the deal cycle. Customer-support-memory organizes ticket history around issues and resolutions after the sale, though both share the same account-scoped recall pattern.

rushdb

Blueprint: sales & CRM

Account memory that follows every deal.

Keep INTERACTION records — calls, emails, notes — linked to the ACCOUNT and OPPORTUNITY they belong to, so a pricing objection logged on account acme-01 stays attached to opportunity opp-7 instead of buried in a transcript. The next rep or assistant queries interaction summaries scoped to that account and picks up from the real objection and commitment history instead of a cold CRM record.

Sales & CRM Memory is a RushDB pattern that persists ACCOUNT, OPPORTUNITY, and INTERACTION records with semantic search over interaction summaries so reps and agents recall objections and commitments scoped to a specific account instead of re-reading a full transcript history.

Start free View docs

Deal context scatters across reps, tools, and transcripts.

A long sales cycle piles up calls, emails, notes, and promises across reps and tools. When that history sits in disconnected CRM fields and call-tool transcripts, objections and commitments get buried, handoffs lose prior account context, and similarity search — if it exists at all — runs on a separate, bolted-on store instead of the account graph the rep is already working in.

Before

Notes spread across CRM fields and call tools
Objections and commitments buried in transcripts
Handoffs lose prior account context
Similarity search bolted onto a separate store

With RushDB

Interactions persist as records linked to the account
Objections and next steps recalled by meaning
Every rep and agent reads the same deal history
Search, filters, and relationships in one backend

Graph intelligence on ingest

Incoming data becomes queryable graph context.

A call or email lands as an INTERACTION record nested under its ACCOUNT, carrying channel, rep, and a summary like the quarterly-billing objection on account acme-01. RushDB types those fields on write, auto-links the INTERACTION to its parent ACCOUNT and OPPORTUNITY, and keeps the summary field searchable so a later query for pricing pushback resolves to the right account without a separate sync step.

Normalize as interactions arrive

ACCOUNT, OPPORTUNITY, and INTERACTION payloads are typed on write, so fields like amountUsd and channel are filterable immediately.

Auto-link nested structure

INTERACTION records nested under an ACCOUNT are automatically related to it, keeping call int-204 attached to opportunity opp-7 without manual foreign keys.

Enrich scattered sources

Suggested-relationship analysis surfaces links between a CONTACT, an OPPORTUNITY, and the INTERACTION records tied to them even when logged from different tools.

Suggested relationship analysis requires an LLM configured for the project. Suggestions stay in draft form until you approve them, so inferred domain meaning never mutates the graph silently. You can also add explicit relationships through the SDK or API.

Review suggested relationship patterns

Data model

One flexible graph for the workflow.

Start with the payload shape your product already produces. RushDB stores it as Records, infers typed properties, and keeps nested or approved domain relationships queryable.

Schema sketch

Account payload

One account write can carry contacts, opportunities, and interactions while later touches append new interactions and next steps.

{
  "accountId": "acme-01",
  "name": "Acme Corp",
  "stage": "negotiation",
  "CONTACT": [{ "contactId": "c-9", "name": "Dana Reed", "role": "VP Eng" }],
  "OPPORTUNITY": [{ "opportunityId": "opp-7", "amountUsd": 48000, "status": "open" }],
  "INTERACTION": [
    { "interactionId": "int-204", "channel": "call", "repId": "rep-12", "summary": "Wants quarterly billing." }
  ],
  "NEXT_STEP": [{ "title": "Send quarterly-billing proposal", "dueAt": "2026-06-20" }]
}

Working example

Store one call. Recall the objection on the next touch.

A rep logs a call as an interaction linked to the account. A later assistant recalls pricing objections scoped to that account before drafting a follow-up.

Input

ACCOUNT acme-01
  stage: negotiation
  OPPORTUNITY opp-7  amountUsd: 48000  status: open
  INTERACTION int-204  channel: call  rep: rep-12
    "Buyer pushed back on annual pricing; wants quarterly billing."

Query

{
  "labels": ["INTERACTION"],
  "propertyName": "summary",
  "query": "What pricing objections came up on this account?",
  "where": { "ACCOUNT": { "accountId": "acme-01" } }
}

Result

{
  "account": "Acme Corp",
  "interaction": "int-204",
  "objection": "Wants quarterly billing instead of annual pricing.",
  "next_step": "Send a quarterly-billing proposal."
}

Python SDK

Log interactions. Recall the deal context by account.

RushDB stores accounts, opportunities, and interactions as connected records and keeps interaction text searchable. Your CRM workflow and model decide what to do with the recalled context.

from rushdb import RushDB

db = RushDB('RUSHDB_API_KEY')

db.ai.indexes.create({'label': 'INTERACTION', 'propertyName': 'summary'})

db.records.import_json({
    'label': 'ACCOUNT',
    'data': {
        'accountId': 'acme-01',
        'name': 'Acme Corp',
        'stage': 'negotiation',
        'OPPORTUNITY': [{'opportunityId': 'opp-7', 'amountUsd': 48000, 'status': 'open'}],
        'INTERACTION': [{
            'interactionId': 'int-204',
            'channel': 'call',
            'repId': 'rep-12',
            'summary': 'Buyer pushed back on annual pricing; wants quarterly billing.',
        }],
    },
})

context = db.ai.search({
    'labels': ['INTERACTION'],
    'propertyName': 'summary',
    'query': 'What pricing objections came up on this account?',
    'where': {'ACCOUNT': {'accountId': 'acme-01'}},
    'limit': 10,
})

Implementation blueprint

Build the sales & CRM memory path.

Use this sequence to persist account history and retrieve focused deal context for reps and assistants.

01Import ACCOUNT records with CONTACT, OPPORTUNITY, and INTERACTION records
02Create a managed index for INTERACTION.summary
03Log calls, emails, and notes as INTERACTION records on the account
04Recall objections and commitments scoped to the account or opportunity
05Attach NEXT_STEP records so follow-ups persist across reps

Build path

Scope every interaction to an account, opportunity, and rep.
Keep commitments and next steps as records, not free-text fields.
Recall by meaning with where filters so context stays on the right deal.
Use relationships when a contact, opportunity, and interaction must stay connected.

Relevant docs

Read the exact primitives behind this pattern.

These links point to the RushDB docs pages that map directly to this blueprint: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.

Semantic search

Index interaction text and recall objections and commitments by meaning with account-scoped filters.

Open docs

Import JSON data

Push nested account, contact, opportunity, and interaction data and let RushDB build the connected structure.

Open docs

Relationships

Keep contacts, opportunities, and interactions linked to the account instead of flattened into separate fields.

Open docs

How it works

Build the smallest useful workflow first.

Model the account graph

Import accounts with their contacts, opportunities, and interactions so deal history stays connected as it arrives.

Index interaction text

Create a managed embedding index once on the interaction summary so calls and emails are recalled by meaning.

Recall before the next touch

Retrieve objections, commitments, and next steps scoped to the account or opportunity before drafting outreach.

Know where it fits.

One history for every rep

Reps and assistants read and write the same account graph, so a handoff keeps the prior context instead of resetting it.

Keep deployment choices open

Use RushDB Cloud for a fast start or deploy the platform with your own Neo4j instance.

Questions developers ask.

Next step

Start with one focused workflow.

Start free

Related use cases

Explore all use cases

Account memory that follows every deal.

Deal context scatters across reps, tools, and transcripts.

Before

With RushDB

Incoming data becomes queryable graph context.

Normalize as interactions arrive

Auto-link nested structure

Enrich scattered sources

One flexible graph for the workflow.

Store one call. Recall the objection on the next touch.

Log interactions. Recall the deal context by account.

Build the sales & CRM memory path.

Build path

Read the exact primitives behind this pattern.

Semantic search

Import JSON data

Relationships

Build the smallest useful workflow first.

Model the account graph

Index interaction text

Recall before the next touch

Know where it fits.

One history for every rep

Keep deployment choices open

Questions developers ask.

Start with one focused workflow.

Customer 360 graph analytics

One memory across LLM providers

Agent memory