Operasjonell ekspertise

Gode Salesforce-løsninger bygges ikke én gang, de forbedres kontinuerlig. Bygg inn god drift i systemene dine ved å overvåke hvordan løsningene gjør det og avgrense hvordan de fungerer, slik at de leverer forretningsverdi på forutsigbar måte og gjenopprettes raskt når noe brytes.

Forsømmelse av operasjonell dyktighet har forutsigbare konsekvenser for løsninger. Manuelle distribusjonsprosesser blir flaskehalser som reduserer leveringen av funksjoner og øker feilrisikoen. Utilstrekkelig overvåking forsinker oppdagelsen av hendelser til brukerne rapporterer problemer, noe som forlenger varigheten av påvirkningen og undergraver Trust. Manglende automatisering krever at driftsteam vokser proporsjonalt med løsningens kompleksitet, slik at det opprettes uholdbare kostnadsbaner. En dårlig overvåket gruppejobb som mislykkes, kan ødelegge data eller nedstrøms prosesser før noen merker seg det.

Løsninger som er utformet for å oppnå god drift, gir team mulighet til å observere systemvirkemåten gjennom omfattende overvåking, distribuere endringer sikkert ved bruk av automatiserte pipelines, reagere effektivt på hendelser med forhåndsdefinerte prosedyrer og lære fra driftsopplevelsen gjennom uskyldige gjennomganger. Disse funksjonene sammensettes over tid. Team som investerer tidlig i operasjonelle grunnlag, leverer funksjoner raskere og mer pålitelig enn team som utsetter operasjonelle bekymringer til produksjonsproblemer tvinger reaksjonær investering.

Operasjonell ekspertise kobler direkte til andre arkitektoniske stolper. Pålitelighet avhenger av overvåking som oppdager feil og automatisering som muliggjør rask gjenoppretting. Trust krever sikre livssyklusrutiner for utvikling og revisjonsspor for driftsendringer. Ressursoptimalisering drar nytte av kontinuerlig forbedring informert av operasjonell telemetri. Kostnadsoptimalisering krever distribusjonseffektivitet og automatisering som hindrer vekst av driftskostnader. Sammen skaper disse stolpene løsninger som gir kontinuerlig forretningsverdi med bærekraftige driftsinvesteringer.

Salesforce driver infrastrukturen – serverne, databasen, kjøretiden og nettverket. Det du driver, er alt som bygges på toppen av den – metadataene som definerer løsningen, konfigurasjonen som styrer virkemåten, dataene som flyter gjennom den, integrasjonene som kobler den sammen, og agentene som handler i den.

Denne ansvarsdelingen former alle driftsbeslutninger du tar. Salesforce sikrer at plattformen er tilgjengelig, ytelsesrik og sikker, men du må utforme løsninger som kan observeres, distribueres, automatiseres og gjenopprettes. Plattformens flerleietagerarkitektur betyr at driftsproblemer i løsningen kan utløse styringsgrenser som mislykkes i individuelle transaksjoner, og radlåser eller ressurskonflikter som kaskaderer på tvers av organisasjonen. Du kan ikke holde oversikt over observabilitet, distribusjonssikkerhet eller hendelsesklargjøring etter at det har skjedd, uten ekstra innsats eller omarbeid.

I denne veiledningen lærer du hvordan du utformer og implementerer driftspraksisene – overvåking, distribusjonsautomatisering, hendelsessvar og kontinuerlig forbedring – som gjør Salesforce-løsninger til pålitelige, bærekraftige systemer.

Bruk disse prinsippene til å lede dine arkitektoniske beslutninger for å oppnå god drift på plattformen.

• Evolver med observasjon. Utform omfattende observabilitet fra den første versjonen i stedet for å tilpasse instrumenteringen på nytt etter at problemer har dukket opp. Observable systemer avdekker hvordan de faktisk oppfører seg under virkelige forhold, og aktiverer datastyrte arkitektoniske forbedringer og rask problemdiagnose. Observabilitet er et arkitektonisk problem som former løsningsutformingen fra begynnelsen av – instrumenterings-, overvåkings- og telemetrisamlingsbeslutninger påvirker datamodeller, integrasjonsmønstre og komponentgrenser.

• Standardiser driftsprosedyrer. Versjonskonfigurasjon og driftsprosedyrer i kildekontroll sammen med programkode. Kodede operasjoner aktiverer automatiserte Salesforce DX, Sandbox-oppdateringsautomatisering og metadatadistribusjoner som utføres konsistent på tvers av miljøer. Tribal Knowledge om organisasjonskonfigurasjon blir til kjørbare skript som alle teammedlemmer kan kjøre. Når prosedyrer leveres i versjonskontroll, utvikles de gjennom de samme gjennomgangs- og forbedringssyklusene som programfunksjoner, og oppretter gjentagbare operasjonsmønstre som reduserer konfigurasjonsavviket betydelig. Implementer et ekspertisenter.

• Omfavne en DevOps-kultur. Dele opp organisasjonsenheter mellom utvikling, drift og forretningsteam. Delt ansvar for løsningsresultater erstatter å kaste arbeid over vegger. DevOps-kultur reduserer friksjon, akselererer tilbakemeldingsløyfer og skaper ansvar for driftsinnvirkning. Arkitekter aktiverer DevOps gjennom teknologivalg som støtter samarbeid, og gjennom organisasjonsforsvar som fjerner strukturelle barrierer for delt ansvar.

• Automatiser for effektivitet. Automatiser gjentagende operative oppgaver for å eliminere manuelt arbeid, redusere menneskelige feil og muliggjøre skalering av operasjoner samtidig som du optimaliserer kostnad og ressursbruk. Vanlige manuelle operasjoner er gode kandidater for automatisering. Måle automatiseringsverdi gjennom lagrede timer, feilreduksjon og opprettede driftskapasiteter.

• Lær av alle operasjonelle hendelser. Trekk ut organisasjonslæring fra hendelser, ytelsesavvik, nesten feil og vellykkede operasjoner. Skamløse postmortems fokuserer på systemforbedringer i stedet for individuell feil, og skaper psykologisk sikkerhet for ærlig vurdering. Operasjonell telemetri viser mønstre på tvers av hendelser som muliggjør proaktiv forebygging. Læringskultur omformer operasjonell opplevelse til organisasjonsegenskaper som sammensettes over tid.

Å forstå hva Salesforce driver hjelper deg med å fokusere driftsutformingsarbeidet på det du kontrollerer. Plattformen håndterer infrastrukturproblemer som krever dedikerte team i tradisjonelle IT-miljøer:

