Byggebeskjemaer

Det finnes flere alternativer for å bygge skjemaer på Agentforce 360 Platform, og de spenner over en kontinuerlig rekke fra lavkodetilnærminger til pro-kodetilnærminger. På den ene enden av kontinuumet kan dynamiske skjemaer i Lightning og skjermflyter i Flow Builder brukes til løsninger med lite kode. På den andre siden brukes Lightning Web Component (LWC)-rammeverket til pro-kodeløsninger. Innenfor kontinuumet kan verktøy blandes på en rekke måter ved å bruke skjermflyter som utvides av LWC-er, og kunderettede skjemaer som bygges med OmniStudio.

Denne veiledningen presenterer et beslutningsrammeverk og veiledning om bygging av skjemaer for brukergrensesnittløsninger. Spesifikt bruker den et dusin kjøretidspunkter og ikke-funksjonelle beslutningspunkter til å velge den beste teknologien riktig for et gitt bruksområde.

• Når du bygger opprettings- og redigeringsoppsett for Lightning-sider, bruker du dynamiske skjemaer. Vi anbefaler deg å bruke dynamiske skjemaer i Lightning-appbyggeren til å konfigurere postdetaljsider.

• Hvis du må bygge, opprette eller redigere et skjema for ett objekt, bruker du Lightning-sider og dynamiske skjemaer. Dette er den enkleste måten å bygge skjemaer på Agentforce 360 Platform. Den har også tilleggsfunksjonalitet (for eksempel feltsynlighetskontroll).

• Hvis du bygger et skjema med flere sider eller en veiviser og ikke har strenge krav til brukergrensesnitt eller merkeprofilering, bruker du en skjermflyt. Skjermflyter er et lineært navigeringsrammeverk for orkestrering av flere skjemaer. Du kan bruke LWC-er til å bygge ditt eget rammeverk for navigering mellom skjemaer, men vi anbefaler at du lar Flyt gjøre arbeidet slik at du kan fokusere på selve skjemaene i stedet for å fokusere på skjemaets tilstand.

• Hvis du trenger mer logikk eller handlinger for å støtte skjemaet, bruker du en skjermflyt, OmniStudio eller LWC-er. Hvert av disse verktøyene tilbyr forskjellige måter å forbedre løsningen på ved å la den utvide seg utover å opprette eller redigere en enkelt post. I dette tilfellet kan begrepet mer referere til avansert logikk (for eksempel forgrening eller gjentagelse), eller det kan referere til handlinger som integrering med eksterne systemer, sending av e-post eller push-varsler til en brukers mobilapp.

• Hvis du har avanserte brukergrensesnittkrav, eller hvis du må håndtere synlighet av mer enn brukergrensesnitt dynamisk, bruker du LWC eller Omniscript. For krav som kan oppfylles ved bruk av tema- og kolonnebaserte oppsett, kan du bygge skjemaene direkte i en lavkodebygger. Men detaljert kontroll over skjemaets stil krever fleksibiliteten til LWC. Hvis du er bransjekunde – og du trenger pikselperfekt merkeprofilering eller har komplekse hierarkiske data – bruker du Omnistudio, som lar deg bygge skjemaer i forbrukernivå som kan håndtere komplekse forretningslogikk- og datatransformasjoner.

• Hvis du trenger å distribuere testautomatisering, bruker du LWC. Du kan skrive enhetstester for en hvilken som helst LWC uavhengig av hvor du bygger den inn. Dette gir mulighet til å opprette en mer robust teststrategi, som kan inkludere massetesting med flere poster i tillegg til negativ testing.

• Du er ikke bundet av enten/eller-beslutninger. Du kan kombinere flere alternativer for å nå den beste løsningen for brukstilfellene dine (hvis du for eksempel trenger Flyts innebygde navigeringssystem og den fulle stylingfleksibiliteten LWC tilbyr, kan du bruke dem sammen).

Følgende verktøy brukes vanligvis til å implementere og utvide skjemaopplevelser.

Denne tabellen viser verktøyene som er tilgjengelig for å bygge skjemaer via Salesforce, sammen med deres nødvendige kvalifikasjoner og lisensvurderinger.

Notat: Vi vil gå dypere inn i de spesifikke funksjonene som støttes for hvert verktøy, hvordan du velger mellom klikkbaserte verktøy og kodebaserte verktøy, og når du kan kombinere dem i en senere del.

Det er en rekke beslutningspunkter du bør være oppmerksom på når du gjør produkt- og verktøyvalg. Denne tabellen beskriver ulike beslutningspunkter og gir veiledning på høyt nivå.

Notat: I etterfølgende beslutningssammenligningstabeller er det en håndfull verdier som er knyttet til hvilket som helst verktøyfunksjonspar:

• Tilgjengelig: Verktøyet/funksjonen fungerer med grunnleggende vurderinger.

• Ikke tilgjengelig: Det er ingen planer om å legge til støtte de neste tolv månedene.

• Ikke ideelt: Dette verktøyet/funksjonen kan fungere, men det er ikke det optimale verktøyet.

• Gjelder ikke: Verktøyet gjelder ikke for det bestemte bruksområdet.

Bruk disse scenariene til å sammenligne verktøyvalg basert på omfang, brukergrensesnitt og operasjonelle behov.

Hvis du kan hente alle brukerinndataene fra et enkeltskjermskjema, starter du med dynamiske skjemaer. Husk at dynamiske skjemaer på postsider kan bruke Bane-funksjonen til å støtte fasede forretningsprosesser.

• Trenger du en enkelt skjerm eller må brukeren navigere mellom flere skjermer for å utføre en oppgave?

• Ønsker du at brukerne skal se et visuelt bilde av hvor langt de er i prosessen når de fyller 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, avhenger valget mellom Flyt, OmniStudio og LWC av noen få flere spørsmål:

• Er det OK å vise en navigeringslinje nederst i skjemaet? Hvis navigeringsopplevelsen Skjermflyt og Omnikanal gir 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, bruker du en flyt. Til komplekse relasjoner med flere objekter bruker du Omniscript eller LWC.

Hvis du velger Flyt eller OmniStudio, må du kanskje også bygge en LWC for å oppnå riktig brukergrensesnitt. Hvis du allerede bygger en LWC for å utforme skjemaet riktig, bør du vurdere om det er nødvendig å bygge inn denne komponenten i en flyt.

Veiviserstilnavigering

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 har en innebygd navigeringsmodell slik at du ikke trenger å 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.

