Salesforce Platform har løbende forbedret sin automatiseringsarkitektur for at opfylde kravene i komplekse forretningsprocesser. Tidligere generationer – Arbejdsflowregler og Proceskonstruktør – leverede de indledende trin i begivenhedsstyret logik, udvidede automatiseringsfunktioner for begivenhedsstyret logik og udvidede rækkevidden til en bredere række af konstruktører.

Denne udvikling har kulmineret i en konsolideret arkitektur med høj ydeevne, der er fokuseret på to komplementære søjler: Registreringsudløst forløb og Apex. Dette dokument leverer rammestrukturen og retningslinjerne til at træffe informerede beslutninger, når du designer udløserautomatiseringer.

Opbygning af skalerbar, vedligeholdbar og effektiv registreringsudløst automatisering på Salesforce Platform kræver en disciplineret, arkitektonisk styret tilgang. Valget mellem forløb og Apex og implementeringen af hver af dem er styret af et klart sæt principper. Disse punkter opsummerer disse principper og tjener som grundlæggende regler for moderne automatiseringsdesign.

• Vælg det rigtige værktøj til jobbet baseret på Salesforce Object-automatiseringstætheden.

  • Brug registreringsudløst forløb for Salesforce-objekter til automatiseringer med lav tæthedsgrad.

  • Udvid registreringsudløst forløbslogik med Apex, der kan kaldes, til automatiseringer med middel tæthed.

  • Brug Apex-udløsere til Salesforce-objekter til automatisering med høj tæthedsgrad.

• Vær forsigtig, når du udløser asynkrone processer.
  Denne regel gælder, uanset om du kalder asynkrone processer i et registreringsudløst forløb eller opretter et job, der kan sættes i kø fra Apex. Selvom dette mønster kan være fristende for aflastning af arbejde, kan det introducere komplekse fejlhåndteringsscenarier og øge risikoen for at nå styringsbegrænsninger.

• Brug et indgangspunkt pr. Salesforce-objekt.
  For et givet Salesforce-objekt skal du bruge en mekanisme som dit indgangspunkt i automatisering. Forsøg at undgå at blande forløbs- og Apex som indgangspunkter for det samme objekt.

Flow og Apex deler et fælles sæt af grundlæggende funktioner. Hvert værktøj kan forespørge på registreringer, køre betinget logik, tildele variabler og udføre DML-handlinger som oprettelse, opdatering og sletning af registreringer – i rækkefølge til at køre i en angivet rækkefølge.

Men denne funktionelle overlapning betyder ikke, at værktøjerne kan udskiftes. Det arkitektoniske valg handler ikke om, hvis en opgave kan udføres, men hvordan den udføres, og hvad de langsigtede konsekvenser er for ydeevne, skalerbarhed og vedligeholdelighed. Flow er fremragende i deklarativ klarhed og implementeringshastighed for enkle processer, mens Apex giver den detaljerede kontrol og råstyrke, der er nødvendig for komplekse løsninger.

Automatiseringstæthed er den indlæsning, der er afgivet på et specifikt Salesforce-objekt. Den fungerer som en heuristik til at bestemme objektets optimale implementering. Efterhånden som automatiseringstætheden øges, øges sandsynligheden for at bryde transaktionsgrænserne.

Beregn automatiseringstæthed ved at undersøge tre specifikke dimensioner af mængde og kompleksitet:

• Automatiseringsmængde: Det rå antal entydige automatiseringsmetadataoplysninger (forløb, udløserhandlinger osv.), der afvikles under en enkelt DML-begivenhed (Data Manipulation Language).

• Record volume: Registreringer pr. transaktion, der behandles via API-indlæsninger eller tung batchbehandling, hvor ydeevnen bliver vigtig.

• Afhængighedsudvidelse: Et mål for de downstream DML-handlinger, der udløses af den indledende CRUD-handling. Den kvantificerer dybden af diagrammet, hvor en opdatering overlapper i opdateringer på relaterede objekter (f.eks. sag → konto → kontakt → tilpasset oprulning).

Efterhånden som omfanget og kompleksiteten af din Salesforce-applikation vokser, skal du forpligte dig til et enkelt primært indgangspunkt – enten registreringsudløst forløb eller Apex. Undgå partitioneringsautomatiseringer på tværs af flere mekanismer på et enkelt Salesforce-objekt, da det fører til dårlig vedligeholdelsesmulighed og fragmenteret ledelse.

Brug denne matrix til at bestemme den krævede arkitektoniske standard for dit Salesforce-objekt.

• Record-Triggered Flow er den foretrukne løsning til lav automatiseringstæthed. Den tilbyder en balance mellem styrke og tilgængelighed, der er ideel til automatiseringer, der er ukomplicerede og uafhængige af hinanden.

• Hybridmønsteret (Registreringsudløst forløb med Apex, der kan kaldes) er et kraftfuldt og vedligeholdeligt valg til automatisering af mellemhøjde med stigende kompleksitet. Dette mønster gør det muligt for teams at vedligeholde arrangeret koreografi i deklarativt forløb, mens de uddelegerer store opgaver til Apex.

