Relationer får konsekvenser

🌐 Finns även på 28 språk

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 7 av 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kursen Data Architect. Varje modul står på egna ben. Föregående: Fält är också arkitektur · Nästa: Ägarskap och livscykel

Frågan den här modulen besvarar: Vad väljer jag egentligen när jag kopplar ihop två objekt i Salesforce?

Att rita en relation är enkelt. I kapitel 2 ritade vi linjer och namngav dem: en detaljhandelspartner skickar många manifest, en leverans bär många rader, team och lastbilar möts i en teamtilldelning (Crew Assignment). Vi pratade om kardinalitet, valfrihet och historik. Nu implementerar vi de linjerna i Salesforce, och en linje i ett diagram börjar bära mycket mer vikt.

När jag väljer en relationstyp i Salesforce säger jag inte bara att de här två posterna hänger ihop. Jag kanske också bestämmer vem som äger barnet, om det kan finnas utan föräldern, vem som kan se det, vad som händer när föräldern raderas, om det kan flyttas till en annan förälder, om jag kan summera det upp till föräldern och vad som händer när det finns hundratusentals barn. En relation är inte bara en linje. Den bär beteende.

Börja med affärsrelationen

Före lookup eller master-detail, gå tillbaka till verksamheten. Ta en leverans (Delivery) och dess leveransrader (Delivery Items): kylskåpet, installationen, bortforslingen. Kan en rad finnas utan sin leverans? Nej. Om leveransen raderas, ska dess rader också försvinna? Ja. Behöver raderna en egen ägare eller egen säkerhet? Egentligen inte. Ska någon flytta en rad från en leverans till en annan? Förhoppningsvis inte av misstag.

Ta nu en leverans och rutten (Route) den ligger på. Leveransen finns innan den läggs på en rutt, den kan flyttas till en annan rutt när planen ändras, och att radera en rutt ska aldrig radera leveranserna på den. Två en-till-många-linjer som ser likadana ut i ett diagram, med helt olika beteende. Lägg märke till att vi fortfarande inte har sagt ”lookup” eller ”master-detail”. Beskriv beteendet först. Konfigurationen implementerar det.

Relationstyperna

Öppna skärmen New Field så erbjuder Salesforce en handfull relationstyper (Object Relationships Overview (opens in a new tab)):

• Lookup: länkar två objekt. Själva basfödan bland relationerna i Salesforce.
• Master-detail: en förälder-barn-bindning där föräldern styr barnet.
• Många-till-många: ingen egen fälttyp, utan ett mönster: ett kopplingsobjekt i Salesforce (Salesforce Junction Object), ett anpassat objekt med två master-detail-relationer.
• Självrelation (self-relationship): en lookup från ett objekt till sig självt.
• Hierarkisk (hierarchical): en särskild lookup som bara finns på objektet User, till exempel en användares chef.
• Extern lookup (external lookup) och indirekt lookup (indirect lookup): relationerna till och från externa objekt, __x-objekten från modul 4. En extern lookup pekar på ett externt föräldraobjekt; en indirekt lookup pekar från ett externt objekt till ett standardobjekt eller anpassat objekt, matchat på ett unikt External ID.

Det mesta av din designtid går till de tre första. Låt oss ta dem en i taget.

Lookup: de här posterna hänger ihop

En lookup säger: den här posten är kopplad till den där posten. Barnet behåller sin egen självständighet, sin egen ägare och sitt eget liv. En leverans pekar på sin rutt. Om rutten ställs in försvinner inte leveranserna; de går tillbaka för att läggas på en rutt igen.

Det är lite roligt: lookup-fältet hamnar på barnet, men föräldern får också något, en relaterad lista med sina barn. Så när du skapar en, namnge båda ändarna. Related List Label är vad folk ser på föräldern, och Child Relationship Name är vad utvecklare och integrationer använder för att gå från förälder till barn. Acceptera inte standardvärdena.

En lookup kan vara obligatorisk eller valfri. När den är valfri bestämmer du vad som händer om posten den pekar på raderas, och det finns tre val (Considerations for Object Relationships (opens in a new tab)):

