Ønsker du å bygge skjemaer på Salesforce Platform? Du har flere alternativer som spenner over hele kontinuumet med lite kode til pro-koding. Representerer med lite kode er dynamiske skjemaer i Lightning og skjermflyter i Flow Builder. Stående midt i kontinuumet er muligheten til å utvide skjermflyter med LWC-er og bygge kunderettede skjemaer med OmniStudio. Og pro-kode representerer LWC-rammeverket og dets stadig voksende bibliotek med basiskomponenter.

Alternativer er gode, men hvordan finner du ut hvilket (eller hvilken kombinasjon) som er det riktige alternativet? Det er her denne veiledningen kommer inn.

• Takeaway #1: Bruk dynamiske skjemaer når du bygger oppsett/redigering/visning av Lightning-sider. Du vil kanskje merke at sideoppsett mangler i sammenligningstabellene i denne veiledningen. Når du går videre, er den anbefalte måten å konfigurere postdetaljsider på å bruke dynamiske skjemaer i Lightning. Se delen om sideoppsett for å få mer informasjon om hvorfor vi ikke forventer å forbedre dem ytterligere.
• Takeaway #2: Hvis du trenger å bygge et opprettelses- eller redigeringsskjema for nøyaktig ett objekt, starter du med Lightning-sider og dynamiske skjemaer. Dette er den enkleste måten å bygge skjemaer på Salesforce-plattformen på. Den har også en del tilleggsfunksjonalitet, som muligheten til å kontrollere feltsynlighet. Hvis kravene er mer avanserte, fortsetter du å lese. Skjermflyt, OmniStudio eller Lightning Web Components (LWC) passer kanskje bedre.
• Takeaway #3: Hvis du bygger et skjema med flere sider eller en veiviser og ikke har strenge krav til brukergrensesnitt eller merkeprofilering, starter du med en skjermflyt. Skjermflyter er et lineært navigeringsrammeverk for å orkestrer flere skjemaer sammen. Du kan bruke LWC til å bygge ditt eget rammeverk for navigering mellom skjemaer, men vi anbefaler at du lar Flyt gjøre det harde arbeidet for deg, slik at du kan fokusere på selve skjemaene i stedet for å bekymre deg for skjemastatus.
• Takeaway #4: Hvis du trenger mer logikk eller handlinger bak skjemaet, bruker du en skjermflyt, OmniStudio eller LWC. Alle de tre verktøyene tilbyr måter løsningen kan gjøre mer enn å opprette eller redigere en enkelt post. Denne "mer" kan være mer avansert logikk, som forgrening eller gjentagelse, eller det kan være flere handlinger som å integrere med eksterne systemer, sende e-postmeldinger eller pushe varsler til en brukers mobilapp.
• Takeaway #5: Har du avanserte UX-krav? Trenger du å håndtere mer dynamisk enn synlighet? Bruk LWC eller Omniscript. Hvis kravene kan oppfylles med enkle temaer og kolonnebaserte oppsett, kan du bygge skjemaene direkte i en lavkodebygger. For å få mer detaljert kontroll over skjemaets stil trenger du den ultimate fleksibiliteten i LWC. Hvis du er bransjekunde og trenger pikselperfekt merkeprofilering eller har komplekse hierarkiske data, bruker du OmniStudio, som lar deg bygge skjemaer for forbrukergrader som kan håndtere komplekse forretningslogikk- og datatransformasjoner.
• Takeaway #6: Hvis du trenger testautomatisering, starter du med Lightning Web Components. Du kan skrive enhetstester for en hvilken som helst LWC uavhengig av hvor du planlegger å bygge den inn. Dette gir deg mulighet til å opprette en mer robust teststrategi, som kan inkludere massetesting med flere poster og negativ testing. Se Salesforce Well-Architected - Testing Strategy for å få mer informasjon om hvordan du oppretter tester som hjelper deg å se hvor godt skjemaene dine vil tilpasse seg funksjonelle og ikke-funksjonelle krav.

Husk at valget ikke trenger å være enten eller - du kan kombinere muligheten til flere alternativer. Hvis du for eksempel trenger både Flyts innebygde navigeringssystem og den fullstendige stilfleksibiliteten LWC tilbyr, bruker du dem sammen.

Tabellen nedenfor viser verktøyene som er tilgjengelig for å bygge skjemaer med Salesforce, sammen med deres nødvendige kvalifikasjoner og lisensvurderinger. Senere ser vi nærmere på de spesifikke funksjonene som støttes for hvert verktøy, og hvordan du velger mellom klikkebaserte verktøy og kodebaserte verktøy (og når du kan kombinere dem):

Tabellen nedenfor inneholder en oversikt over beslutningspunktene du bør tenke over når du gjør produktvalgene, sammen med spørsmål du bør stille deg selv om hvert av dem. Vi vil gå dypere inn i hvert av disse emnene i resten av denne veiledningen.

Her er begrepene vi bruker i sammenligningstabellene sammen med deres definisjoner:

• Tilgjengelig: Fungerer fint med grunnleggende vurderinger.
• Ikke ideelt: Kan fungere, men er ikke det optimale verktøyet.
• Veikart: Støtte for de neste tolv månedene (juni 2025).
• Fremtid: Beregnet for støtte utover de neste tolv månedene.
• Ikke tilgjengelig: Ingen planer om å støtte denne funksjonen innen de neste tolv månedene.

Som lovet, la oss starte et dypdykk i en rekke sammenligningspunkter og funksjonelle forskjeller mellom dynamiske skjemaer, skjermflyter, OmniStudio, skjermflyter med innebygde LWC-er og selve LWC-rammeverket.

Hvis skjemaet ditt fungerer mot ett enkelt Salesforce-objekt, vil alle verktøyene vi sammenligner, fungere. Ting blir litt mer kompliserte med kryssobjekt- eller objektagnostiske skjemaer. Med objektagnoser mener vi inndata som ikke er tilordnet til noe Salesforce-objekt. Kanskje skjemaet representerer en datastruktur som du sender til en ekstern tjeneste, som Stripe eller DocuSign. Eller kanskje du bruker flere inndata i skjemaet til å beregne en verdi, og deretter bekrefter du denne verdien til databasen.

• Hvilke objekter vil skjemaet arbeide mot?
• Er det bare ett objekt, eller finnes det flere objekter?
• Arbeider du med bestemte objekter (for eksempel Konto, Kontakt, Salgsmulighet, Salgsemne og Sak), eller må skjemaet også fungere med andre objekter?

For både kryssobjekt- og objektagnostiske skjemaer er både Flyt og OmniStudio solide alternativer. Komponentene som er tilgjengelig i flytskjermer, er agnostiske av natur, så du kan velge hva du skal gjøre med disse dataene i bakgrunnen. Bruk for eksempel dataene som skrives inn i ett skjema, til å opprette flere poster i bakgrunnen, eller bruk dataene til å utføre andre handlinger som å generere Chatter, sende Slack-meldinger, sende e-postmeldinger eller koble til eksterne tjenester.

I enkle tilfeller kan bruk av eksisterende LWC-komponenter, som Lightning, være en enkel måte å redusere koden som er nødvendig for å gi en robust løsning. Men for scenarier der flere objekter er involvert, gir Flyt omfattende kontroll for alle objekter og fjerner behovet for at utviklere går gjennom komplekse relasjoner og avhengigheter.

OmniStudio tar ting et skritt videre og er fullstendig objektagnostisk – det skiller skjemaet en bruker ser fra den underliggende datamodellen. I stedet manipulerer OmniStudio underliggende JSON som deretter tilordnes til Salesforce-objekter (eller eksterne data) ved hjelp av verktøy som Data Mapper og Integrasjonsprosedyrer. Datatilordning og integrasjonsprosedyrer er to viktige komponenter ved tilkobling av Omni Studio-skjemaer med data internt og eksternt i Salesforce. Ved å bruke dra-og-slipp-elementer kan du arbeide med komplekse hierarkiske data i et eksternt system, og deretter transformere dataene slik at de passer til behovene dine, avhengig av hvor dataene må gå. De lar deg også bruke formler til å utføre matematikk og logikk på matriser, eller lister med data, på samme måte som Apex.

OmniStudio-integrasjoner

Hvis du kan hente alle brukerinndataene fra et enkeltskjermskjema, starter du med dynamiske skjemaer. Dynamiske skjemaer på postsider kan imidlertid bruke Bane-funksjonen til å løst representere de ulike fasene i forretningsprosessen, men den passer kanskje ikke i de fleste bruksområder.

