Salesforce Platform har kontinuerlig forbedret sin automatiseringsarkitektur for å oppfylle kravene til komplekse forretningsprosesser. Tidligere generasjoner – arbeidsflytregler og Prosessbygger – sørget for de første trinnene i hendelsesdrevet logikk, utvidet automatiseringsfunksjonalitet for hendelsesdrevet logikk og utvidet rekkevidden til et bredere utvalg av byggere.

Denne utviklingen har resultert i en konsolidert arkitektur med høy ytelse som er sentrert på to komplementære søyler: Postutløste flyter og Apex. Dette dokumentet inneholder rammeverket og retningslinjene for å ta informerte beslutninger når du utformer utløserautomatiseringer.

Å bygge skalerbar, vedlikeholdbar og ytelsesrik postutløst automatisering på Salesforce Platform krever en disiplinert, arkitekturstyrt tilnærming. Valget mellom Flyt og Apex, og implementeringen av hver av dem, styres av et klart sett av prinsipper. Disse punktene oppsummerer disse prinsippene og tjener som grunnregler for moderne automatiseringsutforming.

• Velg riktig verktøy for jobben basert på Salesforce Object-automatiseringstettheten.

  • Bruk Postutløst flyt for Salesforce-objekter til automatiseringer med lav tetthet.

  • Utvid registreringsutløst forløbslogik med kaldbar Apex til automatiseringer med middel densitet.

  • Bruk Apex-utløsere for Salesforce-objekter til automatiseringer med høy tetthet.

• Vær forsiktig når du utløser asynkrone prosesser.
  Denne regelen gjelder enten du kaller opp asynkrone prosesser i en postutløst flyt eller oppretter en købar jobb fra Apex. Selv om dette mønsteret kan være fristende for utlasting av arbeid, kan det introdusere komplekse feilhåndteringsscenarier og øke risikoen for å nå styringsgrenser.

• Bruk ett inngangspunkt per Salesforce-objekt.
  For et gitt Salesforce-objekt bruker du én mekanisme som inngangspunkt til automatisering. Prøv å unngå å blande Flyt- og Apex som inngangspunkter for samme objekt.

Flyt og Apex deler et felles sett av grunnleggende funksjoner. Hvert verktøy kan spørre poster, utføre betinget logikk, tildele variabler og utføre DML-operasjoner som å opprette, oppdatere og slette poster – sekvensert for å kjøre i en angitt rekkefølge.

Denne funksjonelle overlappingen innebærer imidlertid ikke at verktøyene kan byttes ut. Det arkitektoniske valget handler ikke om hvis en oppgave kan utføres, men hvordan den utføres og hva de langsiktige konsekvensene er for ytelse, skalerbarhet og vedlikehold. Flow utmerker seg i deklarativ klarhet og implementeringshastighet for enkle prosesser, mens Apex gir detaljert kontroll og råstyrke som er nødvendig for komplekse løsninger.

Automatiseringstetthet er belastningen som legges inn på et bestemt Salesforce-objekt. Den tjener som en heuristisk for å bestemme objektets optimale implementering. Etter hvert som automatiseringstettheten øker, øker sannsynligheten for å bryte transaksjonsgrenser.

Beregn automatiseringstetthet ved å inspisere tre spesifikke dimensjoner av volum og kompleksitet:

• Automatiseringsmengde: Råantall unike automatiseringsmetadataoppføringer (flyter, utløserhandlinger og så videre) som utføres i løpet av en enkelt DML-hendelse (Data Manipulation Language).

• Postvolum: Postene per transaksjon som behandles via API-innlastinger eller behandling med stor batch, der ytelsen blir avgjørende.

• Avhengighet: En måling av nedstrøms DML-operasjoner utløst av den første CRUD-operasjonen. Den kvantifiserer dybden av diagrammet der én oppdatering går gjennom oppdateringer i relaterte objekter (for eksempel saks → konto → kontakt → tilpasset oppsummering).

Etter hvert som omfanget og kompleksiteten av Salesforce-programmet vokser, må du bekrefte et enkelt primært inngangspunkt – enten Postutløst flyt eller Apex. Unngå å partisjonere automatiseringer på tvers av flere mekanismer i ett enkelt Salesforce-objekt fordi det fører til dårlig vedlikehold og fragmentert styring.

Bruk denne matrisen til å bestemme den nødvendige arkitektoniske standarden for Salesforce-objektet.

• Postutløst flyt er den foretrukne løsningen for lav automatiseringstetthet. Den tilbyr en balanse mellom kraft og tilgjengelighet som er ideell for automatiseringer som er enkle og uavhengige av hverandre.

• Hybridmønsteret (postutløst flyt med kallbar Apex) er et kraftig og vedlikeholdbart valg for automatiseringer med middels tetthet med økende kompleksitet. Dette mønsteret gir team muligheten til å opprettholde ordnet koreografi i deklarativ flyt, samtidig som de delegerer operasjoner som krever mye databehandling, til Apex, og balanserer tilgjengelighet med ytelse.

