Common questions. Direct answers.

A Salesforce-native app that allows business users to curate 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.

Not as a copy. There is no sync, no external index and no vector store; every query runs inside your org against live records. The only data that leaves is what an AI tool receives in its response, and that is limited to what the user asking is allowed to see.

ContextWorks grants access to specific domains. Salesforce secures everything underneath: every request runs as the person asking, through field-level security and sharing, so a field that person cannot see is never retrieved.

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 full context of its domain: the fields an administrator chose, the briefs and skills that go with them, and the metrics and enrichments defined for it, all intersected with what the requesting user can already see.

Only if you turn it on. Writes are off by default for the whole org. When you enable them, you choose which domains, entities and fields allow them, the agent asks for confirmation before committing, and every write is logged with the user, the agent, and the before-and-after value of each field.

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 agentic 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.

Salesforce's MCP server handles access, and it does that well: per-user permissions are enforced properly. It does not curate. The standard servers expose every standard and custom object in your org, limited only by the user's permissions, and their tool sets cannot be changed. Narrowing that means writing Apex, since there is no declarative path.

No. A Salesforce field description is one global string, the same for every agent and every context, and only an admin with Customize Application can change it. ContextWorks instructions are attached per entity and per domain, so the same amount field can mean one thing in a pipeline view and another in a renewals view. Salesforce admins add and update descriptions; business users manage ContextWorks.

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.

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 security cares about most.

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 is something working immediately. The value comes from tuning the context: adding instructions, briefs and skills.

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

Yes, when that is appropriate: each domain can carry its own definition. Or they can share one definition, which is reusable between domains, so pipeline means the same thing wherever it is used.

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.