• Apex-udløsere udgør de nødvendige byggesten til et solidt arkitektonisk fundament til at understøtte automatisering med høj tæthed. Apex' ydeevne, detaljerede kontrolfunktioner samt objektorienteret abstraktion og polymorfisme er bedre egnet til at håndtere kompleksiteten og omfanget af disse scenarier.

Overvej også det samlede daglige antal DML-handlinger, da Salesforce håndhæver delt ressourceadministration i et miljø med flere lejere og administrationsbegrænsninger for at forhindre, at løbende automatiseringer monopoliserer delte ressourcer. Salesforce-objekter med høj daglig DML-volumen kræver omhyggeligt valg af automatisering. F.eks. er asynkrone grænser for CPU-tid (60.000 ms) og heap-størrelse (12 MB) højere end synkrone grænser. Desuden kræver organisationens 24-timers grænse for asynkrone kørsler – beregnet som 250.000 eller 200 gange dine brugerlicenser – at der tages højde for samlet daglig DML i dit arkitektoniske design for at undgå kørselsundtagelser.

Registreringsudløst forløb er platformens førende deklarative værktøj til registreringsudløst automatisering. Forløbets brugervenlighed og indbyggede platformssikkerhedsforanstaltninger gør det muligt for teams nemt at opbygge skalerbare og pålidelige løsninger. Det er det ideelle valg for de fleste teams, der opbygger løsninger på Salesforce-platformen.

Apex er platformens proprietære, højt typede, objektorienterede programmeringssprog. Brug Apex for Salesforce-objekter med høj automatiseringstæthed og til anvendelsessituationer, der kræver høj ydeevne, sofistikeret logik eller detaljeret kontrol over transaktioner.

For at hjælpe beslutningsprocessen giver denne matrix en direkte sammenligning af Flow og Apex på tværs af de vigtigste arkitektoniske funktioner.

Denne tabel indeholder generelle "bedst tilpassede" anbefalinger for generelle anvendelsessituationer baseret på de præsenterede funktioner. I sidste ende vil du overveje yderligere overvejelser for at finde en, der passer bedst til dine specifikke scenarier, f.eks. dem, der er inkluderet i afsnittet Relaterede bedste fremgangsmåder i dette dokument. Der får du mere at vide om, hvornår en bestemt kombination af forløb og Apex giver den bedste tilgang.

Skalerbarhed er en vigtig overvejelse, når du designer din implementering. Når en registreringsudløst automatiserings forretningslogik bliver kompleks, langvarig eller involverer store datamængder, bliver Salesforce Platforms kerne-styringsbegrænsninger til en arkitektonisk begrænsning. Handlinger som massedataopdateringer, komplekse API-udkald eller tunge beregninger øger risikoen for at bryde grænserne, f.eks. den samlede CPU-tid eller antallet af DML-erklæringer i en enkelt databasetransaktion. En fejl i en synkron udløser på grund af en grænseundtagelse vil medføre, at hele brugerens lagringstransaktion ruller tilbage, hvilket resulterer i dårlig brugeroplevelse og potentielt tab af data. Denne indbyggede risiko kræver et arkitektonisk mønster til at aflede kompleks arbejde.

Asynkron automatisering bliver vigtig i dette tilfælde. Ved at bruge asynkrone mekanismer kan arkitekter effektivt afkoble det længe kørende eller højvolumen arbejde fra den primære, synkrone registreringslagringstransaktion. Gemmer fuldføres hurtigt og pålideligt, mens den hårde behandling uddelegeres til en separat, platformsadministreret transaktion, der udføres senere. Afkobling forbedrer stabiliteten, forhindrer transaktionsfejl og er vigtig for opbygning af skalerbare virksomhedsapplikationer. Platformen tilbyder flere specialiserede værktøjer til dette, hver med særskilte fordele og afvejninger med hensyn til pålidelighed, mængde og kompleksitet.

Stien Kør asynkront i et registreringsudløst forløb giver den enkleste mekanisme for "start og glem" asynkron logik. Denne sti udføres i en separat transaktion, når den oprindelige registreringslagringstransaktion er bekræftet til databasen.

• Ideel anvendelsessituation: Dette er velegnet til opgaver, der ikke kræver øjeblikkelig kørsel eller tilpasset fejlhåndtering. Eksempler omfatter afsendelse af en mailadvisering, oprettelse af en opfølgningsopgave eller oprettelse af et enkelt udkald til et eksternt system.

• Begrænsninger: Denne mekanisme deler de samme daglige styringsbegrænsninger som andre asynkrone forløbsinterviews. Den er ikke designet til meget højvolumen behandling.

Change Dataregistrering (CDC) er et højtydende, skalerbart og fleksibelt mønster til håndtering af asynkron logik, der udløses af en registreringsændring i højvolumen scenarier. I denne model er udløsers eneste ansvar at gemme registreringen synkront. Platformen udgiver derefter en detaljeret begivenhedsmeddelelse, der indeholder registreringens ændringer til en højvolumen begivenhedsbus. En separat, dedikeret Apex abonnerer på denne ændringsbegivenhed. Det udfører kompleks, længerevarende eller asynkront arbejde.