• Apex-utløsere gir de nødvendige byggeblokkene for et solid arkitektonisk grunnlag for å støtte automatiseringer med høy tetthet. Ytelsen, detaljert kontroll og objektorientert abstraksjon og polymorfisme i Apex er bedre egnet for å håndtere kompleksiteten og omfanget av disse scenariene.

Vurder også totalt antall daglige DML-operasjoner fordi Salesforce håndhever delt ressursbehandling i et miljø med flere leietagere og styringsgrenser for å hindre at automatiseringer som utløper, monopoliserer delte ressurser. Salesforce-objekter med høyt daglig DML-volum krever nøye valg av automatisering. Asynkrone grenser for CPU-tid (60 000 ms) og heap-størrelse (12 MB) er for eksempel høyere enn synkrone grenser. Den organisasjonsomfattende 24-timers grensen for asynkrone utførelser – beregnet som 250 000, eller 200 ganger brukerlisensene dine – krever også at totalt antall daglige DML tas med i arkitektonisk utforming for å unngå kjøretidsunntak.

Postutløst flyt er plattformens fremste deklarative verktøy for postutløst automatisering. Flytens brukervennlighet og innebygde plattformbeskyttelser gjør det enkelt for team å bygge skalerbare og pålitelige løsninger. Det er det ideelle valget for de fleste team som bygger løsninger på Salesforce-plattformen.

Apex er plattformens proprietære, sterkt typede, objektorienterte programmeringsspråk. Bruk Apex for Salesforce-objekter med høy automatiseringstetthet, og for brukstilfeller som krever høy ytelse, avansert logikk eller detaljert kontroll over transaksjoner.

For å hjelpe i beslutningsprosessen gir denne matrisen en direkte sammenligning av Flow og Apex på tvers av viktige arkitektoniske funksjoner.

Denne tabellen gir generelle "best-fit"-anbefalinger for generelle brukstilfeller basert på funksjonene som presenteres. Til slutt vil du ta hensyn til flere viktige punkter for å finne en best egnet for dine bestemte scenarier, som de som er inkludert i delen Relatert anbefalt praksis i dette dokumentet. Der finner du mer informasjon om når en bestemt kombinasjon av Flyt og Apex gir den beste løsningen.

Skalerbarhet er en viktig vurdering når du utformer implementeringen. Når en postutløst automatiserings forretningslogikk blir kompleks, langvarig eller involverer store datavolumer, blir Salesforce Platforms kjernestyringsgrenser en arkitektonisk begrensning. Operasjoner som masseopdateringer av data, komplekse API-oppkall eller omfattende beregninger øker risikoen for å bryte grenser, som total CPU-tid eller antall DML-setninger i en enkelt databasetransaksjon. En feil i en synkron utløser på grunn av et grenseunntak vil føre til at brukerens hele lagringstransaksjon rulles tilbake, noe som fører til dårlig brukeropplevelse og potensielt tap av data. Denne innebygde risikoen krever et arkitektonisk mønster for å laste opp komplekst arbeid.

Asynkron automatisering blir viktig i dette tilfellet. Ved å bruke asynkrone mekanismer kan arkitekter effektivt koble det langvarige arbeidet eller arbeidet med stor trafikk fra den primære, synkrone postlagringstransaksjonen. Lagrer fullført raskt og pålitelig, mens den tunge behandlingen delegeres til en separat plattformadministrert transaksjon som utføres senere. Frakobling forbedrer stabiliteten, hindrer transaksjonsfeil og er avgjørende for å bygge skalerbare virksomhetsprogrammer. Plattformen tilbyr flere spesialiserte verktøy for dette, hver med distinkte fordeler og avveininger når det gjelder pålitelighet, volum og kompleksitet.

Run Asynchronously-banen i en postutløst flyt gir den enkleste mekanismen for "fire and forget" asynchrone logikk. Denne banen utføres i en separat transaksjon etter at den opprinnelige postlagringstransaksjonen har blitt riktig bekreftet til databasen.

• Ideal brukstilfelle: Dette er godt egnet for oppgaver som ikke krever umiddelbar utføring eller tilpasset feilhåndtering. Eksempler inkluderer å sende et e-postvarsel, opprette en oppfølgingsoppgave eller utføre et enkelt kall til et eksternt system.

• Begrensninger: Denne mekanismen deler de samme daglige styringsgrensene som andre asynkrone flytintervjuer. Den er ikke utformet for behandling med svært stor trafikk.

Change Datafangst (CDC) er et mønster for å håndtere asynkron logikk utløst av en postendring i scenarier med stor trafikk. I denne modellen er utløserens eneste ansvar å lagre posten synkront. Plattformen publiserer deretter en detaljert hendelsesmelding som inneholder postens endringer i en hendelsesbuss med stor trafikk. En separat, dedikert Apex abonnerer på denne endringshendelsen. Den utfører komplekst, langvarig eller asynkront arbeid.

