Het Salesforce Platform heeft zijn automatiseringsarchitectuur continu verder ontwikkeld om te voldoen aan de eisen van complexe bedrijfsprocessen. Eerdere generaties — Werkstroomregels en Processamensteller — vormden de eerste stappen in eventgestuurde logica, breidden de automatiseringsmogelijkheden voor eventgestuurde logica uit en vergrootten het bereik voor een breder publiek.

Deze evolutie heeft geleid tot een krachtige, geconsolideerde architectuur die is gecentreerd op twee complementaire pijlers: Door records geactiveerde stroom en Apex triggers. Dit document biedt het raamwerk en de richtlijnen voor het nemen van weloverwogen beslissingen bij het ontwerpen van triggerautomatiseringen.

Het bouwen van schaalbare, onderhoudbare en performante door records geactiveerde automatisering op het Salesforce Platform vereist een gedisciplineerde, architectuurgestuurde aanpak. De keuze tussen Flow en Apex, en de implementatie ervan, wordt geleid door een duidelijke set principes. Deze punten vatten deze principes samen en dienen als basisregels voor modern automatiseringsontwerp.

• Kies de juiste tool voor de taak op basis van Salesforce Object automation density.

  • Gebruik door records geactiveerde stromen voor Salesforce-objecten voor automatiseringen met lage dichtheid.

  • Door records geactiveerde stroomlogica aanvullen met aanroepbare Apex voor automatiseringen met een gemiddelde dichtheid.

  • Gebruik Apex triggers voor Salesforce Objects voor automatiseringen met hoge dichtheid.

• Wees voorzichtig bij het activeren van asynchrone processen.
  Deze regel geldt ongeacht of u asynchrone processen aanroept in een door records geactiveerde stroom of een in een wachtrij te plaatsen taak plaatst vanuit Apex. Hoewel dit patroon verleidelijk kan zijn voor het verplaatsen van werk, kan het complexe scenario's voor foutafhandeling introduceren en het risico vergroten dat beheerlimieten worden bereikt.

• Gebruik één invoerpunt per Salesforce-object.
  Gebruik voor een bepaald Salesforce-object één mechanisme als uitgangspunt voor automatisering. Probeer te voorkomen dat u Flow en Apex triggers door elkaar haalt als invoerpunten voor hetzelfde object.

Stroom en Apex delen een gemeenschappelijke set fundamentele mogelijkheden. Elke tool kan query's uitvoeren op records, voorwaardelijke logica uitvoeren, variabelen toewijzen en DML-bewerkingen uitvoeren, zoals records maken, bijwerken en verwijderen — gesequenced voor uitvoering in een opgegeven volgorde.

Deze functionele overlapping impliceert echter niet dat de tools uitwisselbaar zijn. De architectonische keuze gaat niet over of een taak kan worden voltooid, maar hoe deze wordt uitgevoerd en wat de langetermijnimplicaties zijn voor prestaties, schaalbaarheid en onderhoudbaarheid. Stroom blinkt uit in declaratieve helderheid en snelheid van implementatie voor eenvoudige processen, terwijl Apex de fijnmazige controle en ruwe kracht biedt die nodig zijn voor complexe oplossingen.

Automatiseringsdichtheid is de belasting die wordt gelegd op een specifiek Salesforce-object. Het dient als een heuristiek om de optimale implementatie van het object te bepalen. Naarmate de automatiseringsdichtheid groeit, neemt de kans toe dat transactielimieten worden overschreden.

Bereken de automatiseringsdichtheid door drie specifieke dimensies van volume en complexiteit te inspecteren:

• Automatisering hoeveelheid: Het ruwe aantal unieke metagegevensitems voor automatisering (stromen, triggeracties, enzovoort) dat wordt uitgevoerd tijdens één DML-event (Data Manipulation Language).

• Recordvolume: De records per transactie die worden verwerkt via API-belastingen of zware batchverwerking, waarbij prestaties kritiek worden.

• Sprawl van afhankelijkheid: Een meeteenheid van de downstream DML-bewerkingen die zijn geactiveerd door de initiële CRUD-bewerking. Het kwantificeert de diepte van de grafiek waarbij een update trapsgewijs wordt omgezet in updates voor gerelateerde objecten (bijvoorbeeld case → account → contactpersoon → aangepast totaal).

Naarmate het bereik en de complexiteit van uw Salesforce-toepassing toenemen, kiest u één primair invoerpunt—door records geactiveerde stroom of Apex triggers. Vermijd het partitioneren van automatiseringen over meerdere mechanismen voor één Salesforce-object, aangezien dit leidt tot slechte onderhoudbaarheid en gefragmenteerd bestuur.

Gebruik deze matrix om de vereiste architectonische standaard voor uw Salesforce-object te bepalen.

• Door records geactiveerde stroom is de voorkeursoplossing voor een lage automatiseringsdichtheid. Het biedt een balans tussen vermogen en toegankelijkheid die ideaal is voor automatiseringen die eenvoudig en onafhankelijk van elkaar zijn.

• Het hybride patroon (door records geactiveerde stroom met aanroepbare Apex) is een krachtige en onderhoudbare keuze voor automatiseringen met een gemiddelde dichtheid met toenemende complexiteit. Dit patroon stelt teams in staat om geordende choreografie te behouden in declaratieve Flow en tegelijkertijd zware bewerkingen te delegeren aan Apex, waarbij toegankelijkheid en prestaties in evenwicht zijn.

