"Insufficient access rights on object id" — jak to naprawić

INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id wygląda niemal identycznie jak jego kuzyn cross-reference, ale wskazuje na inny problem. Ten dotyczy rekordu, którego dotykasz bezpośrednio — użytkownik po prostu nie może do niego zapisać.

Ten przewodnik wyjaśnia, co oznacza ten komunikat, jak odróżnić go od wersji cross-reference oraz jak go naprawić w powtarzalny sposób.

Co tak naprawdę oznacza ten błąd

Gdy użytkownik wstawia, aktualizuje lub usuwa rekord, Salesforce sprawdza dwie rzeczy przed zezwoleniem na zapis: uprawnienia użytkownika do obiektu (CRUD) oraz jego dostęp na poziomie rekordu (współdzielenie). Jeśli którakolwiek z tych rzeczy jest niewystarczająca dla zapisywanego rekordu, operacja zostaje odrzucona z komunikatem:

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

<id> to 15- lub 18-znakowe ID rekordu, który próbowałeś zapisać — a nie rekordu powiązanego. Użytkownik wykonujący operację może go widzieć, a nawet odczytać, ale nie ma do niego dostępu w trybie zapisu.

Komunikat tłumacz tak: “Użytkownik wykonujący tę akcję nie może edytować (ani usunąć) rekordu <id>, na którym działa."

"object id” a “cross-reference id” — nie myl ich

Te dwa błędy są rodzeństwem i są nieustannie ze sobą mylone:

	`insufficient access rights on object id`	`insufficient access rights on cross-reference id`
Który rekord blokuje?	Rekord, który zapisujesz	Rekord powiązany, na który on wskazuje (lookup / master-detail)
Typowy kod błędu	`INSUFFICIENT_ACCESS_OR_READONLY`	`INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY`
Co naprawić najpierw	Dostęp Edit/Delete do tego rekordu	Dostęp Read do rekordu powiązanego

Jeśli ID w komunikacie to rekord, na którym kliknąłeś Zapisz, czytasz właściwy artykuł. Jeśli to rekord nadrzędny, właściciel lub rekord wskazywany przez lookup, zajrzyj zamiast tego do insufficient access rights on cross-reference id.

Krok 0 — Zidentyfikuj rekord

Skopiuj ID z błędu i otwórz je bezpośrednio:

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

Potwierdź, że to obiekt i rekord, który chciałeś zapisać. Wszystko poniżej dotyczy dostępu do zapisu tego rekordu.

Cztery przyczyny, w kolejności prawdopodobieństwa

1. Brak uprawnienia do obiektu (CRUD)

Profil lub permission sets użytkownika nie mają uprawnienia Edit (lub Delete) do obiektu. Uprawnienia do obiektu to brama, zanim w ogóle zostanie sprawdzone współdzielenie — użytkownik może mieć pełny dostęp do rekordu i nadal być zablokowany, jeśli nie przyznano Edit. Zobacz uprawnienia do obiektów a współdzielenie rekordów. Przyznaj potrzebne uprawnienia CRUD za pomocą permission set.

2. Dostęp tylko do odczytu lub brak dostępu do rekordu (współdzielenie)

Użytkownik ma uprawnienie Edit do obiektu, ale tylko dostęp read — albo żaden dostęp — do tego konkretnego rekordu. Częste przyczyny:

Domyślny dostęp organizacji (org-wide default) ustawiony na Private bez reguły współdzielenia docierającej do użytkownika.
Użytkownik nie znajduje się powyżej właściciela w hierarchii ról.
Rekord jest udostępniony jako Read Only (reguła współdzielenia, zespół lub udostępnienie ręczne), co pozwala go otworzyć, ale nie zapisać.

Potwierdź to przyciskiem Sharing na rekordzie, a następnie rozszerz dostęp Read/Write regułą współdzielenia, zespołem lub udostępnieniem ręcznym. Różnica między dostępem read a read-write to dokładnie to, co oddziela “można otworzyć” od “można zapisać”.

3. Brak dostępu do edycji rekordu nadrzędnego master-detail

Jeśli rekord jest stroną detail relacji master-detail, jego edycja wymaga dostępu do rekordu nadrzędnego. Użytkownik, który może tylko odczytać rekord nadrzędny (albo w ogóle go nie widzi), nie może zapisać rekordu podrzędnego — Salesforce zgłasza to jako niewystarczające uprawnienia do object id rekordu podrzędnego. Przyznaj użytkownikowi dostęp read-write do rekordu nadrzędnego.

4. Rekord zablokowany lub oczekujący na zatwierdzenie

