Salesforces delningsmodell är ett viktigt element i din organisations förmåga att tillhandahålla säker åtkomst till programdata. Därför är det viktigt att utforma din delningsmodell korrekt för att uppfylla dina nuvarande och framtida dataåtkomstkrav. I detta dokument går vi igenom dataåtkomstkomponenter, användningsfall för delningsmodeller och verkliga delningslösningar för kunder, och vi ger några felsökningsriktlinjer.

Detta dokument är avsett för avancerade systemadministratörer och arkitekter. För att förstå koncepten måste du ha en fungerande Knowledge om Salesforces säkerhets- och delningsmodell. Förkrav för denna guide är:

• Salesforce-hjälpen: Delningsinställningar
• Trailhead Modul: Datasäkerhet
• Utforma poståtkomst för företagsskala
• Salesforce välarkitekterade - Säker

Denna guide fokuserar på de huvudfunktioner som används för att styra postnivååtkomst till standardobjekt och egna objekt. Ämnen som inte tas upp i denna guide inkluderar:

• Mappåtkomst
• Innehållsåtkomst
• Chatter
• Knowledge Base-åtkomst
• Idéer, Frågor/Svar-åtkomst
• Tillgänglighet för mobildata

Postnivåsäkerhet låter dig ge användare åtkomst till vissa objektposter, men inte andra. Som med de flesta program börjar dataåtkomst med en användare. Programmet måste veta vem användaren är innan det ger åtkomst. För Salesforce finns det olika typer av användare och ibland är åtkomstnivån olika efter typ. Istället för att granska varje attribut för varje licenstyp kommer vi här att fokusera på de intressanta attribut som har betydande påverkan på dataåtkomst. Postägande och fullständig åtkomst är synonyma och utbytbara och ger användaren den högsta åtkomstnivån till en post.

Användare med hög volym

Användare med hög volym (inklusive användare med licenstyperna Customer Community, High Volume Customer Portal och Authenticated Website) använder inte delningsmodellen eftersom deras licenstyper inte har stöd för roller. Dessa licenser har sin egen delningsmodell som fungerar efter matchning med främmande nyckel mellan användaren (som innehar licensen) och data i sökningar efter Konto och Kontakt. Administratörer kan skapa delningsuppsättningar eller delningsgrupper för att bevilja användare med hög volym åtkomst till poster.

Externa Chatter Free- och Chatter-licenser

Chatter Free- och Chatter External-licenserna följer inte standarddelningsmodellen. Dessa licenser har inte åtkomst till CRM-poster (standardobjekt eller egna objekt) och innehållsfunktionalitet och har inte stöd för roller, därför finns ingen delning.

För resten av detta dokument antar vi att en Salesforce-användartyp använder en fullständig delningsmodell. Se Användarlicenser för mer information om varje tillgänglig licenstyp.

Profiler och behörighetsuppsättningar

Profiler och behörighetsuppsättningar ger objektnivåsäkerhet genom att avgöra vilka typer av data användare ser och om de kan redigera, skapa eller ta bort poster. För varje objekt ignorerar behörigheterna “Visa alla” och “Ändra alla” delningsregler och inställningar, vilket gör att administratörer snabbt kan bevilja åtkomst till poster associerade med ett givet objekt i hela organisationen. Dessa behörigheter är ofta bättre alternativ än de administrativa behörigheterna “Visa alla data” och “Ändra alla data”, som låter användare se eller ändra alla appar och data.

Profiler och behörighetsuppsättningar styr även fältnivåsäkerhet, vilket avgör fälten i varje objekt som användare har åtkomst till. Till exempel kan ett objekt ha 20 fält, men fältnivåsäkerhet kan konfigureras för att förhindra att användare ser fem av de 20 fälten.

Vi rekommenderar starkt att du använder behörighetsuppsättningar och behörighetsuppsättningsgrupper istället för profiler för att hantera dina användares objektbehörigheter. Eftersom du kan återanvända mindre byggstenar för behörighetsuppsättningar kan du undvika att skapa dussintals eller till och med hundratals profiler för varje användare och jobbfunktion.

Postägande och köer

