Write access
Agents can change records, not just read them. Two independent questions decide what happens: may this write happen at all, and must a human see it first. They resolve by different rules, and confusing them is the usual source of “why can’t this agent update close date”.
May it happen: a chain that only narrows
Writability is the AND of four levels. Any one of them off means no write, and none of them can widen what another allows.
| Level | Applies |
|---|---|
| Org — Allow writes | Always. The kill switch |
| Domain — Allow writes | Only when the call comes through that domain |
| Entity — Write Access | Always, for whichever entity the call resolved to |
| Field — the Write column | Always. Nothing is writable unless declared |
Two things follow that surprise people:
A domain being on is not a grant to its roster. Every entity in a permitted domain still needs its own Write Access on, and its own declared fields. Enabling writes through a domain means setting the flag in two places, not one.
A domain controls the path, not the entity. Turning a domain’s writes off covers calls made through that domain. A call naming the entity directly never consults the domain at all. A domain narrows what passes through it; it is not an ACL on its members, exactly as it isn’t for reads.
Then the platform’s own gates apply: field-level security, sharing, and validation rules. The update runs as the calling user, so nothing here widens what that user could already do by hand. → Security
Must a human see it: the domain decides
Confirmation does not narrow through levels. One setting answers it: 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 | The write returns a proposal. Always |
Whether a human is present is a property of the caller, not of the data. A conversational agent can always confirm; a scheduled job never can. The domain is what scopes a deployment, so the domain is where the answer lives — and a call naming no domain has declared no deployment, so it gets no exemption.
Unattended writes take four deliberate acts: the domain exists, an admin turns the flag on, the caller is granted that domain, and the call names it. There is no org-wide switch that enables them everywhere.
It never widens what is writable. Unattended relaxes the confirmation step only. The org switch, the domain, the entity, and the per-field declaration all still gate.
Where confirmation is required, it is enforced, not merely requested: the preview issues a change digest, and a commit that doesn’t echo it back is refused. So is one whose record was edited in the meantime.
Every write is logged either way, and the log records which mode it ran in. → Writes
What’s next
- Turning writes on — the how-to.
- Domains · Security