• Fordel: Dette mønster adskiller den asynkrone proces fra den indledende brugertransaktion. En fejl i den asynkrone behandling vil ikke medføre, at brugerens registreringslager ruller tilbage. Mønsteret leverer også en holdbar begivenhedsstream, som flere interne abonnenter eller eksterne systemer kan bruge, og begivenheder kan afspilles i op til 72 timer, hvilket giver stærk fleksibilitet.

• Begrænsninger: CDC-begivenhedsmeddelelser indeholder ikke registreringens tidligere tilstand – svarende til en Apex Trigger.oldMap. Begivenhedsdata inkluderer de nye feltværdier, men ikke de værdier, de er ændret fra. Dette gør det vanskeligt at implementere logik baseret på en specifik tilstandsovergang (f.eks. Kør kun, hvis Status__c er ændret fra "Afventer" til "Godkendt"). Du kan reducere dette ved at forespørge på objektets felthistorik i begivenhedsabonnenten, men dette føjer kompleksitet til processen, og felthistoriksporing er muligvis ikke tilgængelig for det specifikke interessefelt. Dette kan begrænse typerne af automatisering, du kan offloade til CDC.

CDC kan som standard aktiveres på maksimalt fem Salesforce-objekter. Organisationer, der kræver mere, kan købe en tilføjelsesprogramlicens, der fjerner denne grænse og øger tildelinger af begivenhedsleveringer.

Klargøring af et Apex, der kan sættes i kø, direkte fra en udløser bør betragtes som et risikabelt mønster, der kun bruges, når der er behov for Apex kontrol (f.eks. for kompleks logik eller tilpassede prøvemekanismer), og CDC er ikke en levedygtig mulighed.

Hvis der kræves Apex, der kan sættes i kø, skal implementeringen omfatte passende sikkerhedsforanstaltninger:

• Limit Checks: Koden skal kontrollere antallet af job, der allerede er oprettet i transaktionen, før du forsøger at tilføje et andet.

• Kontekstbevidsthed: Koden skal registrere, om den kører i en asynkron kontekst, f.eks. et batchjob (System.isBatch()), og ændre dens adfærd, så den overholder den strengere grænse for et job pr. transaktion i denne kontekst.

Kald af asynkron Apex fra en synkron udløser medfører stabilitetsrisici. Hvis du vil forhindre påvirkning på organisationsniveau (f.eks. overskridelse af grænser), kræver dette mønster streng design og test.

• Den daglige grænse for asynkrone Apex-kørsler (Batch, Queueable, @Future) deles på tværs af organisationen (typisk 250.000 eller en beregning baseret på brugerlicenser). En massedataindlæsning på 20.000 registreringer vil medføre, at en udløser udføres i segmenter på 200, hvilket resulterer i 100 separate udløserkald – endnu mere, hvis massebatchstørrelsen er færre end 200 registreringer. Hvis hver kald sætter et asynkront job i kø, kan en væsentlig del af den daglige grænse fra en enkelt dataindlæsning forbruges. Dette forbrug kan potentielt nedbryde andre vigtige forretningsprocesser for asynkrone ressourcer.

• Styringsbegrænsningerne for opstilling af job er drastisk forskellige afhængigt af konteksten. Fra en udløser, der udløses af en brugerhandling i brugergrænsefladen – en synkron transaktion – kan op til 50 job, der kan sættes i kø, sættes i kø. Men fra en udløser, der er udløst i execute af en batch Apex-klasse – en asynkron transaktion – kan kun et job, der kan sættes i kø, sættes i kø. Ikke at tage højde for denne forskel er et almindeligt og kritisk fejlpunkt, der fører til LimitException fejl under store datahandlinger.

• Kald Planlægbar Apex (System.schedule) eller Batch Apex (Database.executeBatch) direkte fra en udløserkontekst udgør et modmønster. Disse metoder er ikke designet til at blive kaldt fra udløserkontekst. Hvis du gør det, vil det føre til hurtig forbrug af din asynkrone Apex, hvilket resulterer i begrænsning af undtagelser.

Hver asynkron mekanisme har specifikke afvejninger med hensyn til ydeevne, styringsbegrænsninger og pålidelighed. Brug dette beslutningstræ som en vejledning til at hjælpe dig med at navigere i disse indstillinger og vælge den rigtige mekanisme til din anvendelsessituation.

Som forløbsdiagrammet angiver, når du står over for højvolumen DML-handlinger, men ikke kan bruge Change Dataregistrering (måske på grund af objektbegrænsninger), er det bedste arkitektoniske valg ofte at undgå en udløserindkaldt proces helt.

Overvej i stedet at bruge en planlagt proces. Dette kan enten være et planlagt forløb eller et planlagt Apex. Påkrævede trin er:

1. Udfør en enkel, billig opdatering i den synkrone udløser. Indstil f.eks. et Status__c til "Afventer behandling" eller indsæt en relateret lavprisregistrering, f.eks. et Chatter-indlæg, for at angive, at registreringen skal behandles.