• Apex triggers bieden de noodzakelijke bouwstenen voor een solide architectonische basis om high-density automatiseringen te ondersteunen. De prestaties, fijnmazige besturing en objectgeoriënteerde abstractie en polymorfisme van Apex zijn beter geschikt voor het beheren van de complexiteit en schaal van deze scenario's.

Denk ook aan het totale dagelijkse aantal DML-bewerkingen, omdat Salesforce gedeeld resourcebeheer afdwingt in een omgeving met meerdere belanghebbenden en governorlimieten om te voorkomen dat op hol geslagen automatiseringen gedeelde resources monopoliseren. Salesforce-objecten met een hoog dagelijks DML-volume vereisen een zorgvuldige automatiseringsselectie. Zo zijn asynchrone limieten voor CPU-tijd (60.000 ms) en heapgrootte (12 MB) hoger dan synchrone limieten. Bovendien vereist de 24-uurs limiet voor asynchrone uitvoeringen voor de hele organisatie - berekend als 250.000, oftewel 200 keer uw gebruikerslicenties - dat er rekening wordt gehouden met de totale dagelijkse DML in uw architectonische ontwerp om run-time uitzonderingen te voorkomen.

Door records geactiveerde stroom is de belangrijkste declaratieve tool van het platform voor door records geactiveerde automatisering. Dankzij het gebruiksgemak en de ingebouwde platformbeveiligingen van Flow kunnen teams eenvoudig schaalbare en betrouwbare oplossingen samenstellen. Het is de ideale keuze voor de meeste teams die oplossingen bouwen op het Salesforce-platform.

Apex is de gepatenteerde, sterk getypeerde, objectgeoriënteerde programmeertaal van het platform. Gebruik Apex voor Salesforce-objecten met een hoge automatiseringsdichtheid en voor gebruikscases die hoge prestaties, geavanceerde logica of fijnmazige controle over transacties vereisen.

Om te helpen bij het besluitvormingsproces biedt deze matrix een directe vergelijking van Flow en Apex voor de belangrijkste architectonische mogelijkheden.

Deze tabel bevat algemene aanbevelingen voor "best passende" algemene gebruikscases, op basis van de gepresenteerde mogelijkheden. Uiteindelijk houdt u rekening met extra overwegingen om te komen tot een scenario dat het beste past bij uw specifieke scenario's, zoals die welke zijn opgenomen in de sectie Gerelateerde best practices van dit document. Daar leert u meer over wanneer een bepaalde combinatie van Flow en Apex de beste aanpak biedt.

Schaalbaarheid is een belangrijke overweging bij het ontwerpen van uw implementatie. Wanneer de bedrijfslogica van een door records geactiveerde automatisering complex wordt, lang duurt of grote gegevensvolumes omvat, worden de kernlimieten van het Salesforce-platform een architectonische beperking. Bewerkingen zoals updates van bulkgegevens, complexe API-aanroepen of zware berekeningen verhogen het risico op schending van limieten, zoals totale CPU-tijd of het aantal DML-instructies binnen één databasetransactie. Een fout in een synchrone trigger als gevolg van een limietuitzondering leidt ertoe dat de gehele opslagtransactie van de gebruiker wordt teruggedraaid, wat resulteert in een slechte gebruikerservaring en potentieel gegevensverlies. Dit inherente risico vereist een architectonisch patroon om complex werk te ontlasten.

Asynchrone automatisering wordt in dit geval essentieel. Met behulp van asynchrone mechanismen kunnen architecten het langdurige of grote werk effectief ontkoppelen van de primaire, synchrone transactie voor het opslaan van records. Slaat voltooid snel en betrouwbaar op, terwijl de zware verwerking wordt gedelegeerd aan een afzonderlijke, door het platform beheerde transactie die later wordt uitgevoerd. Ontkoppelen verbetert de stabiliteit, voorkomt transactiefouten en is essentieel voor het samenstellen van schaalbare ondernemingstoepassingen. Het platform biedt hiervoor verschillende gespecialiseerde tools, elk met verschillende voordelen en nadelen op het gebied van betrouwbaarheid, volume en complexiteit.

Het pad Asynchroon uitvoeren in een door records geactiveerde stroom biedt het eenvoudigste mechanisme voor "branden en vergeten" asynchrone logica. Dit traject wordt uitgevoerd in een afzonderlijke transactie nadat de oorspronkelijke recordbewaartransactie met succes is doorgevoerd naar de database.

• Ideale gebruikscase: Dit is zeer geschikt voor taken die geen onmiddellijke uitvoering of aangepaste foutafhandeling vereisen. Voorbeelden zijn het verzenden van een kennisgeving per e-mail, het maken van een vervolgtaak of het doen van een eenvoudige aanroep naar een extern systeem.

• Beperkingen: Dit mechanisme heeft dezelfde dagelijkse beheerlimieten als andere asynchrone stroominteracties. Het is niet ontworpen voor verwerking met extreem groot volume.

Change Gegevensvastlegging (CDC) is een schaalbaar en veerkrachtig patroon met hoge doorvoer voor het afhandelen van asynchrone logica dat wordt geactiveerd door een recordwijziging in scenario's met groot volume. In dit model is de trigger alleen verantwoordelijk voor het synchroon opslaan van de record. Het platform publiceert vervolgens een gedetailleerd eventbericht dat de wijzigingen van de record in een eventbus met groot volume bevat. Een afzonderlijke, speciale Apex trigger abonneert zich op deze wijzigingsevent. Het voert complex, langdurig of asynchroon werk uit.

