Operativ förträfflighet - Automatiseringsmönster
Få reda på mer om välutformad operativ excellens → Automatisering och effektivitet
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Instrumentpaneler | ✅ Alla mått relaterade till nyckeltal inkluderas i minst en instrumentpanel |
| Plattform | Dokumentation | ✅ Utdata för varje automatisering är mätbara och tidsbundna |
| Plattform | Dokumentation | ✅ Ansvariga intressenter listas för varje nyckeltal |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Instrumentpaneler | ️ Nyckeltalsrapportering finns inte eller instrumentpaneler saknar mått relaterade till vissa nyckeltal |
| Plattform | Dokumentation | ️ Nyckeltal finns utan ansvariga intressenter |
| Plattform | Dokumentation | ⚠️ Nyckeltal finns inte för automatisering eller har oklara tidsramar för mätningar |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Flöde | ✅ Flow Builder används för postutlöst automatisering (ersätter Process Builder och arbetsflödesregler) |
| Plattform | Flöde | ✅ Postutlösta flöden med innan sparande används för fältpopulation innan postskapande |
| Plattform | Flöde | ✅ Flöden hanterar beslutslogik, loopar, API-anrop, DML-operationer och komplex orkestrering i flera steg |
| Plattform | Flöde | ✅ Flödestransaktionskontroll används för att utföra mellanliggande ändringar vid behov |
| Plattform | Flöde | ✅ Felhantering implementeras för elegant felåterställning i flöden |
| Plattform | Flöde | ✅ Reaktiva skärmflöden ger dynamiska användarupplevelser |
| Plattform | Flöde | ✅ Deklarativ automatisering väljs när företagsanvändare eller administratörer behöver ändra logik utan utvecklarens inblandning |
| Plattform | Flöde | ✅ Variabler refererar inte till hårdkodade värden (för posttyper, användare, etc.) |
| Plattform | Flöde | ✅ Flöder handlogik till Apex i sammanhang med stora datavolymer |
| Plattform | Flöde | ✅ Underflöden används för sektioner av processer som behöver återanvändas i hela verksamheten |
| Plattform | Flöde | ✅ Alla autostartade flöden använder beslut och / eller pauselement för att utvärdera inmatningskriterier och förhindra oändliga loopar eller körningar mot stora datavolymer |
| Plattform | Flöde | ✅ Användare ombes endast tillhandahålla data när befintliga systemdata inte kan användas |
| Plattform | Flöde | ✅ Flöden är organiserade i en hierarkisk struktur som består av ett huvudflöde och stödjande underflöden |
| Plattform | Flöde | ✅ Alla användarinmatningar har ett tydligt syfte inom flödet |
| Plattform | Flöde | ✅ Varje flöde tjänar ett enskilt, specifikt syfte |
| Plattform | Flöde | ✅ Varje steg utför en specifik, detaljerad uppgift |
| Plattform | Flöde | ✅ Alla flöden som startas i användarsammanhang abstrakta systemsammanhang transaktioner till underflöden, konsekvent placerade efter pauselement för att skapa ny transaktion |
| Plattform | Flöde | ✅ Alla postutlösta flöden har utlösarordervärden ifyllda |
| Plattform | Flöde | ✅ Flöden som involverar externa systemanrop eller processer som körs länge använder asynkrona vägar |
| Plattform | Flöde | ✅ Komplexa sekvenser av relaterade dataoperationer skapas med Orchestrator (istället för att åberopa flera underflöden inom monolitiska flöden) |
| Plattform | Validering | ✅ Dataintegritet upprätthålls på plattformsnivå med valideringsregler, dubblettregler och obligatoriska fält |
| Plattform | Validering | ✅ Valideringsregler förhindrar ogiltig datainmatning innan sparande (effektivare än utlösarvalidering) |
| Plattform | Godkännandeprocesser | ✅ Flerstegs godkännandedirigering hanterar parallella och sekventiella godkännandevägar med delegerade godkännare |
| Plattform | Godkännandeprocesser | ✅ Godkännande arkitektur tar hänsyn till undantagsscenarion (alla godkännare på semester, brådskande verksamhetskrav kringgår normalt godkännande) |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Flöde | ⚠️ Processbyggare och arbetsflödesregler som används för ny automatisering (Flow Builder är den strategiska riktningen) |
| Plattform | Flöde | ⚠️ Programmatisk automatisering som används när företagsanvändare eller administratörer behöver ändra logik utan utvecklarens inblandning |
| Plattform | Flöde | ⚠️ Flöden saknar felhantering vilket resulterar i dålig felåterställning |
| Plattform | Flöde | ⚠️ Variabler har hårdkodade värden |
| Plattform | Flöde | ⚠️ Flöden måste inaktiveras manuellt innan massdata läses in |
| Plattform | Flöde | ⚠️ Delar av ett flöde upprepas över flöden istället för att använda underflöden |
| Plattform | Flöde | ⚠️ Flöden utlöser meddelanden om “ohanterade undantag” |
| Plattform | Flöde | ⚠️ Även enkla flöden orsakar ofta fel relaterade till styrande gränser |
| Plattform | Flöde | ⚠️ Flöden kräver ytterligare inmatningar för att ge sammanhang |
| Plattform | Flöde | ⚠️ Flöden har flera syften |
| Plattform | Flöde | ⚠️ Grupper av relaterade steg innehåller funktionalitet som överlappar grupper av steg i andra flöden |
| Plattform | Flöde | ⚠️ Flöden ber om användarinmatningar när lagrade data kan användas istället |
| Plattform | Flöde | ⚠️ Flöden kräver indata vars data inte används |
| Plattform | Flöde | ⚠️ Utföra DML med hjälp av samling som matas ut från skärmkomponenten (med hjälp av inställningen “Använd ID:n och alla fältvärden från en post eller postsamling” för att skapa, uppdatera eller ta bort element när samlingen matas ut från skärmkomponenten) |
| Plattform | Flöde | ⚠️ Postutlösta flöden använder inte utlösarorderattribut alls eller använder inte utlösarordervärden konsekvent |
| Plattform | Flöde | ⚠️ Asynkrona vägar används inte enhetligt eller alls |
| Plattform | Flöde | ⚠️ Stora monolitiska flöden försöker koordinera komplexa sekvenser av relaterade dataoperationer (med eller utan underflöden) |
| Plattform | Godkännandeprocesser | ⚠️ Godkännandearkitektur tar inte hänsyn till undantagsscenarion (alla godkännare på semester, brådskande verksamhetskrav) |
| Plattform | Validering | ⚠️ Dataintegritet tillämpas endast i utlösare istället för valideringsregler (validering av utlösare är mindre effektiv och mer komplex) |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Apex | ✅ Utlösarhanterarramverk tillämpar enskild utlösare per objekt, buntning, separation av problem och rekursivt utförandeförebyggande |
| Plattform | Apex | ✅ Utlösare delegera till serviceklasser för verksamhetslogik, upprätthålla tydlig separation av problem |
| Plattform | Apex | ✅ Utlösare använder rekursionsskydd med statiska flaggor eller dedikerad rekursionskontrollklass |
| Plattform | Apex | ✅ Future Apex används sparsamt, för anrop eller systemobjekt DML |
| Plattform | Apex | ✅ Asynkrona Apex åberopningar använder kö för att “kedja” komplex DML över transaktioner |
| Plattform | Apex | ✅ Batch Apex används för stora datavolymer (bearbetar stora mängder data med dedikerade styrande gränser per bit) |
| Plattform | Apex | ✅ Batchjobb har felhantering som loggar misslyckade poster utan att stoppa hela batchkörningen |
| Plattform | Apex | ✅ Bulk API används endast när stora mängder data måste bearbetas (inbyggda SOAP och REST API:n utnyttjas för mindre mängder data) |
| Plattform | Apex | ✅ Köbar Apex används för komplexa arbetsflöden orkestrering, externa anrop med återförsök logik och bearbetning som drar nytta av asynkrona gränser |
| Plattform | Apex | ✅ Schemalagda Apex utför bearbetning på fasta scheman för nattligt underhåll, daglig rapportering, periodisk integreringssynkronisering och tidsbaserade verksamhetsregler |
| Plattform | Designstandarder | ✅ Användningsfall för synkrona och asynkrona operationer inom automatisering beskrivs tydligt som en del av designstandarder |
| Plattform | Dokumentation | ✅ Planerade och potentiella körningsvägar för automatisering är tydligt angivna |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Apex | ⚠️ Flera utlösare på ett objekt med oförutsägbar utförandeordning och överlappande logik |
| Plattform | Apex | ⚠️ Affärslogik inbäddad direkt i utlösarfiler vilket gör tester svåra |
| Plattform | Apex | ⚠️ Inget utlösarhanterarramverk eller inkonsekventa utlösarmönster över objekt |
| Plattform | Apex | ⚠️ Batch Apex jobb har mycket liten omfattning (t.ex. omfattningsstorlek = 1) |
| Plattform | Apex | ⚠️ Batch Apex används för externa anrop (stora volymer Salesforce-data pushade till externt system med hjälp av Batch Apex) |
| Plattform | Apex | ⚠️ Asynkrona Apex funktioner används godtyckligt (Future Methods and Queueable Apex används inkonsekvent eller utbytbart) |
| Plattform | Apex | ⚠️ Asynkrona Apex används sällan |
| Plattform | Apex | ⚠️ Databasoperationer har inte tydlig, konsekvent logik för att skicka körning till Apex i sats vid behov |
| Plattform | Designstandarder | ⚠️ Användningsfall för synkrona och asynkrona operationer tas inte upp |
| Plattform | Dokumentation | ⚠️ Automatiseringsanrop dokumenteras inte |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Plattformshändelser | ✅ Plattformshändelser används för händelsedriven automatisering som frikopplar utgivare från prenumeranter |
| Plattform | Plattformshändelser | ✅ Utgivare är omedvetna om prenumeranter och publicera fire-and-forget |
| Plattform | Plattformshändelser | ✅ Flera prenumeranter reagerar oberoende på händelser genom plattformshändelseutlösta flöden, Apex utlösare eller externa integreringar |
| Plattform | Plattformshändelser | ✅ Repris-ID:n används för att spela upp missade händelser från vilken punkt som helst i lagringsfönstret på 72 timmar |
| Plattform | Plattformshändelser | ✅ Plattformshändelser möjliggör korsorganisationskommunikation, externa systemnotiser och intern arbetsflödesorkestrering |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Plattformshändelser | ⚠️ Direktkoppling mellan utgivare och prenumeranter som förhindrar komponerbar automatisering |
| Plattform | Plattformshändelser | ⚠️ Uppgradering av kontonivå anropar direkt säljprojektuppdatering, notis om kontoteam och datalagersynkronisering i en transaktion (tät koppling kräver ändringar av kontologik varje gång ny bearbetning längre ner behövs) |
| Plattform | Apex | ⚠️ Publicera omedelbart plattformshändelser används ad hoc (realtidshändelser används istället för Publicera efter åtagande oavsett publiceringsorderkrav eller risker för låsning av poster) |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Apex | ✅ SOQL-uttryck använder positiva logikjämförelseoperatorer (INCLUDES, IN) som primär eller endast logik |
| Plattform | Apex | ✅ SOQL undviker = NULL, != NULL eller använder dem sparsamt efter positiva jämförelseoperatorer |
| Plattform | Apex | ✅ SOQL använder inte LIMIT 1 |
| Plattform | Apex | ✅ SOQL använder inte nyckelordet ALL ROWS |
| Plattform | Apex | ✅ SOQL visas inte inom loopar |
| Plattform | Apex | ✅ Jokertecken kriterier visas i SOSL (inte SOQL) |
| Plattform | Apex | ✅ SOQL-uttryck undviker LIKE eller delvisa textjämförelser |
| Plattform | Apex | ✅ SOQL är insvept i try-catch |
| Plattform | Apex | ✅ Variabler refererar inte till hårdkodade värden (för posttyper, användare, etc.) |
| Plattform | Apex | ✅ Varje klass tjänar ett enskilt, specifikt syfte |
| Plattform | Apex | ✅ Varje metod utför en specifik, detaljerad uppgift |
| Plattform | Apex | ✅ Alla indatavariabler har ett tydligt syfte inom klassen |
| Plattform | Apex | ✅ Kodkörning kräver ett minimalt antal resurser |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Apex | ⚠️ SOQL-uttryck använder NOT, NOT IN som primär eller endast jämförelseoperator (icke-selektiv) |
| Plattform | Apex | ⚠️ SOQL-uttryck använder nyckelordet ALL ROWS (icke-selektivt) |
| Plattform | Apex | ⚠️ SOQL-uttryck använder = NULL, != NULL som primär eller endast jämförelseoperator (icke-selektiv) |
| Plattform | Apex | ⚠️ Variabler har hårdkodade värden |
| Plattform | Apex | ⚠️ SOQL visas inom loopar |
| Plattform | Apex | ️ SOQL-uttryck använder filterkriterier för LIKE och jokertecken ofta (icke-selektiva) |
| Plattform | Apex | ⚠️ SOQL inte inslagen i try-catch |
| Plattform | Apex | ⚠️ SOQL-uttryck använder LIMIT 1 (icke-selektiv) |
| Plattform | Apex | ⚠️ SOSL används sällan eller inte konsekvent för urvalskriterier för jokertecken |
| Plattform | Apex | ⚠️ Klasser har flera syften |
| Plattform | Apex | ⚠️ Metoder utför flera uppgifter eller metoder utför uppgifter som inte överensstämmer med det angivna syftet för klassen de är en del av |
| Plattform | Apex | ⚠️ Indatavariabler används inte i metoder |
| Plattform | Apex | ⚠️ Metoder som i onödan hämtar data från databasen eller från externa system |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Apex | ✅ Egna undantag används för att skapa avancerade felmeddelanden och logik |
| Plattform | Apex | ✅ Kod omger alla DML, SOQL, anrop och andra viktiga processteg i try-catch |
| Plattform | Apex | ✅ Databasklassmetoder kan endast användas för alla dataoperationer (istället för DML) |
| Plattform | Apex | ✅ I asynkrona och masssammanhang används databasklassmetoder istället för DML |
| Plattform | Aura | ✅ JavaScript omger alla dataoperationer och viktiga processteg i try-catch |
| Plattform | Aura | ✅ Inom try-catch används inbyggd JavaScript Error i utkastuttryck (ingen användning av $A.error()) |
| Plattform | Aura | ✅ Alla återställningsbara fellogik visas i catch och ger tydliga användarmeddelanden |
| Plattform | Flöde | ✅ Flöden med dataoperationer, anrop och annan viktig bearbetningslogik har felvägar för alla nyckelåtgärder |
| Plattform | Flöde | ✅ Skärmflöden använder konsekvent felanslutare för att visa fel för användare |
| Plattform | Flöde | ✅ Egna felmeddelanden är konfigurerade för fel som visas på skärmen |
| Plattform | Lightning webbkomponenter (LWC) | ✅ JavaScript omger alla dataoperationer och viktiga processteg i if () /else if () block |
| Plattform | Lightning webbkomponenter (LWC) | ✅ Alla @wire använder data och error som tillhandahålls av API |
| Plattform | Lightning webbkomponenter (LWC) | ✅ Alla if (error) /else if (error) uttalanden innehåller logik för att bearbeta fel och ge informativa meddelanden |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Apex | ⚠️ DML, SOQL, anrop eller andra viktiga processteg som inte är konsekvent inbäddade i försöksfångstblock |
| Plattform | Apex | ⚠️ Inga databasklassmetoder används |
| Plattform | Apex | ⚠️ Dataoperationer som utförs uteslutande med DML |
| Plattform | Apex | ⚠️ System.debug visas i produktionskoden (och kommenteras inte) |
| Plattform | Aura | ⚠️ JavaScript omger inte konsekvent dataoperationer och viktiga processteg i try-catch |
| Plattform | Aura | ⚠️ Komponenter använder $A.error() |
| Plattform | Aura | ⚠️ Logik för återställningsbara fel visas inte konsekvent i catch och felmeddelanden till användare är inte tydliga |
| Plattform | Flöde | ⚠️ Flöden använder inte felvägar konsekvent eller alls |
| Plattform | Flöde | ⚠️ Egna felmeddelanden används inte, så användare ser standardmeddelandet “Ett ohanterat fel har inträffat i detta flöde” |
| Plattform | Lightning webbkomponenter (LWC) | ⚠️ @wire använder inte data och error som tillhandahålls av API (eller använder dem inte konsekvent) |
| Plattform | Lightning webbkomponenter (LWC) | ⚠️ Om det används alls innehåller if (error)/else if (error) inte logik för att bearbeta fel och ger användbara felmeddelanden |
| Plattform | Lightning webbkomponenter (LWC) | ⚠️ JavaScript använder inte if ()ellerelse if () blockerar konsekvent dataoperationer eller viktiga processteg |