• Infrastrukturens pålitelighet og ytelse: Salesforce overvåker og vedlikeholder serverkapasitet, databaseytelse, nettverkstilgjengelighet og lagringssystemer for alle forekomster. Plattformstatusen vises på status.salesforce.com med hendelsesoppdateringer i sanntid og planlagte vedlikeholdsvinduer.
• Plattformoppdateringer og -oppdateringer: Tre hovedutgivelser per år (Vår, Sommer og Vinter) leverer nye funksjoner, sikkerhetsoppdateringer og ytelsesforbedringer. Salesforce administrerer utgivelsestid, API-versjonsstøtte og -forhindring og endringsbehandling for endringer på plattformnivå. Du tester løsningen mot utgivelser i Sandbox-miljøer før produksjonsdistribusjon.
• Forvaltning av ressurser for flere leietagere: Styringsgrenser finnes for å holde den delte infrastrukturen rettferdig – fordi du kjører på de samme ressursene som andre kunder, håndhever Salesforce takster på ting som CPU-tid, heap-størrelse, SOQL-spørringer (Salesforce Object Query Language), DML-setninger (Data Manipulation Language) og API-kall slik at ingen enkelt leietager kan overforbruke kapasitet. Salesforce sporer generell bruk og lar kunder be om høyere tildelinger for enkelte grenser (som API-kall) via lisensieringsnivåer, men selve Apex per transaksjon er faste og håndheves på samme måte for alle.
• Kjerneplattformsikkerhetsoperasjoner: Salesforce-sikkerhetsteam overvåker trusler, behandler visning og patching av sårbarheter, vedlikeholder sikkerhetssertifiseringer og svarer på sikkerhetshendelser på plattformnivå. Denne grunnleggende sikkerheten oppretter grunnlinjen som du bygger løsningsspesifikke sikkerhetskontroller på.
• Katastrofer og forretningskontinuitet: Salesforce vedlikeholder geografisk distribuerte datasentre, tester prosedyrer for katastrofegjenoppretting og vedlikeholder overflødige systemer som aktiverer feiloverføring uten kundehandling. Gjenoppretting på plattformnivå skjer gjennomsiktig under infrastrukturfeil.

Disse plattformoperasjonene lager grunnlaget som du bygger på. Du klargjør ikke servere, patchdatabaser eller utformer katastrofegjenoppretting for infrastruktur. Du forblir imidlertid ansvarlig for alt du bygger og konfigurerer på toppen av dette grunnlaget.

Delt ansvarsmodell betyr at du eier operasjonell dyktighet for alt du oppretter i Salesforce. Plattformoperasjoner aktiverer arbeidet, men erstatter det ikke. Dine driftsansvar omfatter fem sammenhengende områder:

Observabilitet er muligheten til å forstå den interne systemstatusen fra eksterne utdata. Observable Salesforce-løsninger gir operatorer mulighet til å svare på spørsmål om systemvirkemåte, diagnostisere feil og validere hypoteser uten å distribuere ny instrumentering for hver undersøkelse. Forskjellen mellom overvåking (svar på kjente spørsmål med forhåndsdefinerte kontrollpaneler) og observabilitet (svar på vilkårlige spørsmål med omfattende telemetri) er viktig fordi produksjonssystemer genererer uventede virkemåter som overskrider det du forventet under utformingen.

For Salesforce-løsninger omfatter observabilitet tre komplementære signaltyper tilpasset plattformens modell for flere leietagere:

• Logger - Fang opp diskrete hendelser med full kontekstinformasjon. Hendelsesovervåking gir hendelsesloggfiler som fanger opp API-kall, påloggingshendelser, Apex, SOQL-spørringer, Visualforce, Lightning og rapportkjøringer med forespørselskontekst, inkludert brukeridentitet, tidsstempel, varighet og utfall. Logger svarer på spørsmål som "Hvilke brukere opplevde denne feilen?" og "Hva er endret mellom vellykkede og mislykkede utførelser?"
• Målinger - Numeriske målinger samlet over tid som avslører trender og mønstre. Målinger inkluderer API-forbruksrater, Apex CPU-tidsfordelinger, batchjobb suksessrater, integrasjonslatensprosentiler og fullføringsrater for brukerflyter. Målinger besvarer spørsmål som "Er ytelsen nedgang over tid?" og "Nærmer vi oss styringsgrenser?"
• Spor - Vis forespørselsbaner gjennom distribuerte systemer som avslører latenskilder og feilpunkter. For Salesforce-løsninger kan sporer koble synkrone API-kall til asynkrone behandlingskjeder, plattformhendelser til abonnentutførelser og integrasjonsforespørsler til eksterne systemsvar. Sporer svar på spørsmål som "Hvor oppsamles latens i denne flyten?" og "Hvilken komponent mislyktes i denne flertrinnsprosessen?"

Utforming for observabilitet fra den første arkitekturen. Beslutninger om hvilke Hendelsesovervåking-hendelsestyper som skal aktiveres, hvordan plattformhendelsesbelastninger skal struktureres for operasjonell synlighet, hvor integreringssjekkpunkter skal plasseres, og hvilken tilpasset logging som skal implementeres, skaper løsningenes langsiktige operasjonalitet. Tilpassing av observabilitet i eksisterende løsninger krever instrumenteringsendringer som berører de fleste komponenter, og risikerer å introdusere feil under operasjonelt forbedringsarbeid.

Salesforce tilbyr formålsbygde overvåkingsfunksjoner som arkitekter bør utforme fra start av.

Event Monitoring fanger opp detaljerte driftsdata på tvers av organisasjonen. Hendelsestyper inkluderer API-bruk, påloggingsaktivitet, avloggingshendelser, Apex, SOQL-spørringer, Visualforce, Lightning, rapportkjøringer, dokumentvedlegg, innholdsoverføringer og tilpassede hendelser du definerer. Hendelsesovervåking gir grunnlaget for sikkerhetsanalyse, ytelsesoptimalisering, kapasitetsplanlegging og samsvarsrapportering.

Aktiver Hendelsesovervåking for produksjonsmiljøer, og etabler automatisert eksport av hendelsesloggfiler til eksterne aggregeringsplattformer. Innebygd oppbevaring er begrenset for de fleste hendelsestyper, ikke tilstrekkelig for trendanalyse, kapasitetsplanlegging og krav til samsvar. Ekstern aggregering muliggjør historiske analyser, korrelasjon med foretakstelemetri fra andre systemer, avanserte analyser og oppbevaringsperioder som samsvarer med lovpålagte krav.

