Driftsmæssig excellence - automatiseringsmønstre

Læs mere om veludviklet operativ excellence → Automatisering og effektivitet

Mønstre

Hvor skal du se	Hvad der ser godt ud
Platform \| Dashboards	✅ Alle metrikker, der er relateret til KPI’er, er inkluderet i mindst et dashboard
Platform \| Dokumentation	✅ Output for hver automatisering kan måles og er tidsbundet
Platform \| Dokumentation	✅ Ansvarlige interessenter er angivet for hver KPI

Anti-mønstre

Hvor skal du se	Hvad ser dårligt ud
Platform \| Dashboards	⚡️ KPI-rapportering findes ikke, eller dashboards mangler metrikker, der er relateret til nogle KPI’er
Platform \| Dokumentation	⚡️ KPI’er findes uden ansvarlige interessenter
Platform \| Dokumentation	⚡️ KPI’er findes ikke for automatiseringer eller har uklare tidsrammer for mål

Mønstre

Hvor skal du se	Hvad der ser godt ud
Platform \| Forløb	✅ Flow Builder bruges til registreringsudløst automatisering (erstatter Proceskonstruktør og arbejdsflowregler)
Platform \| Forløb	✅ Registreringsudløste forløb med før lagring-kørsel bruges til feltpopulation før registreringsoprettelse
Platform \| Forløb	✅ Forløb håndterer beslutningslogik, løkker, API-udkald, DML-handlinger og kompleks orkestrering med flere trin
Platform \| Forløb	✅ Forløbstransaktionskontrol bruges til at bekræfte mellemliggende ændringer, når der er behov for det
Platform \| Forløb	✅ Fejlhåndtering implementeres til praktisk fejlgendannelse i forløb
Platform \| Forløb	✅ Reaktive skærmforløb giver dynamiske brugeroplevelser
Platform \| Forløb	✅ Deklarativ automatisering vælges, når forretningsbrugere eller administratorer har brug for at redigere logik uden udviklerengagement
Platform \| Forløb	✅ Variabler refererer ikke til hardcodede værdier (for registreringstyper, brugere osv.)
Platform \| Forløb	✅ Forløbslogik, der er klar til Apex i store datamængdekontekster
Platform \| Forløb	✅ Underforløb bruges til afsnit af processer, der skal genbruges på tværs af forretningen
Platform \| Forløb	✅ Alle automatisk startede forløb bruger beslutnings- og/eller pauseelementer til at evaluere indtastningskriterier og forhindre uendelige løkker eller kørsler mod store datamængder
Platform \| Forløb	✅ Brugere bliver kun bedt om at angive data, når eksisterende systemdata ikke kan bruges
Platform \| Forløb	✅ Forløb er organiseret i en hierarkisk struktur, der består af et hovedforløb og underordnede underforløb
Platform \| Forløb	✅ Alle brugerinput har et tydeligt formål i forløbet
Platform \| Forløb	✅ Hvert forløb tjener et enkelt, specifikt formål
Platform \| Forløb	✅ Hvert trin udfører en specifik, detaljeret opgave
Platform \| Forløb	✅ Alle forløb, der startes i brugerkontekst, abstrakte systemkontekstransaktioner til underforløb, placeret ensartet efter pauseelementet for at oprette ny transaktion
Platform \| Forløb	✅ Alle registreringsudløste forløb har udløserrækkefølgeværdier udfyldt
Platform \| Forløb	✅ Forløb, der involverer eksterne systemudkald eller længe kørende processer, bruger asynkrone stier
Platform \| Forløb	✅ Komplekse sekvenser af relaterede datahandlinger oprettes med Orkestrator (i stedet for at kalde flere underforløb i et monolitisk forløb)
Platform \| Validering	✅ Dataintegritet håndhæves på platformsniveau ved brug af valideringsregler, dubletregler og påkrævede felter
Platform \| Validering	✅ Valideringsregler forhindrer ugyldig dataindtastning før lagring (mere effektiv end udløservalidering)
Platform \| Godkendelsesprocesser	✅ Distribution af godkendelse med flere trin håndterer parallelle og sekventielle godkendelsesstier med uddelegerede godkendere
Platform \| Godkendelsesprocesser	✅ Godkendelsesarkitektur tæller for undtagelsesscenarier (alle godkendere på ferie, vigtige forretningskrav, der tilsidesætter normal godkendelse)

Anti-mønstre