• Clear the value of this field (töm värdet i fältet), standardvalet. Barnet blir kvar, med en tom lookup.
• Don’t allow deletion (tillåt inte radering) av lookup-posten. Försök radera rutten, så säger Salesforce nej: den ingår i en relation.
• Delete this record also (radera även den här posten), en kaskadradering, som vid master-detail. Den erbjuds bara för en anpassad lookup på ett anpassat objekt, den är avstängd som standard, och Salesforce måste slå på den för din org, eftersom en kaskadradering kringgår säkerhet och delning: användare kan radera poster som de inte ens kunde se.

Det är ett livscykelbeslut som gömmer sig på en inställningsskärm.

Lookup-filter begränsar vad en användare kan välja. Säg att leverans har en lookup Installer till kontakt, och att installatörer är en posttyp av kontakt bland många. Ett lookup-filter visar bara installatörer, och det kan filtrera på den aktuella posten, på posten som slås upp och på användaren: deras profil, roll eller behörigheter (Lookup Filters (opens in a new tab)). Det är ett billigt sätt att hålla en lookup ärlig.

Master-detail: det här barnet tillhör den där föräldern

Master-detail gör ett mycket starkare påstående. I klassrummet kallar jag det en väldigt tät bindning. Du kan inte ha en detaljpost utan dess master; masterfältet är obligatoriskt. Detaljposten förlorar sitt eget Owner-fält och ärver förälderns ägare. Det finns ingen separat delningstabell för detaljobjektet, så du kan inte dela ett barn för sig; det ärver förälderns delning. Därför kan ett detaljobjekt inte ha delningsregler, manuell delning eller köer: alla kräver ett Owner-fält (Object Relationships Overview (opens in a new tab)). I Setup står det Controlled by Parent (styrs av föräldern) i dess delningsinställning. Och på själva master-detail-fältet väljer du en Sharing Setting: om en användare behöver Read Only- eller Read/Write-åtkomst till mastern för att skapa, redigera eller radera dess detaljposter. Att radera mastern raderar dess detaljposter. Och mastern får sammanställningsfält (roll-up summary).

Så om leveransrad är en detalj till leverans säger jag: den här raden tillhör den här leveransen hela sitt liv. Det är frågan jag vill ha besvarad innan någon väljer Master-Detail Relationship i Setup.

Raderingsfrågan

Här är mitt favoritsätt att ta reda på om vi har tänkt igenom saken: vad ska hända med barnen om någon raderar föräldern? Alla blir obekväma. Bra. Nu håller vi på med arkitektur.

En detaljhandelspartner har hundratusentals historiska leveranser. Någon raderar partnern. Ska leveranserna försvinna? Nästan säkert inte: reklamationerna, faktureringen och historiken är alla beroende av dem. Kanske ska det inte alls gå att radera en partner, utan partnern ska inaktiveras i stället. Med master-detail kaskaderar raderingen av mastern till detaljposterna och deras detaljposter; att återställa mastern tar tillbaka dem (Considerations for Object Relationships (opens in a new tab)). Så när någon säger ”master-detail ger oss roll-ups” är mitt svar: toppen. Vad mer gick du just med på?

Ägarskapet följer med på köpet

Med en lookup kan barnet ha en egen ägare. Med master-detail kan det inte det; åtkomsten följer mastern. Det är helt rätt om detaljposten verkligen är en del av föräldern. Men om barnet behöver en egen ägare, egen delning eller en egen livscykel säger modellen dig att master-detail är fel val. Nästa modul går djupare in på ägarskap, och kursen om delning och synlighet (Sharing & Visibility) går ännu längre. För tillfället: relationsdesign och säkerhetsdesign är inte separata samtal. Datamodellen formar säkerhetsmodellen innan någon skriver en delningsregel.

Obligatorisk förälder eller valfri?

Kan barnet finnas innan vi vet vem dess förälder är? Det spelar större roll än det låter. Om leveranserna kommer på manifestet kvällen innan och rutterna byggs efteråt skulle en obligatorisk rutt på leveransen innebära att ruttplaneringen måste ske innan posten ens kan skapas. Den fysiska relationen måste stödja den verkliga livscykeln. Så jag designar inte relationer utifrån bara ett statiskt diagram. Jag vill veta: hur föds de, kan de finnas ensamma, kan de flytta, och hur dör de?