2. Opret et planlagt job, enten et planlagt forløb eller et planlagt Apex, der kører regelmæssigt, f.eks. hvert 15. minut eller hver time.

3. Få den planlagte jobforespørgsel for alle registreringer i den ventende tilstand, køre den komplekse logik i en kontrolleret, højvolumen kontekst, og opdater derefter registreringerne som behandlet.

Dette mønster adskiller fuldt ud den hårde behandling fra brugerens synkrone lagring, er ikke underlagt grænsen for et job pr. transaktion for et udløserbaseret batch og leverer en meget skalerbar og administrerbar løsning til ikke-realtidskrav.

Hvis forsinkelsen af et planlagt job ikke er acceptabel for forretningskravene, og du stadig er begrænset til at bruge CDC eller en udløserbaseret kø, indikerer dette en væsentlig arkitektonisk uoverensstemmelse. På dette tidspunkt skal forskellige mekanismer overvejes. Genevaluering af kernes applikationsdesign kan føre til visse konklusioner, f.eks.:

• Køb af tilføjelsesprogrammet for at fjerne CDC-objektgrænser.

• Grundlæggende udfordring af forretningskravet for at bestemme, om næsten realtidsbehandling virkelig er et "skal have", eller om forsinkelsen af et planlagt job er en acceptabel afvejning for platformens stabilitet.

Niveauet af kompleksitet i en implementering er en del af en løsnings samlede ejerskabsomkostninger samt dens mulighed for at tilpasse sig til ændrede forretningskrav. Kompleksitet kan påvirke enhver implementering, hvis de bedste fremgangsmåder ikke følges. I afsnittet Relaterede bedste fremgangsmåder i dette dokument er der anbefalinger til at reducere kompleksiteten i din løsning, herunder disse mønstre:

• Hybrid Pattern: Kaldbar Apex for kompleks logik i forløb

• Brug af en metadatastruktur for Apex

• Mega-Flows vs. Flere forløb

Dokumentation er lige så vigtig som selve automatiseringen. Det sikrer ikke kun vedligeholdelighed, det er også vigtigt for AI og agentbaserede værktøjer. Dokumentation hjælper dig med at forstå og administrere dine forretningsprocesser.

I forløb

• Opret en ensartet navngivningskonvention for alle elementer og variabler.

• Brug feltet Beskrivelse for forløbet til at forklare dets overordnede formål, udløserkriterier og tilsigtet resultat.

• Brug feltet Beskrivelse på hvert enkelt element (f.eks. Get Records, Action, Transform). Denne fremgangsmåde er den bedste måde at formidle hensigter på. Det er især vigtigt for handlinger og underforløb, der kan kaldes, hvor beskrivelsen er det primære sted til at forklare den komplekse logik, der udføres af handlingen.

I Apex

• Kommentar din kode tydeligt for at forklare hvorfor bag din logik, ikke bare hvad.

• Hvis du bruger en metadatastyret struktur, skal du sørge for, at dine metadataregistreringer inkluderer og udfylder et brugervenligt beskrivelsesfelt for at forklare, hvad hver handlerklasse gør, og hvornår den skal køre.

DevOps og kildekontrol er del af en moden udviklingslivscyklus. Brug altid et kildekontrolværktøj som Git for Salesforce-projekter. Både Apex og Salesforce-forløb er metadata, der definerer din forretningslogik, og de skal versioneres og administreres.

I konteksten af administration af registreringsudløste automatiseringer giver en moderne DevOps-pipeline vigtige fordele.

• Automatisk kvalitetskontrol: Værktøjer som f.eks. Salesforce Code Analyzer kan konfigureres til at køre automatisk i din pipeline. Statisk analyse kan registrere problematiske mønstre i begge automatiseringsværktøjer, før de promoveres, hvilket markerer problemer som ineffektive Get Records elementer i en forløbsløg eller SOQL forespørgsler i en Apex for løkke, som er almindelige årsager til nedbringelse af ydeevnen.

• Regressionsforebyggelse: Når din automatiseringstæthed vokser, kan en ændring af et forløb eller en Apex have utilsigtede konsekvenser for andre automatiseringer på det samme objekt. En robust DevOps-teststrategi, hvor automatiserede Apex køres op mod enhver foreslået ændring, er den mest pålidelige måde til at sikre, at en ny forløbsversion ikke bryder eksisterende Apex (og omvendt).

• Samarbejde og synlighed: Kildekontrol er den "enkelt kilde til sandhed". Den tillader administratorer og udviklere at arbejde på automatisering for det samme objekt parallelt. Det giver også et uvurderligt revisionsspor: Når en produktionsproces afbrydes, kan du straks se, hvem ændrede automatiseringen, når de ændrede den, og — via bekræftelsesmeddelelser — hvorfor de ændrede den.

For teams med en blanding af administratorer og udviklere tilbyder DevOps Center en forenet grænseflade til at hjælpe med at koreografere alle disse trin, hvilket gør en skalerbar, kildekontrolbaseret udviklingsproces tilgængelig for alle i teamet.

