Operational Excellence – Automatiseringsmønstre
Lær mer om velbygd driftsutmerkelse → Automatisering og effektivitet
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Kontrollpaneler | ✅ Alle målinger relatert til viktige ytelsesindikatorer er inkludert i minst ett kontrollpanel |
| Plattform | Dokumentasjon | ✅ Utdata for hver automatisering er målbare og tidsbundet |
| Plattform | Dokumentasjon | ✅ Ansvarlige interessenter er oppført for hver KPI |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Kontrollpaneler | ⚡️ KPI-rapportering finnes ikke, eller kontrollpaneler mangler målinger relatert til enkelte KPI-er |
| Plattform | Dokumentasjon | ⚡️ KPI-er finnes uten ansvarlige interessenter |
| Plattform | Dokumentasjon | ⚡️ KPI-er finnes ikke for automatiseringer eller har uklare tidsrammer for målinger |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Flyt | ✅ Flow Builder brukes til postutløst automatisering (erstatter Prosessbygger og arbeidsflytregler) |
| Plattform | Flyt | ✅ Postutløste flyter med utførelse før lagring brukes for feltpopulasjonen før postoppretting |
| Plattform | Flyt | ✅ Flyter håndterer beslutningslogikk, sløyfer, API-oppkall, DML-operasjoner og kompleks orkestrering med flere trinn |
| Plattform | Flyt | ✅ Flyttransaksjonskontroll brukes til å utføre mellomliggende endringer når det er nødvendig |
| Plattform | Flyt | ✅ Feilhåndtering implementeres for god feilgjenoppretting i flyter |
| Plattform | Flyt | ✅ Reaktive skjermflyter gir dynamiske brukeropplevelser |
| Plattform | Flyt | ✅ Deklarativ automatisering velges når forretningsbrukere eller administratorer må endre logikk uten utviklerengasjement |
| Plattform | Flyt | ✅ Variabler refererer ikke til hardkodede verdier (for posttyper, brukere osv.) |
| Plattform | Flyt | ✅ Flyter håndlogikk av til Apex i store datavolumkontekster |
| Plattform | Flyt | ✅ Underflyter brukes til deler av prosesser som må brukes på nytt på tvers av virksomheten |
| Plattform | Flyt | ✅ Alle automatisk startede flyter bruker beslutnings- og/eller pauseelementer til å evaluere inngangskriterier og hindre uendelige sløyfer eller utførelser mot store datavolumer |
| Plattform | Flyt | ✅ Brukere blir bedt om å oppgi data bare når eksisterende systemdata ikke kan brukes |
| Plattform | Flyt | ✅ Flyter er organisert i en hierarkisk struktur som består av en hovedflyt og underflyter som støtter |
| Plattform | Flyt | ✅ Alle brukerinndata har et tydelig formål i flyten |
| Plattform | Flyt | ✅ Hver flyt betjener et enkelt, bestemt formål |
| Plattform | Flyt | ✅ Hvert trinn utfører en spesifikk, detaljert oppgave |
| Plattform | Flyt | ✅ Alle flyter som startes i brukerkontekst, abstrakte systemkontekstraksjoner til underflyter, konsistent plassert etter Pause-element for å opprette ny transaksjon |
| Plattform | Flyt | ✅ Alle postutløste flyter har utløserrekkefølgeverdier fylt ut |
| Plattform | Flyt | ✅ Flyter som involverer eksterne systemoppkall eller prosesser som kjører lenge, bruker asynkrone baner |
| Plattform | Flyt | ✅ Komplekse sekvenser av relaterte dataoperasjoner opprettes med Orchestrator (i stedet for å kalle opp flere underflyter i en monolitt flyt) |
| Plattform | Validering | ✅ Dataintegritet håndheves på plattformnivå ved bruk av valideringsregler, duplikatregler og nødvendige felt |
| Plattform | Validering | ✅ Valideringsregler hindrer ugyldig dataregistrering før lagring (mer effektivt enn utløservalidering) |
| Plattform | Godkjenningsprosesser | ✅ Ruting med godkjenning med flere trinn håndterer parallelle og sekvensielle godkjenningsbaner med delegerte godkjennere |
| Plattform | Godkjenningsprosesser | ✅ Godkjenningsarkitektur tar hensyn til unntaksscenarier (alle godkjennere på ferie, haster med forretningskrav som omgår vanlig godkjenning) |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Flyt | ⚡️ Prosessbygger og arbeidsflytregler som brukes til ny automatisering (Flytbygger er den strategiske retningen) |
| Plattform | Flyt | ⚡️ Programmatisk automatisering brukt når forretningsbrukere eller administratorer må endre logikk uten utviklerengasjement |
| Plattform | Flyt | ⚡️ Flyter mangler feilbehandling som fører til dårlig feilgjenoppretting |
| Plattform | Flyt | ⚡️ Variabler har hardkodede verdier |
| Plattform | Flyt | ⚡️ Flyter må deaktiveres manuelt før massedatalastinger |
| Plattform | Flyt | ⚡️ Deler av en flyt gjentas på tvers av flyter i stedet for å bruke underflyter |
| Plattform | Flyt | ⚡️ Flyter utløser “Ubehandlet unntak”-varsler |
| Plattform | Flyt | ⚡️ Selv enkle flyter fører regelmessig til feil relatert til styringsgrenser |
| Plattform | Flyt | ⚡️ Flyter krever flere inndata for å gi kontekst |
| Plattform | Flyt | ⚡️ Flyter har flere formål |
| Plattform | Flyt | ⚡️ Grupper av relaterte trinn inneholder funksjonalitet som overlapper med grupper av trinn i andre flyter |
| Plattform | Flyt | ⚡️ Flyter ber om brukerinndata når lagrede data kan brukes i stedet |
| Plattform | Flyt | ⚡️ Flyter krever inndata med data som ikke brukes |
| Plattform | Flyt | ⚡️ Utføre DML ved bruk av samling som er utdata fra skjermkomponent (ved å bruke innstillingen “Bruk ID-ene og alle feltverdiene fra en post eller postsamling” ved oppretting, oppdatering eller sletting av elementer når samlingen er utdata fra skjermkomponent) |
| Plattform | Flyt | ⚡️ Postutløste flyter bruker ikke noen attributter for utløserbestilling eller bruker ikke utløserbestillingsverdier konsistent |
| Plattform | Flyt | ⚡️ Asynkrone baner som ikke brukes konsekvent eller ikke brukes i det hele tatt |
| Plattform | Flyt | ⚡️ Store, monolittiske flyter forsøker å koordinere komplekse sekvenser av relaterte dataoperasjoner (med eller uten underflyter) |
| Plattform | Godkjenningsprosesser | ⚡️ Godkjenningsarkitektur tar ikke hensyn til unntaksscenarier (alle godkjennere på ferie, presserende forretningskrav) |
| Plattform | Validering | ⚡️ Dataintegritet håndheves bare i utløsere i stedet for valideringsregler (utløservalidering mindre effektiv og mer kompleks) |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Apex | ✅ Utløserbehandlingsrammeverk håndhever enkeltutløser per objekt, masseutføring, adskillelse av bekymringer og forhindring av rekursiv utførelse |
| Plattform | Apex | ✅ Utløserbehandlere delegeres til serviceklasser for forretningslogikk ved å opprettholde tydelig adskillelse av bekymringer |
| Plattform | Apex | ✅ Utløsere bruker rekursjonsbeskyttelse med statiske flagg eller en dedikert rekursjonskontrollklasse |
| Plattform | Apex | ✅ Fremtidig Apex brukes sparsomt, for oppkall eller systemobjekt DML |
| Plattform | Apex | ✅ Asynkrone Apex bruker Købar til “kjede”-komplekse DML på tvers av transaksjoner |
| Plattform | Apex | ✅ Batch Apex brukes til store datavolumer (behandler store mengder data med dedikerte styringsgrenser per bit) |
| Plattform | Apex | ✅ Gruppejobber har feilhåndtering som logger mislykkede poster uten å stoppe hele gruppeutførelsen |
| Plattform | Apex | ✅ Bulk API brukes bare når store mengder data må behandles (innebygde SOAP- og REST-APIer brukes til mindre mengder data) |
| Plattform | Apex | ✅ Købar Apex brukes til kompleks arbeidsflytorkestrering, eksterne oppkall med forsøkslogikk og behandling som drar nytte av asynkrone grenser |
| Plattform | Apex | ✅ Planlagt Apex utfører behandling etter faste tidsplaner for nattlig vedlikehold, daglig rapportering, periodisk integrasjonssynkronisering og tidsbaserte forretningsregler |
| Plattform | Utformingsstandarder | ✅ Bruksområder for synkrone og asynkrone operasjoner i automatiseringer skisseres tydelig som en del av utformingsstandarder |
| Plattform | Dokumentasjon | ✅ Planlagte og potensielle utførelsesbaner for automatiseringer skisseres tydelig |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Apex | ⚡️ Flere utløsere på ett objekt med uforutsigbar utførelsesrekkefølge og overlappende logikk |
| Plattform | Apex | ⚡️ Forretningslogikk innebygd direkte i utløserfiler som gjør testing vanskelig |
| Plattform | Apex | ⚡️ Ingen utløserbehandlingsrammeverk eller inkonsekvente utløsermønstre på tvers av objekter |
| Plattform | Apex | ⚡️ Apex har svært liten omfangsstørrelse (for eksempel omfangsstørrelse = 1) |
| Plattform | Apex | ⚡️ Batch Apex brukt til eksterne oppkall (stort antall Salesforce-data overført til eksternt system med batch Apex) |
| Plattform | Apex | ⚡️ Asynkrone Apex som brukes vilkårlig (Future-metoder og Apex som kan legges i kø, brukes inkonsistent eller om hverandre) |
| Plattform | Apex | ⚡️ Asynkron Apex brukt sjelden |
| Plattform | Apex | ⚡️ Databaseoperasjoner har ikke klar, konsistent logikk for overføring av utførelse til batch Apex når det er nødvendig |
| Plattform | Utformingsstandarder | ⚡️ Bruksområder for synkrone og asynkrone operasjoner håndteres ikke |
| Plattform | Dokumentasjon | ⚡️ Automatiseringsoppkall er ikke dokumentert |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Plattformhendelser | ✅ Plattformhendelser brukes til hendelsesdrevet automatisering som kobler utgivere fra abonnenter |
| Plattform | Plattformhendelser | ✅ Utgivere er ikke klar over abonnenter og publiserer fire-and-forget |
| Plattform | Plattformhendelser | ✅ Flere abonnenter reagerer uavhengig på hendelser via plattformhendelsesutløste flyter, Apex eller eksterne integrasjoner |
| Plattform | Plattformhendelser | ✅ Avspilling-IDer brukes til å gjengi manglende hendelser fra hvilket som helst punkt i 72-timers oppbevaringsvinduet |
| Plattform | Plattformhendelser | ✅ Plattformhendelser aktiverer kommunikasjon på tvers av organisasjoner, varsling av eksterne systemer og intern arbeidsflytorkestrering |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Plattformhendelser | ⚡️ Direkte kobling mellom utgivere og abonnenter som hindrer komposerbar automatisering |
| Plattform | Plattformhendelser | ⚡️ Kontonivåoppgradering kaller direkte oppdatering av salgsmuligheter, varsler om kontoteam og datalagersynkronisering i én transaksjon (tett kobling krever endringer i kontologikken hver gang ny nedstrøms behandling er nødvendig) |
| Plattform | Apex | ⚡️ Publiser umiddelbart plattformhendelser brukt adhoc (sanntidshendelser brukt i stedet for Publiser etter bekreftelse uavhengig av publiseringskrav eller postlåserisiko) |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Apex | ✅ SOQL-setninger bruker positive logikk sammenligningsoperatorer (INCLUDES, IN) som primær eller eneste logikk |
| Plattform | Apex | ✅ SOQL unngår = NULL, != NULL eller bruker dem sparsomt etter positive sammenligningsoperatorer |
| Plattform | Apex | ✅ SOQL bruker ikke LIMIT 1-setninger |
| Plattform | Apex | ✅ SOQL bruker ikke ALL ROWS-nøkkelord |
| Plattform | Apex | ✅ SOQL vises ikke i sløyfer |
| Plattform | Apex | ✅ Jokertegnkriterier vises i SOSL (ikke SOQL) |
| Plattform | Apex | ✅ SOQL-setninger unngå LIKE sammenligninger eller delvise tekst sammenligninger |
| Plattform | Apex | ✅ SOQL er pakket inn i try-catch blokker |
| Plattform | Apex | ✅ Variabler refererer ikke til hardkodede verdier (for posttyper, brukere osv.) |
| Plattform | Apex | ✅ Hver klasse har ett bestemt formål |
| Plattform | Apex | ✅ Hver metode utfører en spesifikk, detaljert oppgave |
| Plattform | Apex | ✅ Alle inndatavariabler har et tydelig formål i klassen |
| Plattform | Apex | ✅ Kodeutføring krever et minimum antall ressurser |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Apex | SOQL-setninger bruker NOT, NOT IN-kriterier som primær eller eneste sammenligningsoperator (ikke-selektiv) |
| Plattform | Apex | ⚡️ SOQL-setninger bruker ALL ROWS nøkkelord (ikke-selektiv) |
| Plattform | Apex | SOQL-setninger bruker = NULL, != NULL-kriterier som primær eller eneste sammenligningsoperator (ikke-selektiv) |
| Plattform | Apex | ⚡️ Variabler har hardkodede verdier |
| Plattform | Apex | ⚡️ SOQL vises i sløyfer |
| Plattform | Apex | SOQL-setninger bruker ofte LIKE- og jokertegnfilterkriterier (ikke-selektiv) |
| Plattform | Apex | ⚡️ SOQL ikke pakket inn i try-catch blokker |
| Plattform | Apex | ⚡️ SOQL-setninger bruker LIMIT 1 (ikke-selektiv) |
| Plattform | Apex | ⚡️ SOSL brukes sjelden eller ikke konsekvent til jokertegnvalgskriterier |
| Plattform | Apex | ⚡️ Klasser har flere formål |
| Plattform | Apex | ⚡️ Metoder utfører flere oppgaver, eller metoder utfører oppgaver som ikke er i samsvar med det angitte formålet for klassen de er del av |
| Plattform | Apex | ⚡️ Inndatavariabler brukes faktisk ikke i metoder |
| Plattform | Apex | ⚡️ Metoder som unødvendig henter data fra databasen eller fra eksterne systemer |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Apex | ✅ Tilpassede unntak brukes til å opprette avanserte feilmeldinger og logikk |
| Plattform | Apex | ✅ Kode slår sammen alle DML, SOQL, oppkall og andre viktige prosesstrinn i try-catch blokker |
| Plattform | Apex | ✅ Databaseklassemetoder kan brukes eksklusivt for alle dataoperasjoner (i stedet for DML) |
| Plattform | Apex | ✅ I asynkrone og gruppekontekster brukes Database-klassemetoder i stedet for DML |
| Plattform | Aura | ✅ JavaScript pakker alle dataoperasjoner og viktige prosesstrinn i try-catch blokker |
| Plattform | Aura | ✅ Innenfor try-catch blokker brukes innebygd JavaScript Error i kastsetninger (ingen bruk av $A.error()) |
| Plattform | Aura | ✅ All gjenopprettingsfeillogikk vises i catch og gir tydelige brukermeldinger |
| Plattform | Flyt | ✅ Flyter med dataoperasjoner, oppkall og annen viktig behandlingslogikk har feilbaner for alle viktige handlinger |
| Plattform | Flyt | ✅ Skjermflyter bruker konsekvent feilkoblinger til å vise feil til brukere |
| Plattform | Flyt | ✅ Tilpassede feilmeldinger konfigureres for feil som vises på skjermen |
| Plattform | Lightning Web Components (LWC) | ✅ JavaScript avslutter alle dataoperasjoner og viktige prosesstrinn i if ()/else if () blokker |
| Plattform | Lightning Web Components (LWC) | ✅ Alle @wire-funksjoner bruker data og error-egenskaper fra APIen |
| Plattform | Lightning Web Components (LWC) | ✅ Alle if (error)/else if (error)-setninger inneholder logikk for å behandle feil og gi informative meldinger |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Apex | ⚡️ DML, SOQL, oppkall eller andre viktige prosesstrinn ikke konsekvent pakket inn i prøve-fangstblokker |
| Plattform | Apex | ⚡️ Ingen databaseklassemetoder brukes |
| Plattform | Apex | ⚡️ Dataoperasjoner utført eksklusivt med DML |
| Plattform | Apex | ⚡️ System.debug vises i produksjonskode (og blir ikke kommentert) |
| Plattform | Aura | JavaScript pakker ikke dataoperasjoner og viktige prosesstrinn konsekvent inn i try-catch blokker |
| Plattform | Aura | ⚡️ Komponenter bruker $A.error() |
| Plattform | Aura | ⚡️ Gjenopprettbar feillogikk vises ikke konsekvent i catch, og feilmeldinger til brukere er ikke klare |
| Plattform | Flyt | ⚡️ Flyter bruker ikke feilbaner konsistent eller i det hele tatt |
| Plattform | Flyt | ⚡️ Tilpassede feilmeldinger brukes ikke, så brukere ser standardmeldingen “En ubehandlet feil har skjedd i denne flyten” |
| Plattform | Lightning Web Components (LWC) | ⚡️ @wire-funksjoner bruker ikke data og error-egenskaper fra API (eller bruker dem ikke konsekvent) |
| Plattform | Lightning Web Components (LWC) | ⚡️ Hvis det brukes, inneholder ikke if (error)/else if (error)-setninger logikk for å behandle feil og gi nyttige feilmeldinger |
| Plattform | Lightning Web Components (LWC) | JavaScript bruker ikke konsekvent if ()/else if () blokker med dataoperasjoner eller kritiske prosesstrinn |