Byggeformularer

Der er flere muligheder for opbygning af formularer på Agentforce 360 Platform, og de strækker sig over en kontinuerlig række fra low-code til pro-code-tilgange. Dynamiske formularer i Lightning App-konstruktør og skærmforløb i Flow Builder kan bruges til løsninger med lav kode. På den anden side bruges Lightning Web Component-strukturen (LWC) til pro-code-løsninger. Inden for kontinuumet kan værktøjer blandes på en række måder ved brug af skærmforløb, der udvides af LWC'er og kundeorienterede formularer, der er bygget ved brug af Omnistudio.

Denne vejledning præsenterer en beslutningsramme og vejledning om opbygning af formularer til brugergrænsefladeløsninger. Specifikt bruger den et dusin kørsels- og ikke-funktionelle beslutningspunkter til korrekt at vælge den bedste teknologi til en given anvendelsessituation.

• Når du opbygger oprette/redigere/visningslayouts for Lightning-sider, skal du bruge dynamiske formularer. Vi anbefaler, at du bruger dynamiske formularer i Lightning App-konstruktør til at konfigurere registreringsdetaljesider.

• Hvis du har brug for at opbygge, oprette eller redigere en formular for et objekt, skal du bruge Lightning-sider og dynamiske formularer. Dette er den nemmeste måde at opbygge formularer på Agentforce 360 Platform. Den leverer også yderligere funktionalitet (f.eks. feltsynlighedskontrol).

• Hvis du opbygger en formular med flere sider eller en guide, og du ikke har strenge UX- eller brandingkrav, skal du bruge et skærmforløb. Skærmforløb giver en lineær navigationsstruktur til orkestrering af flere formularer. Du kan bruge LWC'er til at konstruere din egen struktur til at navigere mellem formularer, men vi anbefaler, at du lader forløbet udføre arbejdet, så du kan fokusere på selve formularerne i stedet for at fokusere på formulartilstanden.

• Hvis du har brug for yderligere logik eller handlinger til at understøtte formularen, skal du bruge et skærmforløb, Omnistudio eller LWC'er. Hvert af disse værktøjer tilbyder forskellige måder til at forbedre din løsning ved at tillade, at den udvides ud over at oprette eller redigere en enkelt registrering. I dette tilfælde kan udtrykket mere henvise til avanceret logik (f.eks. forgrening eller iteration), eller det kan henvise til handlinger som integration med eksterne systemer, afsendelse af mails eller push-adviseringer til en brugers mobilapp.

• Hvis du har avancerede UX-krav, eller hvis du har brug for dynamisk at administrere mere end UI-synlighed, skal du bruge LWC eller Omniscript. For krav, der kan opfyldes ved brug af temabaserede og kolonnebaserede layouts, kan du opbygge dine formularer direkte i en lav kode-konstruktør. Men detaljeret kontrol over din formularstypografi kræver fleksibiliteten i LWC. Hvis du er Branchekunde – og du har brug for pixel-perfekt branding, eller du har komplekse hierarkiske data – brug Omnistudio, som giver dig mulighed for at opbygge formularer i forbrugerklasse, der kan håndtere kompleks forretningslogik og datatransformationer.

• Hvis du har brug for at implementere testautomatisering, skal du bruge LWC. Du kan skrive enhedstest for ethvert LWC, uanset hvor du integrerer det. Dette giver mulighed for at oprette en mere robust teststrategi, som kan inkludere massetest med flere registreringer samt negativ test.