Denne kombinerede disciplin af dokumentation og DevOps sikrer din organisations langsigtede sundhed og vedligeholdelighed, hvilket vil gavne hver arkitekt og administrator, der følger dig.

Beslutningsvejledningen ovenfor bruges bedst, før du planlægger din implementering. Det er rettet mod at hjælpe dig med at vælge det bedste produkt til dine anvendelsessituationer. Efter produktvalg er det vigtigt at forstå eksisterende bedste fremgangsmåder for din implementering.

Princippet Et værktøj pr. objekt er afgørende for styring af automatisering med høj tæthed, men fortolk det ikke som et binært valg mellem en rent deklarativ eller en rent programmeringsmæssig stak. Et mere effektivt og vedligeholdeligt arkitektonisk mønster udnytter en Hybrid-model: Placering af Record-Udløst Flow som orkestreringslaget, mens der indkapsles handlinger med høj kompleksitet i Invocable Apex.

Registreringsudløst forløb fungerer som orkestreringslaget for forretningsprocessen. Det ejer indgangskriterierne og udførelseskonteksten (hvad og når). Ved at bevare beslutningslogik og distribution i dette lag forbliver arkitekturens procestopologi gennemsigtig og kan administreres via Flow Trigger Explorer, hvilket forhindrer, at vigtig forretningslogik skjules i kode.

Et almindeligt eksempel på en kompleks komponent er implementeringen af Service Level Agreement-beregninger (SLA) for sagsregistreringer. Da BusinessHours-objektet og dets relaterede logik – afgørende for nøjagtige beregninger, der ekskluderer ikke-arbejdstider og helligdage – ikke er tilgængeligt som standard i forløb, bruges der en dedikeret Apex. Denne klasse, der ofte kaldes noget som ServiceLevelAgreementCalculator, er designet med en enkelt statisk metode, annoteret med @InvocableMethod, til at beregne de medgåede arbejdstider, bestemme, om SLA er "Inden for mål" eller "Breached", og returnere et struktureret output. Denne tilgang omfatter den komplekse, højtydende logik i Apex, samtidig med at den kan udføres uden problemer og integreres i det deklarative orkestreringslag i et registreringsudløst forløb.

Når Apex ServiceLevelAgreementCalculator-klassen er defineret, er den tilgængelig for brug i et registreringsudløst forløb:

Dette mønster viser en streng adskillelse af bekymringer. Det deklarative lag bruges til at administrere transaktionslivscyklussen og orkestreringen, mens kode bruges til kørsel af høj kompleksitet. Ved at behandle kode som et funktionelt hjælpeprogram snarere end grundlaget, afbalancerer vi ydeevne og vedligeholdelse.

Modularitet: Beslutningen går væk fra singulariteten af at bruge Apex eller Forløb for hele processen. I stedet indkapsler arkitekturen kompleks logik i diskrete, massesikre og uafhængigt testbare enheder. Disse enheder fungerer som genanvendelige komponenter, der forbruges af det deklarative lag, hvilket sikrer, at automatiseringen skaleres uden at komplicere det arkitektoniske design.

Genanvendelighed: Logik afkobles fra udløserbegivenheden. En veludformet kodeenhed (f.eks. en InvocableMethod) skrives én gang, men bruges på tværs af flere indgangspunkter: Registreringsudløste forløb, skærmforløb eller eksterne integrationer. Denne genbrug af kode eliminerer overflødig udvikling.

Vedligeholdelse: Procesforløbslogikken forbliver synlig og kan administreres i det deklarative forløb. Denne centralisering reducerer fejlfindingsoverhead drastisk og sikrer, at systemets kørselsrækkefølge er deterministisk og gennemsigtig.

Selvom hybridmodellen ved brug af Apex, der kan kaldes fra forløb, er effektiv, er den ikke en tilgang, der passer til alle. Architekter skal kende til de specifikke begrænsninger og afvejninger, før de forpligter sig til en hybridløsning.

• Ingen før lagring-understøttelse: Dette er den mest kritiske begrænsning. Handlinger, der kan kaldes, er kun tilgængelige i konteksten efter lagring (forløb for handlinger og relaterede registreringer). De kan ikke bruges i konteksten før lagring af høj ydeevne (forløb for opdateringer af hurtige felter). Derfor kan dette mønster ikke bruges til at uddelegere feltopdateringer for samme registrering. Udfør dette højtydende arbejde ved brug af oprindelige forløbselementer i et før lagring-forløb eller i en før-kontekst Apex.

• Ingen support efter sletning: Registreringsudløst forløb understøtter aktuelt ikke konteksten efter sletning af fortrydelse. Hvis et Salesforce-objekt har et forretningskrav til at køre automatisering, når en registrering gendannes fra papirkurven, er en Apex den eneste løsning.

• Ydeevne overhead i højvolumen scenarier: Overgangen fra forløbskørsel til Apex er ikke en nulomkostningshandling. Selvom det generelt er hurtigt, er handlingen med at gå i gang med en handling, der kan kaldes, fra forløbskørsel ikke så beregningsmæssigt hurtig som indbygget kørsel, der forbliver fuldstændig i en Apex. For de fleste automatiseringer med medium tæthed er dette mikrooverhead en ubetydelig og værdifuld afvejning for den øgede tilgængelighed. Men for scenarier med ekstrem høj ydeevne og højvolumen, vil en kun Apex have en rå beregningshastighedsfordel.