Hvor skal du se	Hvad ser dårligt ud
Platform \| Forløb	Proceskonstruktør og arbejdsflowregler, der bruges til ny automatisering (Flow Builder er den strategiske retning)
Platform \| Forløb	⚡️ Programmeringsmæssig automatisering, der bruges, når forretningsbrugere eller administratorer har brug for at redigere logik uden udviklerengagement
Platform \| Forløb	⚡️ Forløb mangler fejlhåndtering, hvilket resulterer i dårlig fejlgendannelse
Platform \| Forløb	⚡️ Variabler har hardcodede værdier
Platform \| Forløb	⚡️ Forløb skal manuelt deaktiveres, før der masseindlæses data
Platform \| Forløb	⚡️ Dele af et forløb gentages på tværs af forløb i stedet for at bruge underforløb
Platform \| Forløb	⚡️ Forløb udløser “uhåndteret undtagelse”-adviseringer
Platform \| Forløb	⚡️ Selv enkle forløb forårsager regelmæssigt fejl, der er relateret til styringsbegrænsninger
Platform \| Forløb	⚡️ Forløb kræver yderligere input for at angive kontekst
Platform \| Forløb	⚡️ Forløb tjener flere formål
Platform \| Forløb	Grupper af relaterede trin indeholder funktionalitet, der overlapper grupper af trin i andre forløb
Platform \| Forløb	⚡️ Forløb beder om brugerinput, når lagrede data i stedet kan bruges
Platform \| Forløb	⚡️ Forløb kræver input, hvis data ikke bruges
Platform \| Forløb	⚡️ Udførelse af DML ved brug af samling, der er output fra skærmkomponent (anvendelse af indstillingen “Brug id’er og alle feltværdier fra en registrerings- eller registreringssamling” ved oprettelse, opdatering eller sletning, når samling er output fra skærmkomponent)
Platform \| Forløb	⚡️ Registreringsudløste forløb bruger slet ikke udløserrækkefølgeattributter eller bruger ikke udløserrækkefølgeværdier ensartet
Platform \| Forløb	⚡️ Asynkrone stier, der ikke bruges ensartet eller slet ikke
Platform \| Forløb	⚡️ Store, monolitiske forløb forsøger at koordinere komplekse sekvenser af relaterede datahandlinger (med eller uden underforløb)
Platform \| Godkendelsesprocesser	⚡️ Godkendelsesarkitektur tager ikke højde for undtagelsesscenarier (alle godkendere på ferie, vigtige forretningskrav)
Platform \| Validering	Dataintegritet håndhæves kun i udløsere i stedet for valideringsregler (udløservalidering er mindre effektiv og mere kompleks)

Mønstre

Hvor skal du se	Hvad der ser godt ud
Platform \| Apex	✅ Udløserhåndteringsstruktur håndhæver single-udløser-pr. objekt, massebehandling, adskillelse af bekymringer og forebyggelse af tilbagevendende kørsel
Platform \| Apex	✅ Udløser-handler uddelegeres til serviceklasser for forretningslogik og vedligeholder en tydelig adskillelse af bekymringer
Platform \| Apex	✅ Udløsere bruger rekursionsbeskyttelse ved brug af statiske flag eller dedikeret rekursionskontrolklasse
Platform \| Apex	✅ Future Apex bruges sparsomt til udkald eller systemobjekt-DML
Platform \| Apex	✅ Async Apex bruger DML, der kan sættes i kø til at “kæde” kompleks på tværs af transaktioner
Platform \| Apex	✅ Batch Apex bruges til store datamængder (behandler store datamængder med særlige styringsbegrænsninger pr. segment)
Platform \| Apex	✅ Batchjob har fejlhåndtering, der logfører mislykkede registreringer uden at stoppe hele batchkørslen
Platform \| Apex	✅ Bulk API bruges kun, når store mængder af data skal behandles (oprindelige SOAP- og REST-API’er bruges til mindre mængder af data)
Platform \| Apex	✅ Købar Apex bruges til kompleks arbejdsfloworkestrering, eksterne udkald med forsøgslogik og behandling, der drager fordel af asynkrone grænser
Platform \| Apex	✅ Planlagt Apex udfører behandling efter faste tidsplaner for natlig vedligeholdelse, daglig rapportering, periodisk integrationssynkronisering og tidsbaserede forretningsregler
Platform \| Designstandarder	✅ Anvendelsessituationer for synkrone og asynkrone handlinger i automatiseringer er tydeligt skitseret som en del af designstandarder
Platform \| Dokumentation	✅ Planlagte og potentielle kørselsstier for automatiseringer skitseres tydeligt

Anti-mønstre