• Voordeel: Dit patroon ontkoppelt het asynchrone proces van de initiële gebruikerstransactie. Een fout in de asynchrone verwerking leidt er niet toe dat de recordopslag van de gebruiker wordt teruggedraaid. Het patroon biedt ook een duurzame eventstroom die meerdere interne abonnees of externe systemen kunnen verbruiken, en events kunnen gedurende maximaal 72 uur opnieuw worden afgespeeld, wat een sterke veerkracht biedt.

• Beperkingen: CDC eventberichten bevatten niet de voorafgaande status van de record — het equivalent van een Apex Trigger.oldMap. De eventpayload omvat wel de nieuwe veldwaarden, maar niet de waarden waaruit deze zijn gewijzigd. Dit maakt het lastig om logica te implementeren op basis van een specifieke statusovergang (bijvoorbeeld alleen uitvoeren als Status__c is gewijzigd van "In behandeling" in "Goedgekeurd"). U kunt dit verhelpen door een query uit te voeren op de veldhistorie van het object in de eventabonnee, maar dit maakt het proces complexer en het bijhouden van de veldhistorie is mogelijk niet beschikbaar voor het specifieke veld waarin u geïnteresseerd bent. Dit kan de typen automatisering beperken die u kunt overzetten naar CDC.

Standaard kan CDC worden ingeschakeld voor maximaal vijf Salesforce-objecten. Organisaties die meer nodig hebben, kunnen een uitbreidingslicentie aanschaffen die deze limiet verwijdert en de toewijzingen van eventleveringen verhoogt.

Het rechtstreeks vanuit een trigger in een wachtrij plaatsen van een Apex taak dient als een riskant patroon te worden beschouwd, dat alleen wordt gebruikt wanneer door Apex geleverde controle nodig is (bijvoorbeeld voor complexe logica of aangepaste mechanismen voor opnieuw proberen) en CDC geen haalbare optie is.

Als Apex voor wachtrijen vereist is, moet de implementatie de juiste waarborgen bevatten:

• Controles beperken: De code moet het aantal taken controleren dat al in de transactie in de wachtrij is geplaatst voordat er een nieuwe wordt toegevoegd.

• Contextbewustzijn: De code moet detecteren of deze wordt uitgevoerd binnen een asynchrone context, zoals een batchtaak (System.isBatch()), en de werking ervan aanpassen om te voldoen aan de strengere limiet van één taak per transactie in die context.

Het aanroepen van asynchrone Apex vanuit een synchrone trigger brengt stabiliteitsrisico's met zich mee. Om impact op organisatieniveau (bijvoorbeeld overschrijding van limieten) te voorkomen, vereist dit patroon rigoureus ontwerpen en testen.

• De dagelijkse limiet voor asynchrone Apex uitvoeringen (Batch, Queueable, @Future) wordt gedeeld binnen de organisatie (doorgaans 250.000 of een berekening op basis van gebruikerslicenties). Een bulklading van 20.000 records zorgt ervoor dat een trigger in blokken van 200 wordt uitgevoerd, wat resulteert in 100 afzonderlijke triggeraanroepen — zelfs meer als de bulkbatchgrootte kleiner is dan 200 records. Als elke aanroep een asynchrone taak in de wachtrij plaatst, kan een aanzienlijk deel van de dagelijkse limiet van één gegevenslading worden verbruikt. Dit verbruik kan potentieel andere kritieke bedrijfsprocessen uithongeren van asynchrone resources.

• De beheerlimieten voor het in een wachtrij plaatsen van taken zijn drastisch verschillend, afhankelijk van de context. Vanuit een trigger die wordt geactiveerd door een gebruikersactie in de UI — een synchrone transactie — kunnen maximaal 50 wachtrijtaken in een wachtrij worden geplaatst. Vanuit een trigger die wordt geactiveerd binnen de execute van een Batch Apex klasse — een asynchrone transactie — kan echter slechts één wachtrijtaak in de wachtrij worden geplaatst. Het niet in aanmerking nemen van dit verschil is een veelvoorkomend en kritiek foutpunt, wat leidt tot LimitException tijdens grote gegevensbewerkingen.

• Het rechtstreeks aanroepen van Planbare Apex (System.schedule) of Batch Apex (Database.executeBatch) vanuit een triggercontext vormt een antipatroon. Deze methoden zijn niet ontworpen om te worden aangeroepen vanuit triggercontext. Hierdoor wordt uw asynchrone Apex toewijzing snel verbruikt, wat resulteert in limietuitzonderingen.

Elk asynchroon mechanisme heeft specifieke nadelen met betrekking tot prestaties, beheerlimieten en betrouwbaarheid. Gebruik deze beslissingsstructuur als leidraad om door deze opties te navigeren en het juiste mechanisme voor uw gebruikscase te kiezen.

Zoals het stroomdiagram aangeeft, is het vaak de beste architectonische keuze om een via een trigger aangeroepen proces volledig te vermijden wanneer u te maken krijgt met DML-bewerkingen met groot volume, maar Gegevensvastlegging niet kunt gebruiken (misschien vanwege objectlimieten).

Overweeg in plaats daarvan een gepland proces te gebruiken. Dit kan een geplande stroom of geplande Apex zijn. Verplichte stappen zijn:

1. Voer een eenvoudige, goedkope update uit in de synchrone trigger. Stel bijvoorbeeld een Status__c in op "in afwachting van verwerking" of voeg een goedkope gerelateerde record in, zoals een Chatter post, om aan te geven dat de record verwerking nodig heeft.

2. Maak een geplande taak, een geplande stroom of geplande Apex, die periodiek wordt uitgevoerd, zoals elke 15 minuten of elk uur.