Mens heuristikken for automatiseringstæthed giver en endelig vejledning til nyere greenfield-arkitektur, er virkeligheden i Salesforce-virksomhedsmiljøer ofte mere nuanceret. I modne organisationer er det almindeligt at finde registreringsudløste forløb og Apex, der fungerer på det samme Salesforce-objekt. Dette scenarie er forskelligt fra det hybridmønster, der er forklaret tidligere: her er forløbene og Apex ikke sammenkoblet eller designet til at arbejde sammen.

Denne sameksistens er ofte et resultat af udviklende platformsfunktioner eller forældet teknisk gæld. Selvom dette er en tolereret driftstilstand, skal arkitekter behandle den som en beregnet afvejning snarere end en sluttilstand.

Den fragmenterede orkestrering medfører betydelig styring og vedligeholdelsesoverhead, hvilket gør udvikling, test og hændelseshåndteringsaktiviteter frakoblede og besværlige. Dette fører til øget tid til løsning (TTR) og driftsmæssig kompleksitet.

• For nye Salesforce-objekter skal du overholde principperne for automatiseringstæthed som den primære vejledning.

• For eksisterende Salesforce-objekter med et hybridfodaftryk og en dobbelt Apex og registreringsudløste forløbsindgangspunkter skal du vurdere tætheden og derefter arkitektere til omstrukturering til en vedligeholdelsesbar hybridtilstand.

  • For lavtæthed udløser refactor Apex til registreringsudløste forløb og angiver kørselsrækkefølgen, hvilket fører dem til et enkelt automatiseringsindgangspunkt.

  • For medium tæthed vil omstruktureringskomplekset mega-forløbe i et undersæt af forløb med den rigtige kørselsrækkefølge. Introducer kun Apex, når det er absolut nødvendigt, f.eks. for at understøtte efter sletning af kontekst.

  • Hvis du ønsker høj tæthed, kan du foretrække at implementere Apex.

Efterhånden som en organisations forretningsprocesser på Salesforce-platformen er modne, øges mængden og kompleksiteten af registreringsudløst automatisering uundgåeligt. En grundlæggende bedste fremgangsmåde er at vedligeholde en Apex-udløser pr. Salesforce-objekt. Denne regel er vigtig, fordi platformen ikke garanterer kørselsrækkefølgen af flere udløsere på det samme objekt for den samme begivenhed. Denne begrænsning kan føre til ikke-deterministisk adfærd, løbstilstande og problemer, der er vanskelige at fejlfinde.

Men overholdelse af princippet en udløser skaber en arkitektonisk udfordring: hvordan man administrerer og orkestrerer al forretningslogik, der kaldes fra det ene indgangspunkt på en vedligeholdelig, skalerbar måde.

Den første udvikling af denne arkitektur var mønsteret Classic-udløserhåndtering. I denne tilgang uddelegerer den enkelte Apex-udløser al sin logik til en tilsvarende handlerklasse (f.eks. OpportunityTriggerHandler). Denne metode adskiller logikken fra udløserfilen og giver udviklere deterministisk kontrol over kørselsrækkefølgen i handlerklassens metoder (f.eks. afterInsert()).

Mens dette mønster er en forbedring, fører det ofte til monolithiske handlerklasser. Efterhånden som der tilføjes flere forretningskrav, bliver klassen stor, vanskelig at administrere og vanskelig at teste i isolation. Kørselsrækkefølgen af alle individuelle processer er hardcodet i en enkelt metode, hvilket gør klassen tilbøjelig til at flette konflikter, hvilket øger styringen og vedligeholdelsen dramatisk i et stort virksomhedsmiljø.

For at løse kerneproblemerne med modulalitet og orkestrering skifter arkitekterne til en metadata-drevet Trigger Framework. Dette er et betydeligt arkitektonisk spring, der adskiller selve automatiseringslogikken fra konfigurationen af hvordan og når den kører.

Denne struktur bygger på tre nøglefordele:

• Partitionering: I stedet for en enkelt handlerklasse opdeles kerneforretningslogikken i små atomære Apex-klasser (f.eks. en RecalculateAccountValues eller en NotifySalesLeads), hvor hver klasse overholder princippet om fælles ansvar. Denne modularitet gør det nemmere at teste, fejlfinde og forstå logik isoleret.

• Rækkefølge og koreografi: Kørselsbestillingen er ikke længere hardcodet i Apex. I stedet er det deklarativt defineret af konfigurationsregistreringer, typisk gemt i en tilpasset metadatatype (f.eks. TriggerAction__mdt). Dette giver administratorer mulighed for at omarrangere, tilføje eller fjerne automatiseringshandlinger ved blot at redigere en metadataregistrering, hvilket ikke kræver en implementering eller kodeændring.

