Turning writes on
Agents can change a record only where you have allowed it — at the org, the domain, the entity and the field. This page turns each one on. For how they resolve together, see Write access.
Switch it on
Four switches, all off by default. A field is writable only when all four allow it.
| Step | Where |
|---|---|
| 1. Org | Admin › Settings › Governance › Allow writes |
| 2. Domain | The domain editor’s Allow writes through this domain, if calls name a domain |
| 3. Entity | The builder’s Write Access toggle, on each entity |
| 4. Fields | The field picker’s Write column |
Turn on step 3 for each entity separately, including entities in a domain you just enabled. Enabling a domain does not enable what it carries.
One thing overrides all four: an agent without the Update Records tool registered cannot write at all. Register it only where writes belong.
Declare writable fields
Check Write in the field picker on the fields agents may change. An admin does this, or a manager of the entity’s home domain.
Check Create on the fields agents may set when adding a record. It’s a separate list from Write: Account is usually set once and never changed.
The sample entities arrive with a safe set — Opportunity’s stage, close date and next step — so you edit rather than start from nothing.
Allow unattended writes
Where a domain allows writes, the domain editor shows an Allow unattended writes box. That domain’s managers set it, or an admin.
- Off (the default) — the agent gets a proposal back: the record, the fields, the old and new values. Nothing commits until the agent echoes the change digest back.
- On — the write commits on the first call. For automated jobs with nobody watching.
Set it on the narrowest domain that needs it: any caller holding that domain gets the exemption. → Must a human approve it
A config bundle doesn’t carry this setting. An imported domain asks for confirmation until you turn it off.
How many records at once
One call can 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 caps it — 10 by default, 25 at most. Over the cap the call is refused whole: nothing previewed, nothing saved. The cap counts records because your triggers and flows run for every record in the call.
One record failing validation leaves the others unchanged. The response reports each record separately.
Read the write log
Every commit, failed commit and refused attempt writes an Entity Write Log row per field, grouped by call: who changed which field, from what to what, through which entity and domain, and whether anyone confirmed it.
Payload logs expire. Write log rows do not. Browse them on Observe › Writes.
Check effective permissions
Effective permissions resolves the four levels and names the one that narrowed it — the answer to “why can’t this agent update close date?”
The shield badge opens it. It appears on the builder’s status bar, the field picker’s Write column header, and each domain card. Each badge shows its own level’s state. Click one for the resolved view.
| Badge | Means |
|---|---|
| Off (grey) | This level does not allow writes |
| On (green) | Writes work here, and each one waits for approval |
| Auto (amber) | Writes through this domain commit without confirmation. Domains only |
| Blocked (red) | This level allows writes and a level above it does not, so nothing writes through |
From the builder you get a row per field; from a domain card, a row per entity it carries. Get Catalog shows agents the same resolved set.
Notes
- Creating a record has its own four switches, none of them shared with writes. → Create access
- Confirmation is the same Allow unattended writes setting either way. Whether a person is present depends on the caller, not on whether the call adds or changes a record.
What’s next
- Write access — how the four levels resolve
- Create access — the create chain, and how it differs