3. Laat de geplande taak een query uitvoeren op alle records met de status In behandeling, voer de complexe logica uit in een gecontroleerde context met groot volume en werk de records vervolgens bij zoals ze zijn verwerkt.

Dit patroon ontkoppelt de zware verwerking volledig van de synchrone opslag van de gebruiker, valt niet onder de limiet van één taak per transactie van een via een trigger geactiveerde batch en biedt een zeer schaalbare en beheersbare oplossing voor niet-realtime vereisten.

Als de latentie van een geplande taak niet acceptabel is voor de bedrijfsvereisten en u nog steeds geen CDC of een via een trigger geactiveerd wachtrijbestand kunt gebruiken, duidt dit op een aanzienlijke architectonische mismatch. Op dit punt moeten verschillende mechanismen worden overwogen. Het opnieuw evalueren van het kernontwerp van de toepassing kan leiden tot bepaalde conclusies, zoals:

• De uitbreiding aanschaffen om CDC-objectlimieten te verwijderen.

• Het fundamenteel uitdagen van de bedrijfsvereiste om te bepalen of vrijwel real-time verwerking echt een "must-have" is of dat de latentie van een geplande taak een acceptabel nadeel is voor de stabiliteit van het platform.

De mate van complexiteit van een implementatie maakt deel uit van de totale eigendomskosten van een oplossing en van het vermogen om zich aan te passen aan veranderende bedrijfsvereisten. Complexiteit kan van invloed zijn op elke implementatie als best practices niet worden gevolgd. In de sectie Gerelateerde best practices van dit document staan aanbevelingen om de complexiteit van uw oplossing te verminderen, waaronder deze patronen:

• Hybride patroon: Aanroepbare Apex voor complexe logica in Flow

• Een framework voor metagegevens gebruiken voor Apex triggers

• Megastromen vs. Meerdere stromen

Documentatie is net zo belangrijk als de automatisering zelf. Het zorgt niet alleen voor onderhoudbaarheid, het is ook essentieel voor AI en op agenten gebaseerde tools. Documentatie helpt u uw bedrijfsprocessen te begrijpen en te beheren.

In stroom

• Stel een consistente naamgevingsconventie op voor alle elementen en variabelen.

• Gebruik het veld Beschrijving voor de stroom om het algemene doel, de triggercriteria en de beoogde uitkomst ervan toe te lichten.

• Gebruik het veld Beschrijving voor elk afzonderlijk element (bijvoorbeeld Get Records, Action, Transform). Deze praktijk is de beste manier om intent over te brengen. Dit is met name belangrijk voor aanroepbare acties en substromen, waarbij de beschrijving de primaire plaats is om de complexe logica uit te leggen die door de actie wordt uitgevoerd.

In Apex

• Geef duidelijk commentaar op uw code om het waarom achter uw logica uit te leggen, niet alleen het wat.

• Als u een raamwerk met metagegevens gebruikt, zorgt u ervoor dat uw metagegevensrecords een voor mensen leesbaar veld Beschrijving bevatten en invullen om uit te leggen wat elke handlerklasse doet en wanneer deze moet worden uitgevoerd.

DevOps en bronregeling maken deel uit van een volwassen ontwikkelingslevenscyclus. Gebruik altijd een bronregelingstool zoals Git voor Salesforce-projecten. Zowel Apex klassen als Salesforce Flows zijn metagegevens die uw bedrijfslogica definiëren, en ze moeten van versiebeheer en beheer zijn.

Binnen de context van het beheer van door records geactiveerde automatiseringen biedt een moderne DevOps-pijplijn essentiële voordelen.

• Geautomatiseerde kwaliteitscontroles: Tools zoals Salesforce Code Analyzer kunnen worden geconfigureerd om automatisch in uw pijplijn te worden uitgevoerd. Statische analyse kan problematische patronen in beide automatiseringstools detecteren voordat ze worden doorgezet, waarbij problemen worden gesignaleerd zoals inefficiënte Get Records binnen een Flow-lus of SOQL binnen een Apex for-lus, die veel voorkomende oorzaken van prestatievermindering zijn.

• Regressiepreventie: Naarmate uw automatiseringsdichtheid groeit, kan een wijziging in één stroom of Apex klasse onbedoelde gevolgen hebben voor andere automatiseringen voor hetzelfde object. Een robuuste DevOps-teststrategie, waarbij geautomatiseerde Apex tests worden uitgevoerd op basis van voorgestelde wijzigingen, is de meest betrouwbare manier om ervoor te zorgen dat een nieuwe stroomversie de bestaande Apex logica niet verbreekt (en vice versa).

• Samenwerking en zichtbaarheid: Broncontrole is de "enige bron van waarheid." Hiermee kunnen beheerders en ontwikkelaars parallel aan automatisering voor hetzelfde object werken. Het biedt ook een waardevol controletraject: wanneer een productieproces kapot gaat, kunt u onmiddellijk zien wie de automatisering heeft gewijzigd, wanneer ze deze hebben gewijzigd en – via commit-berichten – waarom ze deze hebben gewijzigd.

Voor teams met een mix van beheerders en ontwikkelaars biedt DevOps Center een gecombineerde interface om al deze stappen te helpen choreograferen, waardoor een schaalbaar, op bronregeling gebaseerd ontwikkelingsproces toegankelijk wordt voor iedereen in het team.

Deze gecombineerde discipline van documentatie en DevOps garandeert de gezondheid en onderhoudbaarheid van uw organisatie op lange termijn, wat ten goede komt aan elke architect en beheerder die u volgt.