• Fordel: Dette mønsteret kobler den asynkrone prosessen fra den første brukertransaksjonen. En feil i den asynkrone behandlingen fører ikke til at brukerens postlagring rulles tilbake. Mønsteret gir også en varig hendelsesstrøm som flere interne abonnenter eller eksterne systemer kan bruke, og hendelser kan spilles av på nytt i opptil 72 timer, noe som gir sterk fleksibilitet.

• Begrensninger: CDC-hendelsesmeldinger inneholder ikke postens tidligere tilstand, som tilsvarer en Apex Trigger.oldMap. Hendelsesbelastningen inkluderer de nye feltverdiene, men ikke verdiene de ble endret fra. Dette gjør det vanskelig å implementere logikk basert på en bestemt tilstandsovergang (kjør for eksempel bare hvis Status__c er endret fra Venter til Godkjent). Du kan avhjelpe dette ved å spørre objektets felthistorikk i hendelsesabonnenten, men dette legger til kompleksitet i prosessen, og felthistorikksporing er kanskje ikke tilgjengelig for det spesifikke interessefeltet. Dette kan begrense hvilke typer automatisering du kan laste ned til CDC.

CDC kan som standard aktiveres for maksimalt fem Salesforce-objekter. Organisasjoner som trenger mer, kan kjøpe en tilleggslisens som fjerner denne grensen og øker tildelingene av hendelseslevering.

Å legge en Apex i kø direkte fra en utløser bør betraktes som et risikabelt mønster, og brukes bare når Apex kontroll er nødvendig (for eksempel for kompleks logikk eller tilpassede prøvemekanismer), og CDC er ikke et levedyktig alternativ.

Hvis købar Apex kreves, må implementeringen inkludere riktige sikkerhetstiltak:

• Limit Checks: Koden må kontrollere antall jobber som allerede er lagt i kø i transaksjonen, før du prøver å legge til en annen.

• Kontekstbevissthet: Koden må oppdage om den kjører innenfor en asynkron kontekst, for eksempel en gruppejobb (System.isBatch()), og endre virkemåten for å overholde den strengere grensen for én jobb per transaksjon i denne konteksten.

Oppkall av asynkron Apex fra en synkron utløser fører til stabilitetsrisiko. For å hindre innvirkning på organisasjonsnivå (for eksempel overskridelse av grenser) krever dette mønsteret streng utforming og testing.

• Den daglige grensen for asynkrone Apex-utførelser (Batch, Queueable, @Future) deles på tvers av organisasjonen (vanligvis 250 000 eller en beregning basert på brukerlisenser). En massedatalast på 20 000 poster vil føre til at en utløser utføres i biter på 200, noe som fører til 100 separate utløserkall – enda mer hvis gruppestørrelsen er mindre enn 200 poster. Hvis hver oppkall legger en asynkron jobb i kø, kan en betydelig del av den daglige grensen fra en enkelt datalasting bli forbrukt. Dette forbruket kan potensielt sulte opp andre viktige forretningsprosesser for asynkrone ressurser.

• Styringsgrensene for å legge opp jobber er drastisk forskjellige avhengig av kontekst. Fra en utløser som utløses av en brukerhandling i grensesnittet, en synkron transaksjon, kan opptil 50 jobber som kan legges i kø, legges i kø. Fra en utløser som utløses innenfor execute-metoden til en gruppe Apex-klasse – en asynkron transaksjon – kan imidlertid bare én jobb som kan legges i kø, legges i kø. Manglende å ta hensyn til denne forskjellen er et vanlig og kritisk feilpunkt som fører til LimitException ved store databehandlinger.

• Å kalle opp Schedulable Apex (System.schedule) eller Batch Apex (Database.executeBatch) direkte fra en utløserkontekst utgjør et anti-mønster. Disse metodene er ikke utformet for å kalles opp fra utløserkontekst. Det vil føre til et raskt forbruk av den asynkrone Apex, noe som fører til begrensede unntak.

Hver asynkron mekanisme har spesifikke avveininger når det gjelder ytelse, styringsgrenser og pålitelighet. Bruk dette beslutningstreet som en veiledning for å navigere i disse alternativene og velge riktig mekanisme for bruksområdet.

Når du står overfor DML-operasjoner med stor trafikk, men ikke kan bruke datafangst (kanskje på grunn av objektgrenser), er det beste arkitektoniske valget ofte å unngå en utløseroppkalt prosess helt.

Vurder i stedet å bruke en planlagt prosess. Dette kan være en Planlagt flyt eller Planlagt Apex. Nødvendige trinn er:

1. Utfør en enkel og billig oppdatering i synkronutløseren. Angi for eksempel et Status__c-felt til "Venter på behandling" eller sett inn en relatert post med lav kostnad, som et Chatter-innlegg, for å angi at posten trenger behandling.

