Du är här:
Om dataoptimering och prestanda i Salesforce Spiff
Designer och kommissionsmotorn delar samma underliggande logik, vilket innebär att de beslut du fattar under konfigurationen direkt påverkar uttrycksprestanda i stor skala.
Designer och kommissionsmotorn
Designer och kommissionsmotorn är i grunden lika men har olika syften. Designer använder kommissionsmotorn för att visa beräkningsresultat i realtid, ungefär som ett kalkylblad. Provisionsmotorn beräknar uttryck isolerat, med en fast mängd minne och tid allokerat till varje uttryck.
Denna tabell visar nyckelegenskaperna för båda.
| Designer | Provisionsmotor |
|---|---|
| Visar beräkningsresultat i realtid medan du bygger, liknande ett kalkylblad. | Genererar slutförda kommissionsuttryck, var och en beräknad separat från de andra. |
| Använder kommissionsmotorn bakom huven, så att dess beteende återspeglar vad motorn gör i produktion. | Bearbetar uttalanden i ingen garanterad ordning — en säljares uttalande blockerar eller påverkar inte en annans. |
| Timeoutfel i Designer signalerar att samma logik skapar prestandatryck i produktion. | Varje uttalande får en fast allokering av minne och bearbetningstid. |
| Timeout eller minnesfel i Designer är en signal att optimera, men de indikerar inte alltid ett problem med beräkning av uttryck. Eftersom Designer-gränserna är lägre kan du se fel i Designer som inte visas när samma logik körs som ett uttalande. | Om ett uttalande överskrider sin allokering, kontakta Salesforces support för att be om en ökning av minnet eller tidsgränserna. |
| En bra proxy i ett tidigt skede för produktionsprestanda — om den löper ut i Designer kämpar den i motorn. För större, mer komplexa planer kan Designer-fel vara oundvikliga. I dessa fall är framgångsrik beräkning av uttryck det lämpliga målet, eftersom Designer-framgång inte alltid kan uppnås eller krävs. | Endast de data som lagras i Insamlingsspårning är tillgängliga för rapportering. Att stänga av spårning för ett fält tar bort det från rapporter och exporter. |
Eftersom Designer arbetar under lägre minnes- och bearbetningsgränser än kommissionsmotorn är en timeout i Designer en användbar signal för att undersöka och optimera — men det betyder inte alltid att beräkning av uttryck misslyckas. För mindre konfigurationer indikerar en timeout i Designer ofta att samma logik kommer att kämpa i uttrycksskala. För större eller mer komplexa planer kan timeouter för Designer inträffa även om motsvarande uttryck beräknas framgångsrikt.
Om ett uttryck överskrider sitt minne eller sin tidstilldelning är två vägar tillgängliga: kontakta Salesforces support för att begära en resursökning eller optimera planlogiken och datafiltren. I praktiken är en resursökning ofta den snabbaste lösningen när problemet upptäcks nära en lönekörning. Optimering åtgärdar den underliggande orsaken och är den rekommenderade uppföljningen om en resursökning inte ensam löser problemet, eller som en mer långsiktig strategi för att minska resursanvändningen för uttryck.
Tänk dig till exempel att du bygger ett beräknat fält på objektet Säljprojekt som använder en sum() för att aggregera årliga återkommande intäkter (ARR) för alla avslutade säljprojekt för en säljare. När du förhandsgranskar ett uttalande i Designer för en enskild representant med två års historik löper beräkningen ut. Om en timeout inträffar i Designer har provisionen samma problem — och troligen i större skala — när den bearbetar uttalanden för hela din representantpopulation i en enda körning. Fixen är att optimera beräkningen innan du går till produktion: stäng av spårning för fältet sum(), kapsla in det som en separat beräkning av kalkylbladet eller ersätt den fullständiga historikskanningen med ett filtrerat dataintervall.
Var optimeringsinsatser ska fokuseras
Prestandaförbättringar i Spiff kommer från tre områden: hur data kommer in i systemet, hur planlogik bearbetar dessa data och vilka fält som är konfigurerade att visas på kontoutdragssidan. Att hantera alla tre tillsammans ger de bästa resultaten.
Fokusera dina optimeringsinsatser på dessa tre lager.
- Datalager. Optimera datafilter, minska postvolymer genom filtrering uppströms (i källsystem) och förstå schemat och relationerna mellan dina objekt. Se Optimera datafilterprestanda i Salesforce Spiff och Minska provisionsmotorbelastning med dataändringar uppströms.
- Planlogiklager. Kapsla in beräkningar, inaktivera spårning där det inte behövs och använd söktabeller och dynamisk logik istället för hårdkodade värden eller komplexa kapslade formler. Se Använd inkapsling i Salesforce Spiffberäkningar och Använd söktabeller och dynamisk logik i Salesforce Spiff.
- Konfiguration av kontoutdragssida. Begränsa fälten på kontoutdragssidan till vad representanterna aktivt behöver se och ta bort mellanliggande beräkningar och diagnostiska fält från den vy som representanterna har framför sig. Provisionsmotorn kör varje synligt fält för varje uttalande — även fält som motorn annars inte skulle stöta på i beräkningsvägen.
Prestandaprinciper
Tänk på dessa vägledande principer genom hela din implementering.
- Starta optimeringen på dag ett och besök den regelbundet igen. Att eftermontera prestandaförbättringar i en befintlig konfiguration är svårare än att bygga in dem från början. Planlogik och datavolymer ändras över tid, så bygg in prestandagranskning i din regelbundna underhållscykel för planen — inte bara din inledande implementering.
- Slå samman och aggregera data innan de når motorn. Strukturera dina data så att representanter arbetar med en meningsfull, hanterbar uppsättning skyldigheter – inte hundratals eller tusentals individuella poster. Att aggregera och slå samman data uppströms, innan de synkroniseras till Spiff, minskar komplexiteten för både säljare och kommissionsmotorn. För specifika tekniker för att styra vilka data som synkroniseras till Spiff, se Optimera datafilterprestanda i Salesforce Spiff.
- Förstå dina datavolymer över tid. En konfiguration som fungerar bra vid lansering kan försämras i takt med att antalet poster ökar. Planera för arkivering och granska beräknade volymer med ditt datateam.
- Begränsa fält på uttryckssidor till vad användare behöver. Varje fält som väljs på kontoutdragssidan körs av motorn för varje kontoutdrag, oavsett om beräkningsvägen annars skulle nå det. Ta bort mellanliggande beräkningar och interna spårningsfält från den representativa vyn.
- Slå endast på spårning där det har ett syfte. Spårning lagrar data och konsumerar minne och beräkningstid. Slå på den för fält som representanter behöver se i sina kontoutdrag eller som Comp Admins behöver för rapportering. Stäng av den för mellanliggande beräkningar, relationsgenomgångar och fält som inte behöver visas i representanternas vyer eller exporter.
- Undvik hårdkodade värden. Lagra variabelbelopp i kalkylbladsfält och använd söktabeller så att logiken förblir underhållsbar när verksamhetsregler ändras.
