Frequently asked questions

A Salesforce-native app that curates your CRM data into context an AI agent can use — which fields, what they mean, how to use them — and delivers it to every agent, tool, and prompt from one definition.

The curation is the smallest part. A field list can't carry instructions about how to use a value, roll up child records, embed a parent, pull in a score from your own code, enforce per-user permissions, or stay consistent across five different AI surfaces.

No. ContextWorks works with external MCP clients — Claude, ChatGPT, anything MCP-compatible — with no Agentforce license. It also works with Agentforce if you have it.

Not for CRM record context. Data 360 is only required if you want to surface Data 360 calculated insights or DMO data as enrichments on a record.

Any standard or custom object. Entities initialize from your existing page layouts and describe metadata, so a new object starts with a working draft rather than a blank canvas.

All of them. ContextWorks never calls a model — it assembles curated context as markdown or JSON and hands it back. Any model, agent framework, or tool that reads text can use it.

No. No copy, no sync, no external index, no vector store. Every query runs inside your org against live records.

Salesforce enforces them, on the query itself. Every request runs as the person asking, through field-level security and sharing. A field that person cannot see is never retrieved, so it cannot come back by mistake. Two people calling the same tool on the same record get different results, and nobody configures that per person.

No. The author controls what is in the context; they never control who may see it. A person composing a domain cannot widen anyone's access. The worst outcome available to them is composing something useless.

Exactly the fields an administrator chose, intersected with what the requesting user can already see. That's answerable by reading a list, and the list can be exported for a security review.

Only if you turn it on. Write is off at the org level by default, narrowed at domain, entity, and field level, requires confirmation before committing, and every change is logged durably with the user, the agent, and the field-by-field before and after.

No. Records returned by an enrichment are treated as an ID list: the values are discarded, the records are re-queried as the calling user, and only then rendered. Computed scalar values are returned as-is, because arithmetic has nothing to re-check against.

Configuration is versioned, with required comments on activation and one-action rollback, and writes are logged durably.

Salesforce solved getting your agents to the data — securely, per user, properly governed. ContextWorks adds what that data means: entities that curate which fields an agent receives and attach an instruction to each one, briefs carrying the knowledge that isn't in any field, and skills describing how the work gets done. All of it maintained by the business users who own the meaning, and read by every surface at once. Full detail on the Salesforce page.

It does the access part, and does it well — per-user permissions are enforced properly. What it doesn't do is curate. The standard servers expose every standard and custom object in your org, gated only by the user's permissions, and their tool sets can't be modified. Narrowing that means writing Apex; there's no declarative path.

It's the same idea, and it's why we think this is the right direction. The difference is scope: a Salesforce field has exactly one Description, global and permanent, the same string for every agent and every context, editable only by someone with Customize Application. ContextWorks attaches instructions per entity and per domain — so the same Amount field can mean one thing in a pipeline view and another in a renewals view — and the business user who owns the meaning changes it without a release.

Yes, and a real one. It's metric-level: it defines what revenue or churn means, consistently, over data modeled in Data 360. It doesn't curate which fields and instructions an agent gets when it opens one Account record. Different layer, different job — an org running both isn't running two of the same thing.

No, and the name is an unfortunate collision. Salesforce Context Service is an Industries developer feature: an in-memory data context that saves repeated database trips for Flow and the Business Rules Engine. It's a performance mechanism, and it has nothing to do with what an AI tool knows about your data.

Both encode meaning and procedure, so there's real overlap. The difference is that an Agentforce topic is part of an agent — build three agents and you have three copies of your methodology, drifting independently, each owned by whoever built that agent. A ContextWorks brief or skill is a standalone, versioned artifact any agent can use, including agents on other platforms, authored by the function that owns the knowledge.

Plenty of teams could. The honest framing is that it isn't build-or-buy — ContextWorks ships a public Apex API and invocable actions, so an AI or agent project already in flight plugs the context layer in rather than rebuilding it. Build on this rather than instead of it.

No. You can move one object at a time, and the surfaces you haven't migrated keep working. Most teams start with the object their agents get wrong most often.

Those are useful for documents and unstructured content. They can't carry field-level meaning for an object model they don't own, and they can't enforce Salesforce sharing on the way out — which is usually the thing the security review is actually about.

The business functions that own the meaning — sales ops, rev ops, marketing ops, finance ops — each managing their own domain. A data or platform team typically enables it and sets the guardrails. A Salesforce admin handles installation and permissions.

Not for entities, briefs, skills, instructions, filters, or domains. A developer is needed only for custom enrichments — bringing in computed analysis from Apex, an external API, or a scoring model.

Standard entities ship activated and initialized from your existing setup, so there's something working immediately. The value curve is in the instructions, and those accumulate — usually starting the first time someone sees an answer that's wrong and knows why.

Change the definition. It takes effect on the next request — no deployment, no release window, no ticket.

Definitions are shared and owned, so pipeline means what the owning team says it means everywhere. Where two teams genuinely need different guidance on the same data, that's an instruction overlay per domain rather than a second definition. Where they need a different definition, that's a deliberate copy, and it's visible as one.

The Quality view runs three numbers per field: designed, permitted, and populated. That separates a permissions problem from a data problem numerically, rather than leaving you to guess why an answer was thin. See how that works.