"Insufficient access rights on object id" — how to fix it

INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id looks almost identical to its cross-reference cousin, but it points at a different problem. This one is about the record you are touching directly — the user simply can’t write to it.

This guide explains what the message means, how to tell it apart from the cross-reference version, and a repeatable way to fix it.

What the error actually means

When a user inserts, updates, or deletes a record, Salesforce checks two things before allowing the write: the user’s object permissions (CRUD) and their record-level access (sharing). If either is missing for the record being saved, the operation is rejected with:

INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id: <id>

The <id> is the 15- or 18-character ID of the record you tried to save — not a related one. The running user can see it, or even read it, but does not have write access to it.

Translate the message as: “The user running this action can’t edit (or delete) the record <id> they are acting on."

"object id” vs “cross-reference id” — don’t confuse them

These two errors are siblings and are constantly mixed up:

	insufficient access rights on object id	insufficient access rights on cross-reference id
Which record is blocking?	The record you are saving	A related record it points to (lookup / master-detail)
Typical error code	INSUFFICIENT_ACCESS_OR_READONLY	INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY
First thing to fix	Edit/Delete access to this record	Read access to the related record

If the ID in the message is the record you clicked Save on, you are reading this article. If it is a parent, owner, or looked-up record, see insufficient access rights on cross-reference id instead.

Step 0 — Identify the record

Copy the ID from the error and open it directly:

https://yourdomain.my.salesforce.com/<id>

Confirm it is the object and record you expected to save. Everything below targets write access to that record.

The four causes, in order of likelihood

1. Missing object permission (CRUD)

The user’s profile or permission sets lack Edit (or Delete) on the object. Object permissions are the gate before sharing is ever evaluated — a user can have full record access and still be blocked if Edit isn’t granted. See object permissions vs record sharing. Grant the needed CRUD via a permission set.

2. Read-only or no record access (sharing)

The user has object Edit, but only read access — or no access — to this specific record. Common causes:

• A Private org-wide default with no sharing rule reaching the user.
• The user isn’t above the owner in the role hierarchy.
• The record is shared Read Only (sharing rule, team, or manual share), which allows opening but not saving.

Confirm with the Sharing button on the record, then extend Read/Write access with a sharing rule, team, or manual share. The difference between read and read-write here is exactly what separates “can open” from “can save”.

3. No edit access to a master-detail parent

If the record is the detail side of a master-detail relationship, editing it requires access to its parent. A user who can only read the parent (or can’t see it at all) cannot save the child — Salesforce reports it as insufficient access on the child’s object id. Grant the user read-write access to the parent record.

4. A locked or approval-pending record

A record locked by an active approval process — or by an Apex lock — cannot be edited by anyone (admins aside) until it is approved, recalled, or unlocked. This produces the same error even for users who genuinely have edit access. Check the record’s approval history before touching permissions.

Bonus cause — automation in user context. A Flow set to run “in user context” or Apex declared with sharing enforces the running user’s access. If that user can’t write to the record, the automation fails with this error even though an admin tested it fine. Either run the automation in system context, or grant the user real access (causes 1–3).

A repeatable fix checklist

1. Extract <id> from the error and open it — confirm which record failed.
2. Is the record in an approval process / locked? → resolve that first.
3. Does the user have object Edit/Delete on that object? → fix profile/permission set.
4. Does the user have read-write record access (not just read)? → check the Sharing button; add a read-write share.
5. Is it a master-detail child? → grant read-write on the parent.
6. Is an automation running in user context? → decide between system context vs granting access.

The first failing check is your root cause.

Why this error is really an access-tracing problem

Every cause above is the same underlying question: does this user actually have write access to this record, and through which mechanism? That’s tedious to answer by hand across CRUD, ownership, the role hierarchy, and six sharing mechanisms — especially when read vs read-write is the difference.

AgentForceAccess answers it in plain English — paste the user and the record, and it traces exactly which permission or share grants (or blocks) write access, so you stop guessing which cause you’re looking at.

Frequently asked questions

What is the difference between "insufficient access rights on object id" and "on cross-reference id"?

"On object id" is about the record you are directly inserting, updating, or deleting — the user lacks edit/delete access to *that* record. "On cross-reference id" is about a *related* record reached through a lookup or master-detail field. Same family of error, opposite target. If the ID in the message is the record you clicked Save on, it is the object-id version.

Why can an admin edit the record but a standard user gets this error?

Admins usually have "Modify All Data" or "Modify All" on the object, which bypass org-wide defaults, sharing rules, and the role hierarchy. The standard user is blocked by object permissions or record-level sharing. Always reproduce the action while logged in as (or via "Login As") the affected user to isolate it.

The user has Read access to the record — why still insufficient access on save?

Read is not enough to write. Editing or deleting requires Edit/Delete object permission *and* read-write record access. A record shared as "Read Only" (via a sharing rule, role hierarchy, or manual share) lets the user open it but not save changes, which surfaces as insufficient access on update.

Can a locked or approval-pending record cause this error?

Yes. While a record is locked by an active approval process (or an Apex lock), even users with edit access cannot save until it is approved, recalled, or unlocked. Check whether the record is in an approval process before chasing permissions.