• Trenger du en enkelt skjerm eller må brukeren navigere mellom flere skjermer for å utføre en oppgave?
• Vil du at brukerne skal se en visuell beskrivelse av hvor langt de er i prosessen med å fylle ut skjemaet?
• Trenger brukerne å fylle ut informasjonen på hver skjerm i en bestemt rekkefølge, eller kan de flytte frem og tilbake mellom skjermer etter behov?

Hvis du trenger mer funksjonalitet enn det Dynamiske skjemaer tilbyr, vil valget mellom Flyt, OmniStudio og LWC også avhenge av noen få andre spørsmål:

• Hvilke kvalifikasjoner har teamet ditt? For en organisasjon som er mer administrativ, anbefaler vi å starte med Flyt. Hvis du har bransjeløsninger, er teamet kjent med OmniStudio allerede, og prosjektet ditt har strenge brukergrensesnittkrav, start med OmniStudio.
• Er det OK å vise en navigeringslinje nederst i skjemaet? Hvis skjermflyten og Omnikanal-navigeringsopplevelsen er uønsket brukergrensesnitt, fører du til LWC.
• Hva må skje bak skjemaet? Hvis du trenger at virkemåten skal kunne konfigureres av en administrator, bygger du en flyt eller, for grunnleggende endringer som å endre feltetiketter, et Omniscript. Ellers bygger du et Omniscript eller LWC for komplekse relasjoner med flere objekter.
• Hvis du velger Flyt eller OmniStudio, må du kanskje bygge en LWC uansett for å oppnå riktig brukergrensesnitt. Hvis du allerede bygger en LWC for å utforme skjemaet riktig, bør du vurdere om det er overdrevet å bygge inn denne komponenten i en flyt.

Hvis på den annen side løsningen ser ut som en veiviser der brukeren navigerer mellom flere skjermer, kan du vurdere Flyt eller OmniStudio. Flyter og OmniStudio leveres med en innebygd navigeringsmodell, så du trenger ikke å bygge og vedlikeholde LWC-er som er knyttet sammen. Navigeringen er lineær, med handlinger som beveger seg fremover, handlinger som beveger seg bakover, og en mekanisme for lagring av skjemaet for senere bruk. Du kan også bygge et skjema med ikke-lineær navigering hvis det passer til formålet ditt. Et godt eksempel på bruk av skjermflyter er pakken Digital Store Audit fra Salesforce Labs.

OmniStudio tilbyr en viktig navigasjonsfordel ved å gi fremdriftsindikatorer fra standardnavigering som viser "trinn" i skjemaet. Denne trinnvisningen viser automatisk hvor en bruker er i et gitt skjema med flere trinn. Til forskjell fra Flyt kan brukere hoppe mellom skjermer ved å klikke på på forskjellige trinn i skjemaet.

Uansett om du bygger enkeltskjerm- eller flerskjermskjemaer, må du sørge for at skjemaene er strømlinjeformet slik at de er enkle for brukerne å navigere i.

Hvis du bygger inn et skjema på en standard Lightning, vil alle verktøyene vi sammenligner, fungere, med forbehold om at dynamiske skjemaer for øyeblikket bare er tilgjengelig på skrivebordet. Hvis du imidlertid ønsker å tilby en opplevelse som gir brukere tilgang til skjemaer fra andre steder, kan det hende du må vurdere alternative alternativer.

• Trenger brukere tilgang til skjemaet via skrivebord, mobil eller begge deler?
• Skal brukere ha tilgang til skjemaet fra hvor som helst i appen via en verktøylinje?
• Vil du bruke hurtighandlinger slik at brukere kan fylle ut skjemaet uten å måtte forlate siden de er på for øyeblikket?
• Trenger skjemaet å være tilgjengelig på et eksternt nettsted?

Fordi de krever postkontekst, støttes dynamiske skjemaer bare på Lightning. Dynamiske skjemaer støttes imidlertid ikke på Experience Cloud-sider. Denne begrensningen gjelder fordi Experience Cloud ikke bruker det underliggende rammeverket som dynamiske skjemaer er avhengig av: Lightning. Vi evaluerer dette basert på forespørsler om dynamiske skjemaer i Experience Cloud.

Du kan bygge flyter som krever en postkontekst, eller flyter som fungerer globalt. Som sådan kan du bygge inn flyter på en rekke steder. For postkontekstuelle flyter kan det være en Lightning, en Experience Cloud-postside, en objektspesifikk handling eller en Handlinger og anbefalinger-distribusjon. For den globale flyten kan det være verktøylinjen, andre Lightning eller Opplevelsesbygger-sider, et Snap eller et eksternt program. Flyter støttes for øyeblikket ikke som globale handlinger, men som en midlertidig løsning kan du pakke flyten inn i en Aura-komponent.

Med OmniStudio kan du bygge komponerbare FlexCard- og OmniScript-kort som du kan plassere nesten hvor som helst du kan legge inn en flyt. De kan imidlertid komponeres, men de kan ikke pakkes.

LWC støtter en høy grad av gjenbrukbarhet fordi du oppretter komponenter som kan knyttes til mål via metadata på tvers av Salesforce, fellesskap og også i prosjekter med åpen kildekode. LWC-komponenter kan også bygges inn på ditt eget nettsted via Lightning Out.

_ Lightning Out på eksterne nettsteder_

Lightning nettkomponenter støttes for øyeblikket ikke som hurtighandlinger (objektspesifikke eller globale), men som en midlertidig løsning kan du pakke en LWC inn i en Aura-komponent (slik du kan med flyter). LWC-komponenter kan også starte flyter med Lightning-flyt-komponenten.

OmniStudio utmerker seg ved å vise innhold til dine eksterne nettsteder via OmniOut-funksjonen. Med OmniStudio og OmniOut kan du kompilere Omniscript-skjemaer og FlexCard-komponenter til standardkomponenter og kjøre dem offline på tredjeparts nettsteder eller i apper.

Ingen av skjemateknologiene som dekkes i denne veiledningen, støttes offisielt i Mobile SDK-maler i dag. Hvis Mobile SDK er avgjørende for brukstilfellet ditt, er det bedre å bygge skjemaet ditt som standard i mobilappen eller bygge en Visualforce-side, samtidig som du tar hensyn til Salesforce Well-Architected formfaktor veiledning.

Veikartnotat: Mobile SDK-teamet arbeider aktivt med å støtte LWC-er på Visualforce.

Dynamiske skjemaer er perfekt hvis du trenger å bruke verdiene i skjemaet til å opprette eller oppdatere en post. For eventuelle funksjoner utover dette må du benytte Flow, OmniStudio eller LWC. Disse funksjonene kan inkludere et lag med beslutninger eller gjentagelser, eller generering av Slack-innlegg eller e-postmeldinger ved bruk av inndata fra skjemaet.

• Hvilke handlinger eller logikk vil du at skal utføres i bakgrunnen?
• Inneholder datamodellen hierarkiske data?
• Trenger skjemaet å fullføre operasjonene i en enkelt transaksjon eller på tvers av flere transaksjoner?
• Trenger du å integrere med eksterne systemer?
• Hva er kravene til gjenbrukbarhet og modularitet?

Flyt tilbyr standardhandlinger for innlegg til Slack, sending av e-post og samhandling med Quip, så du trenger ikke å skrive kode for disse operasjonene. LWC tilbyr omfattende interaksjoner med enkeltposter og relaterte objekter gjennom bruk av trådadaptere som samhandler med Brukergrensesnitt-API. LWC kan også samhandle med flere poster når du bruker tråden for getListInfoByName.

_ Lightning Web Components Interaksjon via trådadaptere_

Som nevnt ovenfor bruker OmniStudio Integrasjonsprosedyrer og Datatilordning til enkelt å hente og transformere data som er eksterne og interne for Salesforce. Den skiller ut i å flate ut og utvide datasett med ulike nivåer av relasjoner takket være mange kodefrie funksjoner du kan bruke.

Veikartnotat: Flyten vil snart støtte muligheten til å sette inn samlinger av poster og behandle hierarkiske data.

Flow, OmniStudio og LWC er alle integrert med Apex, slik at du enkelt kan lukke eventuelle hull i den løsningen du velger. Hvis du for eksempel trenger å filtrere poster fra en LWC, kan du alltid bruke adapteren for Apex til å opprette komplekse SOQL-spørringer. Hvis du blir overveldet av den klikkbaserte historien, kan du vurdere Flyt eller OmniStudio som levedyktige alternativer til en Apex for serversidebehovene dine.

