Create access
Agents can add records, not just read and change them. Creating has its own switches, separate from the ones that govern updates. So an agent can log a task without being able to touch a deal, or the other way round.
How it works
ContextWorks adds a record only when all four levels allow it. Any one of them off means no record.
| Level | Applies | Who sets it |
|---|---|---|
| Org — Allow record creation | Always. The kill switch | Admin |
| Domain — Allow records to be created | Only when the call comes through that domain | That domain’s managers, or an admin |
| Entity — Create Access | Always, for whichever entity the call resolved to | Managers of its home domain, or an admin |
| Field — the Create column | Always. Nothing is set unless you declare it | Managers of its home domain, or an admin |
Then field-level security, the object’s Create permission and your validation rules apply. ContextWorks creates the record as the calling user, so an agent can’t add anything that user couldn’t add by hand.
Turning writes on does not turn creating on. An entity with Write Access on and Create Access off cannot add a record. → Write access
Create has its own field list
The Create column sits beside Write in the field picker and holds a different set. Fields you want set at creation are often ones you never want changed: the account on an opportunity, a last name, a type. Check those for Create and not Write. The reverse works too.
When you first switch Create Access on, ContextWorks copies the Write list into Create. That is a starting point only; nothing keeps the two lists in step afterwards.
Required fields
The picker marks the fields the object requires, warns when one isn’t checked, and offers to check them all.
It warns rather than blocks, because a before-save flow or a trigger in your org may fill a required field where ContextWorks can’t see it. If nothing fills it, the create fails when it runs. The error names the field and says an admin must declare it first.
Confirming a create
A create takes two calls. The first returns the record the agent proposes and adds nothing; the second creates it. The same Allow unattended writes setting on the domain decides whether a create needs that confirmation. → Write access
Repeating an update changes nothing, but repeating a create makes a duplicate, and agents retry when a call times out. So a confirmed create repeated within five minutes returns the record it already made, and says it added nothing the second time.
Notes
- Agents own what they create. You can’t check
OwnerIdfor Create, so an agent can’t create a record for someone else. It creates as the user it runs as. - Required on a page layout is a different thing. Salesforce doesn’t enforce it through the API, so the picker doesn’t show it.
What’s next
- Write access — the chain for changing records.
- Turning writes on — the how-to, including create.
- Security · Domains