Kan barnet byta förälder?

Som standard kan ett master-detail-barn inte flyttas till en annan förälder. Du kan tillåta det genom att välja Allow reparenting på relationen (Considerations for Object Relationships (opens in a new tab)). Min instinkt är konservativ: om verksamheten säger att barnet tillhör en förälder hela livet gör jag det inte lätt att flytta det. En rad som flyttas från en leverans till en annan ska vara en medveten affärshändelse, inte en fältredigering. Återigen: inställningen är inte arkitekturen. Livscykelregeln är det, och inställningen implementerar den.

Två saker till som fångar team senare. Du kan inte skapa en master-detail-relation på ett objekt som redan har data; du skapar en lookup, fyller i den på varje post och konverterar den sedan. Och du kan bara konvertera tillbaka till en lookup om det inte finns några sammanställningsfält på mastern. Se också vad konverteringen gör med säkerheten: att göra om en lookup till master-detail sätter barnets delning till Controlled by Parent, och att göra om en master-detail till lookup igen sätter barnets organisationsövergripande standard (organization-wide default) till Public Read/Write (Considerations for Object Relationships (opens in a new tab)). Poster som var privata i går är öppna i dag, tills någon märker det. Välj tidigt.

Roll-ups är användbara, men de är inte gratis

Jag gillar roll-ups. Räkna raderna på en leverans, summera radbeloppen på en faktura, hitta det senaste datumet: inbyggt, ingen kod. Master-detail-fältet hamnar på barnet, men roll-upen hamnar på föräldern. De kommer dock med finstilt (Roll-Up Summary Field (opens in a new tab)):

• Att beräkna roll-up-värden efter vissa ändringar (ett nytt roll-up-fält, en ändrad formel som det är beroende av, en tvingad omräkning) kan ta upp till 30 minuter, beroende på hur många poster som påverkas. Jag har sett folk undra varför siffran på föräldern inte har ändrats än.
• De kan inte summera allt. Ett Auto Number kan inte vara fältet du aggregerar. Och en roll-up kan summera ett formelfält bara om formeln inte sträcker sig över till ett annat objekt och inte använder en funktion som ändras av sig själv, som NOW() eller TODAY(). En formel för ”dagar försenad” byggd på TODAY() ändras varje natt utan att någon sparar en post, så det finns inget för roll-upen att räkna om utifrån. Den sortens siffra kräver ett schemalagt flöde, eller en rapport.
• Filtret har också begränsningar: inga långa textområden, flervalsplocklistor, Description, systemfält som Last Activity, formler över flera objekt eller lookup-fält.
• Roll-ups finns inte på redigeringssidor, så en valideringsregel kan använda en men kan inte visa sitt fel där.

Och vänd inte på beslutet. Säg inte: ”Vi behöver en roll-up, alltså måste det här vara master-detail.” Säg: ”Det här barnet tillhör verkligen den här föräldern, ägarskapet och livscykeln passar, och en av fördelarna är inbyggda roll-ups.” Om semantiken inte passar, lös beräkningen på något annat sätt. Förvräng inte datamodellen för att få en funktion.

Så vilket är det andra sättet? Du bygger roll-upen själv: ett fält på föräldern som håller det beräknade värdet, och automatisering som håller det aktuellt. Säg att detaljhandelspartner är en lookup från leverans, som den ska vara, och att verksamheten vill se Open Deliveries (öppna leveranser) på partnern. Lägg till ett talfält, Open Deliveries, på partnern. Sedan räknar ett postutlöst flöde (record-triggered flow), eller en Apex-trigger när volymen eller logiken kräver kod, om det varje gång en leverans ändras. Det fungerar över en lookup, det kan filtrera på vad som helst, och det kan använda datum och formler som en inbyggd roll-up inte kan.