Varje post måste ägas av en enskild användare eller en kö. Ägaren har åtkomst till posten, baserat på objektinställningarna för ägarens profil. Till exempel, om ägarens profil har behörigheten Skapa och Läs för ett objekt, men inte behörigheten Redigera eller Ta bort, kan ägaren skapa en post för objektet och se den nya posten. Ägaren kan dock inte redigera eller ta bort posten. Användare högre upp i en hierarki (roll eller område) ärver samma dataåtkomst som sina underordnade för standardobjekt. Om den underordnade har skrivskyddad åtkomst kommer även användarna ovanför dem i rollhierarkin att ha det. Denna åtkomst gäller för poster som ägs av användare samt poster som delas med dem.

Köer hjälper dig prioritera, distribuera och tilldela poster till team som delar arbetsbelastningar. Kömedlemmar och användare högre upp i rollhierarkin kan komma åt köer från listvyer och ta över ägarskapet för poster i en kö.

Om en enskild användare äger fler än 10 000 poster rekommenderas följande:

• Användarposten för ägaren ska inte ha en roll i rollhierarkin.

• Om ägarens användarpost måste ha en roll, placera rollen högst upp i hierarkin i sin egen gren av rollhierarkin.

Mer information finns i Se Salesforce väl arkitektritat - Pålitligt.

Organisationsomfattande standarder

Organisationsomfattande delningsinställningar specificerar standardåtkomstnivån som användare har till varandras poster. Du använder organisationsomfattande delningsinställningar för att låsa dina data till den mest restriktiva nivån. Använd de andra postnivåsäkerhetsverktygen och delningsverktygen för att selektivt ge åtkomst till andra användare. Till exempel har användare objektnivåbehörigheter för att läsa och redigera säljprojekt och den organisationsomfattande delningsinställningen är Skrivskyddad. Som standard kan dessa användare läsa alla säljprojektposter, men kan inte redigera några om de inte äger posten eller beviljas andra behörigheter.

Organisationsomfattande standardinställningar kan ändras från en inställning till en annan (Privat till Styrd av överordnad och sedan tillbaka till Privat). Dessa ändringar kräver dock omräkning av delning och kan beroende på volym resultera i långa bearbetningstider.

Endast för egna objekt kan du konfigurera inställningen Bevilja åtkomst med hierarkier. Om det inte är markerat (standard är markerat) hindras användare högre upp i rollhierarkin från att ärva åtkomst. Denna inställning finns i de organisationsomfattande standardinställningarna.

Rollhierarki

En rollhierarki representerar en nivå av dataåtkomst som en användare eller grupp av användare behöver. Rollhierarkin säkerställer att chefer alltid har åtkomst till samma data som sina anställda, oavsett de organisationsomfattande standardinställningarna. Rollhierarkier behöver inte matcha ditt organisationsschema exakt. Istället bör varje roll i hierarkin representera en nivå av dataåtkomst som en användare eller grupp av användare behöver.

I Salesforce-organisationer som skapats i utgåvan Spring '21 eller senare kan du skapa upp till 5 000 roller. I organisationer som skapats innan utgåvan Spring '21 kan du skapa upp till 500 roller och kan kontakta Salesforces kundsupport för att öka denna gräns. Vi rekommenderar att hålla antalet interna roller till 25 000 och antalet externa roller till 100 000.

Vi rekommenderar att du inte håller rollhierarkin på fler än 10 nivåer i hierarkin.

Om en användares roll ändras utvärderas alla relevanta delningsregler för att korrigera åtkomst efter behov. Peer inom samma roll garanterar dem inte åtkomst till varandras data.

Modellering av rollhierarkin börjar med att förstå hur organisationen är strukturerad. Detta byggs vanligtvis från att förstå en chefs omfattning, med början från början. VD övervakar hela företaget. VD har vanligtvis direkta rapporter som sedan kan segmenteras efter affärsenhet (försäljning eller support) eller geografisk region (EMEA, APAC). Personen har sedan direkta rapporter som kan segmenteras ytterligare, och så vidare. Även om detta låter väldigt likt ett organisationsschema för HR, fokusera på dataåtkomst vid modellering med hänsyn till HR-rapportering.