2. Opprett en planlagt jobb, enten en planlagt flyt eller planlagt Apex, som kjører regelmessig, for eksempel hvert 15. minutt eller hver time.

3. Ha den planlagte jobbspørringen for alle poster i ventende tilstand, utfør den komplekse logikken i en kontrollert kontekst med stor trafikk, og oppdater deretter postene slik de er behandlet.

Dette mønsteret kobler fullstendig den tunge behandlingen fra brukerens synkrone lagring, er ikke underlagt grensen for ett jobb per transaksjon for en utløserutløst batch, og gir en svært skalerbar og styrbar løsning for ikke-sanntidskrav.

Hvis latensen til en planlagt jobb ikke er akseptabel for forretningskravene, og du fremdeles er begrenset til å bruke CDC eller en utløserutløst kø, indikerer dette en betydelig arkitektonisk avvik. På dette punktet må forskjellige mekanismer vurderes. Evaluering på nytt av kjerneprogramutformingen kan føre til visse konklusjoner, som

• Kjøp av tillegget for å fjerne CDC-objektgrenser.

• Grunnleggende utfordring av forretningskravet for å finne ut om nær sanntidsbehandling virkelig er en "må ha" eller om latens for en planlagt jobb er en akseptabel avveining for plattformstabilitet.

Kompleksitetsnivået i en implementering er en del av en løsnings totale eierskapskostnad i tillegg til dens mulighet til å tilpasse seg endrede forretningskrav. Kompleksitet kan påvirke alle implementeringer hvis gode fremgangsmåter ikke følges. I delen Relatert anbefalt praksis i dette dokumentet finner du anbefalinger for å redusere kompleksiteten i løsningen, inkludert disse mønstrene:

• Hybridmønster: Kallbar Apex for kompleks logikk i flyt

• Bruke et metadatastrammeverk for Apex

• Mega-Flyter kontra. Flere flyter

Dokumentasjon er like viktig som selve automatiseringen. Det sikrer ikke bare vedlikehold, det er også viktig for AI og agentbaserte verktøy. Dokumentasjon hjelper deg å forstå og behandle forretningsprosesser.

I flyt

• Opprett en konsistent navnekonvensjon for alle elementer og variabler.

• Bruk Beskrivelse-feltet for flyten til å forklare den generelle hensikten, utløserkriteriene og det tiltenkte utfallet.

• Bruk Beskrivelse-feltet på hvert enkelt element (for eksempel Get Records, Action, Transform). Denne praksisen er den beste måten å formidle hensikt på. Det er spesielt viktig for kallbare handlinger og underflyter, der beskrivelsen er det primære stedet for å forklare den komplekse logikken som utføres av handlingen.

In Apex

• Kommentar koden tydelig for å forklare hvorfor bak din logikk, ikke bare hva.

• Hvis du bruker et metadatastyrt rammeverk, må du forsikre deg om at metadatapostene inkluderer og fyller ut et menneskeskjennelig Beskrivelse-felt for å forklare hva hver behandlerklasse gjør og når den skal kjøres.

DevOps og kildekontroll er en del av en moden livssyklus for utvikling. Bruk alltid et kildekontrollverktøy som Git for Salesforce-prosjekter. Både Apex og Salesforce-flyter er metadata som definerer forretningslogikken, og de må være versjonert og administrert.

I forbindelse med behandling av postutløste automatiseringer gir en moderne DevOps pipeline viktige fordeler.

• Automatisk kvalitetskontroll: Verktøy som Salesforce Code Analyzer kan konfigureres til å kjøre automatisk i pipelinen. Statisk analyse kan oppdage problemmønstre i begge automatiseringsverktøyene før de fremheves, og flagger problemer som ineffektive Get Records i en flytsløyfe eller SOQL i en Apex for sløyfe, som er vanlige årsaker til ytelsesreduksjon.

• Regresjonsforebygging: Etter hvert som automatiseringstettheten øker, kan en endring i én flyt- eller Apex ha utilsiktede konsekvenser for andre automatiseringer på samme objekt. En robust DevOps-teststrategi, der automatiske Apex kjøres mot eventuelle foreslåtte endringer, er den mest pålitelige måten å sikre at en ny flytversjon ikke bryter eksisterende Apex (og omvendt).

• Samarbeid og synlighet: Kildekontroll er "den eneste sannhetskilden". Den gir administratorer og utviklere mulighet til å arbeide med automatisering for samme objekt parallelt. Det gir også et uvurderlig revisjonsspor: Når en produksjonsprosess brytes, kan du umiddelbart se hvem som endret automatiseringen, når de endret den, og – via bekreftelsesmeldinger – hvorfor de endret den.

For team med en blanding av administratorer og utviklere tilbyr DevOps Center et forent grensesnitt som hjelper deg med å koreografere alle disse trinnene, og gjør en skalerbar, kildekontrollbasert utviklingsprosess tilgjengelig for alle i teamet.

