Använd inkapsling i Salesforce Spiffberäkningar

Vad är inkapsling?

När du skriver en provisionsberäkning är det frestande att bygga ett stort uttryck som kombinerar varje villkor, relation och aritmetisk operation. Inkapsling använder motsatt metod: dela upp logiken i de minsta meningsfulla enheterna, namnge varje enhet och skapa den slutgiltiga beräkningen från dessa namngivna bitar.

Inkapsling sker på den beräknade fältnivån. I en välstrukturerad plan utför varje beräknat fält en enskild operation. Beräkningar på lägre nivå används i beräkningar på högre nivå, som används i det slutgiltiga utbetalningsvärdet.

Överväg en plan som betalar en säljare en provision på delade affärer som avslutats under den aktuella perioden, där säljarens andel av de årliga återkommande intäkterna (ARR) överskrider en tröskel. Utan inkapsling kombinerar ett uttryck varje villkor och varje aritmetiskt steg.

Calculated field, without encapsulation:

=if(CloseDate >= BeginningOfPeriod
    AND CloseDate <= EndOfPeriod
    AND OwnerId == UserId
    AND ContractLength_Months__c > 12
    AND Split_Percent__c != null
    AND (Split_Percent__c * ARR) >= 20000,
    Split_Percent__c * ARR * CommissionRate,
    0)

Detta uttryck är svårt att läsa, svårt att felsöka i spårning och ömtåligt — ett fältnamn kräver att hitta och redigera varje beräkning som refererar det.

Med inkapsling blir varje villkor och varje beräknat värde sitt eget namngivna fält. Det slutgiltiga utbetalningsuttrycket läses direkt från dessa namngivna fält.

Följande exempel använder både filteruttryck och beräknade fält. Filteruttryck returnerar sant eller falskt och använder endast boolesk logik — de har inte stöd för if(). Beräknade fält returnerar värden och har stöd för den fullständiga uttryckssyntaxen. Båda gynnas av inkapsling, men av olika anledningar: beräknade fält får en prestandafördel (motorn utvärderar varje fält när och lagrar resultatet), medan filteruttryck får en strukturell fördel (lättare att läsa, underhålla och uppdatera).

With encapsulation:

// Step 1 — Qualify the period (filter expression)
ClosedInPeriod = CloseDate >= BeginningOfPeriod
                 AND CloseDate <= EndOfPeriod

// Step 2 — Qualify the rep and deal type (filter expression)
ByRepMultiYear  = OwnerId == UserId
                  AND ContractLength_Months__c > 12

// Step 3 — Compute the split amount (calculated field)
SplitARR        = Split_Percent__c * ARR

// Step 4 — Qualify the threshold (filter expression)
SplitARREligible = Split_Percent__c != null
                   AND SplitARR >= 20000

// Step 5 — Final payout (calculated field)
Payout = if(ClosedInPeriod AND ByRepMultiYear AND SplitARREligible,
            SplitARR * CommissionRate,
            0)

För beräknade fält utvärderar kommissionsmotorn varje fält en gång och lagrar resultatet — efterföljande referenser läser det lagrade värdet istället för att räkna om logiken. Filteruttryck delar inte detta beteende, eftersom filter alltid körs som en helhet oavsett hur de är strukturerade.

Fältet Payout läser fyra namngivna värden istället för att omberäkna samma aritmetik- och datumjämförelser direkt. Om du byter namn på Split_Percent__c, uppdatera endast SplitARR och SplitARREligible — utbetalningsuttrycket påverkas inte.

Fördelar med inkapsling

Inkapsling erbjuder dessa fördelar jämfört med monolitiska uttryck.