De bovenstaande beslissingshandleiding kunt u het beste gebruiken voordat u uw implementatie plant. Het is gericht op het helpen kiezen van het beste product voor uw gebruikscases. Na de productselectie is het belangrijk om inzicht te hebben in bestaande best practices voor uw implementatie.

Het principe van één tool per object is essentieel voor het beheer van automatisering met hoge dichtheid, maar interpreteer het niet als een binaire keuze tussen een puur declaratieve of een puur programmatische stapel. Een effectiever en onderhoudbaarder architecturaal patroon maakt gebruik van een hybride model: positioneer Door record geactiveerde stroom als de doeltreffende laag, terwijl u uiterst complexe bewerkingen inkapselt binnen Aanroepbare Apex.

Door records geactiveerde stroom fungeert als de orkestrerende laag voor het bedrijfsproces. Het is eigenaar van de invoercriteria en uitvoeringscontext (het wat en wanneer). Door beslissingslogica en routering binnen deze laag te behouden, blijft de procestopologie van de architectuur transparant en beheersbaar via de Verkenner van stroomtrigger, waardoor wordt voorkomen dat kritieke bedrijfslogica wordt verborgen binnen code.

Een veelvoorkomend voorbeeld van een complexe component is de implementatie van SLA-berekeningen (Service Level Agreement) voor caserecords. Aangezien het object BusinessHours en de gerelateerde logica ervan – cruciaal voor nauwkeurige berekeningen die niet-werkuren en vrije dagen uitsluiten – niet native toegankelijk zijn in Flow, wordt een speciale Apex klasse gebruikt. Deze klasse, vaak iets als ServiceLevelAgreementCalculator genoemd, is ontworpen met één statische methode, geannoteerd met @InvocableMethod, om de verstreken kantooruren te berekenen, te bepalen of de SLA "Binnen doel" of "Inbreuk" is, en een gestructureerde uitvoer te retourneren. Deze benadering omvat de complexe, hoogwaardige logica in Apex, terwijl deze naadloos kan worden uitgevoerd en geïntegreerd in de declaratieve doeltreffende laag van een door records geactiveerde stroom.

Zodra de Apex ServiceLevelAgreementCalculator klasse is gedefinieerd, is deze beschikbaar voor gebruik binnen een door records geactiveerde stroom:

Dit patroon toont een strikte scheiding van zorgen. De declaratieve laag wordt gebruikt om de levenscyclus en doeltreffende combinatie van transacties te beheren, terwijl code wordt gebruikt voor de uitvoering met grote complexiteit. Door code te beschouwen als een functioneel hulpprogramma in plaats van de basis, brengen we prestaties en onderhoudbaarheid in balans.

Modulariteit: De beslissing draait weg van de eigenheid van het gebruik van Apex of Flow voor het gehele proces. In plaats daarvan vat de architectuur complexe logica in discrete, bulkveilige en onafhankelijk te testen eenheden in. Deze eenheden functioneren als herbruikbare componenten die worden verbruikt door de declaratieve laag, waardoor de automatiseringsschalen worden gewaarborgd zonder het architectonische ontwerp te bemoeilijken.

Herbruikbaarheid: Logica wordt losgekoppeld van de triggerevent. Een goed ontworpen code-eenheid (zoals een InvocableMethod) wordt één maal geschreven, maar gebruikt voor meerdere invoerpunten: Door records geactiveerde stromen, schermstromen of externe integraties. Dit hergebruik van code elimineert redundante ontwikkeling.

Onderhoudbaarheid: De processtroomlogica blijft zichtbaar en beheersbaar binnen de declaratieve stroom. Deze centralisatie vermindert de foutopsporingsoverhead drastisch en zorgt ervoor dat de uitvoeringsvolgorde van het systeem deterministisch en transparant is.

Hoewel het hybride model van het gebruik van aanroepbare Apex vanuit Flow krachtig is, is het geen one-size-fits-all-benadering. Architecten moeten zich bewust zijn van de specifieke beperkingen en nadelen voordat ze overgaan tot een hybride oplossing.

• Geen ondersteuning vóór opslaan: Dit is de meest kritieke beperking. Aanroepbare acties zijn alleen beschikbaar in de context na opslaan (stromen voor acties en gerelateerde records). Ze kunnen niet worden gebruikt in de hoogwaardige context vóór opslaan (stromen voor snelle veldupdates). Daarom kan dit patroon niet worden gebruikt om veldupdates voor dezelfde record te delegeren. Voer dat hoogwaardige werk uit met behulp van native stroomelementen in een stroom vóór opslaan of binnen een Apex trigger vóór de context.

• Geen ondersteuning na verwijdering ongedaan maken: Door records geactiveerde stroom biedt momenteel geen ondersteuning voor de context voor verwijderen na ongedaan maken. Als een Salesforce-object een bedrijfsvereiste heeft voor het uitvoeren van automatisering wanneer een record wordt hersteld vanuit de Prullenbak, is een Apex trigger de enige oplossing.

• Prestatieoverhead in scenario's met groot volume: De overstap van de Flow-runtime naar de Apex runtime is geen kostenloze bewerking. Hoewel het over het algemeen snel is, is het laten wegvallen in een aanroepbare actie vanuit de run-time van Flow niet zo snel als native uitvoering die volledig binnen een Apex trigger blijft. Voor de meeste automatiseringen met een gemiddelde dichtheid is deze micro-overhead een verwaarloosbaar en waardevol nadeel voor de verbeterde toegankelijkheid. Voor scenario's met extreme prestaties en groot volume heeft een puur Apex framework echter een ruw voordeel voor de rekensnelheid.