• Bypass funktionalitet: Strukturen leverer standardiseret, detaljeret tilsidesættelsesfunktionalitet. Hver automatiseringshandling kan konfigureres via dens metadataregistrering til at blive deaktiveret globalt eller tilsidesat for specifikke administrative brugere ved at henvise til en tilpasset tilladelse.

Den enkelte Apex for objektet fungerer derefter kun som en dynamisk udsender. Den indeholder ingen forretningslogik, men opretter i stedet en central MetadataTriggerHandler-klasse. Denne handler forespørger på de tilpassede metadataregistreringer for dynamisk at bestemme kørselssekvensen og kalde de korrekte atomiske Apex i den foreskrevne rækkefølge. Automatisering er forenet under et enkelt, gennemsigtigt og administrerbart lag.

En vigtig fordel ved at bruge Apex i en robust ramme er muligheden for at styre transaktionel tilstand og optimere ydeevnen ved at fjerne overflødigt arbejde. Efterhånden som logik akkumuleres, er det almindeligt for forskellige automatiseringer i lagringsrækkefølgen at udføre de samme dyre handlinger uafhængigt, hvilket forbruger værdifulde styringsbegrænsninger og øger DML-handlingstiden.

Strukturen er udarbejdet til at håndtere dette med to primære strategier:

• Delt statsadministration: Inden for omfanget af en enkelt Apex anvendes statiske egenskaber og variabler til cachelagring af data. Dette sikrer, at en dyr handling, f.eks. en SOQL for en konfigurationsindstilling, kun udføres en gang, selvom automatiseringslogikken kaldes flere gange på tværs af forskellige registreringer eller faser af udløseren. Forbrug af transaktionsbegrænsninger reduceres væsentligt.

• Platformscacheanvendelse: Hvis du vil gå ud over simpel intra-transaktionscachelagring, skal du bruge platformens cache til at undgå at forespørge på hele databasen for bestemte data. Denne administrerede cache i hukommelsen er ideel til hentning af data, der ikke er primitive, læses hyppigt på tværs af kodebasen og kan ikke ændres i løbet af en transaktion (f.eks. profiler, roller, arbejdstider). Ved hjælp af Cache.CacheBuilder-grænsefladen kontrollerer systemet cachen først og udfører kun databaseforespørgslen, hvis dataene ikke er til stede, hvilket maksimerer ydeevnen og skalerbarheden.

Brug altid en før lagring-opdatering, når din automatisering kun har brug for at ændre feltværdier på den registrering, der starter transaktionen. Dette gælder både for hurtigfeltopdateringer i forløb (der køres før lagring) og før kontekstlogik i Apex (før indsættelse, før opdatering).

Dette mønster er effektivt, uanset hvilket værktøj der bruges, fordi det undgår en anden DML-handling og en rekursiv lagringscyklus. Ændringerne foretages i registreringen i hukommelsen, før den er bekræftet til databasen, og gemmes som en del af den oprindelige transaktion. Overhead af en anden lagring, som ellers ville genudføre hele lagringsbestillingen og starte al automatisering igen, elimineres.

Ukontrolleret rekursion er en almindelig fejl i efter-opdateringsudløsere, hvor en udløsers logik udfører en DML-opdatering, der igen medfører, at den samme udløser udløses igen. Dette opretter en uendelig løkke, der til sidst slutter med en undtagelse for styringsbegrænsning. Mens statiske booleske flag eller samlinger af behandlede registrerings-id'er historisk set er blevet brugt til at forhindre en sådan rekursion, er et mere præcist og robust mønster at gate logikken ved at sammenligne feltværdier mellem de nye og gamle versioner af selve registreringen.

Kør kun logikken, hvis et specifikt interessefelt faktisk er ændret. Dette forhindrer udløseren i at køre dens logik på efterfølgende DML-handlinger i den samme transaktion, hvor de vigtige data forbliver uændrede.

I et registreringsudløst forløb skal du forhindre ukontrolleret rekursion ved at indstille forløbet til kun at køre, når registreringen opdateres, så den opfylder betingelseskravene:

Hvis du vælger at bruge en indtastningskriterieformel i dit forløb, kan du forhindre løbende rekursion ved at sammenligne den globale variabel $Record (der repræsenterer de nye værdier) med den globale variabel $RecordPrior (der repræsenterer de oprindelige værdier før lagringen). Hvis du f.eks. vil sikre, at et forløb kun kører, hvis feltet Beløb på en salgsmulighed er ændret, skal du bruge dette i indtastningskriterierne:

Sammenlign feltværdier fra den nye version af registreringen, Trigger.new, med feltværdier fra den gamle version af registreringen, Trigger.oldMap, for at se, om den specifikke ændring, du søger efter, er sket. Denne tilgang sikrer, at automatiseringen er idempotent og kun kører, når det er nødvendigt, hvilket gør systemet mere effektivt og forhindrer katastrofale rekursive løkker.

En veludarbejdet Salesforce-organisation kræver en ensartet og pålidelig mekanisme til at tilsidesætte automatisering. Dette er ikke en valgfri funktion, men et kerneoperativt krav til vedligeholdelse af dataintegritet og aktivering af administrative opgaver.

