Agentforce Coworker is still Beta, and the setup docs name its permissions differently from page to page. This update corrects the GA claim in our earlier version, keeps the comparison with Hosted MCP Servers, and adds the admin path from Turn On through Data 360 policies, identity mapping and record writes.
Status and eligibility in October 2026
Coworker, previously called Ask Agentforce, is a beta service. The Coworker setup guide is labelled Beta: the pages Set Up Agentforce Coworker (Beta), Turn On Agentforce Coworker (Beta), Add or Remove User Access in Agentforce Coworker (Beta), Set Object and Record Access Policies for Agentforce Coworker (Beta) and Review Agentforce Coworker User Mapping (Beta) carry the suffix in their page titles, though the headings inside those pages leave it off. The guide's notice reads: "Agentforce Coworker is a beta service that is subject to the Beta Services Terms at Agreements.Salesforce.com or a written Unified Beta Agreement if executed by Customer, and applicable terms in the Product Terms Directory."
The same notice covers spend: "Any corresponding consumption of entitlements arising from Customer's use of the Non-GA Services shall not give rise to any refund or credit rights." Credits your pilot burns are gone, whatever happens to the feature before GA. Record a Digital Wallet baseline before Turn On and keep the pilot group small.
Salesforce has not published a GA date for Coworker. Winter '27 brings rolling auto-enablement of the Agentforce platform in orgs with Agentforce access, and that change says nothing about when Coworker leaves beta.
My position: pilot in a sandbox or with a small production group under the beta terms, and keep Coworker out of any SLA or support commitment until GA.
Coworker is available in Enterprise, Unlimited and Agentforce 1 Editions. How your org pays for it changes the setup steps.
| Access model | What the org holds | Extra setup |
|---|---|---|
| Usage-based | Foundations or Flex Foundations license, plus Flex Credits entitlements | None beyond the standard steps |
| Seat-based | Agentforce 1 Edition, or an Agentforce for Sales, Service, and Industries license | Assign the Unmetered User Based AI permission set license, create an Unmetered User Based AI permission set, and assign it to those license holders |
Permissions and turning it on
Who needs what
| Person | Permission set or group | Permission set license | Notes |
|---|---|---|---|
| Admin who configures Coworker | Agentforce Coworker Admin permission set | Not named consistently; copy your org's label | Also needs the Salesforce Admin Role |
| End user | Access_Ai_Search permission set group | Not named consistently; copy your org's label | Some pages mention an AI Search license, and the docs don't say whether that is the same assignment |
| Seat-based end user | The Unmetered User Based AI permission set you create | Unmetered User Based AI | Added on top of the end-user assignment |
| Data governance admin | Data 360 Admin or Data 360 Architect role | Not listed | Data 360 Architect to open the Data Governance tab |
The Turn On and user access pages state the admin requirement as the Salesforce Admin Role and Agentforce Coworker Admin Permission Set, and the Turn On page says to assign users the Access_Ai_Search (API Name) permission set group. The docs refer to the matching permission set license without naming it on every page; copy the label your org shows. Write your runbook from what Setup displays in your own org.
The Turn On sequence
- Confirm Data 360 is activated in the org. Provisioned isn't enough.
- Read the billing considerations and record your current Digital Wallet consumption as a baseline.
- Give the configuring admin the Salesforce Admin Role and the Agentforce Coworker Admin permission set.
- In Setup, type Agentforce Coworker in Quick Find, open Get Started with Agentforce Coworker, click Turn On and then Confirm.
- Wait. Salesforce describes setup as "largely automated", so there is little to click, but the job runs for several minutes.
If a prerequisite is missing, the setup page shows a warning and won't activate. Turning on Coworker also turns on Einstein, and Einstein has to stay on for the generative AI features to work.
Assigning and removing users
You can assign the Access_Ai_Search permission set group by hand, though the docs point you to the Coworker Setup route: Manage Agentforce Coworker Users, then Manage, then select users in the Assign Permission Groups to Users window and click Assign and Done. The window shows how many permission set groups are assigned and how many remain. Usage-based orgs are finished at that point. Seat-based orgs still have the Unmetered step from the table above.
Removing access takes two separate actions: remove the permission set group, then remove the permission set license. Skip the second and the license stays assigned to someone who can no longer use Coworker. I run these two queries after every removal batch, with the label filters changed to whatever your org shows.
SELECT Assignee.Username, PermissionSet.Label, PermissionSetGroup.MasterLabel
FROM PermissionSetAssignment
WHERE PermissionSet.Label LIKE '%Coworker%'
OR PermissionSetGroup.DeveloperName = 'Access_Ai_Search'
SELECT Assignee.Username, PermissionSetLicense.MasterLabel
FROM PermissionSetLicenseAssign
WHERE PermissionSetLicense.MasterLabel LIKE '%Coworker%'
OR PermissionSetLicense.MasterLabel LIKE '%AI Search%'
Any username the second query returns that the first does not is probably holding a license with no Coworker access attached; check it before you remove the license.
The pages I read don't explain how assignment behaves when an org has more than one data space. If yours does, test assignment and search results in a sandbox first, and don't assume the default group covers every space.
Access policies and identity mapping
When you connect a supported source such as Google Drive or SharePoint, Coworker applies default data access policies to it automatically. Our earlier version said Microsoft 365 wasn't supported; the current docs list SharePoint as a supported source with default access policies. Whether SharePoint and Google Drive connections are open to every beta org is not yet confirmed, so ask your account team before you plan around them. Slack results follow Slack's own visibility, so users see only Slack content they can already view there. To control which objects and records show up in search results, you add object-level and record-level governance policies in Data 360.
Configuring these needs the Data 360 Admin or Data 360 Architect role, and the Data Governance tab itself needs Data 360 Architect. The path is App Launcher, Data 360, the Data Governance tab, then Policies.
| Level | How many | Targets | Rule |
|---|---|---|---|
| Object | 2 | Search Query DMO, Record View DMO | Grant access to all users holding the Coworker permission set groups and licenses |
| Record | 4 | Record View DLO, Record View DMO, Search Query DLO, Search Query DMO | Deny records where the Individual field doesn't match the current user ID |
As the names suggest, these objects hold per-user search and record-view activity, and the record-level rule keeps one person's rows out of another person's results. The docs go no further than that. Any new DMO you create from the Record View DLO or Search Query DLO needs its own policy, which is easy to forget six months after the pilot.
Turning on Coworker also creates an Identity Resolution ruleset that links each person's Salesforce CRM, Slack and Google Drive identities, matching by default on email address or on a federated ID from your identity provider. A profile from one source inherits permissions from the source it is linked to, so a bad match is a permissions problem. To check one, type User Mapping in Setup Quick Find, select the user, and read the name, username and email used to map them. I would do this by hand for anyone whose Slack or Google email differs from their Salesforce email.
Letting Coworker write records, and the companion-org path
Record creation and updates stay off until you open Get Started with Agentforce Coworker, find the Salesforce CRM row in the Add Existing Data table and switch on Agent Actions. Users can then create and update records from Ask mode, within these limits:
- Coworker proposes each change, and the user confirms it before anything saves.
- It uses the user's existing object and field permissions but checks them only when the user confirms, so a user can be shown a change they aren't allowed to make, and the action then fails.
- One command can change at most 15 records.
- The toggle covers the whole source, so you can't limit writes to particular users, objects or fields.
- Only field-level required settings are checked, so fields required on the page layout can be saved empty.
- Proposed changes may skip field dependencies or validation rules, and the save can then fail after the user has confirmed.
- There is no separate audit log for Coworker changes. Standard field history records them like any edit the user makes by hand.
I'd leave Agent Actions off for the first pilot wave. The toggle reaches every object, and you can't tell Coworker's edits from the user's own afterwards. If the pilot group works mostly on objects with simple validation, turn writes on for a second wave.
If your org uses a Data Cloud One companion org and users need to search the shared data, you set up both orgs. Create the data space first if it is new, and share it with the companion. If Coworker is already on in the home org, either share that org's data space or pick a different home org that doesn't run Coworker. Turn Coworker on in the home org, optionally after making Data 360 objects searchable there. In the companion org, check that Connection Status is Active, Companion Sync Status is Succeeded and the data space's Initialization Status is Active. Then add a Data Cloud Governance policy on the shared data space, since Coworker needs access to the object types before it can search them, and turn Coworker on. Allow All Objects suits most orgs; write a custom policy if you need tighter control.
Coworker or a Hosted MCP Servers build
MCP is an open standard for connecting AI assistants and agents to other systems. With Salesforce Hosted MCP Servers, Salesforce runs the server, handles sign-in and enforces permissions, and an assistant outside Salesforce can look up records and run your Flows and Apex actions.
| Concern | Agentforce Coworker | Hosted MCP Servers |
|---|---|---|
| Who runs it | Salesforce, inside your org | Salesforce runs the server, handles sign-in and enforces permissions |
| Where users work | The Coworker search bar and experience | An external assistant of your choice |
| Data reach | Salesforce CRM, Data 360, Slack, Google Drive and SharePoint sources | Salesforce only; Google, Slack and other tools need their own integrations |
| Actions | Record writes through Agent Actions, plus delegation to your other Agentforce agents | Record lookups, Flows and Apex actions |
| What you build | Configuration and policies | Logic, context assembly and UX |
I would choose MCP when users already spend their day in another assistant, when you need your own orchestration or UX, or when the org isn't eligible for Coworker. Running both is fine. Either way, any Apex action you expose should run in user mode. I have seen a system-mode action written for a nightly integration later wired to an agent, and support users could then read credit balances in chat that their profile hid on the Account page. The fix was one line. Finding it took a security review.
public with sharing class OverdueInvoiceSummary {
public class Request {
@InvocableVariable(required=true label='Account Id')
public Id accountId;
}
public class Result {
@InvocableVariable(label='Overdue invoice count')
public Integer overdueCount = 0;
@InvocableVariable(label='Overdue balance')
public Decimal overdueBalance = 0;
@InvocableVariable(label='Summary')
public String summary;
}
@InvocableMethod(label='Summarise Overdue Invoices' description='Returns unpaid, past-due invoice totals for an account, limited to what the running user can see.')
public static List<Result> summarise(List<Request> requests) {
Set<Id> accountIds = new Set<Id>();
for (Request req : requests) {
accountIds.add(req.accountId);
}
Map<Id, AggregateResult> byAccount = new Map<Id, AggregateResult>();
String accessError;
try {
for (AggregateResult ar : [
SELECT Account__c acct, COUNT(Id) cnt, SUM(Balance__c) bal
FROM Invoice__c
WHERE Account__c IN :accountIds
AND Status__c != 'Paid'
AND Due_Date__c < TODAY
WITH USER_MODE
GROUP BY Account__c
]) {
byAccount.put((Id) ar.get('acct'), ar);
}
} catch (QueryException e) {
accessError = 'You do not have access to invoice balances for this account.';
}
List<Result> results = new List<Result>();
for (Request req : requests) {
Result res = new Result();
AggregateResult ar = byAccount.get(req.accountId);
if (accessError != null) {
res.summary = accessError;
} else if (ar == null) {
res.summary = 'No overdue invoices you can see on this account.';
} else {
res.overdueCount = (Integer) ar.get('cnt');
res.overdueBalance = ar.get('bal') == null ? 0 : (Decimal) ar.get('bal');
res.summary = res.overdueCount + ' overdue invoices totalling ' + res.overdueBalance.setScale(2) + '.';
}
results.add(res);
}
return results;
}
}
with sharing plus WITH USER_MODE applies the running user's sharing, object permissions and field-level security, so a user who can't read Balance__c gets the access message instead of a number the record page would hide. The method takes a list because invocable actions are always called in bulk form, even when a single request arrives.
Both routes cost more than the prompts. Unmetered prompts don't cover Data 360 ingestion, processing or indexing, which draw on Flex Credits or Data Services Credits, so take that Digital Wallet baseline before the pilot. Salesforce has also announced that MCP and API calls from registered external agents will be metered as Headless Platform Interactions against Flex Credits. One user question can trigger several tool calls, so model cost per question, not per conversation. The multiplier isn't published, and Salesforce has committed to 30 days' notice; our Flex Credits agentic API post covers how to plan for it.
What to watch for
- Beta terms apply, and labels or setup steps can change before GA. Recheck the setup pages before each pilot wave.
- Entitlements consumed during the beta carry no refund or credit rights, so cap the pilot and watch Digital Wallet weekly.
- Permission and license names differ between doc pages. Write the runbook from the labels your org shows.
- Removing only the permission set group leaves the license assigned. Run the two queries above after every removal batch.
- Turn On stays blocked while Data 360 is provisioned and not yet activated.
- Every DMO you build from the Record View or Search Query DLO needs its own record-level policy.
- Users whose email differs between Salesforce, Slack and Google Drive can be mapped wrongly. Review User Mapping for them by hand.
- Saves through Agent Actions can fail after the user confirms, layout-required fields can be left empty, and the edits appear in field history as the user's own.
Leave a Comment