• Minneseffektivitet. Provisionsmotorn kör en inkapslad beräkning en gång per uttryck och lagrar resultatet. Efterföljande beräkningsreferenser läser det lagrade resultatet istället för att räkna om logiken. Detta tillvägagångssätt är särskilt värdefullt för beräkningar som refererar till stora datauppsättningar eller traversrelationer.
• Enklare felsökning. Om en utbetalning är felaktig, spåra varje namngiven beräkning individuellt för att hitta var logiken avviker från förväntningarna. I föregående exempel, spåra ClosedInPeriod, SplitARR och SplitARREligible separat för att hitta vilket villkor som utesluter eller inkluderar poster felaktigt. Ett monolitiskt uttryck är svårt att inspektera eftersom kommissionsmotorn utvärderar det som en enskild enhet.
• Rationaliserad rapportering. Namngivna beräknade fält är tillgängliga som diskreta datapunkter för Spiff-rapporter. Ett monolitiskt uttryck producerar endast sin slutgiltiga utdata. Inkapslade fält ger dig insyn i mellanvärden—till exempel rapportering om SplitARR oberoende av rätt till utbetalning.
• Förbättrad läsbarhet. En slutgiltig utbetalningsberäkning som läser SplitARR * CommissionRate är mycket enklare att förstå än ett motsvarande kapslat uttryck. Namngivna fält kommunicerar syfte till alla som granskar planen i framtiden.
• Utökning. När ett anslutarfält ändras eller när du uppdaterar en verksamhetsregel kräver en väl inkapslad konfiguration en ändring på ett och samma ställe. I det föregående exemplet innebär att ändra tröskeln för rätt från 20 000 till 25 000 att endast uppdatera SplitARREligible. Ett monolitiskt uttryck som bäddar in direkttröskeln kräver att hitta och redigera varje filter och beräkning som innehåller det.

Tillämpa inkapsling för relationer

Relationer mellan objekt är en av de platser med högst värde för att tillämpa inkapsling. Varje gång en beräkning går igenom en relation för att hämta ett fält tar det upp minne och bearbetningstid. Att kapsla in relationsanropet innebär att arbete sker en gång.

Tänk på dessa metoder när du arbetar med relaterade objekt.

• Använd direkta vägar när de är tillgängliga. Om du behöver data från Säljprojektprodukt och Säljprojektdelning, använd en direkt OppProduct-to-OppSplit-relation istället för att dirigera genom objektet Säljprojekt. Kortare vägar innebär färre genomgångar.
• Använd självrefererande relationer. Istället för att skapa OppToAccount och AccountToOpps som två separata relationer, skapa en OppToOpp-relation där den unika nyckeln är AccountId. Detta tillvägagångssätt uppnår samma resultat med en enskild relationsdefinition.
• Utför beräkningar på det relaterade objektet. Istället för att hämta tre fält från ett relaterat objekt och kombinera dem i det aktuella objektets beräkning, skapa ett beräknat fält på det relaterade objektet som producerar det värde du behöver. Referera sedan det enskilda fältet via relationen. Ett relationsanrop för att hämta ett fält är billigare än ett relationsanrop för att hämta flera fält.

Till exempel, istället för att referera OppSplit.SplitPercent och OppSplit.ARR separat via en relation och multiplicera dem i säljprojektberäkningen, skapa ett SplitARR fält i objektet OppSplit. Säljprojektberäkningen gör sedan ett enskilt relationsanrop för att läsa ett förberäknat värde.

Less efficient — two relationship traversals per record:
Payout = OppSplit.SplitPercent * OppSplit.ARR * Rate

More efficient — one relationship traversal per record:
// On OppSplit object:
SplitARR = SplitPercent * ARR

// On Opportunity object:
Payout = OppSplit.SplitARR * Rate

Tillämpa inkapsling med insamlingsspårning

Inkapsling och spårning fungerar tillsammans. Eftersom inkapslade beräkningar är separata namngivna fält — fälten är diskreta och uttryckligen identifierade — kan du selektivt slå på spårning på fältnivå. Du kan stänga av spårning för mellanliggande beräkningar som representanter inte behöver se och som involverar stora datauppsättningar. Slå på spårning för de slutgiltiga utbetalningsvärdena och de nyckelmått som säljare granskar för sina kontoutdrag.

Till exempel, om din utbetalningslogik inkluderar en löpande totalsumma för varje år som ett mellansteg, sammanfatta den löpande totalsumman som ett eget fält med spårning avstängt. Payout som refererar till det kan fortfarande ha spårning påslaget, vilket ger representanten ett slutgiltigt nummer utan att exponera den interna ackumuleringslogiken.

// YTDCommissions — turn off trace (large dataset, internal only)
YTDCommissions = amounts_from(beginning_of_year(BeginningOfPeriod),
                               days_ago(BeginningOfPeriod, 1),
                               plan_name)

// CurrentPeriodPayout — turn on trace (rep-facing)
CurrentPeriodPayout = SplitARR * CommissionRate

// YTDTotal — turn on trace (rep-facing summary metric)
YTDTotal = YTDCommissions + CurrentPeriodPayout