Home/Glossary/What is a tenant knowledge graph?
What is a tenant knowledge graph?
A tenant knowledge graph is a persistent, connected map of everything an AI system knows about a single customer environment - in a Salesforce context: org metadata, repository code, documentation, past decisions and the relationships between them. It is scoped to one tenant, so knowledge never crosses customer boundaries, and it persists between sessions, so understanding accumulates instead of being rebuilt on every request.
Last updated: 2026-08-25Why a graph rather than a transcript
Salesforce work is relational. A field belongs to an object, is written by a flow, is read by an Apex class, is exposed by a permission set, and was introduced by a decision recorded somewhere else. Answering a practical question - why is this flow failing for one region - means traversing those relationships, not searching text.
A conversation transcript stores what was said, in order. It cannot answer which permission sets grant access to a field, because that relationship was never modelled. A graph stores the entities and the edges between them, so the connections are queryable.
What RplAI stores, in four layers
RplAI organises tenant knowledge into four layers, each answering a different kind of question:
- L1 - Org metadata: objects, fields, flows and permissions, read from the real environments rather than from documentation.
- L2 - Repository awareness: the codebase, branches and the conventions the team actually follows.
- L3 - Tenant knowledge graph: decisions, documentation and drift, connected across the whole tenant.
- L4 - Agent memory: session context and feedback signals from previous executions.
Tenant scoping
The word tenant is doing real work in the term. The graph is bounded to one customer environment, which is what makes it safe to store specifics - field names, business rules, internal decisions - that must never leak into another customer’s answers.
For a consulting organisation working across many client orgs, that boundary is the difference between an AI system that can be used on client work and one that cannot.
Why persistence changes the output
When knowledge persists, each execution can add to it. A resolved incident records its root cause; a generated flow records the convention it followed; a rejected suggestion records why it was rejected.
The practical effect is that later requests start further along than earlier ones. Without persistence, request ten is identical in cost to request one, because nothing learned in between was retained.
Frequently asked questions
How is a tenant knowledge graph different from retrieval over documentation?
Retrieval over documentation searches text that someone wrote, and inherits whatever is stale or missing in it. A tenant knowledge graph is built primarily from the live environment - metadata and code read directly from orgs and repositories - and models relationships between entities rather than similarity between passages.
Does the graph mix knowledge between customers?
No. The graph is scoped per tenant. That boundary is the point of the term: knowledge about one environment stays inside it.
What happens when the org changes?
The graph is maintained continuously rather than snapshotted, so metadata changes and drift between environments are reflected as they occur, and documentation generated from the graph stays aligned with the org.
See it against your own org
RplAI is in early access and onboards in small batches. No credit card, every request reviewed.
Request early access