Turning writes on
What agents may change, and how to enable it. Writes are declared the same way fields are curated — one more property on the entity — and every level must allow them. For how the levels resolve, see Write access.
Switch it on
Four flags, all off by default. All four must be on for a single field to be writable:
| Step | Where |
|---|---|
| 1. Org | Admin › Settings › Governance › Allow writes |
| 2. Domain | The domain editor’s Allow writes through this domain — only if calls route through a domain |
| 3. Entity | The builder’s Write Access toggle, on each entity |
| 4. Fields | The field picker’s Write column |
Step 3 is per entity, including entities inside a domain you just enabled — turning a domain on does not grant its roster.
Stronger than all four: a surface without the Update Records tool registered cannot write at all. Deploy it only where writes belong.
Declare writable fields
In the field picker, tick Write on the fields agents may change (admin-only). The sample entities arrive with a safe set — Opportunity’s stage, close date, and next step — so you edit rather than author.
Allow unattended writes
Where a domain allows writes, the domain editor shows an admin-only Allow unattended writes box.
- Off (the default) — the agent gets a proposal back: the record, the fields, old and new values. Nothing commits until it echoes the change digest back.
- On — the write commits on the first call. For automated processes with no human in the loop.
It is set once per domain, not per entity. Whether someone is present to confirm is a property of the caller, not of the data — the same headless job requiring confirmation for Opportunity but not for Task would be an incoherent configuration.
Two rules keep the exemption deliberate:
- A call naming no domain always confirms. There is no org-wide setting that relaxes it.
- Unattended writes belong to scoped tools, where the generated Apex pins the domain. A domain arriving as an agent-supplied input is not a declaration of anything.
It never widens what is writable. The org switch, the domain, the entity, and the per-field flags all still gate.
Config bundles never carry the setting; an imported domain confirms until someone says otherwise.
How many records at once
One call may address several records, each with its own changes, so a set found through Find Records becomes one call and one approval. Max records per write call (default 10, max 25) caps it, counting records rather than calls. Over the cap the call is refused whole — nothing previewed, nothing saved. Your triggers and flows run for every record in a call, which is what the bound is really about; data-loader scale is not this tool’s job.
The set is not a transaction. One record failing validation leaves the others as they were, and each record is reported on its own.
Read the write log
Every commit, failed commit, and refused attempt writes durable Entity Write Log rows — one per field, grouped per call: which surface changed which field, from what to what, through which entity and domain, under which confirmation posture, by whom, when. A row marked unattended is the audit answer for an autonomous write: what makes it defensible is that an admin turned it on deliberately and every row says so. Read payload logs expire; the write log does not. Browse it on Observe › Writes.
Check effective permissions
Effective permissions resolves the chain and names the level that narrowed it — the answer to “why can’t this agent update close date”.
Reach it from the shield badge, which appears at every level writes narrow: the builder’s status bar, the field picker’s Write column header, and each domain card. The badge always shows that level’s own state, and clicking it opens the resolved view.
| Badge | Means |
|---|---|
| Off (grey) | This level does not allow writes |
| On (green) | Writes work here, and each one is confirmed |
| Auto (amber) | Unattended — writes through this domain commit without confirmation. Domains only |
| Blocked (red) | This level allows writes and something above it does not, so nothing writes through |
From the builder you get one row per field; from a domain card, one row per entity it carries. Get Catalog shows agents the same resolved set.
What’s next
- Write access — how the levels resolve.
- Invocable actions — Update Records’ inputs and behavior.