Et sekundært spørsmål her er om du vil utføre handlinger umiddelbart eller utsette dem til en bestemt del av skjemaet. Dette er spesielt relevant hvis du har et skjema med flere sider. Flyt gjør det enkelt å kombinere inndata fra flere skjemaer (flytskjermer) og bruke dem mye senere i veiviseren (flyt) for å utføre noen operasjoner. Vi anbefaler faktisk å utforme flyter på akkurat den måten – utfør handlinger på slutten – i tilfelle brukeren går frem og tilbake mellom skjermer og endrer svarene sine.

Transaksjoner og styringsgrenser er en livsstil på Salesforce Platform. Hvis brukstilfellet er ganske enkelt, er det kanskje ikke like viktig å kontrollere hvilken transaksjon en bestemt operasjon skjer i. Det er imidlertid noen få brukstilfeller der du kanskje vil kombinere flere operasjoner til én enkelt transaksjon i stedet for å utføre dem på tvers av flere transaksjoner. Noen eksempler:

• Å rulle tilbake eller ikke å rulle tilbake: Det er spørsmålet. La oss si at skjemaet ditt oppretter flere poster i bakgrunnen. Hvis den tredje posten ikke opprettes, skal de to første postene rulles tilbake? Hvis hver av handlingene dine er uavhengige av hverandre, kan du utføre dem i separate transaksjoner. Men hvis de er avhengige og du vil at en av dem skal falle til å rulle tilbake de andre, implementerer du dem i én enkelt transaksjon. Hvis skjemaet er i Flyt, kan du bruke Tilbakekall-elementet i en feilbane til å rulle tilbake transaksjonen og sikre dataintegritet.
• Innvirkning på styringsgrenser: Spesielt når skjemaet oppretter eller oppdaterer en post, bør du vurdere hva nedstrøms konsekvensene av denne operasjonen er. Hvilke prosesser, arbeidsflytregler, flytutløsere, Apex eller andre elementer i lagringsrekkefølgen skal utløses basert på denne postendringen? Og hvordan påvirker disse kollektive endringene styringsgrensene som forbrukes i denne transaksjonen? Hvis en bestemt postendring fører til mange nedstrøms endringer som påvirker grensene dine, kan du vurdere å isolere denne postendringen i sin egen transaksjon.
• Batchbehandling: Selv i en brukergrensesnittkontekst kan det hende du må gruppere flere oppdateringer sammen. La oss si at skjemaet for flere skjermer gjentar seg over en stor gruppe poster. I stedet for å utføre en postoppdatering etter hvert skjermbilde, venter du til du har samlet inn oppdateringene for alle postene, og deretter sender du én forespørsel om å oppdatere alle postene.

Når du bruker dynamiske skjemaer til å opprette eller redigere en post, utfører du bare én operasjon, og denne operasjonen er alltid starten på en ny transaksjon.

Når du bygger en skjermflyt, har du betydelig kontroll over hva som skjer i en gitt transaksjon. Skjermer og lokale handlinger fungerer som grenser mellom transaksjoner. Her er et sammendrag på høyere nivå av hvordan transaksjoner behandles i skjermflytarkitekturen.

1. Sluttbrukeren samhandler med en skjerm, og klikker deretter på Neste.
2. Klienten sender en forespørsel til API-et med inndataene.
3. API-et mottar forespørselen, og en transaksjon og en databasetilkobling åpnes. API kaller deretter opp Flyt-motoren for å kalle opp forespørselen.
4. Flytmotoren tar over og følger den riktige banen i flytdefinisjonen til den når en Skjerm- eller Local Action-node. Motoren returnerer deretter informasjon om denne noden til API-et.
5. API oppretter et svarobjekt som inneholder detaljene for neste skjerm som skal gjengis, og returnerer dette objektet til klienten. På dette punktet blir databaseendringer utført (for å utføre lagringsbestillingen), og databasetilkoblingen og transaksjonen avsluttes.
6. Klienten bruker API-svaret til å gjengi neste skjermbilde som brukeren skal samhandle med.
7. Gjenta fra trinn 1.

Med andre ord "bryter" skjermen transaksjoner. Når det skjer, bekreftes eventuelle ventende handlinger eller DML, den tidligere transaksjonen avsluttes og en ny transaksjon starter.

Den riktige utformingen – hvilke operasjoner du grupperer i en gitt transaksjon – er kallet ditt. La oss gå gjennom noen eksempler.

Til venstre kan du se en flyt som samler inn inndata på tvers av flere skjermer, og deretter utfører flere handlinger i én transaksjon.

Flyten til høyre utfører hver operasjon i en separat transaksjon.

Anta at du har en flyt som oppretter poster, oppdaterer poster og deretter oppretter flere poster, som vist i neste flyt til høyre.

I dette scenariet vil de første to DML-operasjonene fremdeles opprette og oppdatere disse postene, mens det tredje ikke gjør det.

Ved å bruke elementet Rull tilbake poster kan du sikre at hele transaksjonen rulles tilbake hvis alle tre operasjonene må skje sammen – som vist i den endelige flyten til venstre.

Se flyter i transaksjoner og flyt masseutførelse i transaksjoner for å få mer informasjon. Avsnittet Automatisert i Salesforce Well-Architected går også dypere inn i dette i Datahåndtering.

Muligheten til å kontrollere transaksjonen fra en LWC kommer til de underliggende tjenestene som LWC bruker til å utføre sine operasjoner. Hvis du bruker basiskomponenten Lightning, skjer den underliggende operasjonen (oppretting eller oppdatering av posten) i en frittstående transaksjon så snart skjemaet sendes.

Generelt gjelder disse reglene:

• Hvert API-kall i brukergrensesnittet er isolert i sin egen transaksjon.
• Hvis du trenger å utføre flere operasjoner i én enkelt transaksjon, sender du inndataene til en teknologi på serversiden, som en Apex eller en flyt. De vanlige transaksjonsreglene for denne teknologien gjelder.

Flow, OmniStudio og LWC støtter alle plattformhendelser (for arrangementsdrevet arkitektur) og API-integrasjoner. I tillegg til tilpasset Apex støtter både Flow og OmniStudio deklarative mekanismer for å integrere en API.

Hvis du trenger å koble til en Mulesoft API- eller RPA-robot, bruker du Mulesoft Services. Dette genererer en ekstern tjeneste.

_ Eksterne integrasjoner via Mulesoft API-er og RPA-roboter_

Hvis API-et har et OpenAPI-skjema, oppretter du en ekstern tjeneste.

_ Eksterne integrasjoner til API-er med OpenAPI-skjemaer_

Ellers bruker du HTTP-oppkallfunksjonen i Flyt eller HTTP-handling i Omni Studio. Flytens HTTP-udkald leveres af Eksterne tjenester.

_ Eksterne integrasjoner via HTTP_

OmniStudio har et rikt sett integrasjonsfunksjoner som kan kalle opp eksterne systemer med Integrasjonsprosedyrer og transformere dataene med Datatilordning. (Se Objektinnvirkning for å få mer informasjon)

Uavhengig av om du implementerer den med tilpasset Apex eller en ekstern tjeneste, er et oppkall et oppkall. Her er det du trenger å vite.

1. Et oppkall kan ta lang tid.
2. Når et oppkall utføres synkront, utføres det mens en databasetransaksjon er åpen.
3. Salesforce lar deg ikke beholde en databasetransaksjon åpen hvis du har ventende databaseoperasjoner.

Den viktigste begrensningen å huske på er faren for såkalte skitne transaksjoner, der du utfører en opprettelse, oppdatering eller slette operasjon og deretter, i den samme transaksjonen, utføre et oppkall. Dette mønsteret er ikke tillatt på grunn av vurdering nr. 3 ovenfor, som selvfølgelig finnes på grunn av vurderingene nr. 1 og nr. 2.

I Flyt kan du omgå denne begrensningen ved å bryte transaksjonen. Husk at både skjermer og lokale handlinger introduserer nettleserkonteksten på nytt, noe som avbryter transaksjonen. Selv om du kan bruke skjermer og lokale handlinger når du arbeider med eksterne oppkall, anbefaler vi at du aktiverer Transaksjonskontroll i avanserte innstillinger som kan kalles opp. Transaksjonskontroll er en funksjon med kallbare handlinger som lar deg avslutte transaksjonen automatisk før et oppkall utføres. Du kan aktivere Transaksjonskontroll ved å velge Start alltid en ny transaksjon i Avansert-delen av en kalt handling.

Se Arkitektveiledningen for dataintegrering med Salesforce for å få mer detaljert veiledning om Apex-oppkall, eksterne tjenester og dataintegreringsfunksjoner generelt.