Överlägg är alltid den svåra delen av hierarkin. Om de är i sin egen filial behöver de antingen delningsregler, team eller områdeshantering för att få den åtkomst som behövs. Om de viks in i hierarkin kan det få konsekvenser för rapporteringen.

Det är viktigt att lägga tid på att konfigurera rollhierarkin eftersom det är en av de grundläggande aspekterna av delningsmodellen.

Offentliga grupper

En offentlig grupp är en samling individuella användare, roller, områden och så vidare, som alla har en funktion gemensamt. Offentliga grupper kan bestå av:

• Användare
• Kundportalanvändare
• Partneranvändare
• Roller
• Roller och interna underordnade
• Roller, interna och portalunderordnade
• Portalroller
• Portalroller och underordnade
• Områden
• Områden och underordnade
• Andra offentliga grupper (kapsling)

Grupper kan kapslas (Grupp A kapslas i Grupp B), men kapsla inte fler än fem nivåer. Kapsling påverkar gruppunderhåll och prestanda på grund av gruppmedlemskapsberäkning. Vi rekommenderar att hålla det totala antalet offentliga grupper för en organisation till 100 000.

Ägarbaserade delningsregler

Ägarbaserade delningsregler tillåter undantag från organisationsomfattande standardinställningar och rollhierarkin som ger ytterligare användare åtkomst till poster de inte äger. Ägarbaserade delningsregler baseras endast på postägaren.

Kontaktägarbaserade delningsregler gäller inte för privata kontakter eller kontakter som inte är associerade med ett konto.

Gränsen för totala delningsregler per objekt är 300.

Kriteriebaserade delningsregler

Kriteriebaserade delningsregler ger åtkomst till poster baserat på postens fältvärden (kriterier). Om kriterierna uppfylls (ett eller flera fältvärden) skapas en delningspost för regeln. Ägarskap av poster övervägs inte.

Gränsen för kriteriebaserade delningsregler och delningsregler för gästanvändare per objekt är 50.

Delningsregler för gästanvändare

En delningsregel för gästanvändare är en speciell typ av kriteriebaserade delningsregler som används för att bevilja poståtkomst till ej inloggade gästanvändare. Gränsen för kriteriebaserade delningsregler och delningsregler för gästanvändare per objekt är 50.

Varning: Delningsregeltypen Gästanvändare beviljar åtkomst till gästanvändare utan inloggningsuppgifter. Genom att skapa en delningsregel för gästanvändare tillåter du omedelbar och obegränsad åtkomst till alla poster som matchar delningsregelns kriterier för vem som helst. För att säkra dina Salesforce-data och ge dina gästanvändare åtkomst till vad de behöver, tänk igenom alla användningsfall och konsekvenser av att skapa denna typ av delningsregel. Implementera säkerhetskontroller som du tycker är lämpliga för dina datas känslighet. Salesforce ansvarar inte för någon exponering av dina data för ej inloggade användare baserat på denna ändring från standardinställningarna.

Manuell delning

Ibland är det omöjligt att definiera en enhetlig grupp av användare som behöver åtkomst till en viss uppsättning poster. Postägare eller andra användare med lämpliga behörigheter, som systemadministratörer, kan använda manuell delning för att ge läs- och redigeringsbehörigheter till användare som inte har åtkomst på något annat sätt. Manuell delning automatiseras inte som organisationsomfattande delningsinställningar, rollhierarkier eller delningsregler. Men det ger postägare flexibiliteten att dela poster med användare som måste se dem.

Manuell delning tas bort om postägaren ändras eller om delningsåtkomsten som beviljas inte beviljar ytterligare åtkomst utöver objektets organisationsomfattande standardåtkomstnivå för delning. Detta gäller även för manuella delningar som skapas programmatiskt.

Manuella delningsposter definieras som delningsposter med radorsaken satt till manuell delning.

Alla delningsposter (standardobjekt och egna objekt) med en radorsak satt till manuell delning kan redigeras och tas bort av knappen Dela på objektets sidlayout, även om delningsposten skapades programmatiskt.

Teams