Men nu är det ditt ansvar att få det rätt, och det är där sådana här går snett. Automatiseringen måste köras vid varje ändring som spelar roll: ett nytt barn, ett redigerat barn, ett raderat barn, ett återställt barn och ett barn som flyttas till en annan förälder, vilket innebär att både den gamla och den nya föräldern måste räknas om. Den måste klara en dataladdning med 200 poster åt gången utan att slå i gränserna. Räkna om från början i stället för att addera och subtrahera, så att en missad händelse inte lämnar siffran fel för alltid. Planera ett sätt att räkna om allt, för den första laddningen och den dag det glider. Och kom ihåg att varje gång ett barn sparas uppdateras nu föräldern, så en förälder med tusentals barn tar tillbaka den låsning vi snart ska se. En inbyggd roll-up gör allt det åt dig; en anpassad är en liten bit mjukvara som du äger.

Tre nivåer djupt: stapla master-detail

Plattformen har en form, och master-detail har två dimensioner av den. Den första är djup.

Du kan stapla master-detail tre anpassade detaljnivåer djupt, och där är botten (Considerations for Object Relationships (opens in a new tab)). I klassrummet ritar jag det som ett konto med en order (ett), ordern med sina rader (två) och raderna med sina detaljer (tre), och sedan försöker jag lägga till en fjärde och Salesforce låter mig inte. Hos Steve Trucking kan det se ut så här: en leverans (Delivery) är mastern; dess leveransrader (Delivery Items) är första nivån; en rads installationsuppgifter (Install Tasks) är den andra; och varje uppgifts uppgiftssteg (Task Steps) är den tredje. En fjärde nivå, säg en stegnotering (Step Note), måste vara en lookup.

Click to enlarge

Några regler följer med stapeln:

• Standardobjekt kan inte stå på detaljsidan till ett anpassat objekt. Ett anpassat objekt kan vara en detalj till konto; konto kan inte vara en detalj till ditt objekt.
• Ett objekt kan bara förekomma en gång i en stapel med flera nivåer. Salesforce vill inte att du loopar tillbaka på dig själv: en underdetalj kan inte samtidigt vara master till sin egen master.
• Mastern kan inte summera den nedersta nivån direkt. Om leverans vill ha antalet uppgiftssteg summerar installationsuppgift sina steg, leveransrad summerar de sammanställningarna och leverans summerar raderna: en nivå i taget.
• Ägarskap och delning kommer uppifrån. Varje nivå ärver masterns ägare och åtkomst.
• Att radera mastern raderar allt under den, och att återställa den tar tillbaka allt.

Tre nivåer räcker oftast gott. Om din design hela tiden vill ha en fjärde, fråga om varje nivå verkligen tillhör nivån ovanför hela livet. Och kom ihåg att du får välja vilken länk som bryter kedjan. Den fjärde nivån behöver inte vara lookupen: kanske tillhör en installationsuppgift egentligen inte sin leveransrad, den schemaläggs och tilldelas för sig, så den länken blir en lookup, och nu startar installationsuppgift en ny kedja med uppgiftssteg och stegnotering under sig. Välj länken där barnet verkligen har ett eget liv, och gör den till lookupen.

Click to enlarge

Nu har installationsuppgift en egen ägare och egen delning, en leverans kan raderas utan att dra med sig sina installationsuppgifter, och installationsuppgift kan ha två nivåer till under sig. Det är bytet: kedjan blir kortare, och installationsuppgiftens liv blir dess eget.

Två föräldrar brett: kopplingsobjektet i Salesforce

Först ett ord om ord, eftersom ”kopplingsobjekt” (junction object) betyder två saker, och jag undervisar om båda.

I kapitel 2 hittade vi det logiska kopplingsobjektet: kopplingen mellan två nyckelidéer som blir en egen sak, med egna attribut. En hund kan många trick, ett trick kan många hundar, och Hundtrick sitter mellan dem och håller färdighetsnivån och datumet. Det är ett logiskt kopplingsobjekt, i den logiska modellen, långt innan någon bestämmer lookup eller master-detail.

Salesforce använder termen snävare. När Salesforce säger junction object menar det ett anpassat objekt med två master-detail-relationer (Create a Many-to-Many Object Relationship (opens in a new tab)). Jag kallar det ett kopplingsobjekt i Salesforce (Salesforce Junction Object). Varje kopplingsobjekt i Salesforce är ett logiskt kopplingsobjekt, men inte varje logiskt kopplingsobjekt blir ett kopplingsobjekt i Salesforce: bygg ett med en master-detail och en lookup, eller två lookups, så är det fortfarande ett logiskt kopplingsobjekt, bara inte av Salesforce-sorten. (Salesforce är inte helt konsekvent själv: dess egen objektreferens kallar vissa standardobjekt som bygger på lookups för ”junction objects”. På provet, utgå från den snäva definitionen.)