Hvor skal du se	Hvad ser dårligt ud
Platform \| Apex	⚡️ Flere udløsere på et objekt med en uforudsigelig kørselsrækkefølge og overlappende logik
Platform \| Apex	⚡️ Forretningslogik integreret direkte i udløserfiler, hvilket gør testen vanskelig
Platform \| Apex	⚡️ Ingen udløserhåndteringsstruktur eller inkonsekvente udløsermønstre på tværs af objekter
Platform \| Apex	⚡️ Batch Apex har meget lille omfangsstørrelse (f.eks. omfangsstørrelse = 1)
Platform \| Apex	Batch Apex bruges til eksterne udkald (store mængder af Salesforce-data overføres til et eksternt system ved brug af batch Apex)
Platform \| Apex	⚡️ Asynkrone Apex, der bruges vilkårligt (Future Methods og Apex, der kan sættes i kø, bruges inkonsekvent eller udskifteligt)
Platform \| Apex	⚡️ Async Apex bruges sjældent
Platform \| Apex	Databasehandlinger har ikke en tydelig, ensartet logik til at overføre kørsel til batch Apex, når det er nødvendigt
Platform \| Designstandarder	⚡️ Anvendelsessituationer for synkrone og asynkrone handlinger håndteres ikke
Platform \| Dokumentation	⚡️ Automatiseringskald er ikke dokumenteret

Mønstre

Hvor skal du se	Hvad der ser godt ud
Platform \| Platformsbegivenheder	✅ Platformsbegivenheder bruges til begivenhedsstyret automatisering, der adskiller handlingsområder fra abonnenter
Platform \| Platformsbegivenheder	✅ Udgivere er uvidende om abonnenter og udgiver fire-and-glemt
Platform \| Platformsbegivenheder	✅ Flere abonnenter reagerer uafhængigt på begivenheder gennem platformsbegivenhedsudløste forløb, Apex eller eksterne integrationer
Platform \| Platformsbegivenheder	✅ Genafspilnings-id’er bruges til at afspille manglende begivenheder fra ethvert punkt i det 72-timers bevarelsesvindue
Platform \| Platformsbegivenheder	✅ Platformsbegivenheder aktiverer krydsorganisationskommunikation, ekstern systemadvisering og intern arbejdsfloworkestrering

Anti-mønstre

Hvor skal du se	Hvad ser dårligt ud
Platform \| Platformsbegivenheder	⚡️ Direkte tilknytning mellem udgivere og abonnenter forhindrer automatisering, der kan sammensættes
Platform \| Platformsbegivenheder	⚡️ Opgradering af kontotiveau kalder direkte opdatering af salgsmulighed, advisering af kontoteam og datalagersynkronisering i en transaktion (tæt tilknytning kræver ændringer af kontologoik, hver gang der er brug for ny downstream-behandling)
Platform \| Apex	⚡️ Udgiv øjeblikkeligt platformsbegivenheder anvendes adhoc (realtidsbegivenheder bruges i stedet for Udgiv efter bekræftelse, uanset udgivelsesbestillingskrav eller registreringslåsningsrisici)

Mønstre

Hvor skal du se	Hvad der ser godt ud
Platform \| Apex	✅ SOQL-erklæringer bruger positive logik-sammenligningsoperatorer (`INCLUDES`, `IN`) som primær eller eneste logik
Platform \| Apex	✅ SOQL undgår `= NULL`, `!= NULL` eller bruger dem sparsomt efter positive sammenligningsoperatorer
Platform \| Apex	✅ SOQL bruger ikke `LIMIT 1`-erklæringer
Platform \| Apex	✅ SOQL bruger ikke `ALL ROWS` søgeord
Platform \| Apex	✅ SOQL vises ikke i løkker
Platform \| Apex	✅ Jokertegnskriterier vises i SOSL (ikke SOQL)
Platform \| Apex	✅ SOQL-erklæringer undgår `LIKE` sammenligninger eller delvise tekst sammenligninger
Platform \| Apex	✅ SOQL er indpakket i `try-catch` blokke
Platform \| Apex	✅ Variabler refererer ikke til hardcodede værdier (for registreringstyper, brugere osv.)
Platform \| Apex	✅ Hver klasse tjener et enkelt specifikt formål
Platform \| Apex	✅ Hver metode udfører en specifik, detaljeret opgave
Platform \| Apex	✅ Alle inputvariabler har et tydeligt formål i klassen
Platform \| Apex	✅ Kørsel af kode kræver et minimalt antal ressourcer

Anti-mønstre