Denne kombinerte disiplinen med dokumentasjon og DevOps sikrer organisasjonens langsiktige tilstand og vedlikehold, noe som vil være til nytte for alle arkitekter og administratorer som følger deg.

Beslutningsveiledningen ovenfor brukes best før du planlegger implementeringen. Den er rettet mot å hjelpe deg å velge det beste produktet for brukstilfellene. Etter produktvalg er det viktig å forstå eksisterende gode fremgangsmåter for implementeringen.

Prinsippet One Tool Per Object er avgjørende for å håndtere automatisering med høy tetthet, men tolk det ikke som et binært valg mellom en rent deklarativ eller en rent programmatisk stabel. Et mer effektivt og vedlikeholdbart arkitektonisk mønster benytter en Hybrid-modell: Plasser Record-Trigged Flow som orkestreringslaget, samtidig som operasjoner med høy kompleksitet innkapsles i Invocable Apex.

Postutløst flyt fungerer som orkestreringslaget for forretningsprosessen. Den eier inngangskriteriene og utførelseskonteksten (hva og når). Ved å beholde beslutningslogikk og ruting innenfor dette laget forblir arkitekturets prosesstopologi gjennomsiktig og administrerbar via Flow Trigger Explorer, noe som hindrer at kritisk forretningslogikk skjules i kode.

Et vanlig eksempel på en kompleks komponent er implementeringen av beregninger av tjenestenivåavtale (SLA) for Sak-poster. I og med at BusinessHours-objektet og dets relaterte logikk – som er avgjørende for nøyaktige beregninger som utelukker ikke-arbeidstid og fridager – ikke er innebygd tilgjengelig i Flyt, brukes en dedikert Apex. Denne klassen, ofte kalt noe som ServiceLevelAgreementCalculator, er utformet med en enkelt statisk metode, merket med @InvocableMethod, for å beregne medgåtte åpningstider, bestemme om tjenestenivåavtalen er "Inne i mål" eller "Breached", og returnere en strukturert utdata. Denne løsningen innkapsler den komplekse, høyytelseslogikken i Apex samtidig som den kan utføres sømløst og integreres i det deklarative orkestreringslaget i en postutløst flyt.

Når Apex ServiceLevelAgreementCalculator-klassen er definert, blir den tilgjengelig for bruk i en postutløst flyt:

Dette mønsteret viser en streng adskillelse av bekymringer. Det deklarative laget brukes til å behandle transaksjonens livssyklus og orkestrering, mens kode brukes til utføring med høy kompleksitet. Ved å behandle kode som et funksjonelt verktøy i stedet for grunnlaget, balanserer vi ytelse og vedlikehold.

Modularity: Beslutningen svinger bort fra singulariteten ved å bruke Apex eller Flyt for hele prosessen. I stedet innkapsler arkitekturen kompleks logikk til diskrete, gruppebeskyttede og uavhengig testbare enheter. Disse enhetene fungerer som gjenbrukbare komponenter som forbrukes av det deklarative laget, slik at automatiseringen skaleres uten å komplisere den arkitektoniske utformingen.

Gjenbrukbarhet: Logikk kobles fra utløserhendelsen. En velutformet kodeenhet (som en InvocableMethod) skrives én gang, men brukes på tvers av flere inngangspunkter: Postutløste flyter, skjermflyter eller eksterne integrasjoner. Denne gjenbruken av kode eliminerer overflødig utvikling.

Vedlikehold: Prosessflytlogikken forblir synlig og kan behandles i den deklarative flyten. Denne sentraliseringen reduserer overskuddet for feilsøking betydelig og sikrer at systemets utførelsesrekkefølge er deterministisk og transparent.

Hybridmodellen med å bruke kallbar Apex fra Flow er kraftig, men den passer ikke alle. Arkitekter må være klar over de spesifikke begrensningene og avveiningene før de forplikter seg til en hybridløsning.

• Ingen støtte før lagring: Dette er den viktigste begrensningen. Kallbare handlinger er tilgjengelig bare i konteksten etter lagring (flyter for handlinger og relaterte poster). De kan ikke brukes i høyytelseskonteksten før lagring (flyter for oppdateringer av hurtigfelt). Dette mønsteret kan derfor ikke brukes til å delegere feltoppdateringer for samme post. Gjør dette arbeid med høy ytelse ved å bruke innebygde Flyt-elementer i en flyt før lagring eller i en Apex før kontekst.

• Ingen støtte for ettersletting: Postutløst flyt støtter for øyeblikket ikke konteksten etter ikke sletting. Hvis et Salesforce-objekt har et forretningskrav til å kjøre automatisering når en post gjenopprettes fra papirkurven, er en Apex den eneste løsningen.