Proactive Monitoring evaluerer kontinuerlig organisasjonen for ytelses- og skalerbarhetsrisikoer, og varsler om forhåndsdefinerte signaler før de blir brukersynlige hendelser. Proactive Monitoring oppdager mønstre, inkludert API-forespørselsgrenseverdier som nærmer seg daglig tildeling, samtidige Apex som indikerer delt ressurskonflikt, SOQL-radgrenser som nærmer seg styrings terskler, og radlåsekonflikt som foreslår forbedringer i utformingen.

Proactive Monitoring bruker et sett forhåndsdefinerte advarsels- og varselterskler som behandles av Salesforce. For organisasjoner som trenger dypere synlighet av ytelse og ønsker å undersøke grunnlinjer og trender, gir Scale Center detaljert kjøretidsanalyse som dekker CPU-tidsavbrudd, samtidige og radlåser, styringsgrensefeil og databaseytelse.

Data Detect (krever Salesforce Shield) skanner standard og tilpassede objektfelt for å identifisere, kategorisere og rette opp sensitive data – for eksempel personlig identifiserbar informasjon (PII) – i tekst, rik tekst og krypterte felt. Den bruker innebygd plattformbehandling med mønstersamsvar og tilpasset regex for å minimere usanne positive. Kjør gjentakende skanninger (ukentlig eller månedlig) rettet mot nye eller endrede poster, med ekskluderinger for allerede klassifiserte eller forhindrede felt.

Bruk funnene til å fremme nedstrøms styring for å oppdatere samsvarsklassifiseringer, håndheve Shield Platform Encryption, utløse hendelsesovervåking-sikkerhetspolicyer eller bruke Sandbox-datamaskering.

Scale Center gir transaksjonsnivå synlighet til langvarige operasjoner, gjennomløpsmønstre, unntakshotpunkter og styringsgrenseforbruk. Skaleringssenter viser hvilke operasjoner som bruker mest ressurser, hvilke transaksjoner som nærmer seg tidsavbrudds terskler, og hvor optimaliseringsinvesteringer vil gi størst operasjonell innvirkning.

Opprett Scale Center-standarder under løsningsstabilisering og gå tilbake til standarder etter hver hovedutgivelse. Ytelse uten kontekst er vanskelig å tolke. Standard sammenligning avdekker om endringer har forbedret eller redusert ytelsen, som veileder ytterligere optimaliseringsbeslutninger.

• Oppsett Revisjonsspor: sporer konfigurasjonsendringer, inkludert tillatelsesendringer, metadatadistribusjoner, administrative handlinger og oppdateringer av sikkerhetsinnstillinger med oppbevaring i opptil 180 dager som standard. Revisjonsspor for oppsett støtter sikkerhetsundersøkelser, validering av samsvar og hendelses-postmortems ved å avdekke hvem som endret hvilken konfigurasjon og når. Eksporter Revisjonsspor-oppføringer for oppsett for oppbevaring ut over 180 dager når overholdelse eller kontraktsmessige krav krever lengre historiske vinduer.
• Feltrevisjonsspor: (krever Salesforce Shield) sporer historiske feltverdiendringer. Aktiver Feltrevisjonsspor selektivt for felt som inneholder sensitive data, regulerte data som krever endringshistorikk, eller viktige forretningsdata der forståelse av historiske verdier bidrar til operasjoner og samsvarsrapportering.
• Helseundersøkelse: gir automatisk sikkerhetskonfigurasjonsvurdering som sammenligner gjeldende innstillinger med standardanbefalinger for Salesforce-sikkerhet. Planlegg kvartalsvise tilstandssjekksøk og rett opp funn basert på risikoprioritering for miljøet. Ikke alle funn krever rettelse hvis du har kompenserende kontroller eller andre risikotoleranser enn standardanbefalinger, men alle funn fortjener en bevisst gjennomgang.

Plattformovervåking viser tilstanden på organisasjonsnivå, men mangler programspesifikke problemer. Overvåk programtilstanden fra brukerperspektivet ved å instrumentere viktige forretningsreiser:

Definer viktige brukerprosesser basert på forretningseffekten, og overvåk suksessfrekvenser fra slutt til slutt, fullføringstid, avbruddspunkter og feilfrekvenser. Viktige flyter inkluderer vanligvis omsetningsgenererende aktiviteter (innsending av bestillinger, utføring av kontrakter, avslutning av salgsmuligheter), aktiviteter med stor trafikk (brukerpålogging, søkeoperasjoner, postopprettelse) og aktiviteter som kreves for overholdelse (samtykkefangst, innfrielse av registrertes rettigheter, revisjonssensitive arbeidsflyter).

Instrumentprosesser med milepælmarkører som angir start, fullføring, forlatelse og feil i hvert viktig trinn. Varsle når flytsuksessfrekvenser faller under akseptable terskler eller varigheten overskrider latensmål. Overvåking på prosessnivå avdekker problemer som ikke er synlige i overvåking på komponentnivå, fordi en brukerreise som berører flere Apex, flere flyter, tre plattformhendelser og to eksterne integrasjoner, kan mislykkes på hvilket som helst overgangspunkt.

Overvåk integreringstilstanden toveis. Spor utgående samtaler til eksterne systemer for suksessfrekvenser, latens, mønstre for å prøve på nytt og feiltyper. Spor innkommende samtaler fra eksterne systemer for volummønstre, godkjenningsfeil, datavalideringsfeil og behandlingsvarighet. Integrasjonsovervåking avdekker ofte eksterne systemproblemer før operatorene oppdager dem, slik at proaktiv eskalering aktiveres.

Opprett integrasjons-SLA-er med eksterne partnere og overvåk faktisk ytelse mot forpliktet mål. Når det oppstår brudd på tjenestenivåavtale (SLA), skiller telemetri om problemer kommer fra Salesforce, integrasjonslaget, nettverksbanen eller det eksterne systemet. Denne forskjellen er viktig under hendelseseskalering og kontraktsforhandlinger.

Service Level Indicators (SLI-er) er nøye utvalgte målinger som representerer brukeroppfattet kvalitet. Tjenestenivåmål (SLO-er) er målverdier for SLI-er som balanserer brukerforventninger med driftsinvesteringer. For Salesforce-løsninger inkluderer effektive SLI-er:

• Tilgjengelighet: Prosentandelen av tiden løsningen svarer riktig på brukerforespørsler. Mål tilgjengeligheten fra brukerperspektivet, ikke fra infrastrukturperspektivet. En løsning der plattformen er tilgjengelig, men brukere ikke kan logge seg på på grunn av feil konfigurasjon av enkeltpålogging (SSO), er ikke tilgjengelig uavhengig av plattformoppetid.
• Latens: Tiden fra initiering av brukerhandling til synlig svar. Definer latensmål på bestemte prosentiler (p50, p90, p99) i stedet for gjennomsnitt, fordi gjennomsnitt skjuler de forferdelige opplevelsene som lider av de tregere forespørslene. En p99-latens på 8 sekunder betyr at 1 av 100 forespørsler tar mer enn 8 sekunder, noe som kan representere tusenvis av dårlige opplevelser daglig i løsninger med stor trafikk.
• Suksessrate: Prosentandel av operasjoner som er fullført uten brukersynlige feil. Skill mellom brukerårsakte feil (ugyldige inndata, utilstrekkelige tillatelser) og systemårsakte feil (styringsgrensefeil, tidsavbrudd for integrering, ubehandlede unntak). Bare systemårsakte feil teller mot SLO-er med vellykket avlogging.
• Durchput: Volum av operasjoner som er fullført per tidsenhet. Gjennomgang er viktig for gruppebehandling, dataimport, planlagte jobber og masseoperasjoner der oppfyllelse av tidsfrister avhenger av behandlingskapasitet.

Angi enkeltavloggingsavtaler basert på brukerkrav, ikke teknisk funksjonalitet. Spørsmålet er ikke "Hvor raskt kan vi gjøre dette?" men snarere "hvor raskt må dette være for at brukere skal nå målene sine?" Et 200 ms sideinnlastingsmål er meningsløst hvis brukere kan tolerere to sekunder. Omvendt er et to sekunders mål meningsløst hvis brukere avslutter etter 500 ms. Brukerundersøkelse, øktanalyse og forretningskrav gir informasjon om realistiske mål for enkel avlogging.

Overvåk SLI-brennfrekvens for å oppdage når akkumulerte SLO-brudd utløser feilbudsjetter. Feilbudsjetter representerer akseptable feilfrekvenser som balanserer brukeropplevelse med driftsinvesteringer. Når brenngraden overskrider bærekraftige nivåer, stopper du funksjonsarbeidet og fokuserer på pålitelighetsforbedringer til enkel avloggingsavtaler gjenopprettes. Denne disiplinen hindrer det vanlige mønsteret der team ignorerer nedsatt pålitelighet mens de forfølger tidsfrister for funksjoner til katastrofale feil tvinger til hasteavtaler.

Varsler varsler mennesker når automatiserte systemer oppdager problemer som krever menneskelig vurdering eller handling. Effektiv varsling balanserer dekning (oppdagelse av reelle problemer) med presisjon (undgå falske alarmer). Dårlig varsel går enten glipp av hendelser (for få varsler, for høye terskler) eller oppretter varselutmattelse (for mange varsler, for lave terskler) der operatorer lærer å ignorere varsler.

Utform varsler rundt handlingsmuligheter. Hvert varsel bør svare på tre spørsmål:

1. Hva er galt?
2. Hvorfor spiller det noen rolle?
3. Hva skal jeg gjøre?

Varsler som mangler tydelige svar, fører til at operatorer ignorerer dem. Et varsel som for eksempel sier "API-kall har overskredet 80 % av grensen" uten kontekst om hvilket API, hvilken integrasjon eller hvilken handling som skal utføres, gir ikke tilstrekkelig informasjon for svar.

Implementer alvorlighetsnivåer for varsler som samsvarer med operasjonelle eskaleringsprosedyrer:

• Kritiske varsler: angir brukervennlig tjenestegradering som krever umiddelbar respons uavhengig av tidspunkt på dagen. Kritiske varsler-side for ingeniører ved kall. Eksempler inkluderer påloggingsfeil som overskrider den angitte terskelen, omsetningsgenererende flyter under enkeltavlogging (SLO) for tilgjengelighet eller deteksjon av tap av data.
• Advarselsvarsler: angi problemer som vil bli kritiske uten intervensjon, men som ennå ikke påvirker brukere. Advarsler genererer billetter for undersøkelser av åpningstider. Eksempler inkluderer trender for API-forbruk mot daglige grenser, batchjobber som fullføres, men mangler SLA-mål, eller integrasjonsfeil som øker, men fremdeles under feilterskel.
• Informasjonsvarsler: gi bevissthet om operasjonelle endringer uten å kreve handling. Informasjonsvarsler vises i kontrollpaneler for overvåking, men genererer ikke varsler. Eksempler inkluderer vellykkede distribusjoner, planlagt fullføring av vedlikehold eller konfigurasjonsendringer.

Opprett kadensen for varselgjennomgang for å evaluere varselkvalitet og justere terskler basert på faktiske hendelsesmønstre. Spor varseltall, inkludert sann positiv rate (varsler som angir faktiske problemer), usann positiv rate (varsler der det ikke fantes noe problem) og tid til løsning (hvor raskt varsler førte til hendelsesløsning). Høye falske positive verdier indikerer overdreven sensitive terskler som må justeres for å gjenopprette operator Trust.

DevOps-kulturen kombinerer utviklings- og driftsansvar i forente team som eier løsningsutfall fra den første kodeklargjøringen gjennom produksjonsoperasjonen. DevOps muliggjør raskere levering, høyere kvalitet og bedre driftsresultater sammenlignet med tradisjonelle, isolerte organisasjoner der utviklere overfører arbeid til driftsteam som mangler konteksten for å kjøre det effektivt.

Kildedrevet utvikling behandler alle løsningsartefakter – metadata, konfigurasjon, kode, dokumentasjon – som versjonsstyrte kildefiler i stedet for pek-og-klikk-oppsett som bare finnes i organisasjoner. Kildekontroll aktiverer gjentagbare bygg, samarbeidsutvikling, endringssporing og automatiserte distribusjonsledninger.

Salesforce DX tilbyr verktøykjeden for kildedrevet utvikling. Metadata API viser organisasjonskonfigurasjon som XML-filer. Midlertidige organisasjoner tilbyr engangsutviklingsmiljøer som er opprettet fra kildekontroll. CLI-verktøy aktiverer skriptet distribusjon og organisasjonsmanipulering. Versjonskontrollsystemer, inkludert Git, sporer endringer og aktiverer samarbeidsarbeidsflyter.

Strukturer metadata med vilje for å muliggjøre teamsamarbeid. Modulære pakkestrukturer lar team arbeide uavhengig uten sammenslåingskonflikter. Skill delte komponenter (sideoppsett, tillatelsessett og tilpassede felt) fra funksjonsspesifikke komponenter (Apex, flyter og Lightning). Fjern eierskapsgrensene for å hindre kaoset når alle endrer alt.