En tilsidesættelsesstruktur er vigtig for nogle scenarier:

• Når du indlæser store mængder data, kan udløsning af udløsere for hver registrering drastisk nedsætte hastigheden af processen, forårsage grænseundtagelser og oprette forkerte relaterede registreringer og adviseringer. En tilsidesættelse gør det muligt at indsætte dataene korrekt og effektivt.

• En integrationsbruger kan få brug for at synkronisere data fra et eksternt registreringssystem. Den automatisering, der normalt udløses for en brugerinitieret ændring (f.eks. afsendelse af en mail, oprettelse af en opgave), kan være uønsket eller overflødig, når ændringen stammer fra et andet system.

• Administratorer eller supportmedarbejdere kan få brug for at foretage korrigerende opdateringer på registreringer. En tilsidesættelsesmekanisme giver dem mulighed for at foretage disse ændringer uden at udløse standardforretningsautomatiseringen, hvilket kan have utilsigtede konsekvenser.

Tilpassede tilladelser: Den moderne, skalerbare standard til implementering af tilsidesættelseslogik er tilpassede tilladelser. Disse er overlegne over ældre metoder af flere årsager:

• Fleksibilitet: Tilpassede tilladelser kan tildeles til brugere via tilladelsessæt. Denne fremgangsmåde er i overensstemmelse med den moderne Salesforce-sikkerheds- og adgangsmodel, hvilket tillader detaljeret og fleksibel tildeling. En tilsidesættelse kan tildeles til en bestemt bruger eller endda midlertidigt med en specifik udløbsdato/tidspunkt.

• Vedligeholdelse: Brug af tilpassede tilladelser undgår hardcodning af profiler eller brugere i automatiseringslogik. Hvis en brugers rolle ændres, eller en ny profil har brug for tilsidesættelsesadgang, er ændringen en simpel tilladelsessættildeling, ikke en kode- eller forløbsændring, der kræver en implementering.

• Skalerbarhed: Tilpassede tilladelser giver en skalerbar struktur til administration af undtagelser på tværs af en kompleks brugerbase. De kan tildeles til brugere via tilladelsessæt, tilladelsessætgrupper eller profiler. Vedkommendes tilknytning til et tilladelsessæt eller en profil kan også repræsenteres i kildemetadata.

Implementeringsmønstre: Anvend et ensartet tilsidesættelsesmønster på al registreringsudløst automatisering i organisationen.

Begrænsning af et registreringsudløst forløb: Den mest effektive måde at tilsidesætte et forløb på er at forhindre det i at køre. Dette opnås ved at føje en betingelse til forløbets indtastningskriterier.

• I startelementet for det registreringsudløste forløb skal du indstille Betingelseskravene til Formel evaluerer til sand.

  • I formelkonstruktøren skal du indarbejde en kontrol for den tilpassede tilladelse ved brug af den globale variabel $Permission. Kombiner kontrollen med dine eksisterende indtastningskriterier.

    • Formelmønster:

  • Dette mønster sikrer, at forløbet kun kører, hvis brugeren ikke har den angivne tilpassede tilladelse tildelt. Denne kontrol udføres, før forløbsinterviewet endda oprettes, hvilket gør det til den mest effektive tilgang.

Begrænsning af en Apex-udløserstruktur: I Apex skal du integrere tilsidesættelseslogikken direkte i den metadatastyrede udløserstruktur, så der er mulighed for detaljeret kontrol.

• Den tilpassede metadatatype for TriggerAction__mdt skal indeholde et tekstfelt, f.eks. BypassPermission__c.

  • I MetadataTriggerHandler-klassen skal koden læse værdien fra dette felt, før den udfører en handling dynamisk.

  • Hvis feltet er udfyldt, bruger handleren FeatureManagement.checkPermission()-metoden til at bestemme, om den aktuelle løbende bruger har den angivne tilpassede tilladelse.

  • Hvis checkPermission() returnerer true, springer handleren over den pågældende handling og fortsætter til den næste i sekvensen.

  • Dette mønster er effektivt, fordi det tillader både en global tilsidesættelse (hvis alle TriggerAction__mdt refererer til den samme tilladelse) og en detaljeret tilsidesættelse pr. handling (hvis forskellige registreringer refererer til forskellige tilladelser, eller nogle har slet ingen tilsidesættelsestilladelse).

Det er et anti-mønster til at konsolidere alt af et objekts automatisering i et enkelt, massivt mega-forløb. Konsolidering i et forløb i modsætning til opdeling af logik i flere, velbetingede forløb har ikke en større indflydelse på ydeevnen. De mest betydelige præstationsfordele kommer fra:

• Brug af før lagring-forløb til feltopdateringer for samme registrering.

• Skrivning af præcise indtastningsbetingelser for at sikre, at forløb udelukkes fra at køre på ændringer, der ikke påvirker deres specifikke anvendelsessituation.

Flow Trigger Explorer giver dig mulighed for at tildele en bestillingsværdi til hvert forløb på et objekt, hvilket garanterer en sekventiel kørselsbestilling.