Omnistudio tilbyr en viktig navigasjonsfordel ved å tilby fremdriftsindikatorer fra standardnavigering som viser trinn i skjemaet. Trinnvisningen viser automatisk hvor en bruker er i et skjema med flere trinn. Til forskjell fra Flyt lar den brukere hoppe mellom skjermer ved å klikke på forskjellige trinn i skjemaet.

Enten du bygger enkeltskjerm- eller flerskjermskjemaer, er det viktig å sikre at skjemaene dine er strømlinjeformulert 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. Dynamiske skjemaer er imidlertid for øyeblikket bare tilgjengelig på skrivebordet. Hvis du vil tilby en opplevelse som gir brukere tilgang til skjemaer fra andre steder, må du kanskje 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 aktivere 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 den krever postkontekst, støttes funksjonen Dynamiske skjemaer bare på Lightning. Dynamiske skjemaer støttes imidlertid ikke på Experience Cloud-sider.

Du kan bygge flyter som krever en postkontekst, eller flyter som fungerer globalt. Med andre ord kan du bygge inn flyter på en rekke steder. For postkontekstuelle flyter kan steder inkludere følgende: Lightning, Experience Cloud-postsider, objektspesifikke handlinger eller Handlinger og anbefalinger-distribusjoner. For globale flyter kan steder inkludere følgende: verktøylinjen, andre Lightning eller Opplevelsesbygger-sider, Snap eller eksterne programmer. For øyeblikket støttes ikke flyter som globale handlinger, men du kan pakke inn flyter i en Aura-komponent som en løsning.

Med Omnistudio kan du lage komponerbare FlexCard- og Omnikanal-kort som du kan plassere nesten hvor som helst der du kan plassere en flyt, men mens de kan komponeres, kan de ikke pakkes.

LWC tilbyr en høy grad av gjenbrukbarhet for å opprette komponenter som kan knyttes til mål via metadata på tvers av Salesforce, fellesskap og prosjekter med åpen kildekode. LWC-komponenter kan også bygges inn på ditt eget nettsted med Lightning Out 2.0.

LWC-komponenter kan også starte flyter med komponenten Lightning-Flow.

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

For øyeblikket støttes ingen av skjemateknologiene som dekkes i denne veiledningen, offisielt i Mobile SDK-maler. Hvis Mobile SDK er viktig for bruksområdet ditt, anbefaler vi å bygge skjemaet som standard i mobilappen eller bygge en Visualforce, samtidig som du tar hensyn til formfaktor.

Dynamiske skjemaer er perfekte hvis du må bruke verdiene i skjemaet til å opprette eller oppdatere en post. Du må benytte Flyt, Omnistudio eller LWC for funksjoner utenfor dette omfanget, inkludert å opprette beslutnings- eller gjentagelseslag eller generere Slack-innlegg eller e-postmeldinger ved bruk av inndata fra skjemaet.

• Hvilke handlinger eller logikk må utføres i bakgrunnen?

• Trenger du å bruke verdier fra en relatert post?

• 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-postmeldinger og samhandling med Quip, og du trenger ikke å skrive kode for noen av disse operasjonene. LWC tilbyr omfattende interaksjoner med enkeltposter og relaterte objekter via kabeladaptere som samhandler med brukergrensesnittet API. LWC kan også samhandle med flere poster ved å bruke tråden for getListInfoByName.

Omnistudio bruker integrasjonsprosedyrer og Datatilordning til å hente og transformere data (både eksterne og interne til Salesforce). På grunn av mange kodefrie funksjoner utmerker den seg ved å flate ut og utvide datasett med ulike nivåer av relasjoner.