Hvor skal du se	Hvad ser dårligt ud
Platform \| Apex	SOQL-erklæringer bruger `NOT`, `NOT IN` som primær eller eneste sammenligningsoperator (ikke selektiv)
Platform \| Apex	⚡️ SOQL-erklæringer bruger `ALL ROWS` nøgleord (ikke-valgfrit)
Platform \| Apex	SOQL-erklæringer bruger `= NULL`, `!= NULL` som primær eller eneste sammenligningsoperator (ikke selektiv)
Platform \| Apex	⚡️ Variabler har hardcodede værdier
Platform \| Apex	⚡️ SOQL vises i løkker
Platform \| Apex	⚡️ SOQL-erklæringer bruger ofte `LIKE` og jokertegnsfilterkriterier (ikke-valgfrit)
Platform \| Apex	⚡️ SOQL ikke indpakket i `try-catch` blokke
Platform \| Apex	⚡️ SOQL-erklæringer bruger `LIMIT 1` (ikke-valgfrit)
Platform \| Apex	⚡️ SOSL bruges sjældent eller ikke ensartet til jokertegnsvalgekriterier
Platform \| Apex	⚡️ Klasser tjener flere formål
Platform \| Apex	⚡️ Metoder udfører flere opgaver, eller metoder udfører opgaver, der ikke stemmer overens med det angivne formål for den klasse, de er del af
Platform \| Apex	⚡️ Inputvariabler bruges faktisk ikke i metoder
Platform \| Apex	Metoder til unødigt at hente data fra databasen eller fra eksterne systemer

Mønstre

Hvor skal du se	Hvad der ser godt ud
Platform \| Apex	✅ Tilpassede undtagelser bruges til at oprette avancerede fejlmeddelelser og logik
Platform \| Apex	✅ Kode omslutter alle DML, SOQL, udkald og andre vigtige procestrin i `try-catch` blokke
Platform \| Apex	✅ Database-klassemetoder kan bruges udelukkende til alle datahandlinger (i stedet for DML)
Platform \| Apex	✅ I asynkrone og massekontekster bruges Database-klassemetoder i stedet for DML
Platform \| Aura	✅ JavaScript omslutter alle datahandlinger og vigtige procestrin i `try-catch` blokke
Platform \| Aura	✅ Inden for `try-catch` bruges indbygget JavaScript `Error` i udtalelser (ingen brug af `$A.error()`)
Platform \| Aura	✅ Alle gendannelige fejllogik vises i `catch` erklæringer, og giver tydelige brugermeddelelser
Platform \| Forløb	✅ Forløb med datahandlinger, udkald og anden vigtig behandlingslogik har fejlstier for alle nøglehandlinger
Platform \| Forløb	✅ Skærmforløb bruger ensartede fejlforbindelser til at vise fejl for brugere
Platform \| Forløb	✅ Tilpassede fejlmeddelelser konfigureres for fejl, der vises på skærmen
Platform \| Lightning Web-komponenter (LWC)	✅ JavaScript omslutter alle datahandlinger og vigtige procestrin i `if ()`/`else if ()` blokke
Platform \| Lightning Web-komponenter (LWC)	✅ Alle `@wire` funktioner bruger `data` og `error` egenskaber, der leveres af API
Platform \| Lightning Web-komponenter (LWC)	✅ Alle `if (error)`/`else if (error)` erklæringer indeholder logik til at behandle fejl og give informative beskeder

Anti-mønstre

Hvor skal du se	Hvad ser dårligt ud
Platform \| Apex	⚡️ DML, SOQL, udkald eller andre vigtige procestrin, der ikke konsekvent pakkes ind i prøve-registreringsblokke
Platform \| Apex	⚡️ Der bruges ingen databaseklassemetoder
Platform \| Apex	⚡️ Datahandlinger udført udelukkende med DML
Platform \| Apex	`System.debug` vises i produktionskode (og kommenteres ikke)
Platform \| Aura	JavaScript omfatter ikke konsekvent datahandlinger og vigtige procestrin i `try-catch`
Platform \| Aura	⚡️ Komponenter bruger `$A.error()`
Platform \| Aura	Fejllogik, der kan gendannes, vises ikke konsekvent i `catch`, og fejlmeddelelser til brugere er ikke tydelige
Platform \| Forløb	⚡️ Forløb bruger ikke fejlstier ensartet eller slet ikke
Platform \| Forløb	⚡️ Tilpassede fejlmeddelelser bruges ikke, så brugere ser standardmeddelelsen “Der er forekommet en ikke-håndteret fejl i dette forløb”
Platform \| Lightning Web-komponenter (LWC)	`@wire` bruger ikke `data` og `error` egenskaber, der leveres af API (eller bruger dem ikke ensartet)
Platform \| Lightning Web-komponenter (LWC)	Hvis det overhovedet bruges, indeholder `if (error)`/`else if (error)`-erklæringer faktisk ikke logik til at behandle fejl og give nyttige fejlmeddelelser
Platform \| Lightning Web-komponenter (LWC)	JavaScript bruger ikke konsekvent `if ()`/`else if ()` blokke med datahandlinger eller kritiske procestrin