Dynamiske skjemaer støtter ikke gjenbruk. Hvert dynamisk skjema er knyttet til en bestemt Lightning for et bestemt objekt (selv om du kan tildele denne Lightning til flere apper, profiler og så videre).

På samme måte som du kan skrive biblioteker, verktøy og komponenter som er ment å brukes på tvers av flere andre komponenter, kan du bruke lignende designmønstre når du oppretter flyter med kraften i underflyter. Lagre flytene i mindre, mer modulære samlekategorier, og kall dem deretter fra andre flyter ved å bruke Underflyt-elementet. Hvis utformingen krever det, kan du bygge en flyt som både står alene og er nyttig som en underflyt av en annen.

OmniStudio er innebygd for modularitet. Datatilordninger, Omniskript, FlexCard og Integrasjonsprosedyrer er alle bygd uavhengig og kan fungere om hverandre. I tillegg kan FlexCard bygges som LWC-komponenter som kan bygges inn i andre LWC-er, OmniScript-er, postsider og Experience Cloud-nettsteder.

Skjermflyter, Omniscripts og LWC-er kan alle bygges for gjenbruk og bygges inn på en rekke steder, inkludert eksterne nettsteder og Lightning Out-programmer. Når du utformer løsningene slik at de er komponerbare, får du ekstra fordeler som tilpasningsevne og stabilitet.

Alle teknologier som brukes til å opprette eller oppdatere en post, følger validering på systemnivå – enten det er klassiske valideringsregler eller tilpasset validering innebygd i en Apex. Uansett hvilken teknologi du bruker til å utføre en postendring, går alle endringer gjennom lagringsrekkefølgen. Det betyr at i tillegg til valideringsregler behandles postendringen av et hvilket som helst antall flyter før eller etter lagring, før eller etter utløsere, eskaleringsregler, tildelingsregler og mer. Hvis du ikke allerede har gjort det, må du huske å bokmerke og gjøre deg kjent med Apex utførelsesrekkefølge.

• Har skjemaet flere krav enn validering på systemnivå?
• Trenger du å angi at felt skal være obligatoriske eller skrivebeskyttede dynamisk i skjemaet?

Inndata på en flytskjerm eller et Omnikanal-trinn er av natur ubundet, så selve skjemaet følger ikke som standard med validering på systemnivå som er knyttet til et bestemt objekt. Uansett hvilke verdier du bruker til å opprette eller oppdatere poster, behandles imidlertid av lagringsrekkefølgen, som betyr at de går gjennom objektets validering på systemnivå. Vær imidlertid oppmerksom på at ikke alle skjermflytkomponenter støtter validering av inndata. Fra og med Summer '24-utgivelsen er de gjenværende skjermkomponentene som ikke støtter inndatavalidering, Valgknapper, Valgliste, Flervalgliste, Avmerkingsboksgruppe og Valgoppslag.

På samme måte som i sideoppsett kan du bruke dynamiske skjemaer til å angi nødvendighet og skrivebeskyttet status på sidenivå. Du kan imidlertid ikke overstyre innstillinger på systemnivå.

Flyt gir fleksibilitet til å tilpasse validering på inndata i et skjema. Enkelte kontroller utføres i klienten (som å flagge manglende nødvendige felt eller ikke-kompatible verdier), men ingen av valideringene på klientsiden hindrer brukeren i å prøve å navigere. Den faktiske valideringen skjer på serveren. Når en bruker klikker på Neste, sender Flyt inndataene til serveren for validering. Hvis noen inndata returneres som ugyldige, blokkeres navigeringen og den riktige feilen vises. Serveren validerer inndataene ved å kontrollere:

1. Inndataens nødvendighetsinnstilling, eller om den oppgitte verdien er kompatibel med den underliggende datatypen.
2. Tilpasset validering for disse inndataene: Flere standardkomponenter (Avmerkingsboks, Valuta, Dato, Dato/klokkeslett, Område med lang tekst, Tall, Passord og Tekst) støtter tilpasset validering per skjerm. Oppgi et boolsk formeluttrykk og en feilmelding som skal vises når formeluttrykket ikke oppfylles.
3. Tilpasset validering på den underliggende komponenten: Hvis du bygger en tilpasset LWC for en flyt, legger du til din egen valideringskode i validate()-metoden.

OmniStudio har omfattende feilhåndtering og validering via handlingen Angi feil i kombinasjon med betingede visninger og komponenten Meldinger.

På LWC-siden utfører de fleste basiskomponenter sine egne valideringer på klientsiden. Lightning respekterer for eksempel krav på systemnivå, men ikke krav på sidenivå. For dine tilpassede komponenter kan du Build Your Own valideringsmekanismer.

Felt som krever at brukere skriver inn data, bør vises tidlig i skjemaene. Valider brukerinndata på klientsiden før skjemaer sendes inn når det er mulig. Hvis du vil vite mer om gode fremgangsmåter for å effektivisere skjemaene, kan du se veiledningen for skjemaer i Salesforce Well-Architected - Engaging.

Sikkerhet er et komplekst emne generelt, og når det gjelder å bygge skjemaer, er det en rekke viktige punkter som du kanskje ikke engang har tenkt på. På grunnnivå vil du forsikre deg om at skjemaet kjører i riktig kontekst og at brukere har tillatelsene de trenger for å arbeide med de underliggende dataene. Men utover det vil du kanskje også iverksette ekstra tiltak for å fjerne potensielt skadelig kode eller URL-adresser fra felt for rik tekst, hindre at bestemte brukere overhodet får tilgang til skjemaet eller sette begrensninger på hvilke typer steder administratorer potensielt kan bygge inn skjemaet i fremtiden. Pass på å dokumentere sikkerhetskravene grundig før du velger et verktøy. Den velbygde Salesforce sikkerhetspolicymalen inneholder retningslinjer for denne typen dokumentasjon.

• Skal skjemaet sjekke brukerens tilgang før du utfører bestemte operasjoner?
• Skal du rense brukerinndata?
• Vil du bestemme hvem som skal ha tilgang til skjemaet?
• Vil du bestemme hvor skjemaet kan bygges inn?

Når noe kjører i brukerkontekst, håndhever Salesforce en rekke tilgangskontroller, inkludert verifisering av feltnivåsikkerhet, CRUD-tillatelser og posttilgang basert på organisasjonens delingsregler. Så brukere kan for eksempel kjøre et saksoppdateringsskjema bare hvis de har mulighet til å oppdatere saker, den riktige feltnivåsikkerheten og tilgang til den aktuelle posten. Men hva hvis du vil at brukere skal kunne utføre en bestemt operasjon når de bruker ditt skjema, men ikke gjennom noen annen form eller interaksjon? Det er her systemkonteksten kommer inn.

Systemkontekst er en måte å øke kjørende brukers tillatelser på for økten, slik at brukeren for eksempel ikke trenger Oppdater-tilgang til Sak-objektet for å fullføre saksoppdateringsskjemaet riktig. Dette er spesielt nyttig for ikke-godkjente fellesskap. I stedet for å gi gjestebrukere potensielt farlige muligheter, angir du at skjemaet skal kjøres i systemkontekst.

Systemkontekst er selvfølgelig et dobbeltsværd, og du bør bruke det bare når det er nødvendig. Når et skjema kjører i systemkontekst, omgår hver enkelt CRUD-operasjon sikkerhet og deling på objekt- og feltnivå – ikke bare den spesifikke operasjonen du bryr deg om. Vær også oppmerksom på at systemkonteksten ikke har noen betydning for hvem Salesforce vurderer som aktør – navnet du ser i feltet Sist endret av. For hver operasjon som skjemaet utfører, som saksoppdateringen, er aktøren den kjørende brukeren selv om skjemaet kjører i en annen kontekst.

Dynamiske skjemaer, Omniskript og LWC-er kjører alltid i brukerkontekst, og det er ingen måte å overstyre denne virkemåten på.

Skjermflyter kjører som standard i brukerkontekst, men du kan angi dem til å kjøre i systemkontekst. Det er ditt valg om flyten skal gi tilgang til alle data, eller om den fremdeles skal håndheve tilgang på postnivå, som deling.

• Hvis du bygger inn en Lightning i en flyt som kjører i systemkontekst, overstyrer ikke flyten komponentens kontekst. Hvis du trenger å omgå brukertilgangskontroller, anbefaler vi at du bruker flyten til å utføre disse operasjonene og overføre de riktige dataene til eller ut av Lightning. Enkelte forhåndsdefinerte komponenter (som Oppslag) kan ikke fungere i systemkontekst.
• Hvis flyten kaller opp Apex, er det noen flere nyanser du må forstå. Hvis Apex angis til arvet deling, kjøres den i systemkontekst med deling uavhengig av hva flyten er angitt til. Hvis klassen ikke har noen eksplisitt delingsdeklarasjon, kjøres den i systemkontekst uten deling uansett hva flyten er angitt til. Hvis klassen angis til med deling eller uten deling, gjør den det og overstyrer flytens kontekst.