Flyt, Omnistudio og LWC integreres alle med Apex, slik at du enkelt kan lukke eventuelle hull i løsningen du velger (hvis du for eksempel trenger å filtrere poster fra en LWC, kan du bruke adapteren for Apex til å opprette komplekse SOQL-spørringer. Hvis du blir overveldet av klikkebaserte historier, kan du vurdere å bruke Flyt eller Omnistudio som et levedyktig alternativ til en Apex for behovene på serversiden.

Du bør også vurdere om du vil utføre handlinger umiddelbart eller utsette dem til en bestemt del av skjemaet. Dette er spesielt relevant hvis du bruker et skjema med flere sider. Flyt gjør det enkelt å kombinere inndata fra flere skjemaer (flytskjermer) og bruke dem senere i veiviseren (flyt) til å utføre bestemte operasjoner, som er nøyaktig slik vi anbefaler å utforme flyter. Utfør handlinger på slutten (i tilfelle brukere hopper frem og tilbake mellom skjermer for å endre svarene sine).

Transaksjoner og styringsgrenser er en del av Agentforce 360 Platform. Hvis brukstilfellet er ganske enkelt, er det kanskje ikke like viktig å kontrollere transaksjonen der en bestemt operasjon skjer. 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.

Her er noen eksempler:

• Rullback: La oss si at skjemaet ditt oppretter flere poster i bakgrunnen. Hvis opprettelse av en tredje post mislykkes, skal de første to postene rulles tilbake? Hvis hver av handlingene er uavhengige av hverandre, kan du utføre dem som separate transaksjoner. Men hvis de er avhengige av hverandre – og du vil at feilene i én av dem også skal rulle tilbake de andre – bør du implementere dem som en enkelt transaksjon. Hvis skjemaet er i Flyt, kan du bruke Tilbakekall-elementet i Feil-banen til å rulle tilbake transaksjonen og sikre dataintegritet.

• Nedstrøms innvirkning på styringsgrenser: Når skjemaet oppretter eller oppdaterer en post, er det viktig å vurdere hvilke nedstrøms konsekvenser denne operasjonen har:

  • Hvilke prosesser, arbeidsflytregler, Flytutløsere, Apex eller andre elementer i lagringsrekkefølgen kan utløses basert på de foreslåtte postendringene?

  • Hvordan påvirker disse kollektive endringene styringsgrensene som forbrukes i denne transaksjonen?

  • Hvis en bestemt postendring kan føre til mange nedstrøms endringer som påvirker grensene dine, kan det være best å vurdere å isolere denne postendringen i sin egen transaksjon.

• Batchbehandling: Det kan hende du må gruppere flere oppdateringer sammen (selv innenfor en grensesnittkontekst). La oss si at skjemaet for flere skjermer gjentar seg over en stor gruppe poster. I stedet for å utføre en postoppdatering etter hver skjerm – vent til du har samlet inn oppdateringene for alle postene – og send deretter é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 inndataforespørsel til API-et.

3. API-et mottar forespørselen og åpner en transaksjon og en databasetilkobling. 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 lokal handlingsnode. 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 databasen endret (per utføringen av lagringsbestillingen), og databasetilkoblingen og transaksjonen avsluttes.

6. Klienten bruker API-svaret til å gjengi neste skjermbilde som brukeren samhandler med.

7. Start fra trinn 1, og gjenta prosessen.

Med andre ord bryter skjermer transaksjoner. Når dette skjer, bekreftes eventuelle ventende handlinger eller DML, den tidligere transaksjonen avsluttes og en ny transaksjon starter. Husk at de spesifikke utformingselementene (hvilke operasjoner du grupperer i en gitt transaksjon) er opp til deg.

Her er noen eksempler:

• Når du starter, vil du se en flyt som samler inn inndata på tvers av flere skjermer, og deretter utfører flere handlinger i én transaksjon.
• Den neste flyten utfører hver operasjon i en separat transaksjon.
• Flyter kan også bruke Tilbakevulning av poster til å gjøre det mulig å rulle tilbake en hel transaksjon hvis en enkelt operasjon mislykkes i en serie databaseoperasjoner. La oss si at du har en flyt som oppretter poster, oppdaterer poster og deretter oppretter flere poster (vist i neste flyt).

I dette scenariet vil de første to DML-operasjonene fremdeles opprette og oppdatere de riktige postene, men det tredje vil ikke. Ved å bruke elementet Rull tilbake poster kan du sikre at hele transaksjonen rulles tilbake hvis alle tre operasjonene må skje samlet (som vist i den endelige flyten).

Notat: Se flyter i transaksjoner og flytgrupper i transaksjoner for å få mer informasjon.

Muligheten til å kontrollere transaksjonen fra en LWC er basert på 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 når 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 (for eksempel en Apex eller en flyt). Husk at de vanlige transaksjonsreglene for denne teknologien fremdeles gjelder.

Flow, Omnistudio og LWC støtter alle plattformhendelser (for arrangementsdrevet arkitektur) og API-integrasjoner. I tillegg til tilpasset Apex har Flyt og Omnistudio deklarative støttemekanismer som også kan integreres med API-er.

Hvis du må koble til en MuleSoft API- eller RPA-robot, bruker du MuleSoft Services fordi dette genererer en ekstern tjeneste.

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

I alle andre tilfeller bruker du funksjonen HTTP-oppkall (leveres av Eksterne tjenester) i Flyt eller HTTP-handlingen i Omnistudio.

Omnistudio har et rikt sett integrasjonsfunksjoner som kan kalle opp eksterne systemer ved å bruke integrasjonsprosedyrer til å transformere data via Datatilordning.

Uavhengig av om du bruker tilpasset Apex-kode eller en ekstern tjeneste til implementering, er et oppkall fremdeles et oppkall.

Her er det du trenger å vite.

• Det kan ta en betydelig tid å behandle et oppkall.

• Når et oppkall utføres synkront, utføres det mens en databasetransaksjon er åpen.

• Salesforce tillater deg ikke å beholde en databasetransaksjon åpen hvis du har ventende databaseoperasjoner.

Husk at den viktigste begrensningen er faren for å forlate data i inkonsekvent tilstand, som oppstår når du utfører en opprette, oppdatere eller slette operasjon, og deretter utføre et oppkall i den samme transaksjonen. Dette mønsteret er ikke tillatt på grunn av den tredje vurderingen som er nevnt ovenfor, som finnes på grunn av de to første vurderingene.

I Flyt kan du omgå denne begrensningen ved å bryte transaksjonen. Husk at skjermer og lokale handlinger introduserer nettleserkonteksten på nytt. Du kan bruke skjermer og lokale handlinger når du arbeider med eksterne oppkall, men vi anbefaler deg å aktivere Transaksjonskontroll i de kallbare avanserte innstillingene. Med Transaksjonskontroll kan du automatisk avslutte transaksjonen før et oppkall utføres. For å aktivere Transaksjonskontroll velger du "Altid starte en ny transaksjon" i delen Avansert for den kallede handlingen. LWC bidrar til å forenkle innvirkningen av oppkall på transaksjonen. Med andre ord utfører du dataoperasjonene med Lightning (LDS), og deretter bruker du en Apex til å utføre det eksterne oppkallet. I og med at LDS-kallet er isolert i sin egen transaksjon (atskilt fra Apex), beskytter dette deg mot den resulterende datainkonsistensen.

Dynamiske skjemaer støtter ikke gjenbruk. Hver av dem er knyttet til en bestemt Lightning for et bestemt objekt, men 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 kan brukes på tvers av flere komponenter, kan du også bruke lignende utformingsmønstre når du oppretter flyter ved å utnytte kraften i underflyter. Det gjør du ved å lagre flytene i mindre, modulære samlekategorier, og deretter kalle dem opp fra andre flyter ved bruk av **Subflyt-**elementet. Hvis utformingen krever det, kan du bygge en flyt som er nyttig alene og som en underflyt.

Omnistudio er innebygd for modularitet. Datatilordninger, Omniskript, FlexCard og Integrasjonsprosedyrer er alle bygd uavhengig, men de kan også fungere om hverandre. FlexCard kan også bygges som LWC-komponenter som kan bygges inn i andre LWC-er, Omniskript, 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 kan komponeres, får du også tilpassings- og stabilitetsfordeler.

Alle teknologier som brukes til å opprette eller oppdatere poster, må overholde validering på systemnivå, enten det er klassiske valideringsregler eller tilpassede valideringer som er innebygd i en Apex. Uansett hvilken teknologi du bruker til å utføre postendringer, må alle endringer gå gjennom lagringsrekkefølgen. Det betyr at i tillegg til valideringsregler behandles postendringer også av en rekke før- eller etterlagringsflyter, før- eller etter-utløsere, eskaleringsregler, tildelingsregler og så videre.

Notat: Hvis du ikke allerede har gjort det, ser du gjennom og bokmerker Apex utførelsesrekkefølge.

• Har skjemaet noen tilleggskrav utover validering på systemnivå?

• Trenger du å angi nødvendige eller skrivebeskyttede felt dynamisk i skjemaet?

Inndata på en flytskjerm eller et Omnikanal-trinn er vanligvis ikke bundet, så selve skjemaet følger ikke som standard med valideringen på systemnivå som er knyttet til et bestemt objekt. Verdiene som du bruker til å opprette eller oppdatere poster, behandles imidlertid i lagringsrekkefølgen, som betyr at de går gjennom objektets validering på systemnivå.

Notat: Ikke alle Skjermflyt-komponenter støtter validering av inndata.

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

Flyt gir fleksibilitet til å tilpasse validering av skjemainndata. Flere kontroller utføres på klientenivå (for eksempel flagging av nødvendige felt som mangler, datatypekontroller og kompatible formler i inndatavalideringsregler). Som et ekstra sikkerhetsnivå evalueres også inndatavalidering på serveren. Når en bruker klikker på Neste, sender Flyt inndataene til serveren på nytt for validering. Hvis ugyldige inndata returneres, blokkeres navigeringen og den riktige feilen vises.

Serveren validerer inndataene ved å kontrollere:

• Inndataens nødvendighetsinnstilling, eller om den oppgitte verdien er kompatibel med den underliggende datatypen.

• Den tilpassede valideringen av inndataene. Du må oppgi et boolsk formeluttrykk og en feilmelding som skal vises når formeluttrykket ikke oppfylles.

• Den tilpassede valideringen av den underliggende komponenten. Hvis du bygger en tilpasset LWC for en flyt, må du legge til din egen valideringskode i validate()-metoden.

Du kan også gi tilgjengelige brukervarsler via komponenten Meldinger i Skjermflyter, men dette hindrer ikke at en bruker navigerer til andre sider eller går videre til neste trinn i en veiledet flyt. Feil-tilstanden i komponenten Meldinger brukes best på dedikerte feilsøkingsskjermer som utløses via en feilbane når navigering er deaktivert.

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

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

Husk at felt som krever at brukere skriver inn data, skal vises i begynnelsen av skjemaene. Valider brukerinndata på klientsiden før skjemaer sendes (når det er mulig).

Statiske skjemaer er utdaterte. I dag har fokus skiftet til dynamisk oppdatering av skjemaer med de riktige egenskapene og verdiene for en spesifikk bruker, på et spesifikt tidspunkt, på et spesifikt sted. La oss se nærmere på hva som er mulig med Salesforce-verktøy for skjemabygging.

• Hvilke typer interaksjoner eller tilstander skal utløse dynamiske svar i skjemaet?

• Trenger du å utføre offline (bakgrunns) operasjoner mens skjemaet fylles ut?

• Trenger du å angi felt som synlige, nødvendige, skrivebeskyttede eller deaktiverte, eller må du endre formateringen basert på skjemainndata?

Reaktive skjermer aktiverer skjermflytinteraktivitet. Med Reaktivitet kan enkeltkomponenter på en flytskjerm kommunisere med hverandre, noe som gjør skjermflyter mer effektive.

Utføre dataoperasjoner utenfor skjermen

Skjermflyter gir en deklarativ tilnærming til henting av data på samme skjerm via skjermhandlinger. Skjermhandlinger lar deg utløse automatisk startede flyter ved eventuelle endringer på skjermen eller når en bruker klikker på en **Handlingsknapp-**komponent. Du kan tilordne automatisk startede flytresultater til samme skjerm, noe som eliminerer behovet for at brukere navigerer til en annen skjerm.

LWC tilbyr et komplett utvalg av trådadaptere som gir tilgang til Salesforce-data for dynamisk utfylling av data i skjemakomponenter, noe som gjør det mulig for utviklere å oppdatere, slette og opprette poster via Apex-kontrollere.

Synlighet

Synlighet kan kontrolleres dynamisk i alle verktøy for å bygge skjemaer. Dynamiske skjemaer, Flow Builder og Omnistudio håndterer dette ved å bruke komponentsynlighetsfunksjoner. Du kan deklarativt vise eller skjule felt basert på andre verdier i skjemaet, eller om brukeren fyller ut skjemaet på en mobilenhet.

• Dynamiske skjemaer bestemmer synlighet basert på postfeltverdier, oppslagsfelt og formfaktor.

• Med Flyt kan du basere en synlighetsregel på andre skjerminndata i tillegg til andre ressurser som fylles ut tidligere i flyten (for eksempel formler eller verdier fra andre poster).

  • Enhetbaserte regler: Det er kanskje ikke åpenbart fra begynnelsen, 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 til den globale variabelen $User.UIThemeDisplayed. Hvis verdien er Theme4t, fyller brukeren ut skjemaet med Salesforce-mobilappen.

  • Evaluer andre ressurser: Manuelle variabel- og formelreferanser evalueres bare på serveren. Det betyr at verdien som ressursen har når skjermen gjengis første gang, er verdien den vil ha til du navigerer til en annen skjerm. Under navigering sender flytkjøretiden en forespørsel til flytmotoren (serveren), og den returnerer de nyeste manuelle variabel- og formelverdiene. Hvis du forventer at synlighetsregelen oppdateres etter hvert som brukeren går gjennom en enkelt skjerm (for eksempel ved oppblåst), 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 egenskap for betinget visning. Du kan imidlertid ikke legge til flere enn én Betinget visning-egenskap for en inndata.

Betingede inndatastater

Hvis du må styre andre egenskaper dynamisk (for eksempel om et felt er nødvendig, deaktivert eller skrivebeskyttet), er det noen alternativer. LWC gir full, reaktiv kontroll over inndatatilstanden. Med Reaktiv skjermflyt-komponenter kan du dynamisk styre komponentattributter (for eksempel skrivebeskyttet, deaktivert og nødvendig) for standardkomponenter som støtter det, mens Omnistudio 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 trenger å styre andre egenskaper dynamisk (for eksempel om et felt er nødvendig eller skrivebeskyttet), bruker du LWC på kort sikt fordi du har full kontroll. Dette gjelder spesielt hvis du har tilpassede krav til hvordan du håndterer onblur eller onclick.

Reaktive LWC-er i skjermflyter

Hvis du bygger LWC-er som kan reagere på og endre andre komponenter i en skjermflyt, kan du lese LWCs anbefalte fremgangsmåter for skjermflyter for å sikre at komponentene integreres med flytkjøretidsmotoren og fungerer som de skal.

Hvis noen av inndataene (eller hele skjemaet) må kommunisere med et annet element på siden, er LWC det eneste alternativet for tilpassede hendelser.

• 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 detaljert 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 er det viktig å sikre at stilen i skjemaet er konsistent med resten av appen eller nettstedet der den bygges inn. Det kan bety å bruke standardmaler som leveres av Salesforce, eller å opprette et tilpasset CSS som bruker hver piksel i utformingen for å gi et skarpere utseende.

Administratorer kan konfigurere et begrenset sett av skjerm- og komponentstiloverstyringer (for eksempel farger, kantlinjer og knappevisninger), for skjermbeholderen eller for individuelle komponenter. Disse overstyringene brukes etter temaer og merkeprofilering, slik at byggere kan foreta målrettede visuelle justeringer uten å påvirke resten av programmet.

Stylingoverstyringer er ment for lokaliserte visuelle unntak (for eksempel å fremheve en bekreftelsesskjerm eller fremheve et bestemt kall til handling (CTA); de er ikke et fullstendig stiliseringssystem. De gir ikke kontroll på CSS-nivå, og de er ikke utformet for å brukes på nytt på tvers av skjermer eller flyter.

Fra et arkitektonisk perspektiv bør stilen følge denne prioriteringsrekkefølgen:

1. Temaer og merkeprofilering: Lightning, Opplevelsesbygger-merkeprofileringssett eller LWR-nettstedstemaer

2. Flyttestiloverstyringer: målrettede skjerm- eller komponentjusteringer

3. Tilpassede komponenter (LWC): når pikselperfekt kontroll eller gjenbrukbare designmønstre kreves

Bruk av temaer og utformingssystemer bidrar til å sikre at stilen forblir konsistent, skalerbar og enkel å vedlikeholde over tid.

• Hvor avansert er den ønskede stilen og CSS-koden?

• Trenger du tilpasset, pikselperfekt stil eller standardtemaer?

FlexCards er det eneste produktet i denne veiledningen som gir deg mulighet til å deklarativt kontrollere stilen og oppsettet for grensesnittet du bygger i verktøyet (for eksempel marger og utfylling, typografi, farger og så videre).

Dynamiske skjemaer og flyter tar hensyn til deklarative temafunksjoner. Hvis du trenger ekstra kontroll (ut over hva som støttes av Salesforce-temaer, Opplevelsesbygger-merkeprofileringssett eller LWR Experience Cloud-nettsteder), kan du vurdere en programmatisk løsning.

Team som er komfortable med å arbeide med CSS, har flere alternativer:

• Flyter og LWC-er arver standard designtokener.

• Omniskripter og FlexCard inkluderer tilpassbar designsystemstøtte via Newport.

• Med LWC kan du skrive dine egne komponenter og fullt ut kontrollere deres HTML- og CSS-kode.

Når det er mulig, anbefaler vi å bruke temaer og utformingssystemer for å sikre et konsistent utseende på tvers av alt innholdet.

Notat: Du kan bygge inn Lightning i Flyter. Hvis du trenger perfekt kontroll over utseendet til skjemaet, men også ønsker å bruke de andre fordelene med flyter (for eksempel 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.

• Hvordan kan du strukturere skjemaoppsett for å optimalisere brukeropplevelser?

• Hvordan kan du presentere eksisterende data til brukere 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 som kan deles inn i individuelle deler i felt. Disse delene kan plasseres i komponenter (for eksempel faner og overganger) for å opprette organiserte, brukervennlige oppsett.

Flyter kan også gjengis med komponenten Seksjon. Du kan legge til opptil fire kolonner og et ubegrenset antall deler på flytskjermen. Deler-komponenten er også responsiv for skjermbredde, så den fungerer også på mindre skjermer. Den gir deg mulighet til å bruke betinget synlighet på hele delen, noe som gjør det enklere å masseutføre synlighet på flere felt i delen. Flytdeler støtter også kolonneoverskrifter og gir en harmonisk opplevelse der brukere kan skjule hele delen ved å klikke 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 oppsettrestriksjonene kommer fra HTML og CSS. Komponenten Lightning-record-form respekterer avsnittskonfigurasjonen i det tilknyttede sideoppsettet (hvis et avsnitt for eksempel består av to kolonner i sideoppsettet, er det også to kolonner i komponenten).

Hvis skjemaet må 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.

Notat: Spesifikt for skjemaer 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 lokaliserer tilpassede felt, tar dynamiske skjemaer hensyn til de oversatte etikettene. Dynamiske skjemaer tar også hensyn til eventuelle tilpassede etiketter som er tildelt komponentetiketter og attributter i Lightning-appbyggeren.

Flyt støtter oversettelse av brukervennlige etiketter for alle standard og tilpassede skjermkomponenter via Translation Workbench.

Du kan lokalisere etiketter, hjelpetekst og feilmeldinger i disse skjermkomponentene:

• Tekst
• Langt tekstområde
• Tall
• Valuta
• Avmerkingsboks
• Valgknapper
• Valgliste
• Flervalgsliste
• Passord for avmerkingsboksgruppe
• Dato
• Dato/klokkeslett

Det er ingen innebygd oversettelsesstøtte for ferdige handlinger (for eksempel Send e-post eller Legg inn i Chatter), men det finnes en løsning. Hvis du bruker en tilpasset etikett til å definere de oversatte etikettene, kan du referere til den tilpassede etiketten i handlingen eller komponenten når du konfigurerer den i Flow Builder. Det gjør du ved å opprette en flytformel som refererer til den tilpassede etiketten, og deretter referere til denne formelen på de riktige stedene i flyten.

Omniskript bruker tilpassede etiketter til oversettelser. Hvis du vil ha mer informasjon, kan du se på hjelpedokumentet for å sikre at Omnikanalene er klare for flere språk.

For LWC arver enkelte basiskomponenter 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, er tilpassede etiketter den rette løsningen. Deklarer den tilpassede etiketten du trenger, og importer den deretter til komponenten fra modulen med @salesforce/label-omfang.

Bruk denne delen til å evaluere sikkerhets-, kvalitet- og driftsbegrensninger før implementering.

Sikkerhet er et komplekst emne, og når det gjelder å bygge skjemaer, er det en rekke viktige punkter som kanskje ikke er åpenbare. På grunnnivå må du forsikre deg om at skjemaet kjører i riktig kontekst, og at brukere har tillatelsene de trenger for å arbeide med de underliggende dataene. Utover dette vil du kanskje også iverksette ekstra tiltak for å fjerne potensielt skadelig kode eller URL-adresser fra felt for rik tekst, hindre at bestemte brukere 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. Hvis du vil ha mer veiledning om denne typen dokumentasjon, kan du se Salesforce Velbygd sikkerhetspolicymal.

• 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 et program kjører i brukerkontekst, håndhever Salesforce en rekke tilgangskontroller, som inkluderer verifisering av feltnivåsikkerhet, CRUD-tillatelser og posttilgang basert på organisasjonens delingsregler (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).

Hva skjer hvis du vil at brukere skal kunne utføre en bestemt operasjon når de bruker skjemaet, men ikke via noen annen form eller interaksjon? Det er her systemkontekst kommer inn!

Med systemkontekst kan du øke en brukers tillatelser for varigheten av økten (brukeren trenger for eksempel ikke å oppdatere tilgang til Sak-objektet for å fullføre saksoppdateringsskjemaet). 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 bør brukes bare når det er nødvendig. Når et skjema kjører i systemkontekst, omgår hver CRUD-operasjon komponentene for objekt- og feltnivåsikkerhet og deling. Systemkontekst har heller ingen betydning for hvem Salesforce anser for å være aktøren (navnet du ser i feltet Siste endret av). For hver operasjon som skjemaet utfører (for eksempel en saksoppdatering), er aktøren den gjeldende brukeren (selv om skjemaet kjører i en annen kontekst).

Notat: 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. Du kan bestemme om flyten skal gi tilgang til alle data, eller om den skal håndheve tilgang på postnivå.

• Hvis du bygger inn en Lightning i en flyt som kjører i systemkontekst, overstyrer ikke flyten komponentens kontekst. Hvis du trenger å omgå brukertilgangskontroller, bruker du flyten til å utføre disse operasjonene og overføre de riktige dataene til eller ut av Lightning. Enkelte forhåndsdefinerte komponenter (for eksempel Oppslag) kan ikke fungere i systemkontekst.

• Hvis flyten kaller opp Apex, er andre nyanser involvert.

  • Hvis Apex-klassen er satt til arvet deling, kjøres den i systemkontekst med deling uansett hvordan flyten er angitt.

  • Hvis klassen ikke har noen eksplisitt delingsdeklarasjon, kjøres den i systemkontekst uten deling uansett hvordan flyten er angitt.

  • Hvis klassen angis til med deling eller uten deling, overstyrer den flytens kontekst.

Spørring av poster i systemkontekst med Experience Cloud-nettsteder

Hvis du kjører en flyt i systemkontekst på et Experience Cloud-nettsted (spesielt hvis den ikke er godkjent), lagrer du bare bestemte felt i elementene Hent poster. Når du arbeider med Flyt og overfører resultatene fra et **Hent poster-**element til en Underflyt, kallbar handling eller en Lightning-komponent, kan alle feltene fra dette objektet inspiseres av nettleserens utviklerverktøy. Uavhengig av hensikten kan dette gjøre felt tilgjengelig for Experience Cloud-brukere. For å sikre at bare de riktige feltene vises når Systemkontekst er aktivert, angir du disse spesifikke feltene i **Hent poster-**elementene.

Notat: 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 via nettleserens utviklerverktøy. Når du bruker Omniscript, er det viktig å utføre forretningslogikk på serversiden (når det er mulig) og implementere inndatavalideringsregler for eventuelle Apex-metoder som vises via en @InvocableMethod-notasjon.

Sanitize Inputs

For å beskytte organisasjonen mot dårlige aktører bruker du inndatahensyning. La oss si at du har et inndata i et offentlig tilgjengelig skjema som kan tilordnes til et felt for rik tekst i organisasjonen. Du bør kanskje vurdere å aktivere automatisering som fjerner eventuell HTML-kode som kan skjule skadelige URL-adresser.

Det er ikke ideelt å implementere rengjøring på skjemanivå fordi du kan ha et hvilket som helst antall kilder som skriver til disse feltene. For å bidra til å bekjempe dette problemet oppretter du en hurtig feltoppdateringsflyt (før lagring) eller bruker en eksisterende Apex-utløser til å fjerne eller endre eventuelle potensielle HTML-kode som kan skrives inn i skjemaet.

• Tillat at flyter kjører i sin standardkontekst (med mindre du trenger å heve den gjeldende brukerens tilgang for en bestemt operasjon).

• Unngå å kjøre flyter i systemkontekst for gjestebrukere. Opprett tillatelsessett med begrenset felttilgang, og tildel dem til Experience Cloud-gjestebrukerens profil.

• Når du spør etter poster i Systemkontekstkjøringsflyter på Experience Cloud-nettsteder, lagrer du bare feltene du trenger i elementet Hent poster eller Kallbare handlinger.

• Hvis en flyt utfører en rekke operasjoner, som alle ikke krever økt tilgang, bruker du Underflyter til å isolere operasjonene som skal kjøres i Systemkontekst.

• Hvis du bygger inn et skjema på en ekstern nettside, må det kanskje tilordnes til felt for rik tekst for å hindre potensielle phishingangrep. Det gjør du ved å rense brukerinndata for å fjerne HTML med en hurtig feltoppdateringsflyt eller Apex-utløser.

• Omniskript, FlexCard og LWC kjører som standard i brukerkontekst.

• LWC-er kjører som standard i brukerkontekst.

• Flyter kjører i brukerkontekst, men du kan overstyre dem ved å bruke en Apex.

• Operasjoner som utføres i brukergrensesnittets API, kjøres i brukerkontekst.

• Operasjoner som utføres med en Apex, avhenger av den bestemte klassen. Hvis du vil utføre disse operasjonene i systemmodus, angir du Apex-klassen til med deling eller uten deling.

Hvis du må bestemme hvem som skal ha tilgang til et skjema, ser du gjennom beholderen der skjemaet er innebygd (du kan for eksempel tildele Lightning til å være tilgjengelig for bestemte apper, posttyper eller profiler). Hvis visse inndata er sensitive, bruker du synlighetsregler til å bestemme ytterligere hva som skal vises til hvem. Denne funksjonen gjelder for dynamiske skjemaer og skjermflyter.

Du kan begrense en flyt til bestemte profiler eller tillatelsessett (likner Apex-klasse eller Visualforce-sider). Flyter er som standard ubegrenset, som betyr at alle brukere med brukertillatelsen Kjør flyter har tilgang til dem.

Hvis du bruker Omnistudio, kan du konfigurere en Apex-klassetillatelsessjekker som krever at brukere har eksplisitt tilgang til Apex-klassen som administrerer eksterne handlinger fra Omniscript-, Flexcard-, Classic-kort- eller REST-API-er.

Notat: Tillatelseskontroller for Apex gjelder bare for Apex. Det anbefales også å angi tillatelser på profilnivå for integrasjonsprosedyrer og datatilordnere.

• Hvis du viser en flyt til gjestebrukere, bør du gi gjestebrukerprofiltilgang bare til flytene de absolutt trenger. Det er mulig å legge til kjørende flyter i gjestebrukerprofiler, men dette kan være risikabelt.

• Vær forsiktig når du arbeider med flyter som opererer i systemkontekst. Du bør begrense disse flytene til et bestemt sett brukere fordi de har færre kontroller og saldoer på plass for å beskytte dataene dine.

• Forsikre deg om at alle Omniscript som kjører Apex i et gjestebrukerfellesskap, har deling oppført i Apex-klassedefinisjonen.

• For gjestebrukerprofiler tildeler du bare Apex som du vil tillate at gjestebrukere ringer. Ved å følge denne fremgangsmåten bidrar det til å hindre utilsiktet eksponering av ekstra forretningslogikk for gjestebrukere.

For LWC-er kan du kontrollere gjeldende brukers tillatelsestildelinger for å bekrefte om de har en bestemt standard eller tilpasset tillatelse. Du kan importere Salesforce-tillatelser fra @salesforce/userPermission- og @salesforce/customPermission-omfangsmodulene direkte i JavaScript. Du kan også bruke Apex til å kontrollere tillatelser.

LWC-er er bare tilgjengelig på et gitt sted etter at de har blitt lagt til som et gyldig mål (du kan for eksempel gjøre en komponent tilgjengelig på postsider og utilgjengelig som et verktøylinjeelement).

Når en skjermflyt er aktivert, blir den tilgjengelig på alle steder der skjermflyter støttes. Flow Builder støtter flere typer flyter som har skjermer. Den mest fremtredende typen er Skjermflyt, men det er noen andre spesialiserte typer som er begrenset til bestemte steder (for eksempel støtter Field Service Mobile-appen bare Field Service Mobile-flyter). Dette er likt kontaktforespørselsflyter, som støttes bare i Experience Cloud.

Uavhengig av flyttypen har ikke personen som oppretter flyten, noen kontroll over hvor flyten er innebygd. Flyter er tilgjengelig på alle steder der den bestemte flyttypen støttes.

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

Hos Salesforce finnes det flere ende-til-ende-verktøy for automatisering av tester (for eksempel Salesforce UTAM) som lar deg simulere hvordan en bruker samhandler med skjemaene dine. Du kan skrive tester for hvilket som helst standard eller tilpasset brukergrensesnitt, inkludert Lightning og skjermflyter.

Notat: Disse testtypene kan ikke bekrefte utdataene for metodene som utføres. Vær oppmerksom på dette når du konfigurerer kravene til grensesnittautomatisering.

• Trenger du automatisk testing av skjemaene?

• Hvilke typer tester planlegger du å utføre?

• Hvilket detaljnivå er nødvendig for testautomatiseringer?

Vurder krav til brukergrensesnittautomatisering

Enhetstester gir detaljert automatisering og validering som er i samsvar med bransjestandard CI/CD-systemer og -verktøy, som tester forretningslogikken, JavaScript-kontroller og utdata for bestemte komponenter. Hvis du velger en lavkode-tilnærming, kan du ikke skrive tester selv. Men Salesforce tester alle ende-til-slutt-tilbud nøye.

Hvis komponentens metoder er komplekse, kan du skrive dem enkeltvis ved å plassere metodene i dedikerte JavaScript-filer. Dette lar deg importere dem til en LWC, og deretter til en Jest-test (for eksempel importere { sort } fra 'c/utils';).

Du kan bruke en løsning uten kode fra en ISV, bygge en tilpasset testautomatiseringsløsning eller bruke et testrammeverk med åpen kildekode (for eksempel Selenium WebDriver eller WebdriverIO) til ende-til-ende-automatisering. Disse løsningene er gyldige for alle Salesforce-grensesnittinteraksjoner (for eksempel et dynamisk skjema på en Lightning, en skjermflyt på en verktøylinje eller en LWC i en hurtighandlingsflyt).

Når du har distribuert skjemaet til et produksjonsmiljø, må du forsikre deg om at det brukes effektivt. Avhengig av bruksområdet ditt kan det bety å spore antall ganger skjemaet har blitt fylt ut, til tiden gjennomsnittlig bruker bruker bruker på å fylle ut skjemaet før de sender inn informasjonen sin. Det er viktig å identifisere de sporbare KPI-ene før du velger et verktøy.

• Trenger du å spore bruk av skjemaer?

• Hvilke viktige ytelsesindikatorer kan bestemme om skjemaet brukes effektivt?

Hvis du trenger å spore den generelle bruken og bruken av skjemaer, bruker du verktøy med lite kode. Dynamiske skjemaer og skjermflyter kan spores via forhåndsdefinerte tilpassede rapporter. Skjermflytsporingsrapporter gir imidlertid ekstra detaljnivå. Hvis du må spore bruk av LWC, avhenger tilgjengeligheten som er ferdig klargjort, av hvor du bruker LWC. Hvis den er på en Lightning, gjelder også alle tilgjengelige sporingselementer for bruk av Lightning for LWC. Dette gjelder også for LWC-er som er innebygd i flyter.

Dynamiske skjemaer 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 rapporten Brukere med Lightning-bruk etter sidemålinger. For tilpassede Lightning-sider bruker du den tilpassede rapporten Brukere med Lightning-bruk av FlexiPage-målinger.

Flyter kan hjelpe deg å spore tilpassing for bestemte skjemaer. Bruk eksempel på flytrapport: Skjermflyter for å få svar på disse typene spørsmål:

• Hva er fullføringsgraden for dette skjemaet? Er den for øyeblikket godt tatt i bruk?

• Hvor lang tid tar det for brukere å fylle ut dette skjemaet?

• Hvilken skjerm bruker brukerne mest tid på å fullføre?

• Hvor ofte navigerer brukere til tidligere skjermer?

• Hvor ofte oppstår det feil?

Hvis standardrapporten ikke oppfyller behovene dine, kan du klone den og gjøre endringer eller Build Your Own rapport fra bunnen av med rapporten Skjermflyter.

Hvis du bruker den pakkebaserte Omniscript-kjøretiden, kan du også bruke Omnistudio for Vlocity Tracking Service. Denne tjenesten sporer alle typer hendelser (du kan for eksempel spore hvor lang tid det tar å fullføre trinnene i et Omniscript, noe som bidrar til å identifisere prosessforbedringer).

Notat: Det finnes ikke et forhåndsdefinert alternativ for å spore en LWC som ikke er innebygd på en skjermflyt-, Omniscript- eller Lightning, men du kan bygge en tilpasset løsning med Apex.

Du er kanskje kjent med å bruke endringssett eller DevOps Center til å distribuere løsningen til testingmiljøer eller til produksjon. Disse distribusjonsalternativene støtter fullt ut dynamiske skjemaer, flyter og LWC-er. Omnistudio krever imidlertid et eget verktøy, IDX Workbench.

• Hvordan planlegger du å distribuere skjemaet?

• Trenger skjemaet å bli distribuert til flere enn én Salesforce-organisasjon?

Hvis du er ISV eller en partner som planlegger å pakke løsningen for distribusjon på AppExchange, kan du se Dynamiske skjemaer, Flyter og LWC-er. Husk at Omnistudio ikke støtter pakking.

Denne veiledningen er ment å vise deg hvilke funksjonalitet og tilpassingsnivåer som er tilgjengelig via dynamiske skjemaer, skjermflyter, OmniStudio og LWC. Her er en generell oversikt.

• Når det gjelder byggeskjemaer, er LWC det mest robuste, tilpassbare alternativet, men det har færrest vakthull på plass. Derfor er det avgjørende å bygge komponentene med tanke på sikkerhet og skalering.

• Dynamiske skjemaer er det minst fleksible alternativet, men har langt færre muligheter for feiltrinn.

• Flyt og OmniStudio faller litt i midten. De er mer effektive enn dynamiske skjemaer, men de er ikke helt opp til LWC-nivået. De har imidlertid færre sikkerhetsregler enn dynamiske skjemaer, og de er vanskeligere å bryte enn tilpasset kode.

Du finner kanskje at flere verktøy passer til behovene dine. I så fall avhenger avgjørelsen til syvende og sist av hvilket verktøy som er best for teamet. Se gjennom disse Arkitektbeslutningsveiledningene for å få mer informasjon om andre aspekter du bør vurdere.

• Når du sammenligner verktøy, er det viktig å vurdere hvor mye ekspertise teamet ditt har med hensyn til hvert verktøy?
• Hvor mange av utviklerne er godt kjent med LWC eller JavaScript?
• Finnes det noen utviklere i teamet som er eksperter i Flow Builder, eller som har uttrykt interesse for å lære mer?

Vi vil ikke gå inn i spesifikke detaljer, men her er litt mer informasjon om hvordan disse spesifikke verktøyene er relatert til vurderingene vi har dekket så langt.

Leveringsdelegasjon

Husk at selv om noen av kravene krever LWC, kreves det ikke at hele løsningen bygges med LWC. Det er viktig å finne ut hvordan du kan bygge løsningen modulært. Det gjør du ved å identifisere hvilke deler som krever kodet LWC, og hvilke deler som ikke gjør det. Deler som ikke krever LWC, skal bygges med en løsning med lite kode.

Når det gjelder Flyt og LWC, er det forskjellige komponenter (for eksempel Reaktive skjermkomponenter og Skjermflyt) som kan synkroniseres med hverandre på samme skjerm for å låse opp nye verktøy for arkitekter, administratorer og utviklere. Utviklere kan nå opprette målrettede, modulære komponenter som kan gjenbrukes på tvers av organisasjonen, noe som bidrar til å øke teamets produktivitet. Det gir utviklere mulighet til å spare tid ved å bruke en blanding av standard og tilpassede Flyt-komponenter for å oppnå formdynamikk, noe som gir dem mer tid til å fokusere på å løse nye utfordringer. Med introduksjonen av Reaktive komponenter i flyt har det aldri vært et bedre tidspunkt å blande flyt og LWC når du bygger skjemaer.

Langsiktig eierskap og vedlikehold

Hvis du oppretter et skjema med flere trinn, starter du med Flyt eller en blanding av Flyt og LWC. Hvis teamet som vedlikeholder skjemaet, er et lavkodeteam, må du sørge for at løsningen er så konfigurerbar og utvidbar som mulig for den tiltenkte målgruppen. For å forbedre stabiliteten og vedlikeholdet er det viktig å organisere løsningen i komponerbare enheter, uansett hvilket verktøy du velger.

Viktige punkter om ytelse som er relatert til dynamiske skjemaer, skjermflyter, OmniStudio eller LWC, er basert på rammeverket der teknologiene befinner seg. Teknologi som er basert på LWC, har en tendens til å yte bedre enn de som er basert på Aura. På grunn av flere kjernefunksjoner som implementeres innebygd i nettmotorer (i stedet for i JavaScript via rammeabstraksjoner), gir LWC forbedrede ytelsesfordeler.

Så hvordan kan vi utnytte disse ytelsesfordelene for skjemateknologiene våre i Salesforce? La oss ta en nærmere titt.

• Dynamiske skjemaer (integrert i Lightning sidemetadata) er bygget på en LWC-stakk grunnlag, som gjør oss i stand til å implementere flere lenge ventede funksjoner. Som en ekstra ytelsesbonus bruker dynamiske skjemaer progressiv gjengivelse, som forbedrer innlastingstiden for sider som har et stort antall felt.

• Skjermflyter bygger på LWC. De fleste av de forhåndsdefinerte komponentene er nå konvertert til LWC med unntak av komponentene Filopplasting og Bilde. Selv om Flyt-teamet har konvertert flytkjøretidsklienten til LWC (og de fleste av dens komponenter), må kunder fremdeles konvertere Aura-skjermkomponentene til LWC. Husk at Salesforce støtter LWC-komponenter bare innenfor rammeverket for reaktive komponenter i skjermflyter. Se Trailhead-modulen Lightning Web Components for Aura Developer for å få mer informasjon. Hvis du overvejer å bygge en tilpasset komponent for en skjermflyt (eller en hvilken som helst annen beholder), velger du LWC!

• Det finnes flere versjoner av Omnistudio som er tilgjengelig. Hvis du er en langvarig kunde, bruker du kanskje Angular. Vi oppfordrer alle nye kunder til å bruke LWC-baserte Omniskript og FlexCard. Vi oppfordrer også eksisterende kunder til å overføre fra Angular.

• LWC bygger på LWC.