• Ytelsesoverhead i scenarier med stor trafikk: Overgangen fra flytkjøretid til Apex er ikke en operasjon med null kostnader. Selv om det generelt er raskt, er ikke handlingen med å slippe inn i en kallbar handling fra flytens kjøretid så beregningshastig som innebygd utførelse som forblir helt innenfor en Apex. For de fleste automatiseringer med middels tetthet er denne mikrooverhead en ubetydelig og verdig avveining for den økte tilgjengeligheten. Men for scenarier med ekstrem høy ytelse og stor trafikk vil et rent Apex rammeverk ha en rå beregningshastighetsfordel.

Selv om heuristikken for automatiseringstetthet gir en definitiv veiledning for nyere greenfield-arkitektur, er virkeligheten i Salesforce-miljøer for bedrifter ofte mer nyansert. I modne organisasjoner er det vanlig å finne postutløste flyter og Apex som arbeider på samme Salesforce-objekt. Dette scenariet er forskjellig fra hybridmønsteret som er forklart tidligere: Her er ikke flytene og Apex koblet sammen eller utformet for å fungere sammen.

Denne sameksistensen er ofte et resultat av utviklende plattformfunksjonalitet eller tidligere teknisk gjeld. Selv om dette er en tolerert driftstilstand, må arkitekter behandle den som en beregnet avveining i stedet for en slutttilstand.

Den fragmenterte orkestreringen fører til betydelige overhead-kostnader for styring og vedlikehold, noe som gjør utviklings-, testing- og hendelsesbehandlingsaktiviteter uløste og omfattende. Dette fører til økt TTR (Time to Resolution) og operasjonell kompleksitet.

• For nye Salesforce-objekter følger du prinsippet for automatiseringstetthet som primærveiledning.

• For eksisterende Salesforce-objekter med et hybridavtrykk og dobbel Apex og postutløste flytoppføringspunkter må du vurdere tettheten og deretter arkitektere til refaktor til en vedlikeholdbar hybridtilstand.

  • For lav tetthet utløses Apex til postutløste flyter og angir rekkefølgen for utførelse, som bringer dem til et enkelt automatiseringsinngangspunkt.

  • For middels tetthet flyter refaktorkompleks megavløp til et delsett av flyter med riktig utførelsesrekkefølge. Introduser Apex bare når det er nødvendig, for eksempel for å støtte etter oppheving av sletting av kontekst.

  • For høy tetthet favoriserer du implementering av Apex.

Etter hvert som en organisasjons forretningsprosesser på Salesforce-plattformen modnes, øker volumet og kompleksiteten av postutløst automatisering uunngåelig. En grunnleggende god fremgangsmåte er å vedlikeholde én Apex-utløser per Salesforce-objekt. Denne regelen er avgjørende fordi plattformen ikke garanterer utføringsrekkefølgen for flere utløsere på samme objekt for samme hendelse. Denne begrensningen kan føre til ikke-deterministisk virkemåte, rasebetingelser og problemer som er vanskelige å feilsøke.

Men å følge prinsippet om én utløser innebærer en arkitektonisk utfordring: hvordan man kan administrere og orkestrere all forretningslogikk som kalles opp fra det ene inngangspunktet på en vedlikeholdbar, skalerbar måte.

Den første utviklingen av denne arkitekturen var mønsteret i Classic Trigger Handler. I denne tilnærmingen delegerer den ene Apex-utløseren all sin logikk til en tilsvarende behandlerklasse (for eksempel OpportunityTriggerHandler). Denne metoden skiller logikken fra utløserfilen og gir utviklere deterministisk kontroll over utførelsesrekkefølgen i behandlerklassens metoder (for eksempel afterInsert()).

Selv om dette mønsteret er en forbedring, fører det ofte til monolittiske behandlerklasser. Etter hvert som flere forretningskrav legges til, blir klassen stor, vanskelig å behandle og vanskelig å teste isolert. Utføringsrekkefølgen for alle individuelle prosesser er hardkodet i én enkelt metode, noe som gjør klassen utsatt for sammenslåingskonflikter, noe som dramatisk øker styrings- og vedlikeholdsbeløpet i et stort bedriftsmiljø.

For å løse kjerneproblemene med modulalitet og orkestrering går arkitektene over til et Metadata-drevet utløserrammeverk. Dette er et betydelig arkitektonisk sprang som frakobler selve automatiseringslogikken fra konfigurasjonen av hvordan og når den kjører.

Dette rammeverket bygger på tre viktige fordeler:

• Partisjonering: I stedet for en enkelt behandlerklasse er kjerneforretningslogikken delt opp i små, atomære Apex-klasser (for eksempel en RecalculateAccountValues- eller en NotifySalesLeads-klasse), der hver klasse følger Enkel ansvarsprinsipp. Denne modulærheten gjør det enklere å teste, feilsøke og forstå logikk isolert.

• Order og koreografi: Utføringsrekkefølgen er ikke lenger hardkodet i Apex. I stedet defineres det deklarativt av konfigurasjonsposter, vanligvis lagret i en tilpasset metadatatype (for eksempel TriggerAction__mdt). Det gir administratorer mulighet til å omordne, legge til eller fjerne automatiseringshandlinger bare ved å endre en metadatapost, som ikke krever en distribusjon eller kodeendring.