Spørring etter poster i systemkontekst med Experience Cloud-nettsteder:

Hvis du kjører en flyt i systemkontekst på et Experience Cloud-nettsted, spesielt ikke-godkjent, anbefaler vi deg å lagre bare spesifikke felt i Hent poster-elementene. Når du arbeider med Flyt og overfører resultatene av et Hent poster-element til en underflyt, kallbar handling eller en Lightning, kan alle felt fra dette objektet inspiseres via nettleserens utviklerverktøy. Det kan gjøre felt tilgjengelig for Experience Cloud-nettstedsbrukere som du kanskje ikke har tenkt. Ved å angi spesifikke felt i Hent poster-elementene kan du sikre at bare de riktige feltene vises selv med systemkontekst aktivert.

Vær oppmerksom på at Omniscript-logikk kjører på klientsiden, noe som gjør det mulig for angripere å endre den forventede utførelsen av et Omniscript og vise svar på integrasjonsprosedyrer, datatilordninger og Apex-metodekall ved bruk av nettleserens utviklerverktøy. Når du bruker Omniscript, anbefaler vi å utføre forretningslogikk på serversiden når det er mulig og implementere inndatavalideringsregler på eventuelle Apex-metoder som vises via en @InvocableMethod-notasjon.

Sanitizing Inputs:

Vurder også inndatahåndtering for å beskytte organisasjonen mot dårlige aktører. Anta at du har en inndata i et offentlig tilgjengelig skjema som kan tilordnes til et felt for rik tekst i organisasjonen. Du bør kanskje vurdere automatisering som fjerner eventuell HTML-kode som kan skjule skadelige URL-adresser. Generelt sett er det ikke ideelt å implementere denne rengjøringen på skjemanivå fordi du kan få et hvilket som helst antall kilder til å skrive til disse feltene. Vi anbefaler å opprette en hurtig feltoppdateringsflyt (før lagring) eller bruke en eksisterende Apex på objektet til å fjerne eller endre eventuelle potensielle HTML-kode som kan skrives inn i skjemaet.

Gode fremgangsmåter:

• La flyter kjøre i sin standardkontekst med mindre du trenger å øke den kjørende brukerens tilgang for en bestemt operasjon.
• Unngå å kjøre flyter i systemkontekst for gjestebrukere av sikkerhetsgrunner. Opprett i stedet tillatelsessett med begrenset felttilgang tildelt til Experience Cloud-nettstedets gjestebrukerprofil.
• Når du spør etter poster i systemkontekstkjørte flyter på Experience Cloud-nettsteder, lagrer du bare feltene du trenger, i Hent poster-elementet eller Kallbare handlinger.
• Hvis en flyt utfører en rekke operasjoner og ikke alle krever økt tilgang, bruker du underflyter til å isolere operasjonene som skal kjøres i systemkontekst.
• Hvis du planlegger å bygge inn et skjema på en ekstern nettside, kan du vurdere å rense brukerinndata for å fjerne HTML ved hjelp av en hurtig feltoppdateringsflyt eller Apex-utløser hvis de til slutt vil bli tilordnet til felt for rik tekst for å hindre potensielle phishingangrep fra skadelige aktører.

• Omniskript, FlexCard og LWC kjører som standard i brukerkontekst.
• LWC-er kjører som standard i brukerkontekst og flyter kjører i brukerkontekst, men du kan overstyre dette i en Apex.
• Operasjoner som utføres via brukergrensesnittets API, kjøres i brukerkontekst.
• Operasjoner som utføres via en Apex, avhenger av denne klassen. For å utføre disse operasjonene i systemmodus angir du Apex til med deling eller uten deling.

Hvis du trenger kontroll over hvem som skal ha tilgang til skjemaet, kan du ofte se på beholderen som skjemaet er innebygd i. Du kan for eksempel tildele Lightning til å være tilgjengelig for bestemte apper, posttyper eller profiler. Hvis visse inndata i skjemaet er sensitive, bruker du synlighetsregler til å bestemme ytterligere hva som skal vises til hvem. Denne funksjonen gjelder både dynamiske skjemaer og skjermflyter.

Du kan begrense en flyt til bestemte profiler eller tillatelsessett, på samme måte som du kan en Apex-klasse eller Visualforce-side. Flyter er som standard ubegrensede, som betyr at alle brukere med brukertillatelsen Kjøre flyter, kan kjøre dem.

Hvis du bruker OmniStudio, kan du konfigurere en Apex-klassetillatelsessjekker for å sikre at brukere trenger eksplisitt tilgang til Apex-klassen som administrerer den eksterne handlingen som kalles fra et Omniscript-, Flexcard-, Classic-kort eller REST API.

• Merk av at tillatelseskontroller for Apex er aktivert som standard for nylig opprettede skript. De må imidlertid aktiveres manuelt for eventuelle eksisterende skript
• Vær også oppmerksom på at tillatelseskontroller for Apex gjelder bare for Apex. Vi anbefaler også å angi tillatelser på profilnivå for integrasjonsprosedyrer og datatilordnere.

Se følgende for å få flere detaljer om og gode fremgangsmåter for gjestebrukertillatelser:

• Gode fremgangsmåter for gjestebrukerposttilgang
• Utvikle sikre nettsteder: Godkjente brukere og gjestebrukere

Gode fremgangsmåter:

• Hvis du viser en flyt til gjestebrukere, gir du gjestebrukerprofilen bare tilgang til flytene de trenger. Selv om det er mulig å legge til Kjøre flyter i gjestebrukerprofilen, anser vi dette som en risikabel praksis.
• Vær spesielt forsiktig med flyter som opererer i systemkontekst. Vi anbefaler sterkt at du begrenser disse flytene til et bestemt sett brukere, siden de har færre kontroller og balanser på plass for å beskytte dataene dine.
• Sikre deg om at alle OmniScript som kjører Apex i et gjestebrukerfellesskap, har "med deling" i Apex-klassedefinisjonen.
• I Gjestebruker-profilen din tildeler du bare de Apex-klassene som du vil at gjestebrukere skal kunne ringe, eller du risikerer utilsiktet å vise ekstra forretningslogikk til gjestebrukere.

For LWC-er kan du kontrollere den kjørende brukerens tillatelsestildelinger for å bekrefte om de har en bestemt standard eller tilpasset tillatelse. Direkte fra JavaScript kan du importere Salesforce-tillatelser fra @salesforce/userPermission- og @salesforce/customPermission-omfangsmodulene. Eller du kan bruke Apex til å sjekke det samme.

Lightning-nettkomponenter er tilgjengelig på et gitt sted bare når de er lagt til som et gyldig mål. Du kan for eksempel gjøre en komponent tilgjengelig på postsider og ikke tilgjengelig som et verktøylinjeelement.

Når en skjermflyt er aktivert, blir den tilgjengelig på alle steder som skjermflyter støttes for, uavhengig av om du har tenkt at den skal være tilgjengelig overalt eller ikke. Med det sagt støtter Flow Builder flere typer flyter som har skjermer. Brød-og-smør-typen er Skjermflyt, men det finnes noen andre spesialiserte typer som er begrenset til bestemte steder. Field Service-mobilappen støtter for eksempel bare - du gjettet det - Field Service Mobile-flyter. Det samme gjelder for kontaktforespørselsflyter, som støttes bare i Experience Cloud.

Uavhengig av flyttypen har den enkeltpersonen som lager flyten, ingen kontroll over hvor flyten kan bygges inn. Flyten vil være tilgjengelig på alle steder som støttes for denne flyttypen.

Hvis du bruker Salesforce-bransjer, er det en liten advarsel når det gjelder Omniscript: Du kan ikke angi et mål for et eget Omnikanal, men du kan angi et for FlexCard-kortet som du kanskje vil bygge inn i det.

Statiske skjemaer er en fortid. I dag handler det om å oppdatere skjemaet dynamisk med de riktige egenskapene og verdiene for denne brukeren, denne gangen, dette stedet. La oss snakke om hva som er mulig i denne venen for Salesforces skjemabyggeverktøy.

• Hvilke typer interaksjoner eller tilstander skal utløse dynamiske svar i skjemaet?
• Trenger du å utføre off-skjerm-operasjoner i bakgrunnen når skjemaet fylles ut?
• Trenger du å angi felt som synlige, nødvendige, skrivebeskyttede eller deaktiverte eller endre formatering basert på skjemainndata?