Provkunskap. Ett kopplingsobjekt i Salesforce (Salesforce Junction Object) är ett anpassat objekt med två master-detail-relationer, och det är vad Salesforce menar när det säger ”junction object”. Det logiska kopplingsobjektet är den bredare modelleringsidén: vilket objekt som helst som kopplar ihop två andra i en många-till-många-relation och bär egna attribut, hur det än är byggt.

Den andra dimensionen är bredd. Kan ett barn ha två master-detail-föräldrar? Ja. Tre? Nej. Varje anpassat objekt kan ha upp till två master-detail-relationer (Considerations for Object Relationships (opens in a new tab)). Två master-detail-föräldrar är hur du bygger ett kopplingsobjekt i Salesforce för en många-till-många-relation. Team (Crew) och lastbil (Truck) möts i en teamtilldelning (Crew Assignment), och som vi kom fram till i kapitel 2 är den inte rördragning: den har ett datum, en rutt, kanske en status. Kopplingen är där relationen blir ett affärsbegrepp. Salesforces tips för att bygga ett: ge det ett namn som säger vad det är, gör postnamnet till ett Auto Number, och döp om varje masters relaterade lista efter den andra mastern, så att sidan för team visar ”Trucks” och sidan för lastbil visar ”Crews” (Create a Many-to-Many Object Relationship (opens in a new tab)).

Här är det kluriga. En av de två föräldrarna är den primära, och det är den vars master-detail-fält du skapade först. Det finns ingen visuell indikation på vilken det är, så det är en klassisk provfråga, och en klassisk överraskning.

Vad avgör den primära? Tre saker (Create a Many-to-Many Object Relationship (opens in a new tab)):

• Utseende och känsla. Kopplingsobjektets sidor använder den primära masterns färg och ikon.
• Ägare. Kopplingsposterna ärver ägaren av den primära masterposten. Du ser det aldrig, eftersom en detaljpost inte har något Owner-fält; det spelar bara roll om du senare tar bort båda master-detail-relationerna.
• Division, om din org använder divisioner, på samma sätt.

Och den andra är den sekundära. Vad innebär det?

• Den står på tur att bli primär. Radera det primära master-detail-fältet eller konvertera det till en lookup, så blir den sekundära den primära.
• Den sätter rapporternas omfång. Salesforce ger dig två rapporttyper: ”Primary master with junction object and secondary master” och ”Secondary master with junction object and primary master”. Mastern som står först avgör vilka poster rapporten kan visa.
• Den väger lika tungt för åtkomsten. Så här brukar jag säga det: ägarskap från den primära, åtkomst från båda, och det mest restriktiva vinner. Ett kopplingsobjekt har, som alla detaljobjekt, ingen egen delningstabell. Salesforce kontrollerar användarens åtkomst till båda masterposterna, via Sharing Setting på varje master-detail-fält. Om båda är satta till Read/Write behöver användaren Read/Write på teamet och på lastbilen för att redigera teamtilldelningen (Considerations for Object Relationships (opens in a new tab)).
• Den raderar lika mycket. Radera någon av mastrarna, teamet eller lastbilen, så hamnar dess kopplingsposter i papperskorgen (Recycle Bin). Radera båda så är de borta för gott.

Click to enlarge

Några regler till: båda mastrarna kan ha sammanställningsfält från kopplingsobjektet, och kopplingsobjektets formler och valideringsregler kan nå fält på båda. Men ett kopplingsobjekt kan inte vara master till något annat, så det kan inte sitta mitt i en stapel, och de två mastrarna kan inte vara samma objekt; en många-till-många-relation från ett objekt till sig självt kräver en annan design. Och om en förälder har fler än 200 kopplingsposter och kopplingsobjektet summeras upp till den andra föräldern låter Salesforce dig inte radera den föräldern förrän du har tagit bort tillräckligt många av dem.