Hoewel de heuristische automatiseringsdichtheid definitieve richtlijnen biedt voor nieuwere greenfieldarchitectuur, is de realiteit van Salesforce-omgevingen voor ondernemingen vaak genuanceerder. In volwassen organisaties is het gebruikelijk om door records geactiveerde stromen en Apex triggers te vinden die op hetzelfde Salesforce-object werken. Dit scenario verschilt van het hybride patroon dat eerder is uitgelegd: hier zijn de stromen en Apex triggers niet gekoppeld, noch ontworpen om samen te werken.

Deze co-existentie is vaak het resultaat van zich ontwikkelende platformmogelijkheden of verouderde technische schulden. Hoewel dit een gedoogde operationele toestand is, moeten architecten het beschouwen als een berekende trade-off in plaats van een eindtoestand.

De versnipperde doeltreffende combinatie leidt tot aanzienlijke overhead voor beheer en onderhoud, waardoor ontwikkelings-, test- en incidentafhandelingsactiviteiten niet samengaan en lastig worden. Dit leidt tot meer Time to Resolution (TTR) en operationele complexiteit.

• Houd u voor nieuwe Salesforce-objecten aan het principe van automatiseringsdichtheid als primaire richtlijn.

• Voor bestaande Salesforce-objecten met een hybride voetafdruk en dubbele Apex trigger en door records geactiveerde stroominvoerpunten, beoordeelt u de dichtheid en vervolgens de architect om deze te herfactoren naar een onderhoudbare hybride status.

  • Voor stromen met een lage dichtheid activeert refactor Apex triggers om door records geactiveerde stromen te activeren en de volgorde van uitvoering op te geven, waardoor ze op één automatiseringsinvoerpunt komen.

  • Refactoren complexe megastromen in een subset van stromen, met de juiste volgorde van uitvoering. Introduceer Apex triggers alleen wanneer dit absoluut noodzakelijk is, bijvoorbeeld voor ondersteuning na het ongedaan maken van de context.

  • Voor een hoge dichtheid geeft u de voorkeur aan het implementeren van Apex triggers.

Naarmate de bedrijfsprocessen van een organisatie op het Salesforce-platform volwassener worden, nemen het volume en de complexiteit van door records geactiveerde automatisering onvermijdelijk toe. Een fundamentele best practice is om één Apex trigger per Salesforce Object te onderhouden. Deze regel is cruciaal omdat het platform niet de uitvoeringsvolgorde van meerdere triggers voor hetzelfde object voor dezelfde event garandeert. Deze beperking kan leiden tot niet-deterministisch gedrag, race-omstandigheden en moeilijk-op te sporen problemen.

Het naleven van het principe van één trigger brengt echter een architectonische uitdaging met zich mee: hoe moet alle bedrijfslogica die vanuit dat ene invoerpunt wordt aangeroepen, op een onderhoudbare, schaalbare manier worden beheerd en georganiseerd.

De eerste evolutie van deze architectuur was het Classic Trigger Handler-patroon. Bij deze benadering delegeert de enkelvoudige Apex trigger alle logica ervan aan een overeenkomende handlerklasse (bijvoorbeeld OpportunityTriggerHandler). Deze methode scheidt de logica van het triggerbestand en biedt ontwikkelaars deterministische controle over de volgorde van uitvoering binnen de methoden van de handlerklasse (bijvoorbeeld afterInsert()).

Hoewel dit een verbetering is, leidt dit patroon vaak tot monolithische handlerklassen. Naarmate er meer bedrijfsvereisten worden toegevoegd, wordt de klasse in de loop van de tijd groot, moeilijk te beheren en moeilijk te testen. De uitvoeringsvolgorde van alle afzonderlijke processen is hard-coded binnen één methode, waardoor de klasse gevoelig is voor samenvoegingsconflicten, wat de governance- en onderhoudsoverhead in een grote ondernemingsomgeving drastisch vergroot.

Om de kernproblemen van modulariteit en doeltreffende combinatie op te lossen, schakelen architecten over op een door metagegevens gestuurd triggerframework. Dit is een belangrijke architectonische sprong die de automatiseringslogica zelf ontkoppelt van de configuratie van hoe en wanneer deze wordt uitgevoerd.

Dit framework is gebaseerd op drie belangrijke voordelen:

• Partitioneren: In plaats van één handlerklasse wordt de kernbedrijfslogica opgesplitst in kleine, atomaire Apex klassen (bijvoorbeeld een RecalculateAccountValues of een NotifySalesLeads), waarbij elke klasse voldoet aan het Enkelvoudig Verantwoordelijkheidsprincipe. Deze modulariteit maakt het testen, opsporen en begrijpen van logica op zichzelf gemakkelijker.

• Volgorde en choreografie: De uitvoeringsorder is niet langer hard-coded in Apex. In plaats daarvan wordt het declaratief gedefinieerd door configuratierecords, doorgaans opgeslagen in een type aangepaste metagegevens (bijvoorbeeld TriggerAction__mdt). Hierdoor kunnen beheerders automatiseringsacties opnieuw rangschikken, toevoegen of verwijderen door simpelweg een metagegevensrecord te wijzigen, waarvoor geen implementatie of codewijziging nodig is.

• Functionaliteit omzeilen: Het framework biedt gestandaardiseerde, fijnmazige bypass-functionaliteit. Elke automatiseringsactie kan via de bijbehorende metagegevensrecord worden geconfigureerd om globaal te worden uitgeschakeld of voor specifieke gebruikers op beheerdersniveau worden omzeild door te verwijzen naar een aangepaste machtiging.