Interaktivitet i skjermflyter er nå en realitet takket være Reaktive skjermer. Med Reaktivitet kan enkeltkomponenter på en flytskjerm kommunisere med hverandre, noe som gjør skjermflyter uendelig kraftigere.

Utfør dataoperasjoner utenfor skjermen: Skjermflyter tilbyr en deklarativ tilnærming til henting av data på samme skjerm via skjermhandlinger. Skjermhandlinger kan la deg utløse automatisk startede flyter ved eventuelle endringer på skjermen eller når en bruker klikker på en Handlingsknapp-komponent. Du kan deretter tilordne resultatene av disse automatisk startede flytene til samme skjerm, slik at brukere ikke trenger å navigere til en annen skjerm.

LWC tilbyr en hel rekke kabeladaptere som gir deg tilgang til Salesforce-data for å fylle ut data i skjemaets komponenter dynamisk, og gir utviklere mulighet til å oppdatere, slette og opprette poster via Apex.

_ Lightning Web Components Off-Screen Data Operations_

Synlighet: Synlighet kan kontrolleres dynamisk i alle verktøy for bygging av skjemaer. Dynamiske skjemaer, Flow Builder og OmniStudio håndterer dette med komponentsynlighetsfunksjoner. Med denne kan du deklarativt vise eller skjule felt basert på andre verdier i skjemaet eller om brukeren er på en mobilenhet eller ikke.

• Med dynamiske skjemaer kan synlighet kontrolleres basert på postfeltverdier, poster relatert via oppslagsfelt og formfaktor.
• Med Flyt kan du basere en synlighetsregel på andre inndata på skjermen i tillegg til andre ressurser som er fylt ut tidligere i flyten, som formler eller verdier fra andre poster.
  • Enhetbaserte regler: Det er ikke åpenbart fra start av, men du kan bruke en formel til å vise eller skjule et bestemt felt når brukeren er på en mobilenhet. Skriv en flytformel som kontrollerer verdien av den globale variabelen $User.UIThemeDisplayed. Hvis verdien er Theme4t, er brukeren i Salesforce-mobilappen.
  • Evaluering av andre ressurser: Manuelle variabel- og formelreferanser evalueres bare på serveren. Så uansett hvilken verdi denne ressursen har når skjermen gjengis første gang, er verdien den vil ha til du navigerer til en annen skjerm. Ved navigering sender flytkjøretiden en forespørsel til flytmotoren (serveren) og henter tilbake de nyeste verdiene for de manuelle variablene og formlene. Hvis du forventer at synlighetsregelen oppdateres etter hvert som brukeren går gjennom en enkelt skjerm (for eksempel ved oppblåsing), må du forsikre deg om at du bare refererer til verdier fra de andre komponentene på skjermen.
• Med OmniStudio kan du betinget vise eller skjule komponenter ved å konfigurere en Betinget visning-egenskap. Du kan imidlertid ikke legge til flere enn én betinget visningsegenskap for en inndata.

Betinget inndatatilstand: Hvis du må styre andre egenskaper dynamisk, som om et felt er nødvendig, deaktivert eller skrivebeskyttet, har du noen alternativer. Som forventet gir LWC deg full, reaktiv kontroll over inndatatilstanden. Med komponenter for reaktive skjermflyter kan du dynamisk styre komponentavtrykk som Skrivebeskyttet, Deaktivert og Nødvendig for standardkomponenter som støtter den, mens Omni Studio støtter hele spekteret av komponentspesifikke attributter. Hvis kravene dikterer at du trenger Flyt, og komponenten ikke støtter en bestemt attributtstatus, kan du opprette en innebygd LWC for å oppnå en dynamisk inndatatilstand.

Hvis du må kontrollere andre egenskaper dynamisk, som om et felt er obligatorisk eller skrivebeskyttet, er LWC det beste alternativet på kort sikt, der du har full kontroll. Det gjelder spesielt hvis du har tilpassede krav til hvordan du håndterer onblur eller onclick.

Reaktive LWC-er i skjermflyter: Når du bygger LWC-er som både kan reagere på og endre andre komponenter i en skjermflyt, kan du lese denne veiledningen for beste fremgangsmåter for skjermflyter for å sikre at komponentene integreres godt i flytkjøretidsmotoren og fungerer som forventet i fremtiden.

Nå for tilpassede hendelser. Hvis noen av inndataene eller hele skjemaet trenger å kommunisere med noe annet på siden, er LWC det eneste alternativet.

• Hvis du vil kommunisere i samme DOM-tre, bruker du CustomEvent-grensesnittet.
• Bruk Lightning Messaging Service til å kommunisere på tvers av DOM-et.
• Hvis Lightning Messaging Service ikke støttes for målbeholderen, bruker du pub/sub-modulen.

• Hvis du vil ha mer informasjon, kan du se Kommunisere med hendelser og kommunisere på tvers av domenenavnet i Lightning Web Components Dev Guide.
• For OmniStudio kan du se Kommunisere med Omniscript fra en Lightning-nettkomponent.

For å gi den beste brukeropplevelsen må du forsikre deg om at skjemaets stil er konsistent med resten av appen eller nettstedet der den er innebygd. Oppnåelse av dette kan bety alt fra å bruke standardmaler fra Salesforce til å opprette tilpasset CSS som utnytter alle piksler i utformingen for å gi et skarpere utseende.

• Hvor avansert er den ønskede stilen og CSS-koden?
• Trenger du tilpasset, pikselperfekt stil eller er du ok med standardtemaer?

FlexCard er det eneste produktet som dekkes i denne veiledningen, som gir deg mulighet til å deklarativt kontrollere stilen og oppsettet for grensesnittet du bygger i verktøyet direkte – enten det er marginer og utfylling, typografi, farger og så videre.

Både dynamiske skjemaer og flyter tar hensyn til deklarative temafunksjoner. Hvis du trenger kontroll ut over hva Salesforce-temaer, eller Opplevelsesbygger-merkeprofileringssett eller LWR Experience Cloud-nettsteder støtter, kan du vurdere en programmatisk løsning.

For team som er komfortable med å arbeide med CSS, har du noen alternativer:

• Flyter og LWC-er arver standard designtokener.
• Omniskript og FlexCard inkluderer støtte for et tilpassbart utformingssystem: Newport.
• Med LWC kan du skrive dine egne komponenter og fullt ut kontrollere HTML- og CSS-koden for dem.

Der det er mulig anbefaler vi å bruke temaer og utformingssystemer slik at utseendet ditt brukes konsistent på tvers av alt innholdet.

Påminnelse: Du kan bygge inn Lightning i flyter. Så hvis du trenger pikselperfekt kontroll over utseendet til skjemaet, men vil bruke de andre fordelene med flyter, som navigeringsmodellen, kan du få det beste fra begge verdener. Det samme prinsippet gjelder for Omniskript og FlexCard.

Å velge et godt oppsett er avgjørende for å utforme strømlinjeformater som muliggjør rask og effektiv dataregistrering og øker dataintegriteten. Se Salesforce Well-Architected - Forms for å få mer informasjon om dette emnet.

• Hvordan kan du bruke skjemaoppsettet til å optimalisere brukeropplevelser?
• Hvordan kan du presentere eksisterende data til brukerne på en måte som gjør det enklere for dem å legge inn nye data i skjemaene?

Dynamiske skjemaer støtter oppsett med to kolonner og kan deles opp i individuelle deler med felt. Disse delene kan plasseres i komponenter som faner og overganger for å opprette brukervennlige og organiserte oppsett.

Flyter kan eventuelt gjengis med Del-komponenten. Med deler kan du legge til opptil fire kolonner og så mange deler du ønsker, på flytskjermen. Komponenten er også responsiv for skjermbredde slik at den kan fungere på mindre skjermer. Til slutt gir den deg mulighet til å bruke betinget synlighet på hele delen, slik at det blir enklere å masseutføre synlighet på flere felt i delen. Flytdeler støtter også kolonneoverskrifter og gir en samsvarslignende opplevelse der brukere kan skjule hele delen ved å klikke på på etiketten.

Omniskript har en rekke oppsettalternativer for visning av felt og data. Du kan opprette deler av data med opptil 12 kolonner, inkludert vilkårlig skjulbare overlappinger.

Med LWC kan du bruke Lightning |vis]-skjema og det støttende Lightning |utdata]-feltet til å styre oppsettet. De eneste oppsettbegrensningene er de fra HTML/CSS. Lightning respekterer avsnittskonfigurasjonen i det tilknyttede sideoppsettet. Hvis en del for eksempel består av to kolonner i sideoppsettet, er den to kolonner i denne komponenten.