• Du er ikke bundet af enten/eller beslutninger. Du kan kombinere flere indstillinger for at nå frem til den bedste løsning for dine anvendelsessituationer (hvis du f.eks. har brug for Flow's indbyggede navigationssystem og den fulde formateringsflexibilitet, som LWC tilbyder, kan du bruge dem sammen).

Følgende værktøjer bruges almindeligt til at implementere og udvide formularoplevelser.

Denne tabel skitserer de værktøjer, der er tilgængelige for opbygning af formularer via Salesforce, sammen med deres påkrævede færdigheder og licensovervejelser.

Bemærk: Vi vil gå i detaljer med de specifikke funktioner, der understøttes for hvert værktøj, hvordan du vælger mellem klikbaserede værktøjer og kodebaserede værktøjer, og hvornår de skal kombineres i et senere afsnit.

Der er en række beslutningspunkter, du skal huske på, når du foretager produkt- og værktøjsvalg. Denne tabel skitserer forskellige beslutningspunkter og giver vejledning på højt niveau.

Bemærk: I efterfølgende beslutningssammenligningstabeller er der en håndfuld værdier, der er tilknyttet ethvert værktøjsfunktionspar:

• Tilgængelig: Værktøjet/funktionen fungerer med grundlæggende overvejelser.

• Ikke tilgængelig: Der er ingen planer om at tilføje support inden for de næste tolv måneder.

• Ikke ideel: Dette værktøj/funktion fungerer måske, men det er ikke det optimale værktøj.

• Ikke relevant: Værktøjet gælder ikke for den bestemte anvendelsessituation.

Brug disse scenarier til at sammenligne værktøjsvalg baseret på omfang, UX og driftsmæssige behov.

Hvis du kan hente alle dine brugerinput fra en enkelt skærmformular, skal du starte med dynamiske formularer. Husk på, at dynamiske formularer på registreringssider kan bruge stifunktionen til at understøtte faseinddelte forretningsprocesser.

• Skal du have en enkelt skærm, eller skal brugeren navigere mellem flere skærme for at udføre en opgave?

• Skal dine brugere se en visuel beskrivelse af, hvor langt de er i processen, når de udfylder din formular? Skal dine brugere blive bedt om at udfylde oplysningerne på hver skærm i en bestemt rækkefølge, eller skal de kunne flytte frem og tilbage mellem skærme efter behov?

Hvis du har brug for mere funktionalitet end det, som dynamiske formularer tilbyder, afhænger valg mellem forløb, Omnistudio og LWC af nogle få yderligere spørgsmål:

• Er det OK at få vist en navigationslinje nederst i din formular? Hvis skærmforløbet og Omniscript-navigationsoplevelsen giver en uønsket brugergrænseflade, skal du lede mod LWC.

• Hvad skal der ske bag formularen? Hvis du har brug for, at adfærden kan konfigureres af en administrator, skal du bruge et forløb. Brug Omniscript eller LWC til komplekse relationer med flere objekter.

Hvis du vælger Forløb eller Omnistudio, skal du muligvis også opbygge et LWC for at opnå den rigtige UX. Hvis du allerede opbygger en LWC til at formatere din formular korrekt, skal du overveje, om det er nødvendigt at integrere denne komponent i et forløb.

Guidestil navigation

Hvis din løsning på den anden side ligner en guide – hvor brugeren navigerer mellem flere skærme – kan du overveje forløb eller Omnistudio. Forløb og Omnistudio har en indbygget navigationsmodel, så du ikke behøver at opbygge og vedligeholde LWC'er, der er sammenføjet. Navigationen er lineær med fremadgående handlinger, bagudgående handlinger og en mekanisme til lagring af formularen til senere. Du kan også opbygge en formular med ikke-lineær navigation, hvis den passer til dine formål.

Omnistudio tilbyder en vigtig navigationsfordele ved at levere statusindikatorer fra standardnavigation, der viser trin i formularen. Trinvisningen viser automatisk, hvor en bruger er på en formular med flere trin. I modsætning til forløb giver det brugere mulighed for at hoppe mellem skærme ved at klikke på forskellige trin i hele formularen.

Uanset om du opbygger formularer med en enkelt skærm eller flere skærme, er det vigtigt at sikre, at dine formularer strømlines, så de er nemme for dine brugere at navigere i.

Hvis du integrerer en formular på en Lightning, vil ethvert af de værktøjer, som vi sammenligner, fungere. Men dynamiske formularer er i øjeblikket kun tilgængelige på desktop. Hvis du ønsker at levere en oplevelse, der tillader brugere at få adgang til formularer fra andre placeringer, skal du måske overveje alternative muligheder.

• Skal brugerne have adgang til formularen via stationær computer, mobil eller begge dele?

• Skal brugerne kunne få adgang til formularen fra ethvert sted i din app via en hjælpeprogramlinje?

• Vil du aktivere hurtige handlinger, så brugere kan udfylde din formular uden at skulle forlade den side, de aktuelt er på?

• Skal din formular være tilgængelig på et eksternt website?

Da det kræver registreringskontekst, understøttes funktionen Dynamiske formularer kun på Lightning. Men dynamiske formularer understøttes ikke på Experience Cloud-sider.

Du kan opbygge forløb, der kræver en registreringskontekst, eller forløb, der fungerer globalt. Med andre ord kan du integrere forløb på en række forskellige placeringer. For registreringskontekstbaserede forløb kan placeringer inkludere: Lightning, Experience Cloud-registreringssider, objektspecifikke handlinger eller Handlinger og anbefalinger-implementeringer. For globale forløb kan placeringer inkludere: hjælpeprogramlinjen, andre Lightning eller Oplevelseskonstruktør-sider, Snap eller eksterne applikationer. På nuværende tidspunkt understøttes forløb ikke som globale handlinger, men du kan indsætte forløb i en Aura-komponent som en løsning.

Omnistudio giver dig mulighed for at opbygge komposerbare FlexCards og Omniscripts, som du kan placere næsten overalt, hvor du kan placere et forløb, men mens de er komposerbare, kan de ikke pakkes.

LWC tilbyder en høj grad af genanvendelighed til oprettelse af komponenter, der kan knyttes til mål via metadata på tværs af Salesforce, fællesskaber og open-source-projekter. LWC-komponenter kan også integreres på din egen hjemmeside ved hjælp af Lightning Out 2.0.

LWC-komponenter kan også starte forløb med komponenten Lightning-Flow.

Omnistudio klarer sig godt ved at vise indhold til eksterne lokaliteter via OmniOut-funktionen. Med Omnistudio og OmniOut kan du kompilere dine Omniscript-formularer og FlexCard-komponenter til standardkomponenter og derefter køre dem off-platform på tredjepartslokaliteter eller apps.

På nuværende tidspunkt understøttes ingen af de formularteknologier, der er dækket i denne vejledning, officielt i Mobile SDK-skabeloner. Hvis Mobile SDK er vigtigt for din anvendelsessituation, anbefaler vi, at du opbygger din formular som standard i din mobilapplikation eller opbygger en Visualforce, mens du husker på formfaktor.

Dynamiske formularer er perfekte, hvis du har brug for at bruge værdierne i din formular til at oprette eller opdatere en registrering. Du skal bruge forløb, Omnistudio eller LWC til funktioner uden for dette omfang, herunder oprettelse af beslutnings- eller iterationslag eller generering af Slack-indlæg eller mails ved brug af inputs fra formularen.

• Hvilke handlinger eller logik skal udføres i baggrunden?

• Har du brug for at bruge værdier fra en relateret registrering?

• Skal din formular have brug for at fuldføre dens handlinger i en enkelt transaktion eller på tværs af flere transaktioner?

• Har du brug for at integrere med eksterne systemer?

• Hvad er dine krav til genanvendelighed og modularitet?

Forløb tilbyder standardhandlinger til indsendelse til Slack, afsendelse af mails og interaktion med Quip, og du behøver ikke at skrive kode til nogen af disse handlinger. LWC tilbyder omfattende interaktioner med enkelte registreringer og relaterede objekter via kabeladaptere, der interagerer med brugergrænsefladens API. LWC kan også interagere med flere registreringer ved brug af ledningen for getListInfoByName.

Omnistudio bruger integrationsprocedurer og Datatilknytning til at hente og transformere data (både eksterne og interne til Salesforce). På grund af talrige kodefrie funktioner klarer det sig godt ved at fladgøre og udvide datasæt med forskellige niveauer af relationer.

Flow, Omnistudio og LWC er alle integreret med Apex, så du nemt kan lukke eventuelle huller i den løsning, du vælger (hvis du f.eks. har brug for at filtrere registreringer fra en LWC, kan du bruge kabeladapteren til Apex til at oprette komplekse SOQL-forespørgsler. Hvis du er påvirket af klikbaserede historier, kan du overveje at bruge forløb eller Omnistudio som et levedygtigt alternativ til en Apex til dine serversidebehov.

Du bør også overveje, om du vil bekræfte handlinger med det samme eller udsætte dem til en bestemt del af din formular. Dette er især relevant, hvis du bruger en formular med flere sider. Forløb gør det nemt at kombinere input fra flere formularer (forløbsskærme) og bruge dem senere i guiden (forløb) til at udføre bestemte handlinger, hvilket er præcis, hvordan vi anbefaler design af forløb. Udfør handlinger i slutningen (i tilfælde af, at brugere hopper frem og tilbage mellem skærme for at ændre deres svar).

Transaktioner og styringsbegrænsninger er en del af Agentforce 360 Platform. Hvis din anvendelsessituation er ganske enkel, er det måske ikke så vigtigt at kontrollere den transaktion, hvor en bestemt handling forekommer. Der er dog nogle få anvendelsessituationer, hvor du måske vil kombinere flere handlinger i en enkelt transaktion i stedet for at udføre dem på tværs af flere transaktioner.

Her er nogle få eksempler:

• Rullback: Lad os antage, at din formular opretter flere registreringer i baggrunden. Hvis oprettelse af en tredje registrering mislykkes, skal de første to registreringer rulles tilbage? Hvis hver af dine handlinger er uafhængige af hinanden, kan du udføre dem som separate transaktioner. Men hvis de er afhængige af hinanden – og du ønsker, at den ene fejl også skal rulle tilbage til de andre – skal du implementere dem som en enkelt transaktion. Hvis din formular er i Forløb, kan du bruge Tilbagerulning-elementet i fejlstien til at rulle din transaktion tilbage og sikre dataintegritet.

• Nedgående påvirkning af styringsbegrænsninger: Når din formular opretter eller opdaterer en registrering, er det vigtigt at overveje, hvad downstream-påvirkningerne af denne handling er:

  • Hvilke processer, arbejdsflowregler, forløbsudløsere, Apex eller andre elementer i lagringsrækkefølgen kan udløses baseret på de foreslåede registreringsændringer?

  • Hvordan påvirker disse kollektive ændringer styringsbegrænsningerne, der forbruges i denne transaktion?

  • Hvis en bestemt registreringsændring kan resultere i mange downstream-ændringer, der påvirker dine grænser, kan det være bedst at overveje at isolere denne registreringsændring i sin egen transaktion.

• Batchbehandling: Du skal muligvis batche flere opdateringer sammen (selv i en brugergrænsefladekontekst). Lad os antage, at din formular med flere skærme gentages over en stor gruppe af registreringer. I stedet for at bekræfte en registreringsopdatering efter hver skærm – vent, indtil du har indsamlet opdateringerne for alle registreringerne – og send derefter en anmodning om at opdatere alle registreringerne.

Når du bruger dynamiske formularer til at oprette eller redigere en registrering, udfører du kun en handling, og denne handling er altid starten på en netto-ny transaktion.

Når du opbygger et skærmforløb, har du væsentlig kontrol over, hvad der forekommer i en given transaktion. Skærme og lokale handlinger fungerer som grænser mellem transaktioner. Her er et sammendrag på højt niveau over, hvordan transaktioner administreres i skærmforløbsarkitekturen.

1. Slutbrugeren interagerer med en skærm og klikker derefter på Næste.

2. Klienten sender en inputanmodning til API'en.

3. API modtager anmodningen og åbner en transaktions- og databaseforbindelse. Derefter kalder API forløbssystemet for at kalde anmodningen.

4. Forløbssystemet overtager og følger den relevante sti i forløbsdefinitionen – indtil det når en skærm eller en lokal handlingsnode. Derefter returnerer systemet oplysninger om denne node til API.

5. API'en opretter et svarobjekt, der indeholder detaljerne for den næste skærm, der skal gengives, og returnerer dette objekt til klienten. På dette tidspunkt foretages der databaseændringer (pr. gem bestillingsudførelse), og databasetilslutningen og transaktionen lukkes.

6. Klienten bruger API-svaret til at gengive den næste skærm, som brugeren interagerer med.

7. Start fra trin 1, og gentag processen.

Med andre ord, skærme bryder transaktioner. Når dette sker, bekræftes alle ventende handlinger eller DML, den tidligere transaktion lukkes, og en ny transaktion starter. Husk på, at de specifikke designelementer (hvilke handlinger du grupperer i en given transaktion) er op til dig.

Her er nogle få eksempler:

• Når du starter, ser du et forløb, der indsamler input på tværs af flere skærme og derefter udfører flere handlinger i en transaktion.
• Det næste forløb udfører hver handling i en separat transaktion.
• Forløb kan også bruge Tilbagerul registreringer til at gøre det muligt for dig at rulle en hel transaktion tilbage, hvis en enkelt handling mislykkes i en række databasehandlinger. Lad os antage, at du har et forløb, der opretter registreringer, opdaterer registreringer og derefter opretter yderligere registreringer (vises i det næste forløb).

Hvis de første to elementer lykkes, og det sidste mislykkes, vil de første to DML-handlinger stadig oprette og opdatere de relevante registreringer, men det tredje vil ikke. Ved at bruge elementet Tilbagerul registreringer kan du sikre, at hele transaktionen rulles tilbage, hvis alle tre handlinger skal forekomme samlet (som vist i det endelige forløb).

Bemærk: Hvis du ønsker flere oplysninger, kan du se Forløb i transaktioner og Forløbsmassebehandling i transaktioner.

Din mulighed for at kontrollere transaktionen fra en LWC er baseret på de underliggende tjenester, som LWC bruger til at udføre sine handlinger. Hvis du bruger Lightning, forekommer den underliggende handling (oprettelse eller opdatering af registreringen) i en enkeltstående transaktion, når formularen sendes.

Generelt gælder disse regler:

• Hvert API-brugergrænsefladekald er isoleret inden for sin egen transaktion.

• Hvis du har brug for at udføre flere handlinger i en enkelt transaktion, skal du sende inputs til en serversideteknologi (f.eks. en Apex eller et forløb). Husk på, at de almindelige transaktionsregler for denne teknologi stadig gælder.

Flow, Omnistudio og LWC understøtter alle platformsbegivenheder (for begivenhedsstyret arkitektur) og API-integrationer. Udover tilpasset Apex har forløb og Omnistudio deklarative supportmekanismer, der også kan integreres med API'er.

Hvis du har brug for at oprette forbindelse til en MuleSoft API- eller RPA-bot, skal du bruge MuleSoft-tjenester, da dette genererer en ekstern tjeneste.

Hvis API har et OpenAPI-skema, skal du oprette en ekstern tjeneste.

I alle andre tilfælde skal du bruge funktionen HTTP-udkald (drevet af eksterne tjenester) i Forløb eller HTTP-handlingen i Omnistudio.

Omnistudio har et omfattende sæt integrationsfunktioner, der kan fremhæve eksterne systemer ved brug af integrationsprocedurer til at transformere data via Datatilknytning.

Uanset om du bruger tilpasset Apex-kode eller en ekstern tjeneste til implementering, er et udkald stadig et udkald.

Her kan du se, hvad du har brug for at vide.

• Et udkald kan tage en væsentlig mængde tid at behandle.

• Når et udkald udføres synkront, udføres det, mens en databasetransaktion er åben.

• Salesforce tillader dig ikke at bevare en databasetransaktion åben, hvis du har nogen ventende databasehandlinger.

Husk på, at den vigtigste begrænsning er faren for at efterlade data i en inkonsekvent tilstand, som opstår, når du udfører en oprette, opdatere eller slette-handling og derefter udfører et kald inden for den samme transaktion. Dette mønster er ikke tilladt på grund af den tredje overvejelse, der er omtalt ovenfor, som findes på grund af de første to overvejelser.

I Forløb kan du tilsidesætte denne begrænsning ved at afbryde transaktionen. Husk, skærme og lokale handlinger genindfører browsersammenhængen. Selvom du kan bruge skærme og lokale handlinger, når du arbejder med eksterne udkald, anbefaler vi, at du aktiverer Transaktionskontrol i de avancerede indstillinger, der kan kaldes. Transaktionskontrol giver dig mulighed for automatisk at afslutte transaktionen, før der foretages et udkald. Hvis du vil aktivere Transaktionskontrol, skal du vælge "Start altid en ny transaktion" i afsnittet Avanceret for den handling, der kaldes. LWC hjælper med til at forenkle påvirkningen af udkald på transaktionen. Med andre ord skal du udføre dine datahandlinger ved brug af Lightning (LDS), og derefter bruge en Apex til at foretage det eksterne udkald. Da LDS-kaldet er isoleret inden for sin egen transaktion (separat fra Apex), beskytter dette dig mod den resulterende datauoverensstemmelse.

Dynamiske formularer understøtter ikke genbrug. Hver af dem er bundet til en specifik Lightning for et specifikt objekt. Du kan dog tildele denne Lightning til flere apps, profiler osv.

På samme måde som du kan skrive biblioteker, hjælpeprogrammer og komponenter, der kan bruges på tværs af flere komponenter, kan du også anvende lignende designmønstre, når du opretter forløb ved at udnytte styrken fra underforløb. Dette gør du ved at gemme dine forløb i mindre modulære inddelinger og derefter kalde dem fra andre forløb ved brug af underforløbselementet. Hvis dit design kræver det, kan du opbygge et forløb, der er nyttigt i sig selv og som et underforløb.

Omnistudio er opbygget til modularitet. Datatilknytninger, Omniscripts, FlexCards og Integration Procedures er alle opbygget uafhængigt, men de kan også fungere i mellem. FlexCards kan også bygges som LWC-komponenter, der kan integreres i andre LWC'er, Omniscripts, registreringssider og Experience Cloud-lokaliteter.

Skærmforløb, Omniscripts og LWC'er kan alle bygges til genbrug og integreres på en række forskellige steder, herunder eksterne lokaliteter og Lightning Out-applikationer. Når du designer dine løsninger, så de kan sammensættes, får du også fordele ved tilpasning og stabilitet.

Alle teknologier, der bruges til at oprette eller opdatere registreringer, skal overholde validering på systemniveau, uanset om det er klassiske valideringsregler eller tilpassede valideringer, der er indbygget i en Apex Uanset hvilken teknologi du bruger til at foretage registreringsændringer, skal hver ændring gennemgå lagringsrækkefølgen. Dette betyder, at registreringsændringer udover valideringsregler også behandles af et antal før- eller efter-gem-forløb, før- eller efter-udløsere, eskaleringsregler, tildelingsregler osv.

Bemærk: Hvis du ikke allerede har gjort det, skal du gennemse og bogmærke Apex udførelsesrækkefølgen.

• Har din formular yderligere krav udover validering på systemniveau?

• Har du brug for at angive påkrævede felter eller skrivebeskyttede felter dynamisk i formularen?

Input på en forløbsskærm eller et Omniscript-trin er typisk ubundet, så selve formularen overholder ikke som standard valideringen på systemniveau, der er tilknyttet et bestemt objekt. Men de værdier, som du bruger til at oprette eller opdatere registreringer, behandles i lagringsrækkefølgen, hvilket betyder, at de gennemgår objektets validering på systemniveau.

Bemærk: Ikke alle skærmforløbskomponenter understøtter inputvalidering.

I lighed med sidelayouts giver dynamiske formularer dig mulighed for at angive påkrævede og skrivebeskyttede tilstande på sideniveau. Husk på, at du ikke kan tilsidesætte indstillinger på systemniveau.

Forløb giver fleksibilitet til tilpasning af formularinputvalidering. Der udføres flere kontroller på klientniveau (f.eks. markering af påkrævede felter, der mangler, og datatypekontrol samt kompatible formler i inputvalideringsregler). Som et ekstra sikkerhedsniveau evalueres inputvalidering også på serveren. Når en bruger klikker på Næste, sender Forløb inputs til serveren til validering igen. Hvis der returneres ugyldige input, blokeres navigationen, og den relevante fejl vises.

Serveren validerer inputs ved at kontrollere:

• Inputens påkrævede indstilling, eller om den angivne værdi er kompatibel med den underliggende datatype.

• Den tilpassede validering af inputtet. Du skal angive et boolesk formeludtryk og en fejlmeddelelse, der skal vises, når formeludtrykket ikke opfyldes.

• Den tilpassede validering af den underliggende komponent. Hvis du opbygger en tilpasset LWC for et forløb, skal du føje din egen valideringskode til validate()-metoden.

Du kan også levere tilgængelige brugeradvarsler via komponenten Meddelelser i skærmforløb, men dette forhindrer ikke en bruger i at navigere til andre sider eller fortsætte til næste trin i et guidet forløb. Fejltilstanden i komponenten Meddelelser bruges bedst på dedikerede fejlskærme, der udløses via en fejlsti, når navigationen er inaktiveret.

Omnistudio har robust fejl- og valideringshåndtering via handlingen Angiv fejl i kombination med betingede visninger og komponenten Meddelelser.

For LWC udfører de fleste af basiskomponenterne deres egne valideringer på klientsiden (f.eks. overholder Lightning krav på systemniveau, men ikke krav på sideniveau). For dine tilpassede komponenter kan du Build Your Own valideringsmekanismer.

Husk på, at felter, der kræver, at brugere indtaster data, skal vises i starten af dine formularer. Valider brugerinput på klientsiden, før formularer sendes (når det er muligt).

Statiske formularer er forældede. I dag har fokus skiftet til dynamisk opdatering af formularer med de rigtige egenskaber og værdier for en specifik bruger, på et specifikt tidspunkt, på et specifikt sted. Lad os se nærmere på, hvad der er muligt via Salesforce-formularopbygningsværktøjer.

• Hvilke typer interaktioner eller betingelser skal udløse dynamiske svar i din formular?

• Har du brug for at udføre off-screen-handlinger (baggrundshandlinger), mens din formular udfyldes?

• Skal du angive felter som synlige, påkrævede, skrivebeskyttede eller inaktiverede, eller skal du ændre formatering baseret på formularinput?

Reaktive skærme aktiverer skærmforløbsinteraktivitet. Genaktivitet tillader individuelle komponenter på en forløbsskærm at kommunikere med hinanden, hvilket gør skærmforløb mere effektive.

Udfør datahandlinger uden for skærmen

Skærmforløb giver en deklarativ tilgang til at hente data på den samme skærm via skærmhandlinger. Skærmhandlinger giver dig mulighed for at udløse automatisk startede forløb ved enhver ændring på skærmen, eller når en bruger klikker på en Handlingsknap-komponent. Du kan tilknytte automatisk startede forløbsresultater til den samme skærm, hvilket eliminerer behovet for, at brugere navigerer til en anden skærm.

LWC leverer et komplet udvalg af kabeladaptere, der giver adgang til Salesforce-data for dynamisk at udfylde data i formularkomponenter, hvilket gør det muligt for udviklere at opdatere, slette og oprette registreringer via Apex-controllere.

Synlighed

Synlighed kan kontrolleres dynamisk i alle formularopbygningsværktøjer. Dynamiske formularer, Flow Builder og Omnistudio håndterer dette ved brug af komponentsynlighedsfunktioner. Du kan deklarativt vise eller skjule felter baseret på andre værdier i formularen, eller om brugeren udfylder formularen på en mobilenhed.

• Dynamiske formularer kontrollerer synlighed baseret på registreringsfeltværdier, opslagsfelter og formfaktor.

• Med forløb kan du basere en synlighedsregel på andre skærminput samt andre ressourcer, der udfyldes tidligere i forløbet (f.eks. formler eller værdier fra andre registreringer).

  • Enhedsbaserede regler: Det er måske ikke indlysende fra starten, men du kan bruge en formel til at vise eller skjule et bestemt felt, når brugeren er på en mobilenhed. Skriv en forløbsformel, der kontrollerer værdien af den globale variabel $User.UIThemeDisplayed. Hvis værdien er Theme4t, udfylder brugeren formularen ved brug af Salesforce Mobile-appen.

  • Evaluer andre ressourcer: Manuel variabel og formelreferencer evalueres kun på serveren. Dette betyder, at den værdi, som ressourcen har, når skærmen gengives første gang, er den værdi, den vil have, indtil du navigerer til en anden skærm. Under navigation sender forløbskørslen en anmodning til forløbssystemet (serveren), og den returnerer de seneste manuelle variabler og formelværdier. Hvis du forventer, at din synlighedsregel opdateres, når brugeren går gennem en enkelt skærm (f.eks. onblur), skal du sørge for, at du kun refererer til værdier fra de andre komponenter på skærmen.

• Med Omnistudio kan du betinget vise eller skjule komponenter ved at opsætte en egenskab for betinget visning. Du kan dog ikke tilføje mere end en betinget visningsegenskab for et input.

Betingede inputstater

Hvis du har brug for at styre andre egenskaber dynamisk (f.eks. om et felt er påkrævet, inaktiveret eller skrivebeskyttet), er der nogle få muligheder. LWC giver fuld reaktiv kontrol over din inputtilstand. Med komponenter med reaktive skærmforløb kan du dynamisk styre komponentattributter (f.eks. skrivebeskyttet, inaktiveret og påkrævet) for standardkomponenter, der understøtter det, mens Omnistudio understøtter hele spektret af komponentspecifikke attributter. Hvis dine krav dikterer, at du har brug for forløb, og komponenten ikke understøtter en specifik attributtilstand, kan du oprette en integreret LWC for at opnå en dynamisk inputtilstand.

Hvis du har brug for at styre andre egenskaber dynamisk (f.eks. om et felt er påkrævet eller skrivebeskyttet), skal du bruge LWC på kort sigt, da du har fuld kontrol. Dette gælder især, hvis du har tilpassede krav til, hvordan du håndterer onblur eller onclick.

Reaktive LWC'er i skærmforløb

Hvis du opbygger LWC'er, der kan reagere på og ændre andre komponenter på et skærmforløb, kan du se i guiden LWC Best Practices for skærmforløb for at sikre, at dine komponenter integreres med forløbskørselssystemet og fungerer som planlagt.

Hvis nogle af dine input (eller hele formularen) skal kommunikere med et andet element på siden for tilpassede begivenheder, er LWC din eneste mulighed.

• Hvis du vil kommunikere i det samme DOM-træ, skal du bruge CustomEvent-grænsefladen.

• Hvis du vil kommunikere på tværs af DOM, skal du bruge Lightning Messaging Service.

• Hvis Lightning-meddelelsestjenesten ikke understøttes for din målbeholder, skal du bruge pub-/undermodulet.

• Hvis du ønsker flere detaljerede oplysninger, kan du se Kommunikere med begivenheder og Kommunikere på tværs af DOM i Lightning Web Components Dev Guide.

• For Omnistudio kan du se Kommunikere med Omniscript fra en Lightning Web-komponent.

For at give den bedste brugeroplevelse er det vigtigt at sikre, at din formulartypografi er ensartet med resten af appen eller lokaliteten, hvor den integreres. Dette kan betyde brug af standardskabeloner, der leveres af Salesforce, eller oprettelse af en tilpasset CSS, der bruger hver pixel i designet til at give et skarpere udseende og funktionalitet.

Administratorer kan konfigurere et begrænset sæt af skærm- og komponentformateringstilsidesættelser (f.eks. farver, kanter og knapvisninger), for skærmbeholderen eller for individuelle komponenter. Disse tilsidesættelser anvendes efter temaer og branding, hvilket gør det muligt for konstruktører at foretage målrettede visuelle justeringer uden at påvirke resten af applikationen.

Formateringstilsidesættelser er beregnet til lokaliserede visuelle undtagelser (f.eks. fremhævelse af en bekræftelsesskærm eller fremhævelse af et specifikt opkald til handling (CTA). De er ikke et fuldt formateringssystem. De giver ikke kontrol på CSS-niveau, og de er ikke designet til at blive genbrugt på tværs af skærme eller forløb.

Fra et arkitektonisk perspektiv skal formatering følge denne præcedensrækkefølge:

1. Temaer og branding: Lightning, Oplevelseskonstruktør-brandingssæt eller LWR-lokalitetstemaer

2. Flow styling tilsidesættelser: Målrettede skærm- eller komponentjusteringer

3. Tilpassede komponenter (LWC): når der kræves pixel-perfect-kontrol eller genanvendelige designmønstre

Brug af temaer og designsystemer hjælper med til at sikre, at formatering forbliver ensartet, skalerbar og nem at vedligeholde over tid.

• Hvor sofistikeret er din ønskede formatering og CSS?

• Har du brug for tilpasset, pixel-perfekt formatering eller standardtemaer?

FlexCards er det eneste produkt i denne vejledning, der gør det muligt for dig deklarativt at kontrollere formateringen og layoutet af den brugergrænseflade, du opbygger i værktøjet (f.eks. margener og indre margener, typografi, farver osv.).

Dynamiske formularer og forløb respekterer deklarative temafunktioner. Hvis du har brug for yderligere kontrol (udover Salesforce-temaer, brandingssæt for Oplevelseskonstruktør eller understøttelse af LWR Experience Cloud-lokaliteter), kan du overveje en programmeringsmæssig løsning.

Team, der har det nemt at arbejde med CSS, har flere muligheder:

• Forløb og LWC'er overtager standarddesigntokener.

• Omniscripts og FlexCards inkluderer design system support via Newport.

• Med LWC kan du skrive dine egne komponenter og fuldt ud styre deres HTML og CSS.

Når det er muligt, anbefaler vi, at du bruger temaer og designsystemer for at sikre et ensartet udseende på tværs af alt dit indhold.

Bemærk: Du kan integrere Lightning i forløb. Hvis du har brug for pixel-perfekt kontrol over udseendet af din formular, men du også ønsker at bruge de andre fordele ved forløb (f.eks. navigationsmodellen), kan du få det bedste fra begge verdener! Det samme princip gælder for Omniscripts og FlexCards.

Valg af et godt layout er afgørende for at designe strømlinede formularer, der aktiverer hurtig og effektiv dataindtastning og øger dataintegriteten.

• Hvordan kan du strukturere formularlayouts for at optimere brugeroplevelser?

• Hvordan kan du præsentere eksisterende data for brugere på en måde, der gør det nemmere for dem at indsætte nye data i dine formularer?

Dynamiske formularer understøtter layouts med to kolonner, der kan opdeles i individuelle afsnit i felter. Disse afsnit kan placeres i komponenter (f.eks. faner og harmonikaer) for at oprette organiserede, brugervenlige layouts.

Forløb kan også gengives ved brug af komponenten Sektion. Du kan tilføje op til fire kolonner og et ubegrænset antal afsnit på forløbsskærmen. Komponenten Afsnit reagerer også på skærmbredde, så den fungerer også på mindre skærme. Den giver dig mulighed for at anvende betinget synlighed på hele afsnittet, hvilket gør det nemmere at masseanvende synlighed på flere felter i afsnittet. Forløbsafsnit understøtter også kolonnesidehoveder og giver en harmonika-lignende oplevelse, hvor brugerne kan folde hele afsnittet sammen ved at klikke på betegnelsen.

Omniscripts indeholder en række layoutindstillinger til visning af felter og data. Du kan oprette afsnit af data med op til 12 kolonner, herunder harmonikaer, der kan foldes sammen betinget.

Med LWC kan du bruge Lightning |view]-formular og det understøttende Lightning til at kontrollere layoutet. De eneste layoutbegrænsninger kommer fra HTML og CSS. Komponenten Lightning-registrering-format respekterer afsnitskonfigurationen i det tilknyttede sidelayout (hvis et afsnit f.eks. er to-kolonne i sidelayoutet, er det også to-kolonne i komponenten).

Hvis din formular skal være tilgængelig for brugere i forskellige områder, eller som taler forskellige sprog, skal du sørge for, at det værktøj, du bruger til at opbygge den, opfylder dine lokaliseringskrav.

Bemærk: For specifikke formularer involverer lokaliseringskrav typisk oversættelse af tekstelementer til andre sprog.

• Vil din formular blive brugt i mere end et land eller område?

• Skal teksten i din formular oversættes til andre sprog?

Hvis du lokaliserer tilpassede felter, respekterer dynamiske formularer de oversatte betegnelser. Dynamiske formularer respekterer også eventuelle tilpassede betegnelser, der er tildelt til komponentbetegnelser og attributter i Lightning App-konstruktør.

Forløb understøtter oversættelse af brugerorienterede betegnelser for alle standardskærmkomponenter og tilpassede skærmkomponenter via Translation Workbench.

Du kan lokalisere betegnelser, hjælpetekst og fejlmeddelelser på disse skærmkomponenter:

• Tekst
• Langt tekstområde
• Tal
• Valuta
• Afkrydsningsfelt
• Alternativknapper
• Plukliste
• Plukliste med flere valg
• Adgangskode til afkrydsningsfeltgruppe
• Dato
• Dato/tid

Der er ingen indbygget oversættelsessupport til indbyggede handlinger (f.eks. Send mail eller Send til Chatter), men der er en løsning. Hvis du bruger en tilpasset betegnelse til at definere de oversatte betegnelser, kan du referere til denne tilpassede betegnelse i handlingen eller komponenten, når du konfigurerer den i Flow Builder. Hvis du vil gøre det, skal du oprette en forløbsformel, der refererer til den tilpassede betegnelse og derefter referere til denne formel på de relevante steder i dit forløb.

Omniscripts bruger tilpassede betegnelser til oversættelser. Se nærmere på hjælp-dokumentet for at sikre, at dine Omniscripts er klar til flere sprog.

For LWC overtager visse basiskomponenter automatisk oversættelser af det tilknyttede objekts felter, hjælpetekst og valideringsmeddelelser, hvis de er konfigureret i Translation Workbench (f.eks. Lightning).

Hvis du har brug for at introducere nye betegnelser, der kan oversættes, i din kode, er tilpassede betegnelser den rigtige måde. Erklær den tilpassede betegnelse, du har brug for, og importer den derefter til din komponent fra det @salesforce/label-omfangsmodul.

Brug dette afsnit til at evaluere sikkerhed, kvalitet og driftsmæssige begrænsninger før implementering.

Sikkerhed er et komplekst emne, og når det gælder opbygning af formularer, er der en række overvejelser, der måske ikke er indlysende. På grundlæggende niveau skal du sikre, at formularen kører i den korrekte kontekst, og at brugere har de tilladelser, de har brug for til at arbejde med dens underliggende data. Udover dette ønsker du måske også at udføre ekstra foranstaltninger for at fjerne potentielt ondsindet kode eller URL'er fra rich-text-felter, forhindre bestemte brugere i at få adgang til formularen eller placere begrænsninger på typer af placeringer, hvor administratorer potentielt kan integrere formularen i fremtiden.

Sørg for at dokumentere dine sikkerhedskrav grundigt, før du vælger et værktøj. Hvis du ønsker yderligere vejledning om denne type dokumentation, kan du se Salesforce Well-Architected Security Policy Template.

• Skal formularen kontrollere brugerens adgang, før der udføres bestemte handlinger?

• Skal du sanere brugerinput?

• Vil du kontrollere, hvem der kan få adgang til formularen?

• Vil du kontrollere, hvor formularen kan integreres?

Når et program kører i brugerkontekst, håndhæver Salesforce en række adgangskontroller, som inkluderer bekræftelse af sikkerhed på feltniveau, CRUD-tilladelser og registreringsadgang baseret på din organisations delingsregler (f.eks. vil brugere kun kunne køre en sagsopdateringsformular, hvis de har mulighed for at opdatere sager, den relevante sikkerhed på feltniveau og adgang til den pågældende registrering).

Hvad sker der, hvis du ønsker, at brugere skal kunne udføre en bestemt handling, når de bruger din formular, men ikke via nogen anden formular eller interaktion? Det er her, systemkontekst kommer ind!

Systemkontekst giver dig mulighed for at hæve en brugers tilladelser for sessionens varighed (f.eks. behøver brugeren ikke at opdatere adgang til objektet Sag for at udfylde din sagsopdateringsformular). Dette er især nyttigt for ikke-godkendte fællesskaber. I stedet for at tildele gæstebrugere potentielt farlige evner, skal du indstille din formular til at køre i systemkontekst.

Systemkontekst skal kun bruges, når det er absolut nødvendigt. Når en formular køres i systemkontekst, tilsidesætter hver CRUD-handling sikkerhed og delingskomponenter på objekt- og feltniveau. Systemkontekst har heller ingen betydning for, hvem Salesforce anser for at være aktøren (navnet, du ser i feltet Sidst ændret af). For hver handling, som din formular udfører (f.eks. en sagsopdatering), er aktøren den aktuelle bruger (selv hvis formularen kører i en anden kontekst).

Bemærk: Dynamiske formularer, Omniscripts og LWC'er kører altid i brugerkontekst, og der er ingen måde at tilsidesætte denne adfærd på.

Skærmforløb kører som standard i brugerkontekst, men du kan indstille dem til at køre i systemkontekst. Du kan beslutte, om forløbet skal give adgang til alle data, eller om det skal håndhæve adgang på registreringsniveau.

• Hvis du integrerer en Lightning i et forløb, der kører i systemkontekst, tilsidesætter forløbet ikke komponentens kontekst. Hvis du har brug for at tilsidesætte brugeradgangskontroller, skal du bruge forløbet til at udføre disse handlinger og overføre de relevante data ind i eller ud af Lightning. Nogle komponenter, der er klar til brug (f.eks. Opslag), kan ikke fungere i systemkonteksten.

• Hvis dit forløb kalder Apex, er der andre nuancer involveret.

  • Hvis Apex-klassen er indstillet til overtaget deling, kører den i systemkontekst med deling, uanset hvordan forløbet er indstillet.

  • Hvis klassen ikke har nogen eksplicit delingserklæring, så vil den køre i systemkontekst uden deling, uanset hvordan forløbet er indstillet.

  • Hvis klassen er indstillet til med deling eller uden deling, tilsidesætter den forløbets kontekst.

Forespørg på registreringer i systemkontekst med Experience Cloud-lokaliteter

Hvis du kører et forløb i systemkontekst på en Experience Cloud-lokalitet (især hvis det ikke er godkendt), skal du kun gemme specifikke felter i dine Hent registreringer-elementer. Når du arbejder med forløb, og du overfører resultaterne af et Hent registreringer-element til et underforløb, en handling, der kan kaldes, eller en Lightning-komponent, kan alle felterne fra dette objekt blive undersøgt af browserens udviklerværktøjer. På trods af dine hensigter kan dette gøre felter tilgængelige for Experience Cloud-brugere. Hvis du vil sikre, at kun de korrekte felter vises, når Systemkontekst er aktiveret, skal du angive disse specifikke felter i dine Hent registreringer-elementer.

Bemærk: Omniscript-logik kører på klientsiden, hvilket gør det muligt for angribere at redigere den forventede kørsel af et Omniscript og se svar på integrationsprocedurer, datatilknyttere og Apex via browserens udviklerværktøjer. Når du bruger Omniscript, er det vigtigt at køre forretningslogik på serversiden (når det er muligt) og implementere inputvalideringsregler for alle Apex-metoder, der vises via en @InvocableMethod-anmærkning.

Sanitere input

Hvis du vil beskytte din organisation mod dårlige aktører, skal du bruge inputshåndtering. Lad os antage, at du har et input på en offentligt tilgængelig formular, der kan knyttes til et rich text-felt i din organisation. Du ønsker måske at overveje at aktivere automatisering, der fjerner enhver HTML, der kan skjule ondsindede URL'er.

Det er ikke ideelt at implementere sanering på formularniveau, da du muligvis har et hvilket som helst antal kilder, der skriver til disse felter. Hvis du vil hjælpe med at bekæmpe dette problem, skal du oprette et Fast Felt Update-forløb (før lagring) eller bruge en eksisterende Apex-udløser til at fjerne eller ændre eventuelle potentielle HTML, der kan indtastes i formularen.

• Tillad forløb at køre i deres standardkontekst (medmindre du har brug for at hæve den aktuelle brugers adgang til en bestemt handling).

• Undgå at køre forløb i systemkontekst for gæstebrugere. Opret tilladelsessæt med begrænset feltadgang, og tildel dem til Experience Cloud-gæstebrugerens profil.

• Når du forespørger på registreringer i systemkontekstkørselsforløb på Experience Cloud-lokaliteter, skal du kun gemme de felter, du har brug for, i elementet Hent registreringer eller Handlinger, der kan kaldes.

• Hvis et forløb udfører en række handlinger – som alle ikke kræver forhøjet adgang – skal du bruge underforløb til at isolere de handlinger, der skal køres i systemkontekst.

• Hvis du integrerer en formular på en ekstern webside, skal den muligvis knyttes til rich text-felter for at forhindre potentielle phishing-angreb. Dette gør du ved at sanere brugerinput for at fjerne HTML ved brug af et Fast Felt Update-forløb eller Apex-udløser.

• Omniscripts, FlexCards og LWC'er kører som standard i brugerkontekst.

• LWC'er kører som standard i brugerkontekst.

• Forløb kører i brugerkontekst, men du kan tilsidesætte dem ved brug af en Apex.

• Handlinger, der udføres i brugergrænsefladens API, køres i brugerkontekst.

• Handlinger, der udføres med en Apex, afhænger af den specifikke klasse. Hvis du vil udføre disse handlinger i systemtilstand, skal du indstille Apex-klassen til med deling eller uden deling.

Hvis du har brug for at kontrollere, hvem der kan få adgang til en formular, skal du gennemse den beholder, hvor formularen er integreret (du kan f.eks. tildele Lightning til at være tilgængelige for bestemte apps, registreringstyper eller profiler). Hvis visse input er følsomme, skal du bruge synlighedsregler til yderligere at kontrollere, hvad der vises for hvem. Denne funktion gælder for dynamiske formularer og skærmforløb.

Du kan begræns et forløb til bestemte profiler eller tilladelsessæt (ligesom Apex-klasse- eller Visualforce-sider). Forløb er som standard ubegrænsede, hvilket betyder, at enhver bruger med brugertilladelsen Kør forløb kan få adgang til dem.

Hvis du bruger Omnistudio, kan du konfigurere en Apex-klassetilladelseskontrol, der kræver, at brugere har eksplicit adgang til Apex-klassen, der administrerer fjernhandlinger fra Omniscript, Flexcard, Classic Card eller REST API'er.

Bemærk: Apex gælder kun for Apex. Det er også tilrådeligt at angive tilladelser på profilniveau for integrationsprocedurer og datatilknyttere.

• Hvis du viser et forløb til gæstebrugere, skal du kun tildele gæstebrugerprofiladgang til de forløb, som de absolut har brug for. Det er muligt at føje Kør forløb til gæstebrugerprofiler, men denne praksis kan være risikabel.

• Vær forsigtig, når du arbejder med forløb, der fungerer i systemkontekst. Du bør begrænse disse forløb til et bestemt sæt brugere, da de har færre kontroller og afvejninger til at beskytte dine data.

• Sørg for, at ethvert Omniscript, der kører Apex i et gæstebrugerfællesskab, har deling angivet i Apex-klassedefinitionen.

• For gæstebrugerprofiler skal du kun tildele de Apex, som du ønsker at tillade gæstebrugere at kalde. Ved at følge denne fremgangsmåde hjælper det med at forhindre utilsigtet visning af yderligere forretningslogik for gæstebrugere.

For LWC'er kan du kontrollere den aktuelle brugers tilladelsestildelinger for at bekræfte, om de har en bestemt standardtilladelse eller en bestemt tilpasset tilladelse. Du kan importere Salesforce-tilladelser fra de @salesforce/userPermission og @salesforce/customPermission-omfangsmoduler direkte i JavaScript. Du kan også bruge Apex til at kontrollere tilladelser.

LWC'er er kun tilgængelige på en angivet placering, når de er tilføjet som et gyldigt mål (du kan f.eks. gøre en komponent tilgængelig på registreringssider og utilgængelig som en hjælpeprogramlinjevare).

Når et skærmforløb er aktiveret, er det tilgængeligt på alle de placeringer, som skærmforløb understøttes. Flow Builder understøtter flere typer af forløb, der har skærme. Den mest fremtrædende type er skærmforløb, men der er et par andre specialtyper, der er begrænset til bestemte placeringer (f.eks. understøtter Field Service Mobile-appen kun Field Service Mobile-forløb). Dette svarer til kontaktanmodningsforløb, som kun understøttes i Experience Cloud.

Uanset forløbstypen har den person, der opretter forløbet, ingen kontrol over, hvor forløbet er integreret. Forløb er tilgængelige på alle placeringer, hvor den specifikke forløbstype understøttes.

Hvis du bruger Salesforce-brancher, er der en lille forsinkelse, når det gælder Omniscript.Du kan ikke angive et mål for et Omniscript, men du kan angive et mål for de FlexCards, du vil integrere.

I Salesforce findes der adskillige end-to-end-automatiseringsværktøjer til test (se f.eks. Salesforce UTAM), der giver dig mulighed for at simulere, hvordan en bruger interagerer med dine formularer. Du kan skrive test for enhver standardbrugergrænseflade eller tilpasset brugergrænseflade, herunder Lightning og skærmforløb.

Bemærk: Disse typer af test kan ikke bekræfte resultaterne for de metoder, der udføres. Husk på dette, når du konfigurerer dine krav til automatisering af brugergrænsefladen.

• Har du brug for automatiseret test af dine formularer?

• Hvilke typer af test planlægger du at udføre?

• Hvilket niveau af detaljer er nødvendigt for testautomatiseringer?

Overvej krav til automatisering af brugergrænsefladetest

Enhedstest giver detaljeret automatisering og validering, der er i overensstemmelse med branchestandard CI/CD-systemer og -værktøjer, der tester forretningslogik, JavaScript-kontrolelementer og output af specifikke komponenter. Hvis du vælger en tilgang med lav kode, vil du ikke kunne oprette test selv. Men Salesforce tester strengt alle end-to-end-tilbud.

Hvis din komponents metoder er komplekse, kan du skrive dem individuelt ved at placere metoderne i dedikerede JavaScript-filer. Dette giver dig mulighed for at importere dem i en LWC og derefter i en Jest-test (f.eks. importere { sort } fra 'c/utils';).

Du kan bruge en uden kode-løsning fra en ISV, opbygge en tilpasset testautomatiseringsløsning eller bruge en open-source-teststruktur (f.eks. Selenium WebDriver eller WebdriverIO) til end-to-end-automatisering. Disse løsninger er gyldige for alle Salesforce-brugergrænsefladeinteraktioner (f.eks. en dynamisk formular på en Lightning, et skærmforløb på en hjælpeprogramlinje eller et LWC i et hurtigt handlingsforløb).

Når du har implementeret din formular i et produktionsmiljø, skal du sørge for, at den bruges effektivt. Afhængig af din anvendelsessituation kan dette betyde sporing af antallet af gange, din formular er blevet udfyldt, til mængden af tid, som den gennemsnitlige bruger bruger på at udfylde formularen, før de indsender deres oplysninger. Det er vigtigt at identificere dine sporbare KPI'er, før du vælger et værktøj.

• Har du brug for at spore formularanvendelse?

• Hvilke KPI'er kan bestemme, om formularen bruges effektivt?

Hvis du har brug for at spore den generelle formularanvendelse og -indføring, skal du bruge værktøjer med lav kode. Dynamiske formularer og skærmforløb kan spores via tilpassede rapporter, der er klar til brug. Men skærmforløbssporingsrapporter giver yderligere detaljer. Hvis du har brug for at spore LWC-anvendelse, afhænger den tilgængelighed, der er klar til brug, af, hvor du bruger LWC. Hvis det er på en Lightning, gælder alle tilgængelige Lightning også for dit LWC. Dette gælder også for LWC'er, der er integreret i forløb.

Dynamiske formularer kan ikke spores, men du kan spore brugen af den overordnede Lightning-side via Lightning-anvendelsesobjekter. Hvis du vil spore Lightning-standardsider, skal du bruge den tilpassede rapport Brugere med Lightning-anvendelse efter sidemetrikker. For tilpassede Lightning-sider skal du bruge den tilpassede rapport Brugere med Lightning-anvendelse efter FlexiPage-metrikker.

Forløb kan hjælpe dig med at spore ibrugtagning for specifikke formularer. Brug eksempelforløbsrapporten: Skærmforløb til at besvare disse typer af spørgsmål:

• Hvad er fuldførelsesfrekvensen for denne formular? Er det i øjeblikket godt ibrugtaget?

• Hvor lang tid tager det brugere at udfylde denne formular?

• Hvilken skærm bruger brugerne mest tid på at fuldføre?

• Hvor ofte navigerer brugere til tidligere skærme?

• Hvor ofte forekommer der fejl?

Hvis standardrapporten ikke opfylder dine behov, kan du duplikere den og foretage ændringer eller Build Your Own report fra bunden ved brug af rapporten Skærmforløb.

Hvis du bruger den pakkebaserede Omniscript-kørsel, kan du også bruge Omnistudio for Vlocity Tracking Service. Denne tjeneste sporer alle typer af begivenheder (du kan f.eks. spore den tid, det tager at fuldføre trinene i et Omniscript, hvilket hjælper med at identificere procesforbedringer).

Bemærk: Der er ikke en indstilling, der er klar til brug, til at spore et LWC, der ikke er integreret på en skærmforløbs-, Omniscript- eller Lightning, men du kan opbygge en tilpasset løsning ved brug af Apex

Du er måske bekendt med at bruge ændringssæt eller DevOps Center til at implementere din løsning til testmiljøer eller til produktion. Disse implementeringsindstillinger understøtter fuldt ud dynamiske formularer, forløb og LWC'er. Men Omnistudio kræver et separat værktøj, IDX Workbench.

• Hvordan planlægger du at implementere formularen?

• Skal formularen distribueres til mere end en Salesforce-organisation?

Hvis du er ISV eller en partner, der planlægger at pakke din løsning til distribution på AppExchange, kan du se Dynamiske formularer, forløb og LWC'er. Husk på, at Omnistudio ikke understøtter pakning.

Denne vejledning er beregnet til at vise dig, hvilke funktionalitet og tilpasningsniveauer der er tilgængelige via dynamiske formularer, skærmforløb, Omnistudio og LWC. Her er en oversigt på højt niveau.

• Når det gælder opbygning af formularer, er LWC den mest robuste indstilling, der kan tilpasses, men den har de færreste vagter på plads. Derfor er det vigtigt at opbygge dine komponenter med tanke på sikkerhed og skalerbarhed.

• Dynamiske formularer er den mindst fleksible indstilling, men har langt færre muligheder for fejltrin.

• Forløb og Omnistudio falder en smule i midten. De er mere effektive end dynamiske formularer, men de er ikke helt op til LWC-niveauet. Men de har færre guardrails end dynamiske formularer, og de er sværere at bryde end tilpasset kode.

Du kan finde ud af, at flere værktøjer passer til dine behov. Hvis det er tilfældet, afhænger beslutningen i sidste ende af, hvilket værktøj der er bedst for dit team. Hvis du ønsker flere oplysninger om yderligere aspekter, kan du se disse Arkitektbeslutningsvejledninger.

• Når du sammenligner værktøjer, er det vigtigt at vurdere, hvor meget ekspertise dit team har med hensyn til hvert værktøj?
• Hvor mange af dine udviklere kender godt LWC eller JavaScript?
• Er der nogen udviklere i dit team, der er eksperter i Flow Builder, eller som har udtrykt en interesse i at lære mere?

Selvom vi ikke vil gå i detaljer, er der her lidt flere oplysninger om, hvordan disse specifikke værktøjer er relateret til de vurderinger, vi har dækket indtil videre.

Leveringsdelegation

Husk på, at selvom nogle af dine krav kræver LWC, kræver det ikke, at hele løsningen opbygges ved brug af LWC. Det er vigtigt at bestemme, hvordan du kan opbygge din løsning modulært. For at gøre det skal du identificere, hvilke dele der kræver kodet LWC, og hvilke dele der ikke gør. De dele, der ikke kræver LWC, skal bygges ved brug af en lav kode-løsning.

Når det gælder forløb og LWC, er der forskellige komponenter (f.eks. Reaktive skærmkomponenter og Skærmforløb), der kan synkronisere med hinanden på den samme skærm for at låse op for nye værktøjer for arkitekter, administratorer og udviklere. Udviklere kan nu oprette målrettede, modulære komponenter, der kan genbruges på tværs af organisationen, hvilket hjælper med at øge teamproduktiviteten. Dette giver udviklere mulighed for at spare tid ved at bruge en blanding af standardforløbskomponenter og tilpassede forløbskomponenter til at opnå formdynamik, hvilket giver dem mere tid til at fokusere på at løse nye udfordringer. Med introduktionen af Reaktive komponenter i forløb har der aldrig været et mere passende tidspunkt at blande forløb og LWC, når du opbygger formularer.

Langsigtet ejerskab og vedligeholdelse

Hvis du opretter en formular med flere trin, skal du starte med Forløb eller en blanding af Forløb og LWC. Hvis det team, der vedligeholder formularen, er et low-code-team, skal du sørge for, at løsningen er så konfigurerbar og udvidelig som muligt for din tiltænkte målgruppe. For at forbedre stabiliteten og vedligeholdeligheden er det vigtigt at organisere din løsning i komponerbare enheder, uanset hvilket værktøj du vælger.

Overvejelser i forbindelse med ydeevne, der er relateret til dynamiske formularer, skærmforløb, Omnistudio eller LWC, er baseret på den struktur, hvor teknologierne er opbevaret. Teknologier, der er baseret på LWC, klarer sig som regel bedre end dem, der er baseret på Aura. På grund af flere kernefunktioner, der implementeres som standard i websystemer (i stedet for i JavaScript via strukturabstraktioner), giver LWC forbedrede ydeevnefordele.

Så hvordan udnytter vi disse ydeevnefordele for vores formularteknologier i Salesforce? Lad os se nærmere på det.

• Dynamiske formularer (integreret i Lightning side metadata) er bygget på en LWC-stack fundament, som giver os mulighed for at implementere flere længe ventede funktioner. Som en ekstra præstationsbonus bruger dynamiske formularer progressiv gengivelse, hvilket forbedrer indlæsningstiden for sider, der har et stort antal felter.

• Skærmforløb bygger på LWC. De fleste af de enkelte komponenter, der er klar til brug, er nu konverteret til LWC med undtagelse af komponenterne File Upload og Image. Mens forløbsteamet har konverteret forløbskørselsklienten til LWC (og de fleste af dets komponenter), skal kunderne stadig konvertere deres Aura-skærmkomponenter til LWC. Husk på, at Salesforce kun understøtter LWC-komponenter i Reactive Component-strukturen i skærmforløb. Hvis du ønsker flere oplysninger, kan du se Lightning Web Components for Aura Developer Trailhead-modulet. Hvis du overvejer at opbygge en tilpasset komponent for et skærmforløb (eller enhver anden beholder), skal du vælge LWC!

• Der er flere versioner af Omnistudio tilgængelige. Hvis du er en tidligere kunde, bruger du muligvis Angular. Vi opfordrer alle nye kunder til at bruge LWC-baserede Omniscripts og FlexCards. Vi opfordrer også eksisterende kunder til at migrere fra Angular.

• LWC bygger på LWC.