Kodegjennomgang gir kvalitetskontroll, Knowledge og læringsmuligheter før endringer når produksjonsorganisasjonen. Effektive kodevurderinger balanserer nøyaktighet med hastighet og gir meningsfylt tilbakemelding uten å bli flaskehalser i distribusjonen.

Opprett tydelige gjennomgangskriterier. Gjennomganger ser etter følgende:

• Korrekthet: Gjør koden det den krever?
• Vedlikehold - Kan fremtidige utviklere forstå og endre dette?
• Ydeevne - Skalerer denne tilgangen korrekt?
• Sikkerhet – Er det injeksjonsrisikoer eller omgåelser av tillatelser?
• Konsistens: Samsvarer dette med prosjektmønstre og -standarder?

Uten eksplisitte kriterier blir vurderinger subjektive eller overfladiske.

Krev to godkjenninger for produksjonsbaserte endringer. Godkjenning med én godkjenner oppretter Knowledge og mangler problemer som alternative perspektiver ville fange opp. Kravet om to revisorer fordeler Knowledge, holder busfaktoren over én og fanger opp flere feil. Balansere godkjenningskrav mot teamstørrelse – å kreve tre godkjenninger i et team på fem personer skaper flaskehalser.

Hold henteforespørsler (PR-er) små. PR-er som har hundrevis av endrede linjer, får rask gjennomgang fordi de som gjennomgår, har en overveldende kognitiv belastning. PR-er som endrer én funksjon på 200–400 linjer, får en grundig gjennomgang som fanger opp subtile problemer. Del opp store funksjoner i lesbare biter som leveres inkrementelt.

Automatiser mekaniske kontroller. Kodeformatering, samsvar med navnekonvensjoner, testdekningskrav og statiske analysekontroller bør kjøres automatisk i stedet for å forbruke revisors oppmerksomhet. Gjennomgangere bør fokusere på spørsmål om logikk, utforming og vedlikehold som krever menneskelig vurdering.

Testing gir tillit til at løsninger fungerer riktig og fortsetter å fungere etter hvert som endringer akkumuleres. Effektiv testing balanserer dekning (hvor mye kode- og funksjonalitetstester utføres) med utførelseshastighet (hvor raskt testpakker fullføres) og vedlikeholdsbelastning (hvor mye innsats det tar å vedlikeholde tester).

• Enhetstester: validere individuelle komponenter isolert. Apex validerer metoder og klasser isolert fra eksisterende organisasjonsdata og eksterne avhengigheter. Lightning Web Component-tester validerer komponentlogikk og gjengivelse uten serverdel-API-er. Velutformede enhetstester utføres på sekunder og gir umiddelbar tilbakemelding under utvikling. Mål over minimumskravkodedekning på 75 % bare fra enhetstester, og behandle dekning som gulvareal, ikke tak.
• Integreringstester: validere interaksjoner mellom komponenter. Integreringstester utfører faktiske databaseoperasjoner, reelle oppkall til mockede eksterne systemer og virkemåte for godkjente styringsgrenser. Integreringstester fanger opp forutsetninger som enhetstester går glipp av – uventede datatilstander, tillatelsesproblemer, grenser for masseoperasjoner og utløsende bestillingsavhengigheter. Integreringstester utføres i sekunder til minutter per test.
• End-to-end (E2E)-tester: validere fullstendige brukerreiser fra pålogging til fullføring av oppgaver. E2E-tester kjører mot Fullstendig Sandbox, utøver brukergrensesnittinteraksjoner, serverdelprosesser, asynkrone operasjoner og integreringstaktpunkter. E2E tester oppfangingsproblemer som bare vises når hele systemet kjører – løpebetingelser, uventede brukerarbeidsflyter, miljøkonfigurasjonsproblemer. E2E-tester utføres i minutter til timer for omfattende pakker.
• Ytelsestester: validere virkemåten til løsningen under innlasting. Ytelsestester måler responstider, gjennomløp, ressursforbruk og styringsgrense i realistiske trafikkmønstre. Ytelsestester hindrer utgivelse av endringer som reduserer ytelsen, fanger opp N+1-spørringsmønstre før produksjon, og validerer kapasitetssideområde før høysesonger. Ytelsestester krever produksjonslignende datavolumer og kjøres i dedikerte testmiljøer.

Implementer test pyramidestrategi: mange raske enhetstester, færre integrasjonstester, selektiv E2E-test sammen med ytelsestester som er separat validert under lasting. Denne balansen aktiverer rask gjentagelse (hurtig enhetstester gir umiddelbar tilbakemelding) samtidig som integrasjonspunkter fungerer riktig (integreringstester fanger opp problemer på tvers av komponenter) og brukeropplevelsen forblir akseptabel (E2E-tester validerer fullstendige reiser).

Automatiser testutførelse i CI pipelines. Ikke kjør testpakker manuelt før bekreftelser, men la i stedet CI kjøre testpakker automatisk før hver bekreftelse. Automatisert testing fanger opp regresjoner umiddelbart, håndhever kvalitetsstandarder konsekvent og hindrer den gradvise kvalitetsnedgangen som skjer når manuell testing blir valgfri under tidspresset.

Pipelines for kontinuerlig integrasjon (CI) og kontinuerlig distribusjon (CD) automatiserer banen fra kodeforpliktelse til produksjonsdistribusjon. CI/CD reduserer menneskelige feil, akselererer tilbakemeldinger, leverer konsistente kvalitetskontroller og aktiverer rask utgivelseskadens.

• Kontinuerlig integrering bygger, tester og validerer automatisk alle kodekommitteringer. Når utviklere overfører bekreftelser til versjonskontroll, slår CI-systemer opp nye organisasjoner, distribuerer endringene, kjører automatiserte testpakker, utfører statisk kodeanalyse, sjekker testdekningskrav og rapporterer resultater innen minutter. Rask tilbakemelding gir utviklere mulighet til å løse problemer mens konteksten er ny, i stedet for å oppdage problemer dager senere under manuell integreringstesting.

Krev vellykket CI før du tillater flettinger til hovedforgreningen. Denne disiplinen (ofte kalt "beskytte hoved") hindrer at brutt kode akkumuleres i delte grener der den blokkerer andre utviklere. Beskyttede grener med CI-porter sørger for at hovedforgreningen kan distribueres til enhver tid, slik at den aktiverer utgivelse på forespørsel i stedet for utgivelse når hovedforgreningen skjer for arbeid.

• Kontinuerlig distribusjon distribuerer automatisk validerte endringer gjennom miljøer mot produksjon. Når CI har validert endringer i isolerte miljøer, distribueres CD pipelines til integrasjons-Sandbox-organisasjoner, kjører flere tester, distribueres til oppstillingen, kjører endelig validering og kan eventuelt distribueres til produksjon automatisk eller etter manuelle godkjenningsportaler.