Hvis skjemaet vil være tilgjengelig for brukere i forskjellige områder eller som snakker forskjellige språk, må du forsikre deg om at verktøyet du bruker til å bygge det, oppfyller lokaliseringskravene dine. Se Salesforce Well-Architected - Localization for å få mer veiledning og anbefalinger. Når det gjelder skjemaer spesielt, involverer lokaliseringskrav vanligvis oversettelse av tekstelementer til andre språk.

• Skal skjemaet brukes i mer enn ett land eller område?
• Trenger teksten i skjemaet å være lokalisert til andre språk?

Hvis du har lokalisert de tilpassede feltene, respekteres disse oversatte etikettene i dynamiske skjemaer. Dynamiske skjemaer tar også hensyn til tilpassede etiketter du har tildelt komponentetiketter og -attributter i Lightning-appbyggeren.

Med kraften i Translation Workbench støtter Flyt oversettelse av brukervennlige etiketter for alle standard og tilpassede skjermkomponenter. Du kan lokalisere etiketten, hjelpeteksten og feilmeldingen for disse skjermkomponentene: Tekst, Område med lang tekst, Tall, Valuta, Avmerkingsboks, Valgknapper, Valgliste, Flervalgsliste, Avmerkingsboksgruppe, Passord, Dato og Dato/klokkeslett.

Det er ingen innebygd oversettelsesstøtte for ferdige handlinger, som Send e-post eller Legg inn i Chatter. Det finnes imidlertid en løsning! Hvis du definerer de oversatte etikettene med en tilpasset etikett, kan du referere til den tilpassede etiketten i handlingen eller komponenten når du konfigurerer den i Flow Builder. Opprett en flytformel som refererer til den tilpassede etiketten, og referer til denne formelen på de riktige stedene i flyten.

Omniskript bruker tilpassede etiketter til oversettelser. Se hjelpedokumentet for å gjøre Omniskript klar på flere språk.

Nå for LWC. Enkelte basiskomponenter arver automatisk oversettelser av det tilknyttede objektets felt, hjelpetekst og valideringsmeldinger hvis de er konfigurert i Translation Workbench (for eksempel Lightning).

Hvis du trenger å introdusere nye oversettbare etiketter i koden din, er tilpassede etiketter fremdeles den ukjente helten. Deklarer den tilpassede etiketten du trenger, og importer den deretter til komponenten fra @salesforce/etikettomfangsmodulen.

Det finnes flere ende-til-ende-verktøy for automatisering av tester (for eksempel Selenium), som lar deg simulere hvordan brukeren samhandler med skjemaet. Du kan skrive disse testene for hvilket som helst standard eller tilpasset brukergrensesnitt, inkludert Lightning og skjermflyter. Det er imidlertid viktig å merke seg at disse typene tester ikke kan bekrefte utdataene for hver metode som utføres. Pass på å ta dette i betraktning når du tenker gjennom kravene til grensesnittautomatisering.

• Trenger du automatisk testing av skjemaet?
• Hvilke typer tester trenger du å utføre?
• Hvilket detaljnivå trenger du i testautomatiseringene?

Vurder dine krav til grensesnittautomatisering.

Enhetstester muliggjør mer detaljert automatisering og validering som fungerer med bransjestandard CI/CD-systemer og -verktøy, som kan teste komponentens forretningslogikk, JavaScript-kontrolleren og utdataene. Hvis du går eksklusivt med lite kode, kan du ikke skrive tester selv, men Salesforce tester nøye våre ende-til-ende-tilbud.

Hvis komponentens metoder er komplekse nok til at du vil at de skal testes individuelt, plasserer du metodene i dedikerte JavaScript-filer. På den måten kan du importere dem til en LWC og til en Jest-test med noe som import { sort } from 'c/utils';.

Se UI Test Automation på Salesforce for å få en sammenligning av de ulike alternativene du har for å bygge ende-til-ende-automatisering på Salesforce. Inkludert er viktige punkter om når du skal bruke en uten kode-løsning fra en ISV, Build Your Own tilpasset test automatiseringsløsning, eller bruke et åpen kildekode test rammeverk som Selenium WebDriver eller WebdriverIO. Disse løsningene er gyldige for all brukergrensesnittinteraksjon i Salesforce, enten det er et dynamisk skjema på en Lightning, en skjermflyt på en verktøylinje eller en LWC i en flyt i en hurtighandling.

Når du har distribuert skjemaet til et produksjonsmiljø, vil du forsikre deg om at det brukes effektivt. Avhengig av bruksområdet ditt kan dette bety alt fra bare å spore antall ganger det har blitt fylt ut, til hvor mye tid brukere bruker på å fylle det ut før de sender inn informasjonen sin. Pass på å identifisere KPI-ene du vil spore, før du velger et verktøy.

• Trenger du å spore bruken av skjemaet?
• Hvilke viktige ytelsesindikatorer vil bestemme om skjemaet brukes effektivt?

Hvis du trenger å spore generell bruk og tilpassing av skjemaet, starter du med verktøy med lite kode. Både dynamiske skjemaer og skjermflyter kan spores med forhåndsdefinerte tilpassede rapporttyper, men du får mer detaljnivå fra skjermflytsporingsrapportene. Hvis du må spore bruken av en LWC, avhenger tilgjengeligheten som er ferdig klargjort, av hvor du bruker den LWC-en. Hvis den er på en Lightning, gjelder alt som er tilgjengelig for å spore bruk av Lightning, for LWC-en. Den samme historien gjelder for LWC-er som er innebygd i flyter.

Dynamiske skjemaer selv kan ikke spores ferdig, men du kan spore bruken av den overordnede Lightning-siden via Lightning-bruksobjekter. Hvis du vil spore standard Lightning-sider, bruker du den tilpassede rapporttypen Brukere med Lightning-bruk etter sidemålinger. For det samme på tilpassede Lightning-sider bruker du den tilpassede rapporttypen Brukere med Lightning-bruk av FlexiPage-målinger.

For å spore bruk av det spesifikke skjemaet (ikke bare siden det befinner seg på), har flyten deg dekket. Bruk Eksempel på flytrapport: Skjermflyter” for å svare på spørsmål som:

• Hva er fullføringsgraden for dette skjemaet? Er det godt tatt i bruk?
• Hvor lang tid tar det for brukere å fylle ut dette skjemaet?
• Hvilken skjerm bruker brukerne mest tid på?
• Hvor ofte navigerer brukere bakover?
• Hvor ofte oppstår det feil?

Hvis standardrapporten ikke oppfyller behovene dine, kloner du den for å gjøre dine egne endringer eller Build Your Own fra bunnen av ved å bruke rapporttypen Skjermflyter.

Hvis du bruker den pakkebaserte Omniscript-kjøretiden, kan du bruke OmniStudio for Vlocity Tracking Service. Denne tjenesten sporer hvilken som helst type hendelse. Du kan for eksempel spore hvor lang tid det tar å fullføre trinnene i et Omniscript for å identifisere prosessforbedringer. Det er på OmniStudio-teams veikart å støtte denne tjenesten i Standard OmniStudio.

Hvis du vil spore det samme for en LWC som ikke er innebygd i en skjermflyt, Omniscript eller Lightning, er det ikke noe forhåndsdefinert alternativ. Du kan bygge en tilpasset løsning med Apex.

Når du trenger å distribuere løsningen til høyere miljøer for testing eller distribusjon til produksjon, kan du bli brukt til å bruke endringssett eller DevOps Center til å gjøre det. Dynamiske skjemaer, flyter og LWC-er støttes fullt ut i disse distribusjonsalternativene. OmniStudio krever et eget verktøy: IDX Workbench.

• Hvordan planlegger du å distribuere skjemaet?
• Blir skjemaet distribuert til flere enn én Salesforce-organisasjon?

Hvis du er en ISV eller partner som planlegger å pakke opp løsningen for distribusjon på AppExchange, anbefaler vi at du ser på dynamiske skjemaer, flyter og LWC-er først. OmniStudio støtter ikke pakking.

Denne veiledningen har fokusert på å hjelpe deg med å forstå hvilken funksjonalitet og nivå av tilpassing som er mulig med dynamiske skjemaer, skjermflyter, OmniStudio og LWC. På et høyt nivå:

• LWC er det mest tilpassbare og robuste alternativet for å bygge et skjema, men det har færrest vaktskjermer på plass. Det er opp til deg å bygge en komponent på en måte som sikrer sikkerhet og skalerbarhet.
• Dynamiske skjemaer er det minst fleksible, men det er langt færre muligheter for feiltrinn.
• Flyt og OmniStudio er et sted i midten – kraftigere enn dynamiske skjemaer, men ikke helt på LWC-nivå. På samme måte har de færre sikkerhetsregler enn dynamiske skjemaer, men er vanskeligere å bryte enn tilpasset kode.

Hvis flere verktøy passer regningen, kommer avgjørelsen ned til hvilket verktøy som er riktig for teamet. Andre Arkitektbeslutningsveiledninger introduserer flere aspekter å vurdere når du tar denne beslutningen.

Vi vil ikke gå inn i detaljene om hvert av disse aspektene her, men det vi skal gjøre, er å tolke dem for de spesifikke verktøyene dette dokumentet vurderer.

Spesialiserte kvalifikasjoner: Hvor mye ekspertise har teamet ditt i verktøyene du sammenligner? Hvor mange makere er velkomne og kjent med LWC eller JavaScript? Hva med makere som er eksperter i Flow Builder eller har uttrykt interesse for å dykke tærne? Generelt sett er dynamiske skjema- og flytkvalifikasjoner mer tilgjengelige for en større gruppe personer som bygger skjemaer. Dynamiske skjemaer er det mest deklarative verktøyet for skjemabygging og vil alltid være enklere å lære enn Flyt. Med det sagt er Flyt-teamet forpliktet til å få denne stolpen så lav som mulig. Når det gjelder kompleksitet, ligger OmniStudio et sted mellom Flyt og LWC og tilbyr betydelige superstyrker for formbygging.

Delegasjon av levering: Bare fordi noen av kravene krever LWC, betyr ikke at hele løsningen må bygges med LWC. Vurder hvordan du kan bygge løsningen modulært, slik at delene som krever LWC, kodes, og delene som ikke er bygget i en løsning med lite kode. Det maksimerer effektiviteten til et mangfoldig team og sikrer at hver enkelt løser problemer som er riktige for spesialiseringen.

La oss nå snakke om Flyt og LWC. Med Reaktive skjermkomponenter kan skjermflytkomponenter nå snakke med hverandre på samme skjerm og låse opp en helt ny verktøykasse for arkitekter, administratorer og utviklere. Utviklere kan nå opprette målrettede, modulære komponenter som kan gjenbrukes på tvers av organisasjonen, og øke produktiviteten for alle i teamet. Utviklere kan fokusere på å løse nye utfordringer og spare tid ved å bruke en blanding av standard og tilpassede Flyt-komponenter for å oppnå formdynamikk. Med reaktive komponenter i Flyt har det aldri vært et bedre tidspunkt å blande Flyt og LWC når du bygger skjemaer.

Vedlikehold og langsiktig eierskap: Hvis du har et skjema med flere trinn, er det en god idé å starte med Flyt eller en blanding av Flyt og LWC. Hvis du har et team med lite kode som vedlikeholder løsningen, bør du tenke over hvordan du kan gjøre løsningen så konfigurerbar og utvidbar som mulig for den målgruppen. Uansett hvilket verktøy du velger, kan du organisere løsningen i komponerbare enheter for å forbedre vedlikeholds- og stabiliteten.

Når du går videre, er den anbefalte måten å konfigurere postdetaljsider på dynamiske skjemaer i Lightning ved bruk av Lightning. Det er lenge siden vi har forbedret sideoppsett, og denne trenden vil fortsette. Her er årsaken:

• Dynamiske skjemaer er mer fleksible – du kan plassere felt og deler der du ønsker, direkte i Lightning, der du kan dra nytte av deler, faner og overlappinger. Og på samme måte som du kan gjøre med komponenter på Lightning, kan du kontrollere synligheten av feltene og delene uten å definere flere sideoppsett eller posttyper.
• Med Overgang- og Fanekomponenter kan du begrense mengden felt som vises fra start av. Gjett hva det betyr? Raskere sideinnlastingstider.
• Oppsettbehandling er enklere med Lightning fordi du kan behandle alt om sidene dine fra Lightning – enten det er innholdet på siden eller hvilke brukere som har tilgang til siden. Det er ikke lenger nødvendig å gjøre oppdateringer i sideoppsettet for å få en endring til å skje på Lightning. For ikke å nevne at med de kraftige synlighetsreglene trenger du ikke lenger å opprette flere sider (eller sideoppsett) for å bestemme hvem som skal se hvilke felt når. Og det betyr også at du bare trenger å tildele brukere en Lightning i stedet for å tildele både en Lightning og et sideoppsett.

Vi anbefaler å bruke dynamiske skjemaer der det er mulig, og å gå tilbake til sideoppsett bare når det er nødvendig. Som alltid ønsker vi tilbakemeldinger i Idea Exchange om forbedringer som vil ha størst innvirkning på organisasjonen din.

Eventuelle ytelsesvurderinger som er relatert til dynamiske skjemaer, skjermflyter, OmniStudio og LWC, fokuserer på hvilke rammeverk disse teknologiene selv er basert på. De som er basert i LWC (utenom, selvfølgelig, en LWC), vil yte bedre enn de som er basert i Aura. LWC-rammeverket gir bedre ytelse fordi kjernefunksjoner implementeres innebygd i nettmotorer i stedet for i JavaScript via rammeverkabstraksjoner. Hvis du ikke er kjent, gi denne blogginnlegget en lese.

I 2019 gjorde vi en saksstudie som sammenlignet ytelsen til samme funksjonalitet i Aura kontra LWC. Som et resultat av konverteringen av DreamHouse fra Aura til LWC var ikke bare utviklingsopplevelsen langt mer i samsvar med gjeldende nettfrontendutviklingsstandarder og -mønstre, men ytelsesforbedringene var betydelige. Lab-målinger viste gevinster i området 2,4 prosent til 24,7 prosent for kald buffer og gevinster i området 31,83 prosent til 63,32 prosent for varm buffer på de samme to sidene.

Hvilket rammeverk bruker nå skjemateknologiene våre? Med andre ord: Hvilke formteknologier får nytte av denne overlegen ytelsen?

• Dynamiske skjemaer, som er integrert i Lightning, bygger på et grunnlag som bruker LWC-stabelen, noe som gir oss mulighet til å implementere noen funksjoner som vi har bedt om lenge. Som en ytelsesbonus bruker dynamiske skjemaer progressiv gjengivelse, noe som fører til forbedret sideinnlastingstid for sider som har et stort antall felt.
• Skjermflyter bygges på LWC med de fleste av de individuelle ferdige komponentene nå konvertert til LWC med unntak av to ferdige komponenter: Filopplasting og bilde. Selv om Flyt-teamet konverterte flytkjøretidsklienten til LWC og de fleste av dens komponenter, må kundene fremdeles konvertere Aura-skjermkomponentene til LWC. Ikke bare det, men Salesforce støtter bare LWC-komponenter i det nye rammeverket for aktive komponenter i skjermflyter. Det finnes en utmerket Trailhead modul som forklarer hvordan du gjør det: Lightning Web Components for Aura-utviklere. Det er selvsagt følgende: Hvis du tenker på å bygge en tilpasset komponent for en skjermflyt eller en annen beholder, går du alltid til LWC.
• Det finnes noen få versjoner av OmniStudio tilgjengelig. Hvis du er en langtidskunde, kan det hende du bruker Angular. Vi oppfordrer alle nye kunder til å starte med LWC-baserte Omniskript og FlexCard, og for eksisterende kunder til å gå over fra Angular.
• LWC er bygd på ... LWC, selvfølgelig. Dette er en gratisversjon.

Som arkitekt er det viktig å ha en solid forståelse av alle alternativene som er tilgjengelig for deg, og hvordan du kan bruke dem i ditt spesifikke bruksområde. Når det gjelder bygging av skjemaer i Salesforce, går alternativene fra lite kode (ved å bruke dynamiske skjemaer i Lightning, skjermflyter i Flow Builder og Omniscripts i Omni Studio) til pro-kode (ved å bruke LWC-rammeverket), med en kombinasjon av skjermflyter eller Omniscripts og LWC i midten. Ta hensyn til denne veiledningen og bruk den som en referanse når du planlegger å bygge eller utforme skjemaer på nytt i Salesforce. Hvis du leter etter veiledning om hvordan du utformer strømlinjeformater og nyttige skjemaer, kan du kontakte Salesforce Velbygd: Engasjerende.

Hjelp oss med å sikre at vi publiserer det som er mest relevant for deg: Ta undersøkelsen vår for å gi tilbakemelding om dette innholdet og fortell oss hva du vil se videre.