Ett team är en grupp användare som arbetar tillsammans med ett konto, säljprojekt eller kundcase. Postägare kan bygga ett team för varje post de äger. Postägaren lägger till teammedlemmar och specificerar åtkomstnivån som varje teammedlem har till posten. Vissa teammedlemmar kan ha skrivskyddad åtkomst medan andra har läs/skriv.

Endast ägare, personer högre upp i hierarkin och administratörer kan lägga till teammedlemmar och ge mer åtkomst till medlemmen. En teammedlem med läs-/skrivåtkomst kan lägga till en annan medlem som redan har åtkomst till posten som teamet är associerat med. Teammedlemmen kan inte ge dem ytterligare åtkomst.

Att skapa en teammedlem i appen skapar två poster: en teampost och en associerad delningspost. Om du skapar teammedlemmar programmatiskt måste du hantera både teamposten och tillhörande delningspost. Det finns endast ett team per post (Konto, Säljprojekt eller Kundcase). Om flera team behövs, beroende på dina specifika behov, överväg områdeshantering eller programmatisk delning

Områdeshierarki

När du använder Enterprise-områdeshantering konfigurerar du en områdeshierarki som visar en modells områdesstruktur och fungerar som dess huvudsakliga interaktionspunkt. Om Enterprise-områdeshantering har aktiverats måste du hantera både rollhierarkin och områdeshierarkin. Mer information finns i Företagsområdeshantering i Salesforce-hjälpen.

Apex hanterad delning

Apex hanterad delning (även kallad programmatisk delning) låter dig använda kod för att bygga sofistikerade och dynamiska delningsinställningar när ett dataåtkomstkrav inte kan uppfyllas på något annat sätt.

Om du skapar en delningspost programmatiskt och den färdiga radorsaken (manuell delning) används kan du behålla denna delningspost med knappen Dela i appen. Delningsposten är föremål för alla regler med den manuella delningsradorsaken, till exempel borttagning vid ägaröverföring.

Du kan även skapa dina egna Apex för egna objekt för att följa varför en post med en användare eller grupp av användare och förenkla kodningen som krävs för att göra uppdateringar och borttagningar av delningsposter.

Mer information finns i Att dela en post innan du överväger att använda programmatisk delning.

Begränsningsregler

I din dataåtkomstkonfiguration kanske du vill förhindra att användare ser poster som kan innehålla känsliga data eller som helt enkelt inte är viktiga för deras arbete. Du kan använda begränsningsregler för att låta användare komma åt endast poster som uppfyller de kriterier du specificerar. När en begränsningsregel tillämpas för en användare filtreras de poster som användaren beviljas åtkomst till via organisationsomfattande standarder, delningsregler och andra delningsmekanismer efter kriterier som du specificerar. Begränsningsregler fungerar på motsatt sätt som de delningskomponenter som diskuteras i detta ämne. Istället för att öppna åtkomst för användare begränsar de den ytterligare.

Begränsningsregler är tillgängliga för egna objekt, externa objekt, kontrakt, händelser, uppgifter, tidrapporter och tidrapportposter. Du kan skapa upp till två aktiva begränsningsregler per objekt i Enterprise och Developer Editions och upp till fem aktiva begränsningsregler per objekt i Performance och Unlimited Editions. Begränsningsregler tillämpas på följande Salesforce-funktioner:

• Listvyer
• Sökningar
• Relaterade listor
• Rapporter
• Sök
• SOQL
• SOSL

Implicit delning

Implicit delning sker automatiskt. Du kan varken stänga av eller slå på den—den är inbyggd i programmet. Med andra ord är implicit delning inte en konfigurerbar inställning, men det är viktigt för alla arkitekter att förstå. Överordnad implicit delning ger åtkomst till överordnade poster (endast konto) när en användare har åtkomst till underordnade säljprojekt, kundcase eller kontakter för det kontot. Salesforce har en dataåtkomstpolicy som anger om en användare kan se en kontakt (eller säljprojekt, kundcase eller order), då ser användaren underförstått det associerade kontot. Underordnad implicit delning ger åtkomst till ett kontos underordnade poster till kontoägaren. Denna åtkomst definieras vid ägarens roll i rollhierarkin. Underordnad implicit delning gäller endast för kontakt-, säljprojekt- och kundcaseobjekt (kontots underordnade). De åtkomstnivåer som kan tillhandahållas är Visa, Redigera och Ingen åtkomst för vart och ett av de underordnade objekten när rollen skapas. Genom att ställa in till Visa kan kontoägaren implicit se de associerade objektposterna (kontakt, säljprojekt eller kundcase). Genom att ställa in till Redigera kan kontoägaren implicit ändra det associerade objektet (kontakt, säljprojekt eller kundcase).