Så: vilken förälder ska vara primär? Skapa den som äger betydelsen först. För en teamtilldelning är det teamet som gör jobbet, så jag skulle skapa team först. Och skriv sedan ned det, för ingenting på skärmen kommer att berätta det för nästa person.

Med allt det sagt slutar jag inte med särskilt många kopplingsobjekt i Salesforce. Normalt har ett objekt en master-detail-förälder, och det är samma sorts data: kunddata under kunddata, transaktionsdata under transaktionsdata (kom ihåg sorterna av data från kapitel 2: kunddata, transaktionsdata, referensdata). När den andra föräldern är av en annan sort, oftast ett referensobjekt, är den relationen en lookup. En leveransrad tillhör sin leverans: master-detail, båda transaktionsdata. Den pekar på produkten den bär med en lookup, eftersom en produkt är referensdata med ett eget liv, och ingen vill att radering av en produkt ska dra med sig flera års leveranshistorik. Leveransrad är fortfarande ett logiskt kopplingsobjekt mellan en leverans och produkterna på den; det är bara inte ett kopplingsobjekt i Salesforce.

Självrelationer: när linjen kommer tillbaka

Ett objekt kan relatera till sig självt: ett överordnat konto, en chef, en distributionscentral som rapporterar till ett regionalt nav. Salesforce bygger in två som du möter i nästan varje org: konto till konto, fältet Parent Account som bygger kontohierarkin, och ärende till ärende, Parent Case från modul 2 som grupperar relaterade ärenden. En självrelation måste vara en lookup, och en post kan inte peka på sig själv, även om två poster kan peka på varandra (Considerations for Object Relationships (opens in a new tab)). På objektet User är det en egen särskild typ, den hierarkiska relationen, som används för sådant som en användares chef. Mekaniken är enkel; namngivningen spelar roll. En lookup från distributionscentral till distributionscentral som heter Distribution_Center__c hjälper ingen. Överordnad? Reserv? Överflöde? Namnge relationen efter rollen, inte efter objektet den pekar på.

Click to enlarge

Hierarkisk: User-objektets egen relation

Den här är liten, och den är precis den sortens föga kända, unika faktum som jag skulle vänta mig att ett prov plockar upp. Hierarkisk (hierarchical) är en särskild lookup som bara finns på objektet User. Den kopplar en användare till en annan användare, och Salesforce låter inte kedjan loopa tillbaka: en användare kan inte peka på sig själv, direkt eller indirekt (Object Relationships Overview (opens in a new tab)). Om Marias chef är Dev kan Devs chef inte vara Maria, eller någon som rapporterar uppåt till Maria.

Det är skillnaden mot självrelationerna ovan. På konto eller ett anpassat objekt kan två poster peka på varandra. På User måste hierarkin förbli en hierarki. Och det är det enda sättet att relatera User till User: en vanlig lookup från User till sig självt erbjuds inte.

Du har redan en. Standardfältet Manager på User är en hierarkisk relation, och godkännanden kan använda den: skicka den här begäran till inskickarens chef. Du kan också skapa egna, säg en eskaleringskontakt (Escalation Contact) eller en reservgodkännare (Backup Approver), och ett godkännande kan gå längs den på samma sätt (ApprovalProcess, Metadata API (opens in a new tab)). Blanda inte ihop den med rollhierarkin, som styr åtkomsten till poster. Ett hierarkiskt fält är bara en relation mellan användare; det delar inte en enda post.

Provkunskap. Den hierarkiska relationen finns bara på objektet User, som standardfältet Manager, och en användare kan inte peka på sig själv, varken direkt eller indirekt. Det är inte rollhierarkin.

Relationer har också gränser

Varje objekt kan ha högst två master-detail-relationer. Lookup- och master-detail-fält räknas tillsammans som relationsfält: 40 per objekt som standard, högst 50 på begäran. Sammanställningsfält: 25 per objekt som standard, högst 40 (Increase the Maximum Relationships Allowed per Object (opens in a new tab); Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab)). Salesforce tillägger att det kan påverka prestandan att höja någon av gränserna.