Implementer progressive distribusjonsstrategier som begrenser blast radius under produksjonsdistribusjoner:

• Blå-grønn-distribusjon: vedlikeholder to identiske produksjonsmiljøer. Trafikk ruter til det blå miljøet mens det grønne miljøet mottar ny distribusjon. Etter validering bytter trafikk til det grønne miljøet. Det blå miljøet fortsetter å kjøre som et umiddelbart tilbakevulningsmål.
• Canary-distribusjon: utgir endringer i et lite brukerdelsett før full distribusjon. Indledende kanarie modtager en lille procentdel af trafikken, mens overvåger fejlfrekvenser, latens og brugeradfærd. Vellykket kanary utvides gradvis (for eksempel fra 5 % til 25 %, deretter 50 % og deretter 100 %). Problemer som oppdages under Canary-distribusjon, avbryter utgivelsen før de påvirker alle brukere. Kanarisk distribusjon fungerer godt for Salesforce-løsninger med eksterne rutinglag eller funksjonsflagg som aktiverer selektiv funksjonseksponering.
• Flagg: aktiver kjøretidsstyring av funksjonssynlighet uavhengig av distribusjonstidspunkt. Nye funksjoner distribueres til produksjonsorganisasjonen, men forblir skjult bak flagg til de eksplisitt aktiveres. Funksjonsflagg støtter kanarisk distribusjon, A/B testing, gradvis utrulling og umiddelbar tilbakevending ved å bytte flagg i stedet for å distribuere kode.

Notat: Kanariske og blågrønne distribusjonsmønstre gjelder for tilpassede programmer som befinner seg på Heroku eller MuleSoft-programmer som er distribuert på CloudHub 2.0 via kontrollene for ressurstildeling og trafikkfordeling. Distribusjoner av kjerne-metadata i Salesforce-plattformen er transaksjoner med alt eller ingenting.

Infrastruktur som kode (IaC) behandler et miljøs definisjon – organisasjonens form, metadata, avhengigheter og konfigurasjons- og utfyllingsdataene som gjør det funksjonelt – som en versjonsstyrt kilde i stedet for en oppsett som gjøres for hånd i hver organisasjon. I Salesforce er det ingen servere som skal klargjøres, så IaC styrer hvordan et miljø settes sammen, ikke maskinvaren under det. Kodede miljøer kan gjengis, sammenlignes og kastes, og det er nettopp det som hindrer dem i å avvikle.

Miljøer defineres fra kilden i stedet for manuell konfigurasjon. En midlertidig organisasjonsdefinisjonsfil angir versjon, aktiverte funksjoner og innstillinger slik at alle, eller en pipeline, kan slå opp en identisk, engangsorganisasjon på forespørsel. Sandbox-organisasjoner går en annen vei: de klargjøres fra en definisjon som gir navn på kopieringstypen og malen, og deretter arver de konfigurasjonen fra produksjonsorganisasjonen de kloner, noe som gir miljøer med høyere sannhet for integrering og oppstilling. Pakkedefinisjoner erklærer en løsnings komponenter og avhengigheter slik at bygninger kan gjengis fra kilden i stedet for å være avhengige av den akkumulerte tilstanden til en langvarig organisasjon.

Grunnlinjen som alle miljøer forutsetter, er også versjonert. Tilpassede metadata, konfigurasjon av navngitt legitimasjon og definisjoner av tilpassede innstillinger distribueres som metadata, mens angivelsesverdier og referanseposter lastes inn fra versjonsbaserte seedata. Å ha begge i kildekontroll sammen med kode betyr at hvert miljø starter fra en kjent, konsistent standardinnstilling i stedet for en konfigurert manuelt.

Koding av miljøer på denne måten angriper konfigurasjonsavvik ved kilden. Når definisjonen til et miljø finnes i versjonskontroll, vises forskjeller mellom miljøer som synlige forskjeller i stedet for stille avvik, og gjenoppbygging av et rent miljø er raskere enn feilsøking av et som har avviklet. Omklaring fra kilden forkorter gjenoppretting når et miljø blir ødelagt, og det lar pipelines stå opp for engangsmiljøer for hver endring uten manuell oppsett.

Sandbox-organisasjoner sørger for isolerte miljøer for utvikling, testing og opplæring uten å risikere produksjonsdata eller konfigurasjon. Effektiv Sandbox-strategi balanserer miljøtilfredshet (hvor nær Sandbox-organisasjoner samsvarer med produksjon) med kostnad og oppdateringsfrekvens.

• Utvikler-Sandbox-enheter gir lette isolerte miljøer for individuell funksjonsutvikling. Utviklere oppretter midlertidige organisasjoner fra kildekontroll for daglig arbeid ved å bruke Developer-Sandbox-organisasjoner til integrasjonstesting med delte avhengigheter. Developer-Sandbox-organisasjoner og midlertidige organisasjoner oppdateres ofte ved å holde konfigurasjonen synkronisert med produksjon.
• Integrasjons-Sandbox-enheter (developer pro eller delvis kopi) gir delte miljøer der flere funksjoner integreres og samhandler. Integrasjons-Sandbox-organisasjoner inkluderer nok produksjonsdata til å teste realistiske arbeidsflyter uten kostnadene og kompleksiteten til fullstendige datakopier. Integreringstester kjøres mot integrasjonsSandbox-organisasjoner før promotering til oppstillingen.
• Staging Sandbox-enheter (full kopi) speiler produksjonskonfigurasjon og data, og gir endelig validering før produksjonsdistribusjon. Oppstillings-Sandbox-enheter mottar utgivelser før produksjon, og aktiverer produksjonslignende testing av distribusjonsprosedyrer, ytelsesegenskaper og datamigreringsskript. Oppstillings-Sandbox-organisasjoner oppdateres kvartalsvis eller før store utgivelser.
• Opplærings-Sandbox-enheter gir realistiske miljøer for brukeropplæring og demonstrasjon uten å eksponere ekte kundedata. Opplærings-Sandbox-organisasjoner kan inneholde syntetiserte data eller anonymiserte produksjonsdata. Opplæringsmiljøer holdes stabile i lengre perioder for å støtte konsistente opplæringsmateriell og sertifiseringsprosesser.

Automatiser Sandbox-oppdatering og datalasting. Manuell Sandbox-oppdatering blir en flaskehals som hindrer hyppig testing med produksjonsliknende data. Automatiske oppdateringsprosedyrer kombinert med datalastingsskript aktiverer tilbakestilling av miljø på forespørsel, som støtter både kontinuerlige integrasjonsledninger og manuelle testbehov.