• Bypass-funksjonalitet: Rammeverket gir standardisert, detaljert bypassfunksjonalitet. Hver automatiseringshandling kan konfigureres via sin metadatapost til å slås av globalt, eller omgås for bestemte administrative brukere ved å referere til en tilpasset tillatelse.

Den ene Apex for objektet tjener da bare som en dynamisk sender. Den inneholder ingen forretningslogikk, men instansierer i stedet en sentral MetadataTriggerHandler-klasse. Denne behandleren spør de tilpassede metadatapostene for å dynamisk bestemme utførelsessekvensen og kalle opp de riktige atomære Apex i den foreskrevne rekkefølgen. Automatisering er forent under ett enkelt, gjennomsiktig og styrbart lag.

En viktig fordel ved å bruke Apex i et robust rammeverk er muligheten til å administrere transaksjonsstatus og optimalisere ytelsen ved å eliminere overflødig arbeid. Etter hvert som logikk akkumuleres, er det vanlig at forskjellige automatiseringer i lagringsrekkefølgen uavhengig utfører de samme kostbare operasjonene, forbruker verdifulle styringsgrenser og øker DML-operasjonstiden.

Rammeverket er utformet for å løse dette med to primære strategier:

• Delt statsforvaltning: Innenfor omfanget av en enkelt Apex brukes statiske egenskaper og variabler til å bufre data. Dette sikrer at en kostbar operasjon, som en SOQL-spørring for en konfigurasjonsinnstilling, bare utføres én gang, selv om automatiseringslogikken kalles opp flere ganger på tvers av forskjellige poster eller faser av utløseren. Forbruket av transaksjonsgrenser reduseres betydelig.

• Utnyttelse av plattformbuffer: Hvis du vil gå utover enkel bufring i transaksjoner, bruker du plattformbufferen til å unngå å spørre hele databasen etter bestemte data. Denne administrerte bufferen i minnet er ideell for henting av data som ikke er primitive, leses ofte på tvers av kodebasen og er uforanderlige i løpet av en transaksjon (for eksempel profiler, roller, åpningstider). Ved hjelp av Cache.CacheBuilder-grensesnittet kontrollerer systemet bufferen først og utfører databasespørringen bare hvis dataene ikke er til stede, noe som maksimerer ytelsen og skalerbarheten.

Bruk alltid en oppdatering før lagring når automatiseringen bare trenger å endre feltverdier i posten som starter transaksjonen. Dette gjelder både hurtigfeltoppdateringer i Flyt (som kjøres før lagring) og logikk før kontekst i Apex (før innsetting, før oppdatering).

Dette mønsteret gir gode resultater uavhengig av hvilket verktøy som brukes, fordi det unngår en andre DML-operasjon og en rekursiv lagringssyklus. Endringene gjøres i posten i minnet før den blir lagt inn i databasen, og lagres som en del av den opprinnelige transaksjonen. Overhead for en andre lagring, som ellers ville utføre hele lagringsrekkefølgen på nytt og starte all automatisering på nytt, elimineres.

Ukontrollert rekursjon er en vanlig felle i etteroppdateringsutløsere, der en utløsers logikk utfører en DML-oppdatering som igjen fører til at den samme utløseren utløses på nytt. Dette oppretter en uendelig sløyfe som til slutt avsluttes med et styringsgrenseunntak. Statiske boolske flagg eller samlinger av behandlede post-ID-er har historisk vært brukt til å hindre slik rekursjon, men et mer presist og robust mønster er å gate logikken ved å sammenligne feltverdier mellom de nye og gamle versjonene av selve posten.

Utfør logikken bare hvis et bestemt interessefelt har blitt endret. Dette hindrer at utløseren kjører logikken sin på etterfølgende DML-operasjoner i den samme transaksjonen der de viktige dataene forblir uendret.

I en postutløst flyt kan du hindre ukontrollert rekursjon ved å angi at flyten skal kjøres bare når posten oppdateres for å oppfylle betingelsene:

Hvis du velger å bruke en formel for inngangskriterier i flyten, kan du hindre gjentagelse ved å sammenligne den globale variabelen $Record (som representerer de nye verdiene) med den globale variabelen $RecordPrior (som representerer de opprinnelige verdiene før lagringen). Hvis du for eksempel vil sikre at en flyt kjører bare hvis Beløp-feltet i en salgsmulighet har blitt endret, bruker du dette i inngangskriteriene:

Sammenlign feltverdier fra den nye versjonen av posten, Trigger.new, med feltverdiene fra den gamle versjonen av posten, Trigger.oldMap, for å se om den spesifikke endringen du leter etter, har skjedd. Denne tilnærmingen sikrer at automatiseringen er idempotent og kjører bare når det er nødvendig, noe som gjør systemet mer effektivt og hindrer katastrofale rekursive sløyfer.