Du behöver inte designa efter de siffrorna; du behöver märka när du närmar dig dem. Ett objekt med relation efter relation hängande på sig säger dig något. Kanske är det verkligen så centralt. Eller så är modellen fel. (Och marginalregeln från kapitel 18 gäller: håll dig gott och väl under en gräns, mätt mot år tre.)

Frågan om 10 000 barn

Sedan har vi föräldern med för många barn. Salesforces egen vägledning är att inte överstiga cirka 10 000 barnposter för en master-detail-förälder (Considerations for Object Relationships (opens in a new tab)), och dess guide till poståtkomst i stor skala säger detsamma om förälder-barn-relationer i allmänhet (Parent-Child Data Skew (opens in a new tab)). Post nummer 10 001 knäcker inte orgen. Men bortom den punkten kan det låsa föräldern att spara ett barn, och delningsändringar på föräldern sprider sig genom varje barn.

Så när jag ser en förälder med enorma mängder barn frågar jag: varför ligger de alla under samma förälder, vem äger dem, hur ställs frågor mot dem och vilken automatisering rör föräldern? Varje leverans under ett enda konto ”Steve Trucking” skulle passera 10 000 på några dagar. En oskyldig en-till-många blir ett skew-problem. Nästa modul ger en försmak av data skew, och del 2 går på djupet.

Designa inte linjen efter funktionen

Det här är vanan jag vill att du tar med dig från modulen. Börja inte från ”jag behöver en roll-up”, ”jag behöver den obligatorisk”, ”jag vill ha ärvd delning”. Det är implementeringsledtrådar. Börja från verksamheten: har barnet ett eget liv, vem äger det, kan det finnas ensamt, kan det flytta, vad händer när föräldern försvinner, bär relationen data, och hur stor kan varje sida bli? Välj sedan den relation som implementerar svaren.

Click to enlarge

Bortom provet: vad AI förändrar. AI kan föreslå relationer på några sekunder. Den kan inte säga om verksamheten någonsin kommer att radera föräldern. Snabbare diagramritande gör inte en felaktig relation billigare att backa när miljontals poster och dussintals automatiseringar är beroende av den.

Vad en arkitekt bestämmer här

• Om barnet har en egen livscykel eller verkligen tillhör föräldern, och om ägarskap och åtkomst ska vara dess egna eller ärvas.
• Om barnet kan finnas utan förälder, flytta mellan föräldrar eller överleva att föräldern raderas.
• Vad varje lookup gör när dess förälder raderas: tömmer, blockerar eller kaskaderar.
• Om en många-till-många-relation är rördragning eller ett affärsbegrepp, om det logiska kopplingsobjektet blir ett kopplingsobjekt i Salesforce, vilken förälder som är primär och vad båda föräldrarna innebär för åtkomsten.
• Om modellen passar plattformens form: tre anpassade detaljnivåer djupt, två master-detail-föräldrar brett, gränserna för relationer och sammanställningsfält.
• Om det förväntade antalet barn och deras fördelning skapar en skew-risk som borde ändra designen.

En relation är en uppsättning löften om hur två bitar data beter sig tillsammans. Ge dem med avsikt.

Utforska vidare

• Salesforce Help, Considerations for Object Relationships (opens in a new tab) (på engelska, kontrollerad 2026-10-13).
• Salesforce Help, Object Relationships Overview (opens in a new tab) och Create a Many-to-Many Object Relationship (opens in a new tab) (på engelska, kontrollerad 2026-10-13).
• Salesforce Help, Roll-Up Summary Field (opens in a new tab) (på engelska, kontrollerad 2026-10-13).
• Salesforce Developers, Metadata API, ApprovalProcess (opens in a new tab) (på engelska, kontrollerad 2026-10-13).
• Salesforce Help, Lookup Filters (opens in a new tab) (på engelska, kontrollerad 2026-10-13).
• Salesforce Help, Increase the Maximum Relationships Allowed per Object (opens in a new tab) och Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab) (på engelska, kontrollerad 2026-10-02).
• Salesforce Developers, Designing Record Access for Enterprise Scale, Parent-Child Data Skew (opens in a new tab) (på engelska, kontrollerad 2026-10-02).