Implicit delning gäller inte för egna objekt.

Det finns inte en delningsmodell som passar alla Salesforce-organisationer. Alla organisationer har olika krav och utmaningar när de försöker utforma den bästa delningsmodellen. Det är viktigt att använda de mest lämpliga komponenterna för dataåtkomst för att uppfylla organisationens delningskrav. Följande scenarion är vanliga utmaningar när du försöker skapa en delningsmodell.

• Vad händer med rollhierarkin?

  • Inget händer med rollhierarkin om du även använder en områdeshierarki. Om du använder både områdesbaserad prognostisering och rollbaserad prognostisering tillsammans måste du dock hantera två hierarkier. I detta fall rekommenderar vi att du använder rollhierarkin för att modellera HR-rapporteringsstrukturen och sedan använder områdeshierarkin för att modellera den faktiska försäljningshierarkin. Områdeshierarkin är bäst för att modellera en matrisrapporteringsstruktur, där någon kan rapportera till flera chefer.

    Om du inte använder områdesbaserad prognostisering och rollbaserad prognostisering tillsammans är det endast möjligt att använda områdeshierarkin som försäljningshierarki. I detta scenario är det bäst att förenkla, eller platta ut, hierarkin så mycket som möjligt.

    Vi rekommenderar inte att göra rollhierarkin och områdeshierarkin identiska eftersom det orsakar onödig delningsaktivitet.

• Kan du fortfarande använda team?

  • Ja. Om du kan uppfylla dina åtkomstkrav inom områdeshierarkin (som överlägg) är det dock bättre att göra det där än att använda team. Du har redan flera hierarkier (roll och område), så när du försöker hålla saker och ting så enkla som möjligt, implementera endast team om ingen annan befintlig delningskomponent kommer att uppfylla kravet.

• Omjustering och omtilldelning

  • Det finns två typer av ändringar som inträffar – medlemskapet i roller, team eller områden och hierarkins struktur. Medlemskapsändringar kan vanligtvis inträffa dagligen, även per timme. Strukturella förändringar i hierarki (omplaceringar) inträffar i allmänhet mer sällan (kvartalsvis, halvårsvis eller årligen) och kan vara resursdyra. Vad som måste beaktas är volymen av ändringar och antalet kaskadändringar som varje ändring kommer att orsaka. Som en tumregel, ha strukturella ändringar inträffar inte mer än kvartalsvis och alla ändringar med hög volym (mass- eller massändringar) vara väl planerade, testade och samordnade.

• Stora datavolymer

  • Oavsett om du modellerar för den inledande lanseringen eller planerar en ändring av anpassningen måste du allvarligt överväga mängden data. Det finns trösklar där prestanda kan bli en faktor, så att testa dina ändringar i en sandbox rekommenderas starkt innan produktion. Detta test ger dig även en baslinje för hur lång tid ändringen kommer att ta.

    Om du har fler än två miljoner konton och har implementerat team eller Enterprise-områdeshantering måste du särskilt uppmärksamma prestanda. Dessa är komplexa komponenter för delningsmodeller som kan skapa en stor mängd delningsposter och därmed långa transaktioner.

• Skjut upp delningsberäkningar

  • Om du har ett objekt som använder delning och har en stor mängd poster (till exempel mer än två miljoner konton) och du måste göra en massändring (till exempel en kvartalsvis omplacering som kräver en ändring av hierarkin), finns det en funktion som Salesforces kundsupport kan aktivera för att skjuta upp automatiska delningsberäkningar. Ursprungligen kan varje enskild ändring av rollhierarkin, områdeshierarkin, grupper, delningsregler, användarroller, teammedlemskap eller ägarskap för poster inleda automatiska delningsberäkningar. När en massändring görs börjar ett antal automatiska omräkningar av delning. Genom att tillfälligt avbryta dessa omräkningar kan du göra ändringen och sedan låta delningsberäkningar utföras samtidigt. Denna metod är vanligtvis mer effektiv och fungerar bättre för massändringar.