Notat: "Sandbox" har to forskjellige betydninger i et agentisk foretak. Sandbox-organisasjonene ovenfor er miljøer: isolerte kopier av en organisasjon der team bygger og tester før endringer når produksjonsorganisasjonen. Sandboxing av en agents handlinger er forskjellig. Det er kjøretidsgrensen som begrenser hvor og hvordan en autonom handling utføres, via omfangstillatelser, begrenset objekt- og integreringstilgang og kontrollert utførelse, slik at agenten ikke kan nå utover det tiltenkte omfanget. De to er komplementære: en Developer Sandbox er der du validerer en agents handlinger mot ikke-produksjonsdata, og action Sandbox er det som inneholder disse handlingene i produksjon.

Selv med automatiserte pipelines bærer distribusjoner risiko. Sikker distribusjonsrutiner reduserer risikoen gjennom validering, overvåking og kontrollert utførelse:

• Distribusjonsvalidering: kjører distribusjonen som tørrkjøring uten å utføre endringer. Validering fanger opp distribusjonsfeil – manglende avhengigheter, komponentkonflikter og ugyldige referanser – før faktisk distribusjon. Salesforce støtter valideringsdistribusjoner via både grensesnitt og CLI, og aktiverer validering i produksjon i åpningstider selv om den faktiske distribusjonen venter på vedlikeholdsvinduer.
• Distribusjonsovervåking: overvåker viktige målinger under og etter distribusjon. Overvåk feilfrekvenser, ytelsesmålinger, vellykkede brukerflyter og API-forbruk. Plutselig endring etter distribusjon indikerer regresjon som krever undersøkelse og mulig tilbakekalling. Automatisert overvåking sammenligner målinger før distribusjon og etter distribusjon, og varsler når statistisk avvik overskrider terskler.
• Distribusjonskjørebøker: dokumenter distribusjonsprosedyrer, inkludert forutsetninger, utførelsestrinn, valideringskontroller, tilbakeføringsprosedyrer og kommunikasjonsplan. Løpebøker forvandler distribusjoner fra stressende tribal Knowledge-seremonier til rutinemessige prosedyrer som alle kan utføre. Kjørebøker utvikles gjennom distribusjonsretrospektiver som fanger opp leksjoner og hindrer gjentagende problemer.
• Rullback-egenskap: gir isoleringsbane når distribusjoner mislykkes. Tilbakestilling av Salesforce-metadata krever omdistribusjon av forrige versjon i stedet for innebygde kommandoer for tilbakestilling, noe som gjør versjonskontroll viktig. Vedlikehold distribusjonspakker for hver produksjonsversjon som aktiverer rask omdistribusjon. Ved dataendringer vedlikeholder du sikkerhetskopier før distribusjon som aktiverer gjenoppretting. Spor tidligere verdier i Revisjonsspor for oppsett for konfigurasjonsendringer.

Planlegg distribusjoner i perioder med lite trafikk når distribusjonens innvirkning påvirker færre brukere. Weekend- og kveldsdistribusjoner minimerer forretningsrisiko, men øker driftsbelastningen. Balanse brukerinnvirkning mot teamets bærekraft. Løsninger med robuste distribusjonsrutiner og omfattende overvåking kan distribueres trygt i åpningstider, men ikke-godkjente løsninger får nytte av distribusjon utenfor åpningstider til tillit bygges.

Konfigurasjon er metadata som styrer virkemåten til løsninger – organisasjonsinnstillinger, funksjoner, tillatelser, integrasjoner og tilpassing. Konfigurasjonsendringer påvirker kjørende løsninger umiddelbart uten kodedistribusjon, noe som gjør konfigurasjonsbehandling avgjørende for driftsstabilitet.

Versjonskonfigurasjon i kildekontroll sammen med kode. Profildefinisjoner, tillatelsessettildelinger, tilpassede innstillinger, plattformhendelsesdefinisjoner, navngitt legitimasjon og innstillinger for eksterne nettsteder tilhører versjonskontrollen. Versjonskonfigurasjon aktiverer distribusjonsautomatisering, endringssporing, miljøkonsistens og muligheten til å rulle tilbake.

Oppdage og rette opp konfigurasjonsavvik. Over tid avviker produksjonsorganisasjoner fra dokumentert konfigurasjon etter hvert som administratorer gjør direkte endringer, hurtigreparasjoner omgår normale distribusjonsprosesser og upokumenterte omgåelser akkumuleres. Automatisk sammenligning mellom produksjonskonfigurasjon og versjonskontroll viser avvik. Planlegg deteksjon og rettelse av kvartalsvis avvik for å hindre at konfigurasjonsforpliktelser akkumuleres til et punkt der distribusjoner blir uforutsigbare.

Dokumenter konfigurasjonsbeslutninger og deres begrunnelse. Fremtidige vedlikeholdere må forstå ikke bare hva som er konfigurert, men hvorfor. Organisasjonsomfattende innstilling er som standard Privat for Konto, men Felles for Kontakt, krever dokumentasjon som forklarer forretningskravet som førte til denne beslutningen. Uten dokumentert grunnlag risikerer fremtidige endringer å bryte forutsetninger som er begravd i forretningsprosesser.

Automatisering eliminerer gjentagende manuelt arbeid, reduserer menneskelig feil og gjør det mulig å skalere operasjoner uten proporsjonal økning i antall personer. For Salesforce-løsninger omfatter automatiseringsmuligheter deklarative plattformfunksjoner, programmatisk automatisering og driftsprosedyrer.

Salesforces deklarative automatiseringsverktøy Flow Builder, Formelfelt, Valideringsregler og Godkjenningsprosesser gir ikke-utviklere mulighet til å implementere kompleks forretningslogikk uten kode. Deklarativ automatisering gir styringsfordeler (administratorer kan endre uten distribusjoner), gjennomsiktighet (selve de visuelle utformingsdokumentene) og plattformoptimalisering (deklarative operasjoner utføres ofte mer effektivt enn tilsvarende kode).

• Flytbygger: automatiserer komplekse prosesser som kombinerer brukermedvirkning, datamanipulering, forretningslogikk og integrering. Flyter håndterer vanlige mønstre, inkludert postopprettelse med avhengige oppslag, betinget godkjenningsruting, dataimport med flere trinn, planlagte oppryddingsjobber og arbeidsflyter for feilmeldinger. Automatisk startede flyter utføres på postendringer, planlagte intervaller eller eksplisitt kall fra kode. Skjermflyter leder brukere gjennom prosesser med flere trinn med forgreningslogikk basert på brukerinndata.