En velbygd Salesforce-organisasjon krever en konsistent og pålitelig mekanisme for å omgå automatisering. Dette er ikke en valgfri funksjon, men et kjerneoperasjonskrav for å opprettholde dataintegritet og aktivere administrative oppgaver.

Et omgåelsesrammeverk er viktig for enkelte scenarier:

• Når du laster inn store mengder data, kan utløsing av utløsere for hver post redusere prosessen dramatisk, føre til grenseunntak og opprette feilaktige relaterte poster og varsler. En omgåelse gjør det mulig å sette inn dataene rent og effektivt.

• En integrasjonsbruker må kanskje synkronisere data fra et eksternt postsystem. Automatiseringen som normalt utløses for en brukerinitiert endring (for eksempel å sende en e-postmelding, opprette en oppgave), kan være uønsket eller overflødig når endringen kommer fra et annet system.

• Administratorer eller kundestøttepersonell må kanskje utføre korrigering av poster. En omgåelsesmekanisme lar dem gjøre disse endringene uten å utløse standard forretningsautomatisering, noe som kan ha utilsiktede konsekvenser.

Tilpassede tillatelser: Den moderne, skalerbare standarden for implementering av bypasslogikk er tilpassede tillatelser. Disse er bedre enn eldre metoder av flere grunner:

• Fleksibilitet: Tilpassede tillatelser kan tildeles til brukere via tillatelsessett. Denne fremgangsmåten er i samsvar med den moderne Salesforce-modellen for sikkerhet og tilgang, slik at det blir mulig å tildele detaljerte og fleksible tildelinger. En omgåelse kan gis til en bestemt bruker, eller til og med midlertidig med en bestemt utløpsdato/klokkeslett.

• Vedlikehold: Bruk av tilpassede tillatelser unngår hardkoding av profiler eller brukere i automatiseringslogikk. Hvis en brukers rolle endres eller en ny profil trenger å omgå tilgang, er endringen en enkel tillatelsessettildeling, ikke en kode- eller flytendring som krever en distribusjon.

• Skalerbarhet: Tilpassede tillatelser gir et skalerbart rammeverk for behandling av unntak på tvers av en kompleks brukerbase. De kan tildeles til brukere via tillatelsessett, tillatelsessettgrupper eller profiler. Deres tilknytning til et tillatelsessett eller en profil kan også representeres i kildemetadata.

Implementeringsmønstre: Bruk et konsistent bypass-mønster på all postutløst automatisering i organisasjonen.

Forbigå en postutløst flyt: Den mest effektive måten å omgå en flyt på, er å hindre at den kjører. Dette oppnås ved å legge til en betingelse i flytens inngangskriterier.

• I Start-elementet i den postutløste flyten angir du Betingelseskrav til Formel evalueres til sann.

  • I formelbyggeren innebygger du en sjekk for den tilpassede tillatelsen med den globale variabelen $Permission. Kombiner kontrollen med eksisterende inngangskriterier.

    • Formelmønster:

  • Dette mønsteret sikrer at flyten bare kjøres hvis brukeren ikke har den angitte tilpassede tillatelsen tildelt. Denne kontrollen utføres før flytintervjuet opprettes, noe som gjør det til den mest effektive løsningen.

Forbigå et Apex-utløserrammeverk: I Apex kan du integrere bypasslogikken direkte i det metadatadrevne utløserrammeverket slik at du får detaljert kontroll.

• Den tilpassede metadatatypen TriggerAction__mdt bør inkludere et tekstfelt, for eksempel BypassPermission__c.

  • I MetadataTriggerHandler-klassen må koden lese verdien fra dette feltet før en handling utføres dynamisk.

  • Hvis feltet er fylt ut, bruker behandleren FeatureManagement.checkPermission()-metoden til å finne ut om gjeldende kjørende bruker har den angitte tilpassede tillatelsen.

  • Hvis checkPermission() returnerer true, hopper behandleren over den bestemte handlingen og fortsetter til den neste i sekvensen.

  • Dette mønsteret er kraftig fordi det tillater både en global bypass (hvis alle TriggerAction__mdt-poster refererer til den samme tillatelsen) og en detaljert bypass per handling (hvis forskjellige poster refererer til forskjellige tillatelser, eller noen har ingen bypass-tillatelse i det hele tatt).

Det er et motmønster for å konsolidere alt av et objekts automatisering til en enkelt, massiv megaflyt. Konsolidering i én flyt kontra oppdelingslogikk i flere, velbetingede flyter har ingen stor innvirkning på ytelsen. De mest betydelige ytelsesforbedringene kommer fra

• Bruke flyter før lagring til feltoppdateringer med samme post.

• Skriv presise inngangsbetingelser for å sikre at flyter ekskluderes fra kjøring av endringer som ikke påvirker deres spesifikke bruksområde.

Med Flow Trigger Explorer kan du tildele en bestillingsverdi til hver flyt på et objekt, noe som garanterer en sekvensiell utførelsesrekkefølge.