De enkelvoudige Apex trigger voor het object dient dan alleen als dynamische dispatcher. Het bevat geen bedrijfslogica, maar instantieert in plaats daarvan een centrale MetadataTriggerHandler. Deze handler voert een query uit op de aangepaste metagegevensrecords om dynamisch de uitvoeringsvolgorde te bepalen en de juiste atomaire Apex klassen in de voorgeschreven volgorde aan te roepen. Automatisering wordt gecombineerd onder één transparante en beheersbare laag.

Een belangrijk voordeel van het gebruik van Apex in een robuust framework is de mogelijkheid om de transactiestatus te beheren en prestaties te optimaliseren door redundant werk te elimineren. Naarmate de logica zich opstapelt, is het gebruikelijk dat verschillende automatiseringen binnen de opslagorder onafhankelijk dezelfde dure bewerkingen uitvoeren, wat waardevolle beheerlimieten verbruikt en de DML-bewerkingstijd vergroot.

Het framework is ontworpen om dit aan te pakken met twee primaire strategieën:

• Gedeeld beheer van staat/provincie: Binnen het bereik van één Apex transactie worden statische eigenschappen en variabelen gebruikt voor het cachen van gegevens. Dit zorgt ervoor dat een dure bewerking, zoals een SOQL voor een configuratie-instelling, slechts één maal wordt uitgevoerd, zelfs als de automatiseringslogica meerdere malen wordt aangeroepen in verschillende records of fasen van de trigger. Het verbruik van transactielimieten wordt aanzienlijk verlaagd.

• Inzet van platformcache: Als u verder wilt gaan dan alleen cachegeheugen voor transacties, gebruikt u het platformcachegeheugen om te voorkomen dat u een query uitvoert op de gehele database voor bepaalde gegevens. Dit beheerde, in-memory cachegeheugen is ideaal voor het ophalen van gegevens die niet-primitief zijn, vaak worden gelezen binnen de codebasis en onveranderbaar zijn gedurende de loop van een transactie (bijvoorbeeld profielen, rollen, kantooruren). Met behulp van de Cache.CacheBuilder controleert het systeem eerst het cachegeheugen en voert het alleen de databasequery uit als de gegevens niet aanwezig zijn, wat de prestaties en schaalbaarheid maximaliseert.

Gebruik altijd een update voordat wordt opgeslagen wanneer uw automatisering alleen veldwaarden hoeft te wijzigen voor de record die de transactie start. Dit geldt voor zowel snelle veldupdates in Flow (die worden uitgevoerd vóór opslaan) als vóór-contextlogica in Apex Triggers (vór invoegen, vóór bijwerken).

Dit patroon werkt goed, ongeacht welke tool wordt gebruikt, omdat het een tweede DML-bewerking en een terugkerende opslagcyclus vermijdt. De wijzigingen worden in het geheugen van de record aangebracht voordat deze wordt opgenomen in de database en worden opgeslagen als onderdeel van de oorspronkelijke transactie. De overhead van een tweede opslag, die anders de gehele opslagorder opnieuw zou uitvoeren en alle automatisering opnieuw zou activeren, wordt geëlimineerd.

Ongecontroleerde herhaling is een veelvoorkomende valkuil in triggers na bijwerken, waarbij de logica van een trigger een DML-update uitvoert die op zijn beurt ervoor zorgt dat dezelfde trigger opnieuw wordt geactiveerd. Hierdoor ontstaat een oneindige lus die uiteindelijk eindigt met een uitzondering voor de beheerlimiet. Hoewel statische booleaanse vlaggen of verzamelingen verwerkte record-ID's van oudsher werden gebruikt om een dergelijke herhaling te voorkomen, is een nauwkeuriger en robuuster patroon om de logica te omzeilen door veldwaarden te vergelijken tussen de nieuwe en de oude versie van de record zelf.

Voer de logica alleen uit als een specifiek interessegebied daadwerkelijk is gewijzigd. Dit voorkomt dat de trigger zijn logica uitvoert bij daaropvolgende DML-bewerkingen binnen dezelfde transactie, waarbij de kritieke gegevens ongewijzigd blijven.

Voorkom in een door records geactiveerde stroom ongecontroleerde herhaling door de stroom zo in te stellen dat deze alleen wordt uitgevoerd wanneer de record wordt bijgewerkt om aan de vereisten voor voorwaarden te voldoen:

Als u ervoor kiest om een formule voor invoercriteria in uw stroom te gebruiken, kunt u herhaling voorkomen door de globale variabele $Record (die de nieuwe waarden vertegenwoordigt) te vergelijken met de globale variabele $RecordPrior (die de oorspronkelijke waarden vóór het opslaan vertegenwoordigt). Als u er bijvoorbeeld voor wilt zorgen dat een stroom alleen wordt uitgevoerd als het veld Bedrag voor een opportunity is gewijzigd, gebruikt u dit in de invoercriteria:

Vergelijk veldwaarden uit de nieuwe versie van de record, Trigger.new, met de veldwaarden uit de oude versie van de record, Trigger.oldMap, om te zien of de specifieke wijziging die u zoekt, zich heeft voorgedaan. Deze aanpak zorgt ervoor dat de automatisering idempotent is en alleen wordt uitgevoerd wanneer dat nodig is, waardoor het systeem efficiënter wordt en catastrofale recursieve lussen worden voorkomen.