Utform flyter for gjenbrukbarhet og vedlikehold. Underflyter innkapsler vanlige mønstre (som feilhåndtering eller postlåsingslogikk) som flere overordnede flyter gjenbruker. Velnavngitte flytvariabler og eksplisitte beskrivelser oppretter selvdokumenteringslogikk som fremtidige vedlikeholdere forstår. Modulær flytutforming muliggjør testing av individuelle komponenter før integrering.

• Formelfelt: beregne verdier dynamisk fra andre felt uten kode- eller databaseoppdateringer Formler støtter komplekse beregninger, betinget logikk, datoaritmetikk og tekstmanipulering. Formelfelt fungerer i rapporter, listevisninger, valideringsregler og flyter, og gir konsistente beregninger på tvers av ulike kontekster. Formler utføres effektivt fordi de ikke bruker databaselagring og beregnes direkte under posttilgang.
• Valideringsregler: håndheve datakvalitet ved lagring av tid. Valideringsregler fanger opp dataregler, håndhever forretningsregler og hindrer ugyldige statusoverganger. Plasser valideringsregler på standardobjekter og tilpassede objekter for å fange opp feil uavhengig av datakilde – brukergrensesnitt, API, Data Loader, integrasjon. Velutformede valideringsregelfeilmeldinger leder brukerne til å rette opp problemer i stedet for å frustrere dem med kryptiske tekniske meldinger.
• Godkjenningsprosesser: rute poster gjennom nødvendige godkjenninger før statusforbedring. Godkjenningsprosesser implementerer hierarkier for signeringsinstanser, samsvarsvurderinger, juridiske godkjenninger og arbeidsflyter for samtykke med flere parter. Godkjenningsprosesser gir automatisk revisjonsspor som registrerer hvem som godkjente hva og når uten tilpasset utvikling.

Selv om deklarativ automatisering håndterer mange scenarier, krever komplekse krav eller ytelsesbegrensninger noen ganger programmatisk automatisering i Apex. Effektiv Apex balanserer kraft og fleksibilitet mot vedlikeholds- og styringsutfordringer.

• Utløserrammeverk gir en konsistent struktur for databaseutløserlogikk. Velutformede utløserrammeverk skiller bekymringer (når logikk utføres, hvilken logikk utføres, hvordan avhengigheter ordnes), aktiverer/deaktiverer individuelle behandlere uten kodeendringer og hindrer gjentagelsesproblemer via kontekstsporing. Utløserrammeverk gjør Apex mer vedlikeholdbart ved å hindre "én stor utløser"-antimønsteret der ikke-relatert logikk akkumuleres til ikke-vedlikeholdbare monolitter.
• Batch Apex behandler store datavolumer asynkront i bunker, respekterer styringsgrenser og utfører operasjoner som vil ta tid i synkron utførelse. Gruppejobber håndterer datarensing, masseoppdateringer som krysser objektgrenser, komplekse beregninger som krever flere spørringer per post, og dataoverføringsoperasjoner. Utform gruppejobber for idempotency – kjøring av samme jobb to ganger skal gi det samme resultatet uten duplikatarbeid eller korrupsjon.
• Købar Apex kjeder asynkront arbeid gjennom eksplisitte jobbesekvenser. Der fremtidige metoder glemmer, aktiverer Apex i kø strukturerte sekvenser der fullføring av én jobb utløser den neste. Købare jobber støtter kompleks orkestrering, inkludert API-oppkall fulgt av databehandling, datatransformasjoner med flere faser og prøvelogikk med eksponentiell tilbakekall.
• Planlagt Apex utfører jobber med faste intervaller. Planlagte jobber håndterer periodisk opprydding, nattlig datasynkronisering, timebaserte integrasjonsavstemninger og behandling på slutten av dagen. Planlegg jobber i perioder med lite trafikk, og implementer overvåking for å oppdage manglende utførelser. Vurder om planlagte intervaller virkelig dekker forretningsbehovene, eller om hendelsesdrevet utløsing vil svare raskere.

Utform programmatisk automatisering for operativ synlighet. Logg start-/sluttklokkeslett, antall behandlede poster, oppdagede feil og ytelsesmålinger. Når gruppejobber mislykkes stille, blir de ofte ubemerket til brukerne merker seg dataproblemer dager senere. Proaktiv logging og varsling transformerer stille feil til diagnostiserbare hendelser.

Plattformhendelser aktiverer hendelsesdrevet arkitektur der produsenter publiserer hendelser uten å vite forbrukerne, og forbrukere abonnerer på hendelser uten å være avhengige av produsenter. Hendelsesdrevet arkitektur kobler komponenter fra hverandre, aktiverer asynkron behandling og støtter flerspråklige integrasjonsmønstre.

• Plattform Hendelse publisering: varsler interesserte abonnenter om betydelige forretningshendelser. Bestillingsplassering, betalingsbehandling, fullføring av innfrielse, SLA-brudd og feilbetingelser representerer alle hendelser som er verdt å publisere. Hendelsesbelastninger inkluderer tilstrekkelig kontekst slik at abonnenter kan reagere riktig uten flere spørringer. Publiser hendelser fra utløsere, flyter, Apex eller API-kall for å gi fleksibilitet i hendelsessurfing.
• Plattformhendelsesabonnementer: reagere på publiserte hendelser via Apex, flyter eller eksterne integrasjonsplattformer. Abonnenter behandler hendelser asynkront, som betyr at utgivere ikke venter på abonnentens fullføring. Hendelsesdrevet behandling respekterer styringsgrenser ved å fordele arbeid på tvers av separate utførelseskontekster i stedet for å forbruke grenser i massive synkrone transaksjoner.
• Event repetisjon: gir abonnenter muligheten til å behandle historiske hendelser. Bruk plattformhendelses-ID til å gjengi hendelser fra et bestemt punkt. Eksterne abonnenter må behandle sin egen Replay ID-status. Fordi levering skjer minst én gang, er duplikatbehandling mulig – håndtere den i abonnentlogikk. Konfigurer hendelsesoppbevaring basert på abonnentgjenopprettingskrav – 72 timer for plattformhendelser med stor trafikk og 24 timer for tidligere standardhendelser er tilstrekkelig for rask gjenoppretting, og lengre oppbevaring støtter katastroffjenopprettingsscenarier.

Utform hendelser for å få stabilitet. Hendelsesskjemaer blir kontrakter mellom produsenter og forbrukere. Skjemaendringer krever koordinering på tvers av flere team og systemer. Legg til nye felt i stedet for å endre eksisterende felt når hendelser utvides. Versjonshendelser eksplisitt når det blir uunngåelig å bryte endringer.