En användare ser en post de inte borde — så hittar du orsaken

Varför kan den här personen se den där posten? är den vanligaste åtkomstfrågan i Salesforce — och den svåraste att besvara med blotta ögat, eftersom plattformen aldrig avgör synlighet på ett enda ställe. Den beviljar unionen av flera mekanismer. Den här guiden ger dig en upprepningsbar ordning för att hitta den som öppnade åtkomsten.

Först, den mentala modellen

Delning i Salesforce är additiv och mest tillåtande vinner. Du letar inte efter en regel som tillåter åtkomst och en regel som blockerar den. Du letar efter vilken enskild tilldelning som helst, eftersom en räcker. (För hela lagringen, se vem kan se en post i Salesforce.)

Om så bara en enda mekanism beviljar åtkomst har användaren den. Ditt jobb är att hitta vilken.

Steg 1 — Läs Sharing-knappen

På posten, klicka på Sharing (tillgänglig för objekt vars org-wide default inte är helt publik). Listan visar användare med åtkomst och en kolumn Reason — Owner, Role Hierarchy, Sharing Rule, Manual Share, Team och så vidare. I de flesta fall namnger detta din boven direkt.

Om användaren inte ens står med i listan men ändå ser posten, misstänk en kringgång på profilnivå — gå till Steg 2.

Steg 2 — Uteslut kringgångar på behörighetsnivå

Dessa ignorerar delningsmodellen helt:

• View All Data / Modify All Data (systembehörigheter, t.ex. på profilen System Administrator).
• View All / Modify All på objektnivå för det specifika objektet.

Har användaren någon av dessa via profil eller ett permission set döljer inga delningsändringar posten. Du måste ta bort behörigheten. Kontrollera deras profil och varje tilldelat permission set.

Steg 3 — Gå igenom delningslagren, uppifrån och ner

Om det verkligen rör sig om en delningstilldelning, identifiera vilket lager:

Org-wide default är för öppen

Om objektets OWD är Public Read Only eller Public Read/Write ser alla med objektåtkomst varenda post. Lösningen är strukturell — strama åt org-wide default och bevilja åtkomst medvetet på nytt.

Rollhierarkin rullar åtkomst uppåt

Om användaren står ovanför postens ägare i rollhierarkin och “Grant Access Using Hierarchies” är på, ärver de automatiskt ägarens åtkomst. Detta är den vanligaste överraskningen.

En alltför vidöppen delningsregel

En kriteriebaserad regel som Region = EMEA → dela med roll X kan inkludera långt fler personer än avsett, särskilt efter data- eller rolländringar. Granska reglerna som riktar sig mot användarens roll, publika grupper eller territorium.

En manuell eller implicit share

• Manuell share: någon använde postens Share-knapp.
• Implicit share: åtkomst till ett överordnat Account ger begränsad läsåtkomst till dess underordnade Cases och Contacts. Folk glömmer ständigt den här — och den är alltid skrivskyddad.
• Apex managed sharing: anpassad kod skapade din share; Sharing-knappen visar den men ursprunget ligger i koden.

Teams och territorier

Medlemskap i ett team för Account/Opportunity/Case, eller ett matchande territorium under Enterprise Territory Management, ger var för sig åtkomst oberoende av varandra.

Steg 4 — Bekräfta att det inte är eftersläpning i omberäkning

Om åtkomsten ser inkonsekvent ut kanske du ser omberäkning av delning slutföras efter en nyligen gjord ägar-, roll- eller regeländring. Låt den bli klar innan du utropar ett fel.

En diagnoschecklista

1. Sharing-knappen → läs Reason för den användaren.
2. Profil + permission sets → någon View All / Modify All?
3. OWD för öppen för det här objektet?
4. Användaren ovanför ägaren i rollhierarkin?
5. Någon delningsregel (särskilt kriteriebaserad) som inkluderar dem?
6. Manuell, implicit eller Apex-share?
7. Team-medlem eller matchande territorium?
8. Nyligen gjord ändring → vänta på omberäkning.

Det första “ja” är ditt svar — och det kan finnas mer än en väg som beviljar samma åtkomst. För det motsatta problemet — en användare som inte kan se en post de borde — se diagnoschecklistan för saknad åtkomst.

Att göra detta på sekunder i stället för en hel eftermiddag

Att gå igenom åtta lager per användar–post-par, tvärs över profiler, permission sets och sex delningsmekanismer, är precis det manuella slitet som döljer verklig exponering. AgentForceAccess gör det åt dig: fråga på vanlig svenska varför en användare kan se en post, så spårar verktyget varje lager och pekar ut den exakta tilldelningen — så att du går rakt på lösningen.

Vanliga frågor

Vilken är den snabbaste första kontrollen?

Öppna posten, klicka på Sharing-knappen och läs kolumnen "Reason" för den användaren. Den namnger mekanismen som ger åtkomst — Owner, Role Hierarchy, Sharing Rule, Manual och så vidare — för de flesta standardobjekt. Bekräfta också att användaren inte helt enkelt har "View All Data" eller "View All" på objektnivå.

Sharing-knappen säger "Role Hierarchy" — vad nu?

Någon som användaren står ovanför i rollhierarkin äger posten (eller har fått den delad med sig), och "Grant Access Using Hierarchies" är aktiverat för objektet. För att ta bort den åtkomsten skulle du behöva ändra hierarkin, ägarskapet eller inaktivera hierarkiåtkomst för anpassade objekt — inget av det görs lättvindigt.

Kan en profilbehörighet, inte delning, vara orsaken?

Ja. "View All Data"/"Modify All Data" och "View All"/"Modify All" på objektnivå kringgår delningsmodellen helt. Har användaren någon av dessa döljer ingen delningsändring posten — du måste i stället ta bort behörigheten.

Varför dyker åtkomst upp och försvinner ryckvis?

Omberäkning av delning. Efter ägarbyten, rollflyttar eller regeländringar bearbetar Salesforce om shares asynkront. Under det fönstret kan åtkomsten se inkonsekvent ut. Låt omberäkningen slutföras innan du drar slutsatsen att det finns ett konfigurationsfel.