• Data- och ägarskapsskick

  • Dataförvrängningar definieras som några överordnade poster med många underordnade poster. Dessa skevheter kan verkligen skada dig när några konton har många kontakter, säljprojekt eller kundcase. Förhållandet där vi börjar se prestandaförsämring är 1:10 000. Vi rekommenderar att hålla förhållandet så nära som möjligt (lägre är att föredra).

    Ägarförvrängningar liknar dataförvrängningar, förutom att vi refererar till att en enskild användare, roll eller grupp äger många poster för ett objekt. Precis som med dataförvrängningar kan dessa även orsaka långa transaktioner, vilket kan orsaka en prestandaförsämring när en ändring sker. Det rekommenderade förhållandet mellan ägare och antal poster är också 1:10 000.

    Om en enskild användare äger fler än 10 000 poster rekommenderas följande:

    • Användarposten för ägaren ska inte ha en roll i rollhierarkin.

    • Om ägarens användarpost måste ha en roll, placera rollen högst upp i hierarkin i sin egen gren av rollhierarkin.

• Kontohierarkiers påverkan på dataåtkomst

  • Många människor gör ett dåligt antagande när de implementerar en kontohierarki. De antar att de användare som har åtkomst till ett överordnat konto också har åtkomst till de underordnade kontona. Det enkla faktum att endast ha en överordnad/underordnad relation mellan två poster driver inte åtkomst. Även om rollhierarkin och områdeshierarkin fungerar på detta sätt gör inte kontohierarkin det.

När du har slutfört din delningsmodellarkitektur kommer du troligen att få frågan varför en användare kan eller inte kan se en post. Vanligtvis hör du inte när användare kan se något de inte borde, men om det behövs finns det ett sätt att se alla användare som har åtkomst till en post och varför.

Den svårare utmaningen, och antagligen vanligare, är varför en användare inte kan se en post. De säkerhetslager du har konstruerat avgör var du börjar. Om du känner till delningsmodellen väl vet du antagligen vilken komponent som borde ha tillhandahållit åtkomsten och kan börja där. Men om du är mindre bekant med delningsmodellen, börja med rollhierarkin och skala av varje lager för att avgöra vilket som ska ge åtkomsten. Här är ett felsökningsflöde.

1. Kontrollera att användaren har behörighet att komma åt objektet.
2. Identifiera användarens roll som inte kan se posten och notera den.
3. Identifiera ägaren av postens roll och notera den.
4. Granska rollhierarkin och kontrollera att dessa två roller är i två olika grenar (det borde de vara).
5. Nu måste du granska delningsreglerna för objektet och se till att det inte finns någon regel som beviljar användaren åtkomst. Om det behövs, titta även i offentliga grupper. Kanske har användaren utelämnats från en grupp där det finns en delningsregel, eller är det vettigt att skapa en ny delningsregel för att bevilja användaren åtkomst? Detta val beror på vilken arkitektur du försöker upprätthålla och gäller för både ägarbaserade delningsregler och kriteriebaserade delningsregler.
6. Om du använder team, ska denna användare vara med i teamet för den posten? Hur underhålls team och hur inträffade missen?
7. Om manuell delning används kan användaren ha förlorat åtkomst på grund av att postägaren ändrades. Manuella delningar släpps när ägarskapet ändras. Den manuella delningen kunde även ha tagits bort med knappen Dela.
8. Om du använder Enterprise-områdeshantering, saknas användaren i ett av områdena? Var upprätthålls medlemskapet i områden och hur inträffade missen? Eller så kanske posten inte tilldelades till området där användaren är medlem.
9. Om du skapar programmatiska delningar och det finns kriterier för att skapa delningen i kod, gå igenom koden för att förstå varför denna användare har utelämnats.