Een goed ontworpen Salesforce-organisatie vereist een consistent en betrouwbaar mechanisme om automatisering te omzeilen. Dit is geen optionele voorziening, maar een operationele kernvereiste voor het onderhouden van gegevensintegriteit en het inschakelen van administratieve taken.

Een framework voor omzeilen is essentieel voor sommige scenario's:

• Bij het laden van grote hoeveelheden gegevens kunnen triggers voor elke record het proces drastisch vertragen, limietuitzonderingen veroorzaken en foutieve gerelateerde records en kennisgevingen maken. Met een bypass kunnen de gegevens schoon en efficiënt worden ingevoegd.

• Een integratiegebruiker moet mogelijk gegevens synchroniseren vanuit een extern recordsysteem. De automatisering die normaal gesproken wordt geactiveerd voor een door de gebruiker geïnitieerde wijziging (bijvoorbeeld het verzenden van een e-mail, het maken van een taak) kan ongewenst of redundant zijn wanneer de wijziging afkomstig is van een ander systeem.

• Beheerders of ondersteuningsmedewerkers moeten mogelijk corrigerende updates uitvoeren op records. Met een bypass-mechanisme kunnen ze deze wijzigingen aanbrengen zonder de standaardbedrijfsautomatisering te activeren, wat onbedoelde gevolgen kan hebben.

Aangepaste machtigingen: De moderne, schaalbare standaard voor het implementeren van bypass-logica zijn aangepaste machtigingen. Deze zijn om verschillende redenen superieur aan oudere methoden:

• Flexibiliteit: Aangepaste machtigingen kunnen aan gebruikers worden toegewezen via machtigingensets. Deze werkwijze komt overeen met het moderne beveiligings- en toegangsmodel van Salesforce, waardoor fijnmazige en flexibele toewijzingen mogelijk zijn. Een bypass kan worden verleend aan een specifieke gebruiker of zelfs tijdelijk met een specifieke vervaldatum/-tijd.

• Onderhoudbaarheid: Met behulp van aangepaste machtigingen wordt voorkomen dat profielen of gebruikers hard worden gecodeerd in automatiseringslogica. Als de rol van een gebruiker verandert of als een nieuw profiel toegang moet omzeilen, is de wijziging een eenvoudige toewijzing van machtigingensets, geen code- of stroomwijziging die een implementatie vereist.

• Schaalbaarheid: Aangepaste machtigingen bieden een schaalbaar raamwerk voor het beheer van uitzonderingen binnen een complex gebruikersbestand. Ze kunnen aan gebruikers worden toegewezen via machtigingenset, groepen machtigingensets of profielen. Hun koppeling aan een machtigingenset of profiel is ook vertegenwoordigt in bronmetagegevens.

Implementatiepatronen: Pas een consistent bypass-patroon toe op alle door records geactiveerde automatisering in de organisatie.

Een door records geactiveerde stroom omzeilen: De meest efficiënte manier om een stroom te omzeilen is te voorkomen dat deze wordt uitgevoerd. Dit wordt bereikt door een voorwaarde toe te voegen aan de invoercriteria van de stroom.

• Stel in het element Start van de door records geactiveerde stroom de voorwaarde Vereisten in op Formule wordt geëvalueerd naar True (Waar).

  • Neem in de formulesamensteller een controle op de aangepaste machtiging op met behulp van de globale variabele $Permission. Combineer de controle met uw bestaande invoercriteria.

    • Formulepatroon:

  • Dit patroon zorgt ervoor dat de stroom alleen wordt uitgevoerd als de gebruiker de opgegeven aangepaste machtiging niet heeft toegewezen. Deze controle wordt uitgevoerd voordat de stroominteractie is gemaakt, waardoor deze de best presterende benadering is.

Een Apex Trigger Framework omzeilen: Integreer in Apex de bypass-logica rechtstreeks in het metagegevensgestuurde triggerframework, waardoor fijnmazige aansturing mogelijk is.

• Het type aangepaste metagegevens voor TriggerAction__mdt moet een tekstveld bevatten, bijvoorbeeld BypassPermission__c.

  • In de klasse MetadataTriggerHandler moet de code, voordat een actie dynamisch wordt uitgevoerd, de waarde uit dit veld lezen.

  • Als het veld is ingevuld, gebruikt de handler de methode FeatureManagement.checkPermission() om te bepalen of de huidige huidige huidige gebruiker de opgegeven aangepaste machtiging heeft.

  • Als checkPermission() true (waar) retourneert, slaat de handler die specifieke actie over en gaat door met de volgende in de reeks.

  • Dit patroon is krachtig omdat het zowel een globale bypass (als alle TriggerAction__mdt naar dezelfde machtiging verwijzen) als een fijnmazige bypass (als verschillende records naar verschillende machtigingen verwijzen of als sommige helemaal geen bypass-machtiging hebben) mogelijk maakt.

Het is een anti-patroon om alle automatisering van een object te consolideren in één enorme megastroom. Consolideren in één stroom versus logica splitsen in meerdere, goed geconditioneerde stromen heeft geen grote invloed op prestaties. De belangrijkste prestatieverbeteringen zijn afkomstig van:

• Stromen gebruiken voordat wordt opgeslagen voor veldupdates van dezelfde record.

• Precieze invoervoorwaarden schrijven om ervoor te zorgen dat stromen niet worden uitgevoerd voor wijzigingen die geen invloed hebben op hun specifieke gebruikscase.

Met Stroomtriggerverkenner kunt u een orderwaarde toewijzen aan elke stroom voor een object, waardoor een sequentiële uitvoeringsvolgorde wordt gegarandeerd.