Rekord zablokowany przez aktywny proces zatwierdzania — albo przez lock w Apex — nie może być edytowany przez nikogo (poza administratorami), dopóki nie zostanie zatwierdzony, wycofany lub odblokowany. Powoduje to ten sam błąd nawet dla użytkowników, którzy faktycznie mają dostęp do edycji. Sprawdź historię zatwierdzania rekordu, zanim zaczniesz zmieniać uprawnienia.

Dodatkowa przyczyna — automatyzacja w kontekście użytkownika. Flow ustawiony tak, by działać “w kontekście użytkownika”, albo Apex zadeklarowany jako with sharing, egzekwuje dostęp użytkownika wykonującego operację. Jeśli ten użytkownik nie może zapisać rekordu, automatyzacja zawodzi z tym błędem, mimo że administrator testował ją bez problemu. Albo uruchom automatyzację w kontekście systemowym, albo przyznaj użytkownikowi rzeczywisty dostęp (przyczyny 1–3).

Powtarzalna lista kontrolna naprawy

Wyodrębnij <id> z błędu i otwórz je — potwierdź, który rekord zawiódł.
Czy rekord jest w procesie zatwierdzania / zablokowany? → najpierw rozwiąż ten problem.
Czy użytkownik ma uprawnienie Edit/Delete do tego obiektu? → popraw profil/permission set.
Czy użytkownik ma dostęp do rekordu w trybie read-write (nie tylko read)? → sprawdź przycisk Sharing; dodaj udostępnienie read-write.
Czy to rekord podrzędny master-detail? → przyznaj read-write na rekordzie nadrzędnym.
Czy automatyzacja działa w kontekście użytkownika? → zdecyduj między kontekstem systemowym a przyznaniem dostępu.

Pierwszy nieudany punkt kontrolny to Twoja przyczyna źródłowa.

Dlaczego ten błąd to tak naprawdę problem śledzenia dostępu

Każda z powyższych przyczyn sprowadza się do tego samego pytania: czy ten użytkownik rzeczywiście ma dostęp do zapisu tego rekordu i przez jaki mechanizm? Odpowiedź na nie ręcznie — w obrębie CRUD, własności, hierarchii ról i sześciu mechanizmów współdzielenia — jest żmudna, zwłaszcza gdy różnica między read a read-write ma kluczowe znaczenie.

AgentForceAccess odpowiada na nie prostym językiem — wklej użytkownika i rekord, a narzędzie prześledzi dokładnie, które uprawnienie lub udostępnienie przyznaje (lub blokuje) dostęp do zapisu, dzięki czemu przestaniesz zgadywać, z którą przyczyną masz do czynienia.

Najczęściej zadawane pytania

Jaka jest różnica między "insufficient access rights on object id" a "on cross-reference id"?

"On object id" dotyczy rekordu, który bezpośrednio wstawiasz, aktualizujesz lub usuwasz — użytkownikowi brakuje dostępu do edycji/usunięcia *tego* rekordu. "On cross-reference id" dotyczy rekordu *powiązanego*, do którego prowadzi pole lookup lub master-detail. Ta sama rodzina błędów, przeciwny cel. Jeśli ID w komunikacie to rekord, na którym kliknąłeś Zapisz, masz do czynienia z wersją object-id.

Dlaczego administrator może edytować rekord, a zwykły użytkownik dostaje ten błąd?

Administratorzy zwykle mają "Modify All Data" lub "Modify All" na obiekcie, które omijają domyślny dostęp organizacji (org-wide defaults), reguły współdzielenia i hierarchię ról. Zwykły użytkownik jest blokowany przez uprawnienia do obiektu lub współdzielenie na poziomie rekordu. Zawsze odtwarzaj akcję zalogowany jako (lub przez "Login As") dotknięty użytkownik, aby wyizolować problem.

Użytkownik ma dostęp Read do rekordu — dlaczego nadal niewystarczające uprawnienia przy zapisie?

Read nie wystarcza do zapisu. Edycja lub usunięcie wymaga uprawnienia Edit/Delete do obiektu *oraz* dostępu do rekordu w trybie odczyt-zapis. Rekord udostępniony jako "Read Only" (przez regułę współdzielenia, hierarchię ról lub udostępnienie ręczne) pozwala użytkownikowi go otworzyć, ale nie zapisać zmian, co objawia się jako niewystarczające uprawnienia przy aktualizacji.

Czy zablokowany lub oczekujący na zatwierdzenie rekord może powodować ten błąd?

Tak. Gdy rekord jest zablokowany przez aktywny proces zatwierdzania (lub blokadę Apex), nawet użytkownicy z dostępem do edycji nie mogą go zapisać, dopóki nie zostanie zatwierdzony, wycofany lub odblokowany. Sprawdź, czy rekord jest w procesie zatwierdzania, zanim zaczniesz szukać przyczyny w uprawnieniach.