"Insufficient access rights on object id" — så fixar du det

INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id ser nästan identiskt ut som sin cross-reference-kusin, men det pekar på ett annat problem. Det här handlar om den post du rör direkt — användaren kan helt enkelt inte skriva till den.

Den här guiden förklarar vad meddelandet betyder, hur du skiljer det från cross-reference-versionen och ger en upprepningsbar metod för att lösa det.

Vad felet faktiskt betyder

När en användare infogar, uppdaterar eller raderar en post kontrollerar Salesforce två saker innan skrivningen tillåts: användarens objektbehörigheter (CRUD) och deras postnivååtkomst (delning). Om någon av dessa saknas för posten som sparas avvisas operationen med:

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

<id> är det 15- eller 18-teckens ID:t för den post du försökte spara — inte en relaterad. Den körande användaren kan se den, eller till och med läsa den, men har inte skriv-åtkomst till den.

Tolka meddelandet som: “Användaren som kör den här åtgärden kan inte redigera (eller radera) posten <id> som de agerar på."

"object id” kontra “cross-reference id” — blanda inte ihop dem

De här två felen är syskon och förväxlas ständigt:

	`insufficient access rights on object id`	`insufficient access rights on cross-reference id`
Vilken post blockerar?	Posten du sparar	En relaterad post den pekar på (lookup / master-detail)
Typisk felkod	`INSUFFICIENT_ACCESS_OR_READONLY`	`INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY`
Första att åtgärda	Redigerings-/raderingsåtkomst till den här posten	Läsåtkomst till den relaterade posten

Om ID:t i meddelandet är den post du klickade Spara på, läser du rätt artikel. Om det är en överordnad, ägare eller uppslagen post, se insufficient access rights on cross-reference id i stället.

Steg 0 — Identifiera posten

Kopiera ID:t från felet och öppna det direkt:

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

Bekräfta att det är objektet och posten du förväntade dig att spara. Allt nedan riktar sig mot skrivåtkomst till den posten.

De fyra orsakerna, i sannolikhetsordning

1. Saknad objektbehörighet (CRUD)

Användarens profil eller permission sets saknar Edit (eller Delete) på objektet. Objektbehörigheter är grinden som passeras innan delning ens utvärderas — en användare kan ha full poståtkomst och ändå blockeras om Edit inte är beviljat. Se objektbehörigheter kontra postdelning. Tilldela den nödvändiga CRUD-behörigheten via ett permission set.

2. Skrivskyddad eller ingen poståtkomst (delning)

Användaren har objektets Edit, men endast läs-åtkomst — eller ingen åtkomst — till just den här posten. Vanliga orsaker:

En Private org-wide default utan delningsregel som når användaren.
Användaren ligger inte över ägaren i rollhierarkin.
Posten är delad Read Only (delningsregel, team eller manuell delning), vilket tillåter öppning men inte sparning.

Bekräfta med Sharing-knappen på posten och utöka sedan Read/Write-åtkomsten med en delningsregel, ett team eller en manuell delning. Skillnaden mellan läs och läs-skriv här är exakt det som skiljer “kan öppna” från “kan spara”.

3. Ingen redigeringsåtkomst till en master-detail-överordnad

Om posten är detail-sidan i en master-detail-relation kräver redigering av den åtkomst till dess överordnade. En användare som bara kan läsa den överordnade (eller inte kan se den alls) kan inte spara barnposten — Salesforce rapporterar det som otillräcklig åtkomst på barnpostens object id. Ge användaren läs-skriv-åtkomst till den överordnade posten.

4. En låst eller godkännandeväntande post

En post som är låst av en aktiv godkännandeprocess — eller av ett Apex-lock — kan inte redigeras av någon (admins undantaget) förrän den är godkänd, återkallad eller upplåst. Det här ger samma fel även för användare som faktiskt har redigeringsåtkomst. Kontrollera postens godkännandehistorik innan du rör behörigheter.

Bonusorsak — automation i användarkontext. En Flow som konfigurerats att köras “i användarkontext” eller Apex deklarerad with sharing upprätthåller den körande användarens åtkomst. Om den användaren inte kan skriva till posten misslyckas automationen med det här felet, även om en admin testade den utan problem. Antingen kör du automationen i systemkontext, eller så ger du användaren verklig åtkomst (orsak 1–3).

En upprepningsbar åtgärdschecklista

Extrahera <id> från felet och öppna det — bekräfta vilken post som misslyckades.
Ligger posten i en godkännandeprocess / är den låst? → lös det först.
Har användaren objektets Edit/Delete på det objektet? → åtgärda profil/permission set.
Har användaren läs-skriv-poståtkomst (inte bara läs)? → kontrollera Sharing-knappen; lägg till en läs-skriv-delning.
Är det ett master-detail-barn? → ge läs-skriv-åtkomst på den överordnade.
Körs en automation i användarkontext? → välj mellan systemkontext och att ge åtkomst.

Den första kontrollen som misslyckas är din grundorsak.

Varför det här felet egentligen är ett åtkomstspårningsproblem

Varje orsak ovan är samma underliggande fråga: har den här användaren faktiskt skrivåtkomst till den här posten, och via vilken mekanism? Det är mödosamt att besvara för hand över CRUD, ägarskap, rollhierarkin och sex delningsmekanismer — särskilt när läs kontra läs-skriv är skillnaden.

AgentForceAccess besvarar det på vanlig svenska — klistra in användaren och posten, så spårar verktyget exakt vilken behörighet eller delning som ger (eller blockerar) skrivåtkomst, så att du slutar gissa vilken orsak du har framför dig.

Vanliga frågor

Vad är skillnaden mellan "insufficient access rights on object id" och "on cross-reference id"?

"On object id" handlar om den post du direkt infogar, uppdaterar eller raderar — användaren saknar redigerings-/raderingsåtkomst till *den* posten. "On cross-reference id" handlar om en *relaterad* post som nås via ett lookup- eller master-detail-fält. Samma felfamilj, motsatt mål. Om ID:t i meddelandet är den post du klickade Spara på, är det object-id-versionen.

Varför kan en admin redigera posten medan en standardanvändare får det här felet?

Admins har vanligtvis "Modify All Data" eller "Modify All" på objektet, som kringgår org-wide defaults, delningsregler och rollhierarkin. Standardanvändaren blockeras av objektbehörigheter eller postnivådelning. Återskapa alltid åtgärden inloggad som (eller via "Login As") den drabbade användaren för att isolera problemet.

Användaren har Read-åtkomst till posten — varför ändå otillräcklig åtkomst vid sparning?

Read räcker inte för att skriva. Att redigera eller radera kräver objektbehörigheten Edit/Delete *och* läs-skriv-poståtkomst. En post som delats som "Read Only" (via en delningsregel, rollhierarki eller manuell delning) låter användaren öppna den men inte spara ändringar, vilket visar sig som otillräcklig åtkomst vid uppdatering.

Kan en låst eller godkännandeväntande post orsaka det här felet?

Ja. Medan en post är låst av en aktiv godkännandeprocess (eller ett Apex-lås) kan inte ens användare med redigeringsåtkomst spara förrän den är godkänd, återkallad eller upplåst. Kontrollera om posten ligger i en godkännandeprocess innan du jagar behörigheter.