Write access
Agents can change records, not just read them. Two questions decide what happens: may this write happen at all, and must a human approve it first. Each has its own answer, in its own place.
May it happen
A write happens only if all four levels allow it. Any one of them off means no write.
| Level | Applies | Who sets it |
|---|---|---|
| Org — Allow writes | Always. The kill switch | Admin |
| Domain — Allow writes | Only when the call comes through that domain | That domain’s managers, or an admin |
| Entity — Write Access | Always, for whichever entity the call resolved to | Managers of its home domain, or an admin |
| Field — the Write column | Always. Nothing is writable unless you declare it | Managers of its home domain, or an admin |
Then field-level security, sharing and your validation rules apply. The update runs as the calling user, so an agent can’t change anything that user couldn’t change by hand. → Security
Domain managers own the entities homed with them, writable fields included. An admin keeps the org-wide settings: the kill switch above, and Max records per write call.
Two points to watch:
Each entity needs its own switches. Turning Allow writes on for a domain doesn’t reach the entities it carries: each one still needs its own Write Access and its own checked fields. That’s two places, not one.
A domain governs the calls that come through it. Turning a domain’s writes off stops calls made through that domain. A call that names the entity directly never consults the domain, the same as it works for reads.
Must a human approve it
One setting answers this, not a chain of four: Allow unattended writes on the domain, off by default.
| The call | What happens |
|---|---|
| Names a domain with Allow unattended writes off | The write returns a proposal. Nothing commits until the caller confirms |
| Names a domain with it on | The write commits on the first call |
| Names no domain | Only Apex can make that call; an agent call always names a domain. The write returns a proposal. Always |
A conversational agent can always confirm; a scheduled job never can. The caller decides that, not the record it touches. A domain scopes a deployment, so the setting lives there.
Unattended writes need three things: the domain exists, a manager or an admin turns the flag on, and the caller holds that domain. There is no org-wide switch.
Naming the domain used to be a fourth requirement, and for an Apex caller it still is. An agent call names a domain either way, so it adds nothing there.
Deploy unattended writes through a scoped tool and keep the domain’s reach narrow. Every caller granted that domain writes without confirming.
Allow unattended writes relaxes the confirmation step only. It never widens what an agent may change.
ContextWorks enforces the confirmation rather than asking for it. The preview issues a change digest, and ContextWorks refuses any commit that doesn’t echo it back, or whose record changed in the meantime.
ContextWorks logs every write either way, and each row says confirmed or unattended. → Writes
Write config travels with the version
Write Access and the Write column belong to the entity, so they belong to each version. Activating captures them; rolling back restores them.
A rollback can therefore widen what an agent may change, so the activation screen lists write config alongside fields and instructions.
Notes
- Creating has its own chain. Adding a record answers to its own org toggle, domain flag, entity toggle and field list. Turning writes on doesn’t turn creating on. → Create access
- Versions activated before write config shipped carry none. Those versions defer to whatever the entity has now; a missing setting doesn’t mean off.
What’s next
- Create access — the same shape, for adding records.
- Turning writes on — the how-to.
- Domains · Security