Vil du opbygge formularer på Salesforce Platform? Du har flere indstillinger, der strækker sig over hele den lave kode til pro-code-kontinuum. Repræsenterer lav kode dynamiske formularer i Lightning App-konstruktør og skærmforløb i Flow Builder. Hængende midt i kontinuumet er muligheden for at udvide skærmforløb med LWC'er og opbygge kundeorienterede formularer med OmniStudio. Og repræsenterer pro-code er LWC-strukturen og dens stadig voksende bibliotek af basiskomponenter.

Indstillingerne er gode, men hvordan bestemmer du, hvilken (eller hvilken kombination) der er den rigtige valgmulighed? Det er her, denne vejledning kommer ind.

• Takeaway # 1: Når du opbygger oprette/rediger/vis layouts for Lightning-sider, skal du bruge dynamiske formularer. Du vil måske bemærke, at sidelayouts mangler i sammenligningstabellerne i denne vejledning. Den anbefalede måde at konfigurere registreringsdetaljesider på er at bruge dynamiske formularer i Lightning App-konstruktør. Se afsnittet om sidelayouts for at få flere oplysninger om, hvorfor vi ikke forventer at forbedre dem yderligere.
• Takeaway # 2: Hvis du har brug for at opbygge en oprette- eller redigeringsformular for præcis ét objekt, skal du starte med Lightning-sider og dynamiske formularer. Dette er den enkleste måde at opbygge formularer på Salesforce-platformen. Den leverer også nogle yderligere funktioner, f.eks. muligheden for at kontrollere feltsynlighed. Hvis dine krav er mere avancerede, skal du blive ved med at læse. Skærmforløb, OmniStudio eller Lightning Web Components (LWC) kan være en bedre løsning.
• Takeaway #3: Hvis du opbygger en formular med flere sider eller en guide, og du ikke har strenge UX- eller brandingkrav, skal du starte med et skærmforløb. Skærmforløb leverer en lineær navigationsstruktur til orkestrering af flere formularer sammen. Du kan bruge LWC til at konstruere din egen ramme til at navigere mellem formularer, men vi anbefaler, at du lader Flow gøre det hårde arbejde for dig, så du kan fokusere på selve formularerne i stedet for at bekymre dig om formstilstanden.
• Takeaway # 4: Hvis du har brug for yderligere logik eller handlinger bag formularen, skal du bruge et skærmforløb, OmniStudio eller LWC. Alle tre værktøjer tilbyder måder, hvorpå din løsning kan gøre mere end at oprette eller redigere en enkelt registrering. Dette "mere" kan være mere avanceret logik, f.eks. forgrening eller iteration, eller det kan være flere handlinger som integration med eksterne systemer, afsendelse af mails eller overførsel af adviseringer til en brugers mobilapp.
• Takeaway # 5: Har du sofistikerede UX-krav? Har du brug for at håndtere mere dynamisk end synlighed? Brug LWC eller Omniscript. Hvis dine krav kan opnås med enkle temaer og kolonnebaserede layouts, kan du opbygge dine formularer direkte i en low-code-konstruktør. Hvis du ønsker mere detaljeret kontrol over din formularstypografi, skal du have den ultimative fleksibilitet i LWC. Hvis du er en Branchekunde og har brug for pixel-perfekt branding eller har komplekse hierarkiske data, skal du bruge OmniStudio, som giver dig mulighed for at opbygge formularer af forbrugerklasse, der kan håndtere kompleks forretningslogik og datatransformationer.
• Takeaway # 6: Hvis du har brug for testautomatisering, skal du starte med Lightning Web Components. Du kan skrive enhedstest for ethvert LWC, uanset hvor du planlægger at integrere det. Dette giver dig mulighed for at oprette en mere robust teststrategi, som kan inkludere massetest med flere registreringer og negativ test. Se Salesforce Well-Architected - Testing Strategy for at få flere oplysninger om oprettelse af test, der hjælper dig med at se, hvor godt dine formularer passer til dine funktionelle og ikke-funktionelle krav.

Husk på, at dit valg ikke behøver at være et enten/eller - du kan kombinere styrken fra flere indstillinger. Hvis du f.eks. har brug for både forløbets indbyggede navigationssystem og den fulde formateringsflexibilitet, som LWC tilbyder, skal du bruge dem sammen.

Tabellen nedenfor skitserer de værktøjer, der er tilgængelige for opbygning af formularer med Salesforce, sammen med deres påkrævede færdigheder og licensovervejelser. Senere vil vi gå i detaljer med de specifikke funktioner, der understøttes for hvert værktøj, samt hvordan du vælger mellem klikbaserede værktøjer og kodebaserede værktøjer (og hvornår de skal kombineres):

Tabellen nedenfor indeholder en oversigt over de beslutningspunkter, du bør overveje, når du foretager dine produktvalg, sammen med spørgsmål, du bør stille dig selv om hver af dem. Vi vil gå i detaljer med hvert af disse emner i resten af denne vejledning.

Her er de udtryk, vi bruger i sammenligningstabellerne sammen med deres definitioner:

• Tilgængelig: Fungerer fint med grundlæggende overvejelser.
• Ikke ideel: Kan fungere, men er ikke det optimale værktøj.
• Roadmap: Estimeret support inden for de næste tolv måneder (juni 2025).
• Future: Estimeret for support ud over de næste tolv måneder.
• Ikke tilgængelig: Ingen planer om at understøtte denne funktionalitet inden for de næste tolv måneder.

Som lovet, lad os starte med at gå i detaljer med en række sammenligningspunkter og funktionelle forskelle mellem dynamiske formularer, skærmforløb, OmniStudio, skærmforløb med integrerede LWC'er og selve LWC-strukturen.

Hvis din formular fungerer mod et enkelt Salesforce-objekt, vil ethvert af de værktøjer, vi sammenligner, fungere. Ting bliver lidt mere kompliceret med krydsobjekt- eller objekt-agnostiske formularer. Med objekt-agnostisk mener vi input, der ikke er tilknyttet noget Salesforce-objekt. Måske repræsenterer din formular en datastruktur, som du sender til en ekstern tjeneste, f.eks. Stripe eller DocuSign. Eller måske bruger du flere input i din formular til at beregne en værdi og derefter bekræfte denne værdi til databasen.

• Hvilke objekter vil formularen fungere mod?
• Er det kun et objekt, eller er der flere objekter?
• Arbejder du med specifikke objekter (f.eks. Konto, Kontakt, Salgsmulighed, Emne og Sag), eller skal din formular også fungere med andre objekter?

For både krydsobjekt- og objektagnostiske formularer er forløb og OmniStudio begge solide muligheder. De komponenter, der er tilgængelige på forløbsskærme, er agnostiske af natur, så du kan vælge, hvad du skal gøre med disse data i baggrunden. Brug f.eks. de data, der er angivet i en formular, til at oprette flere registreringer i baggrunden, eller brug dataene til at udføre andre handlinger som at generere Chatter, sende Slack-meddelelser, sende mails eller oprette forbindelse til eksterne tjenester.

For enkle sager kan brug af eksisterende LWC-komponenter, f.eks. Lightning, være en enkel måde til at reducere den kode, der er nødvendig for at levere en robust løsning. Men for scenarier, hvor flere objekter er involveret, giver forløb omfattende kontrol for alle objekter og fjerner behovet for, at udviklere gennemgår komplekse relationer og afhængigheder.

OmniStudio tager tingene et skridt videre og er fuldstændig objektagnosticeret – det adskiller den form, som en bruger ser, fra den underliggende datamodel. I stedet manipulerer OmniStudio underliggende JSON, der derefter knyttes til Salesforce-objekter (eller eksterne data) ved hjælp af værktøjer som Data Mapper og Integration Procedures. Datatilknytning og integrationsprocedurer er to nøglekomponenter i tilslutning af dine OmniStudio-formularer med interne og eksterne data til Salesforce. Ved at bruge træk-og-slip-elementer kan du arbejde med komplekse hierarkiske data i et eksternt system og derefter transformere dataene, så de passer til dine behov, afhængigt af hvor data skal flyttes hen. De giver dig også mulighed for at bruge formler til at udføre matematik og logik på matrikser eller lister over data, ligesom Apex.

OmniStudio Integrations

Hvis du kan hente alle dine brugerinput fra en enkelt skærmformular, skal du starte med dynamiske formularer. Men mens dynamiske formularer på registreringssider kan bruge stifunktionen til løst at vise de forskellige faser i din forretningsproces, passer den muligvis ikke til de fleste af dine anvendelsessituationer.

• Skal du have en enkelt skærm, eller skal brugeren navigere mellem flere skærme for at udføre en opgave?
• Vil du have dine brugere til at se en visuel beskrivelse af, hvor langt de er gået i processen med at udfylde 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, vil valget mellem forløb, OmniStudio og LWC også afhænge af nogle få andre spørgsmål:

• Hvilke færdigheder har dit team? Hvis du ønsker en mere administrativ organisation, anbefaler vi, at du starter med forløb. Hvis du har brancheløsninger, er dit team allerede bekendt med OmniStudio, og dit projekt har strenge UX-krav, start med OmniStudio.
• Er det OK at få vist en navigationslinje nederst i din formular? Hvis skærmforløbet og Omniscript-navigationsoplevelsen er uønsket UX, 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 opbygge et forløb eller – for grundlæggende ændringer som ændring af feltbetegnelser – et Omniscript. Ellers kan du for komplekse relationer med flere objekter opbygge et Omniscript eller et LWC.
• Hvis du vælger Forløb eller OmniStudio, skal du muligvis opbygge et LWC alligevel for at opnå den rigtige brugergrænseflade. Hvis du allerede opbygger en LWC til at formatere din formular korrekt, skal du overveje, om det er overdrevent at integrere denne komponent i et forløb.

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 leveres med 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. Et godt eksempel på dette er pakken Digital Store Audit fra Salesforce Labs.

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

Uanset om du opretter enkeltskærmsformularer eller formularer med flere skærme, skal du sørge for, at dine formularer er strømlinede, så de er nemme at navigere i.

Hvis du integrerer en formular på en Lightning, vil ethvert af de værktøjer, vi sammenligner, fungere, med den bemærkning, at dynamiske formularer aktuelt kun er tilgængelige på desktop. Men 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 bruge 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 de kræver registreringskontekst, understøttes dynamiske formularer kun på Lightning. Men dynamiske formularer understøttes ikke på Experience Cloud-sider. Denne begrænsning er gældende, fordi Experience Cloud ikke bruger den underliggende struktur, som dynamiske formularer er afhængige af: Lightning. Vi evaluerer dette baseret på anmodninger om dynamiske formularer i Experience Cloud.

Du kan opbygge forløb, der kræver en registreringskontekst eller forløb, der fungerer globalt. Som sådan kan du integrere forløb på en række forskellige placeringer. For registreringskontekstmæssige forløb kan det være en Lightning, en Experience Cloud-registreringsside, en objektspecifik handling eller en Handlinger og anbefalinger-implementering. For det globale forløb kan det være hjælpeprogramlinjen, andre Lightning eller Oplevelseskonstruktør-sider, et Snap eller en ekstern applikation. Forløb understøttes aktuelt ikke som globale handlinger, men som en løsning kan du indsætte forløbet i en Aura-komponent.

OmniStudio giver dig mulighed for at opbygge komponerbare FlexCards og Omniscripts, som du kan placere næsten overalt, hvor du kan placere et forløb. Men selvom de kan sammensættes, kan de ikke pakkes.

LWC understøtter en høj grad af genanvendelighed, da du opretter komponenter, der kan knyttes til mål via metadata på tværs af Salesforce, fællesskaber og endda i open source-projekter. LWC-komponenter kan også integreres på din egen hjemmeside via Lightning Out.

_ Lightning på eksterne lokaliteter_

Lightning webkomponenter understøttes i øjeblikket ikke som hurtige handlinger (objektspecifikke eller globale), men som en løsning kan du indpakke en LWC i en Aura-komponent (ligesom du kan med forløb). LWC-komponenter kan også starte forløb med komponenten Lightning-flow.

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

Ingen af de formularteknologier, der er dækket i denne vejledning, understøttes officielt i Mobile SDK-skabeloner i dag. Hvis Mobile SDK er afgørende for din anvendelsessituation, er det bedre, at du opbygger din formular som standard i din mobilapplikation eller opbygger en Visualforce-side, mens du husker på vejledningen om Salesforce Well-Architected formfaktorer.

Ruteoversigtsnotat: Mobile SDK-teamet arbejder aktivt på at understøtte LWC'er på Visualforce.

Dynamiske formularer er perfekt, hvis du har brug for at bruge værdierne i din formular til at oprette eller opdatere en registrering. Hvis du ønsker yderligere funktioner, skal du bruge Flow, OmniStudio eller LWC. Disse funktioner kan inkludere et lag af beslutningstagning eller iteration eller generering af Slack-indlæg eller mails ved brug af inputs fra formularen.

• Hvilke handlinger eller logik ønsker du, der skal udføres i baggrunden?
• Indeholder din datamodel hierarkiske data?
• 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 mail og interaktion med Quip, så du ikke behøver at skrive kode til disse handlinger. LWC tilbyder omfattende interaktioner med enkelte registreringer og relaterede objekter gennem brug af kabeladaptere, der interagerer med brugergrænseflade-API. LWC kan også interagere med flere registreringer, når du bruger ledningen til getListInfoByName.

_ Lightning Web Components Interaktion via Wire Adapters_

Som omtalt ovenfor bruger OmniStudio integrationsprocedurer og Datatilknytning til nemt at hente og transformere eksterne og interne data til Salesforce. Det skinner i fladgørende og udvidende datasæt med forskellige niveauer af relationer takket være talrige kodefrie funktioner, du kan bruge.

Ruteoversigtsnotat: Forløb understøtter snart muligheden for at upsertere samlinger af registreringer samt administrere hierarkiske data.

Flow, OmniStudio og LWC er alle integreret med Apex, så du nemt kan udfylde eventuelle huller i den løsning, du vælger. Hvis du f.eks. skal filtrere registreringer fra en LWC, kan du altid bruge kabeladapteren til Apex til at oprette komplekse SOQL-forespørgsler. Hvis du er påvirket af den klikbaserede historie, kan du overveje Forløb eller OmniStudio som levedygtige alternativer til en Apex til dine serversidebehov.

Et sekundært spørgsmål her er, 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 har en formular med flere sider. Forløb gør det nemt at kombinere input fra flere formularer (forløbsskærme) og bruge dem meget senere i guiden (forløb) til at udføre nogle handlinger. Faktisk anbefaler vi, at du designer forløb på netop den måde – udfør handlinger i slutningen – i tilfælde af, at brugeren hopper frem og tilbage mellem skærme og ændrer deres svar.

Transaktioner og styringsbegrænsninger er en livsstil på Salesforce Platform. Hvis din anvendelsessituation er ganske enkel, er det måske ikke så vigtigt at kontrollere, hvilken transaktion en bestemt handling forekommer i. 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. Nogle eksempler:

• Til tilbagerulning eller ikke til tilbagerulning: Det er spørgsmålet. Lad os antage, at din formular opretter flere registreringer i baggrunden. Hvis den tredje registrering ikke oprettes, skal de første to registreringer rulles tilbage? Hvis hver af dine handlinger er uafhængige af hinanden, kan du køre dem i separate transaktioner. Men hvis de er afhængige, og du ønsker, at en af deres fejl også skal rulles tilbage til de andre, skal du implementere dem i en enkelt transaktion. Hvis din formular er i Forløb, kan du bruge Tilbagerulning-elementet i en fejlsti til at rulle din transaktion tilbage og sikre dataintegritet.
• Downstream-påvirkning af styringsbegrænsninger: Især når din formular opretter eller opdaterer en registrering, skal du overveje, hvad downstream-påvirkningerne af denne handling er. Hvilke processer, arbejdsflowregler, forløbsudløsere, Apex eller andre elementer i lagringsrækkefølgen vil blive udløst baseret på denne registreringsændring? Og hvordan påvirker disse kollektive ændringer styringsbegrænsningerne, der forbruges i den pågældende transaktion? Hvis en bestemt registreringsændring resulterer i en masse downstream-ændringer, der påvirker dine grænser, kan du overveje at isolere denne registreringsændring i dens egen transaktion.
• Batchbehandling: Selv i en brugergrænsefladekontekst skal du muligvis batche flere opdateringer sammen. 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, skal du vente, indtil du har indsamlet opdateringerne for alle registreringerne og derefter sende 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 sker 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 anmodning til API med inputs.
3. API modtager anmodningen, og der åbnes en transaktions- og databaseforbindelse. API kalder derefter 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 lokal handlingsnode. Systemet returnerer derefter oplysninger om denne node til API'en.
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 (efter gem bestillingsudførelse), og databaseforbindelsen og transaktionen lukkes.
6. Klienten bruger API-svaret til at gengive den næste skærm, som brugeren kan interagere med.
7. Gentag fra trin 1.

Med andre ord "bryder" skærme transaktioner. Når det sker, bekræftes alle ventende handlinger eller DML, den tidligere transaktion lukkes, og en ny transaktion starter.

Det rigtige design – hvilke handlinger du grupperer i en given transaktion – er dit kald. Lad os gennemgå nogle eksempler.

Til venstre kan du se et forløb, der indsamler input på tværs af flere skærme og derefter udfører flere handlinger i en transaktion.

Forløbet til højre udfører hver handling i en separat transaktion.

Antag, at du har et forløb, der opretter registreringer, opdaterer registreringer og derefter opretter flere registreringer – som illustreret i det næste forløb til højre.

Hvis de første to elementer lykkes, og det sidste mislykkes, vil de første to DML-handlinger stadig oprette og opdatere disse registreringer, mens det tredje ikke gør.

Ved at bruge elementet Tilbagerul registreringer kan du sikre, at hele transaktionen rulles tilbage, hvis alle tre handlinger skal forekomme sammen – som det ser ud i det endelige forløb til venstre.

Hvis du ønsker flere oplysninger, kan du se Forløb i transaktioner og Forløbsmassebehandling i transaktioner. Afsnittet Automatiseret i Salesforce Well-Architected går også i detaljer om dette i datahåndtering.

Din mulighed for at kontrollere transaktionen fra en LWC kommer ned til de underliggende tjenester, som LWC bruger til at udføre sine handlinger. Hvis du bruger Lightning, sker den underliggende handling (oprettelse eller opdatering af registreringen) i en enkeltstående transaktion, så snart formularen er sendt.

Generelt gælder disse regler:

• Hvert API-brugergrænsefladekald er isoleret i sin egen transaktion.
• Hvis du har brug for at udføre flere handlinger i en enkelt transaktion, skal du sende inputs til en serversidet teknologi, f.eks. en Apex eller et forløb. De almindelige transaktionsregler for denne teknologi gælder.

Flow, OmniStudio og LWC understøtter alle platformsbegivenheder (for begivenhedsstyret arkitektur) og API-integrationer. I tillæg til tilpasset Apex understøtter både Forløb og OmniStudio deklarative mekanismer til at integrere en API.

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

_ Eksterne integrationer via Mulesoft API'er og RPA-bots_

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

_ Eksterne integrationer til API'er med OpenAPI-skemaer_

Ellers skal du bruge HTTP-udkaldsfunktionen i Forløb eller HTTP-handling i OmniStudio. Forløbets HTTP-udkald er drevet af Eksterne tjenester.

_ Eksterne integrationer via HTTP_

OmniStudio indeholder et omfattende sæt integrationsfunktioner, der kan fremhæve eksterne systemer med integrationsprocedurer og transformere data med Data Mapper. (Se Objektpåvirkning for at få flere oplysninger)

Uanset om du implementerer det med tilpasset Apex eller en ekstern tjeneste, er et udkald et udkald. Her kan du se, hvad du har brug for at vide.

1. Et udkald kan tage lang tid.
2. Når et udkald udføres synkront, udføres det, mens en databasetransaktion er åben.
3. Salesforce tillader dig ikke at bevare en databasetransaktion åben, hvis du har ventende databasehandlinger.

Den vigtigste begrænsning at huske på er faren ved såkaldte smudtransaktioner, hvor du udfører en oprettelses-, opdaterings- eller sletningshandling og derefter udfører et udkald i samme transaktion. Dette mønster er ikke tilladt på grund af overvejelse nr. 3 ovenfor, hvilket selvfølgelig findes på grund af overvejelser nr. 1 og nr. 2.

I Forløb kan du omgå denne begrænsning ved at afbryde transaktionen. Husk, at skærme og lokale handlinger begge genindfører browserkonteksten, hvilket afbryder transaktionen. Selvom du kunne bruge skærme og lokale handlinger, når du arbejder med eksterne udkald, anbefaler vi, at du aktiverer Transaktionskontrol i avancerede indstillinger, der kan kaldes. Transaktionskontrol er en funktion af handlinger, der kan kaldes, og som giver dig mulighed for automatisk at afslutte transaktionen, før der foretages et udkald. Du kan aktivere Transaktionskontrol ved at vælge Start altid en ny transaktion i afsnittet Avanceret for en kaldt handling.

For mere detaljeret vejledning om Apex-udkald, eksterne tjenester og dataintegrationsfunktioner generelt, kan du se Arkitektens vejledning til dataintegration med Salesforce.

Dynamiske formularer understøtter ikke genbrug. Hver dynamisk formular er bundet til en specifik Lightning for et specifikt objekt (men du kan tildele denne Lightning til flere apps, profiler osv.).

Ligesom du kan skrive biblioteker, hjælpeprogrammer og komponenter, der skal bruges på tværs af flere andre komponenter, kan du anvende lignende designmønstre, når du opretter forløb med styrken fra underforløb. Gem dine forløb i mindre, mere modulære inddelinger, og kald dem derefter fra andre forløb ved brug af underforløbselementet. Hvis dit design kræver det, kan du opbygge et forløb, der begge står på egen hånd og er nyttigt som et underforløb til et andet.

OmniStudio er opbygget til modularitet. Datatilknytninger, Omniscripts, FlexCards og Integration Procedures er alle opbygget uafhængigt og kan fungere i mellem. Desuden kan FlexCards 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 til at være komponerbare, får du yderligere fordele som tilpasningsevne og stabilitet.

Alle teknologier, der bruges til at oprette eller opdatere en registrering, overholder validering på systemniveau – uanset om det er klassiske valideringsregler eller tilpasset validering, der er indbygget i en Apex Uanset hvilken teknologi du bruger til at foretage en registreringsændring, går hver ændring gennem lagringsrækkefølgen. Dette betyder, at registreringsændringen udover valideringsregler behandles af et hvilket som helst antal før- eller efter-gem-forløb, før eller efter udløsere, eskaleringsregler, tildelingsregler mm. Hvis du ikke allerede har gjort det, skal du sørge for at bogmærke og gøre dig bekendt med Apex udførelsesrækkefølgen.

• Har din formular yderligere krav udover validering på systemniveau?
• Skal du angive felter til at være påkrævede eller skrivebeskyttede dynamisk i formularen?

Input på en forløbsskærm eller et Omniscript-trin er af natur ubundet, så selve formularen overholder ikke som standard validering på systemniveau, der er knyttet til et bestemt objekt. Uanset hvilke værdier du bruger til at oprette eller opdatere registreringer, behandles de dog af lagringsrækkefølgen, hvilket betyder, at de gennemgår objektets validering på systemniveau. Bemærk dog, at ikke alle skærmforløbskomponenter understøtter inputvalidering. Fra og med Summer '24 er de resterende skærmkomponenter, der ikke understøtter inputvalidering, Alternativknapper, Plukliste, Plukliste med flere valg, Afkrydsningsfeltgruppe og Valgopslag.

Ligesom sidelayouts giver dynamiske formularer dig mulighed for at angive krav og skrivebeskyttet tilstand på sideniveau. Du kan dog ikke tilsidesætte indstillinger på systemniveau.

Forløb giver fleksibilitet til tilpasning af validering på en formularinput. Mens nogle kontroller udføres i klienten (f.eks. markering af manglende påkrævede felter eller inkompatible værdier), blokerer ingen af valideringen på klientsiden brugeren mod at forsøge at navigere. Den virkelige validering sker på serveren. Når en bruger klikker på Næste, sender Forløb inputs til serveren til validering. Hvis nogen input returneres som ugyldigt, blokeres navigationen, og den relevante fejl vises. Serveren validerer inputs ved at kontrollere:

1. Inputets kravindstilling, eller om den angivne værdi er kompatibel med den underliggende datatype.
2. Tilpasset validering på dette input: Adskillige standardkomponenter (Afkrydsningsfelt, Valuta, Dato, Dato/tid, Langt tekstområde, Tal, Adgangskode og Tekst) understøtter tilpasset validering pr. skærm. Angiv et boolesk formeludtryk og en fejlmeddelelse, der skal vises, når formeludtrykket ikke opfyldes.
3. Tilpasset validering på den underliggende komponent: Hvis du opbygger en tilpasset LWC for et forløb, skal du føje din egen valideringskode til validate()-metoden.

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

På LWC-siden udfører de fleste basiskomponenter deres egne valideringer på klientsiden. Lightning respekterer f.eks. krav på systemniveau, men ikke krav på sideniveau. For dine tilpassede komponenter kan du Build Your Own valideringsmekanismer.

Felter, der kræver, at brugere indtaster data, skal vises tidligt i dine formularer. Når det er muligt, skal du validere brugerinput på klientsiden, før formularer sendes. Hvis du ønsker flere bedste fremgangsmåder for at strømline dine formularer, kan du se vejledningen til formularer i Salesforce Well-Architected - Engagement.

Sikkerhed er generelt et komplekst emne, og når det gælder opbygning af formularer, er der en række overvejelser, som du måske ikke engang har tænkt over. På det grundlæggende niveau ønsker du at sikre, at formularen kører i den korrekte kontekst, og at brugerne har de tilladelser, de har brug for til at arbejde med dens underliggende data. Men udover det ønsker du måske også at tage ekstra foranstaltninger for at fjerne potentielt ondsindet kode eller URL'er fra rich text-felter, forhindre bestemte brugere i at kunne få adgang til formularen overhovedet eller sætte begrænsninger på typer af steder, 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. Den veludformede Salesforce-sikkerhedspolitikskabelon indeholder retningslinjer for denne type dokumentation.

• 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 noget kører i brugerkontekst, håndhæver Salesforce en række adgangskontroller, herunder bekræftelse af sikkerhed på feltniveau, CRUD-tilladelser og registreringsadgang baseret på din organisations delingsregler. Så 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. Men hvad nu hvis du ønsker, at brugerne skal kunne udføre en bestemt handling, når de bruger din formular, men ikke gennem nogen anden form eller interaktion? Det er her, systemkonteksten kommer ind.

Systemkontekst er en måde til at hæve den løbende brugers tilladelser for varigheden af sessionen, så brugeren ikke har brug for f.eks. opdateringsadgang til objektet Sag for at fuldføre 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.

Systemkonteksten er naturligvis et dobbeltkantet sværd, og du bør kun bruge det, når det er nødvendigt. Når en formular køres i systemkontekst, tilsidesætter hver enkelt CRUD-handling sikkerhed og deling på objekt- og feltniveau – ikke kun den specifikke handling, du er interesseret i. Bemærk også, at systemkonteksten ikke har nogen betydning for, hvem Salesforce tager aktøren med i betragtning – det navn, du ser i feltet Sidst ændret af. For hver handling, som din formular udfører, f.eks. sagsopdateringen, er aktøren den løbende bruger, selvom formularen kører i en anden kontekst.

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. Det er dit valg, om forløbet skal give adgang til alle data, eller om det stadig skal håndhæve adgang på registreringsniveau som deling.

• 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, anbefaler vi, at du bruger 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 nogle flere nuancer, du skal forstå. Hvis Apex er indstillet til overtaget deling, kører den i systemkontekst med deling, uanset hvad forløbet er indstillet til. Hvis klassen ikke har nogen eksplicit delingserklæring, kører den i systemkontekst uden deling, uanset hvad forløbet er indstillet til. Hvis klassen er indstillet til med deling eller uden deling, gør den det og tilsidesætter 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 ikke-godkendt, anbefaler vi, at du kun lagrer 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, kan alle felter fra dette objekt undersøges via browserens udviklerværktøjer. Dette kan gøre felter tilgængelige for dine Experience Cloud-lokalitetsbrugere, som du måske ikke har til hensigt. Ved at angive specifikke felter i dine Hent registreringer-elementer kan du sikre, at kun de rigtige felter vises, selv med systemkontekst aktiveret.

Bemærk, at Omniscript-logik kører på klientsiden, hvilket gør det muligt for angribere at ændre den forventede kørsel af et Omniscript og se svar på integrationsprocedurer, datatilknyttere og Apex-metodekald ved brug af browserens udviklerværktøjer. Når du bruger Omniscript, anbefaler vi, at du eksekverer forretningslogik på serversiden, når det er muligt, og implementerer inputvalideringsregler på alle Apex-metoder, der vises via en @InvocableMethod-anmærkning.

Sanitering Input:

Hvis du vil beskytte din organisation mod dårlige aktører, kan du også overveje inputrensning. Antag, 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 automatisering, der fjerner enhver HTML, der kan skjule ondsindede URL'er. Generelt er det ikke ideelt at implementere denne sanering på formularniveau, da du kan få et hvilket som helst antal kilder til at skrive til disse felter. Vi anbefaler, at du opretter et hurtigt feltopdateringsforløb (før lagring), eller at du bruger en eksisterende Apex på objektet til at fjerne eller redigere eventuelle potentielle HTML, der kan angives i formularen.

Bedste fremgangsmåder:

• Lad forløbene køre i deres standardkontekst, medmindre du har brug for at hæve den løbende brugers adgang til en bestemt handling.
• Undgå at køre forløb i systemkontekst for gæstebrugere af sikkerhedsmæssige årsager. Opret i stedet tilladelsessæt med begrænset feltadgang tildelt til Experience Cloud-lokalitetens gæstebrugerprofil.
• 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 dit Hent registreringer-element eller Handlinger, der kan kaldes.
• Hvis et forløb udfører en række handlinger, og ikke alle af dem kræver forhøjet adgang, skal du bruge underforløb til at isolere de handlinger, der skal køre i systemkontekst.
• Hvis du planlægger at integrere en formular på en ekstern webside, kan du overveje at sanere brugerinput for at fjerne HTML ved hjælp af et hurtigt feltopdateringsforløb eller Apex-udløser, hvis de i sidste ende vil blive tilknyttet Rich Text-felter for at forhindre potentielle phishing-angreb fra dårlige aktører.

• Omniscripts, FlexCards og LWC'er kører som standard i brugerkontekst.
• LWC'er kører som standard i brugerkontekst, og forløb kører i brugerkontekst, men du kan tilsidesætte dette i en Apex.
• Handlinger, der udføres gennem brugergrænsefladens API, køres i brugerkontekst.
• Handlinger, der udføres gennem en Apex, afhænger af denne klasse. Hvis du vil udføre disse handlinger i systemtilstand, skal du indstille Apex til med deling eller uden deling.

Hvis du har brug for kontrol over, hvem der kan få adgang til din formular, kan du ofte se på den beholder, som formularen er integreret i. Du kan f.eks. tildele Lightning til at være tilgængelige for bestemte apps, registreringstyper eller profiler. Hvis visse input i din formular er følsomme, skal du bruge synlighedsregler til yderligere at kontrollere, hvad der vises for hvem. Denne funktion gælder for både dynamiske formularer og skærmforløb.

Du kan begræns et forløb til bestemte profiler eller tilladelsessæt, ligesom du kan en Apex-klasse eller Visualforce-side. Som standard er forløb ubegrænsede, hvilket betyder, at enhver bruger med brugertilladelsen Kør forløb kan køre dem.

Hvis du bruger OmniStudio, kan du konfigurere en Apex-klassetilladelseskontrol for at sikre, at brugere kræver eksplicit adgang til den Apex-klasse, der administrerer den fjernhandling, der kaldes fra et Omniscript-, Flexcard-, Classic-kort- eller REST API.

• Bemærk Apex er aktiveret som standard for netop oprettede scripts. Men de skal være aktiveret manuelt for eventuelle eksisterende scripts
• Bemærk også, at Apex kun gælder for Apex. Vi anbefaler også at indstille tilladelser på profilniveau for integrationsprocedurer og datatilknyttere.

Hvis du ønsker flere oplysninger og bedste fremgangsmåder for gæstebrugertilladelser, kan du se:

• Bedste fremgangsmåder for adgang til gæstebrugerregistreringer
• Udvikl sikre lokaliteter: Godkendte brugere og gæstebrugere

Bedste fremgangsmåder:

• Hvis du viser et forløb til gæstebrugere, skal du kun give gæstebrugerprofilen adgang til de forløb, de har brug for. Selvom det er muligt at føje Kør forløb til gæstebrugerprofilen, anser vi det for en risikabel praksis.
• Vær særligt forsigtig med forløb, der fungerer i systemkontekst. Vi anbefaler på det kraftigste, at du begrænser disse forløb til et bestemt sæt brugere, da de har færre kontroller og balancer på plads for at beskytte dine data.
• Sørg for, at enhver Omniscript, der kører Apex i et gæstebrugerfællesskab, har "med deling" i Apex-klassedefinitionen.
• I din gæstebrugerprofil skal du kun tildele de Apex-klasser, som du ønsker, at gæstebrugere skal kunne ringe til, eller du risikerer utilsigtet at vise yderligere forretningslogik for gæstebrugere.

For LWC'er kan du kontrollere den løbende brugers tilladelsestildelinger for at bekræfte, om de har en bestemt standardtilladelse eller en bestemt tilpasset tilladelse. Direkte fra JavaScript kan du importere Salesforce-tilladelser fra de @salesforce/userPermission- og @salesforce/customPermission-omfangsmoduler. Eller du kan bruge Apex til at kontrollere det samme.

Lightning-webkomponenter er kun tilgængelige på et givet sted, når de er tilføjet som et gyldigt mål. Du kan f.eks. gøre en komponent tilgængelig på registreringssider og ikke tilgængelig som et hjælpeprogramlinjevare.

Når et skærmforløb er aktiveret, er det tilgængeligt på alle de placeringer, som skærmforløb understøttes, uanset om du har til hensigt at gøre det tilgængeligt overalt eller ej. Med det sagt understøtter Flow Builder flere typer af forløb, der har skærme. Brød-og-smør-typen er Skærmforløb, men der er nogle få andre specialtyper, der er begrænset til specifikke placeringer. Field Service Mobile-appen understøtter f.eks. kun - du gættede det - Field Service Mobile-forløb. Det samme gælder for 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 kan integreres. Forløbet vil være tilgængeligt på alle placeringer, der understøttes for den pågældende forløbstype.

Hvis du bruger Salesforce-brancher, er der en lille undtagelse, når det gælder Omniscript: Selvom du ikke kan angive et mål for et Omniscript selv, kan du angive et for de FlexCards, som du måske ønsker at integrere i det.

Statiske formularer er noget fra fortiden. I dag handler det om dynamisk at opdatere formularen med de rigtige egenskaber og værdier for denne bruger, denne gang, dette sted. Lad os tale om, hvad der er muligt i denne forbindelse for Salesforces formularopbygningsværktøjer.

• Hvilke typer interaktioner eller betingelser skal udløse dynamiske svar i din formular?
• Skal du udføre handlinger uden for skærmen i baggrunden, når din formular udfyldes?
• Skal du angive felter som synlige, påkrævede, skrivebeskyttede eller inaktiverede eller ændre formatering baseret på formularinput?

Skærmforløbsinteraktivitet er nu en realitet takket være genaktive skærme. Genaktivitet tillader individuelle komponenter på en forløbsskærm at kommunikere med hinanden - hvilket gør skærmforløb uendeligt mere effektive.

Udfør datahandlinger uden for skærmen: Skærmforløb tilbyder en deklarativ tilgang til at hente data på den samme skærm gennem skærmhandlinger. Skærmhandlinger kan give dig mulighed for at udløse automatisk startede forløb på enhver ændring på skærmen, eller når en bruger klikker på en handlingsknapkomponent. Du kan derefter tilknytte resultaterne af disse automatisk startede forløb til den samme skærm og eliminere behovet for, at brugere navigerer til en anden skærm.

LWC tilbyder en fuld række kabeladaptere, der giver dig adgang til Salesforce-data for at udfylde data i din formularkomponenter dynamisk og gør det muligt for udviklere at opdatere, slette og oprette registreringer gennem Apex

Lightning Web Components Off-Screen-datahandlinger

Synlighed: Synlighed kan kontrolleres dynamisk i alle formularopbygningsværktøjer. Dynamiske formularer, Flow Builder og OmniStudio håndterer dette med komponentsynlighedsfunktioner. Med dette kan du deklarativt vise eller skjule felter baseret på andre værdier på formularen, eller om brugeren er på en mobilenhed eller ej.

• Med dynamiske formularer kan synligheden kontrolleres baseret på registreringsfeltværdier, registreringer, der er relateret via opslagsfelter og formfaktor.
• Med forløb kan du basere en synlighedsregel på andre input på skærmen samt andre ressourcer, der er udfyldt tidligere i forløbet, f.eks. formler eller værdier fra andre registreringer.
  • Enhedsbaserede regler: Det er ikke tydeligt 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, er brugeren på Salesforce Mobile-appen.
  • Evaluering af andre ressourcer: Manuel variabel og formelreferencer evalueres kun på serveren. Så uanset hvilken værdi 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ørsel en anmodning til forløbssystemet (serveren) og henter de seneste værdier for de manuelle variabler og formler. 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 betinget visningsegenskab. Du kan dog ikke tilføje mere end en betinget visningsegenskab for et input.

Betinget inputstat: Hvis du har brug for dynamisk at kontrollere andre egenskaber, f.eks. om et felt er påkrævet, inaktiveret eller skrivebeskyttet, har du nogle få muligheder. Som forventet giver LWC dig fuld, reaktiv kontrol over din inputtilstand. Med reaktive skærmforløbskomponenter kan du dynamisk kontrollere komponentattributter som Skrivebeskyttet, Inaktiveret og Påkrævet for standardkomponenter, der understøtter det, mens OmniStudio understøtter det fulde spektrum 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 dynamisk at kontrollere andre egenskaber, f.eks. om et felt er påkrævet eller skrivebeskyttet, vil din bedste indsats på kort sigt være LWC, hvor du har fuld kontrol. Dette gælder især, hvis du har tilpassede krav til, hvordan du håndterer onblur eller onclick.

Reaktiver LWC'er i skærmforløb: Når du opbygger LWC'er, der både kan reagere på og ændre andre komponenter på et skærmforløb, kan du læse denne LWC Best Practices for Screen Flows guide for at sikre, at dine komponenter integreres godt i forløbskørselsmotoren og fungerer som forventet i fremtiden.

Nu til tilpassede begivenheder. Hvis nogle af dine input eller hele formularen skal kommunikere med noget andet på siden, 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 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 skal du sørge for, at din formular er i overensstemmelse med resten af appen eller lokaliteten, hvor den er integreret. Hvis du opnår dette, kan det betyde alt fra at bruge standardskabeloner, der leveres af Salesforce, til at oprette tilpasset CSS, der fuldstændigt bruger hver eneste pixel i designet til at give et skarpere udseende og funktionalitet.

• Hvor sofistikeret er din ønskede formatering og CSS?
• Har du brug for tilpasset, pixel-perfekt formatering, eller er du okay med standardtemaer?

FlexCards er det eneste produkt, der er dækket 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, direkte – uanset om det er margener og indre margener, typografi, farver osv.

Både dynamiske formularer og forløb respekterer deklarative temafunktioner. Hvis du har brug for kontrol ud over, hvad Salesforce-temaer eller Oplevelseskonstruktør-brandingssæt eller LWR Experience Cloud-lokaliteter understøtter, kan du overveje en programmeringsmæssig løsning.

For teams, der har det nemt at arbejde med CSS, har du et par muligheder:

• Forløb og LWC'er overtager standarddesigntokener.
• Omniscripts og FlexCards inkluderer understøttelse af et designsystem, der kan tilpasses: Newport.
• Med LWC kan du skrive dine egne komponenter og fuldt ud styre HTML og CSS for dem.

Hvor det er muligt, anbefaler vi brug af temaer og designsystemer, så dit udseende anvendes ensartet på tværs af alt dit indhold.

Påmindelse: Du kan integrere Lightning i forløb. Så hvis du har brug for pixel-perfekt kontrol over udseendet af din formular, men ønsker at bruge 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. Se Salesforce Well-Architected - Forms for at få flere oplysninger om dette emne.

• Hvordan kan du bruge dit formularlayout til at optimere brugeroplevelser?
• Hvordan kan du præsentere eksisterende data for dine 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 og kan opdeles i individuelle afsnit med felter. Disse afsnit kan placeres i komponenter som f.eks. faner og harmonika for at oprette brugervenlige og organiserede layouts.

Forløb kan eventuelt gengives ved brug af komponenten Afsnit. Med afsnit kan du tilføje op til fire kolonner og lige så mange afsnit, som du ønsker, på forløbsskærmen. Komponenten reagerer også på skærmbredde, så den kan fungere på mindre skærme. Endelig giver det 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 brugere 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 inklusive betinget sammenfoldelige harmonikaer.

Med LWC kan du bruge Lightning |view]-formular og det understøttende Lightning til at kontrollere layoutet. De eneste layoutbegrænsninger er dem fra HTML/CSS. Lightning respekterer afsnitskonfigurationen i det tilknyttede sidelayout. Hvis f.eks. et afsnit er to-kolonne i sidelayoutet, er det to-kolonne i denne komponent.

Hvis din formular vil 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 vil bruge til at opbygge den, opfylder dine lokaliseringskrav. Se Salesforce Well-Architected - Localization for at få yderligere vejledning og anbefalinger. I tilfælde af 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 har lokaliseret dine tilpassede felter, respekteres disse oversatte betegnelser på dynamiske formularer. Dynamiske formularer respekterer også tilpassede betegnelser, du har tildelt til komponentbetegnelser og attributter i Lightning App-konstruktør.

Med styrken fra Translation Workbench understøtter forløb oversættelse af brugerorienterede betegnelser for alle standardskærmkomponenter og tilpassede skærmkomponenter. Du kan lokalisere betegnelsen, hjælpeteksten og fejlmeddelelsen for disse skærmkomponenter: Tekst, Langt tekstområde, Tal, Valuta, Afkrydsningsfelt, Alternativknapper, Plukliste, Plukliste med flere valg, Afkrydsningsfeltgruppe, Adgangskode, Dato og 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 definerer de oversatte betegnelser med en tilpasset betegnelse, kan du referere til denne tilpassede betegnelse i handlingen eller komponenten, når du konfigurerer den i Flow Builder. Opret en forløbsformel, der refererer til den tilpassede betegnelse, og henvis til denne formel på de relevante steder i dit forløb.

Omniscripts bruger tilpassede betegnelser til oversættelser. Se i denne hjælpe-dokument for at gøre dine Omniscripts flersprogede klar.

Nu til LWC. Visse basiskomponenter overtager 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 stadig den usang hero. Erklær den tilpassede betegnelse, du har brug for, og importer den derefter til din komponent fra det @salesforce/label-omfangsmodul.

Der er flere end-to-end-testautomatiseringsværktøjer tilgængelige (f.eks. Selenium), som giver dig mulighed for at simulere, hvordan brugeren interagerer med din formular. Du kan skrive disse test for enhver standardbrugergrænseflade eller tilpasset brugergrænseflade, herunder Lightning og skærmforløb. Men det er vigtigt at bemærke, at disse typer af test ikke kan bekræfte resultaterne af hver metode, der udføres. Sørg for at tage dette med i betragtning, når du overvejer dine krav til brugergrænsefladetestautomatisering.

• Har du brug for automatiseret test for din formular?
• Hvilke typer af test skal du udføre?
• Hvilket detaljeniveau har du brug for i dine testautomatiseringer?

Overvej dine krav til brugergrænsefladetestautomatisering.

Enhedstest muliggør mere detaljeret automatisering og validering, der fungerer med branchestandard CI/CD-systemer og værktøjer, der kan teste komponenternes forretningslogik, dens JavaScript-controller og dens output. Hvis du kun bruger lav kode, kan du ikke selv oprette test, men Salesforce tester vores end-to-end-tilbud grundigt.

Hvis din komponents metoder er komplekse nok til, at du ønsker, at de skal testes individuelt, skal du placere metoderne i dedikerede JavaScript-filer. På den måde kan du importere dem i en LWC og i en Jest-test med noget som import { sort } from 'c/utils';.

Se UI Test Automation på Salesforce for at få en sammenligning af de forskellige muligheder, du har for at opbygge end-to-end-automatisering på Salesforce. Det omfatter overvejelser for, hvornår du skal bruge en uden kode-løsning fra en ISV, Build Your Own tilpasset testautomatiseringsløsning eller bruge en open source-teststruktur som Selenium WebDriver eller WebdriverIO. Disse løsninger er gyldige for enhver brugergrænsefladeinteraktion i Salesforce, uanset om det er en dynamisk formular på en Lightning, et skærmforløb på en hjælpeprogramlinje eller et LWC i et forløb i en hurtig handling.

Når du har implementeret din formular i et produktionsmiljø, ønsker du at sikre, at den bruges effektivt. Afhængig af din anvendelsessituation kan dette betyde alt fra blot at spore antallet af gange, den er blevet udfyldt, til mængden af tid, som brugere bruger på at udfylde den, før de indsender deres oplysninger. Sørg for at identificere de KPI'er, du vil spore, før du vælger et værktøj.

• Har du brug for at spore anvendelse af din formular?
• Hvilke KPI'er bestemmer, om din formular bruges effektivt?

Hvis du har brug for at spore den generelle anvendelse og ibrugtagning af din formular, skal du starte med værktøjerne med lav kode. Både dynamiske formularer og skærmforløb kan spores ved brug af tilpassede rapporttyper, der er klar til brug, men du får flere detaljer fra skærmforløbssporingsrapporterne. Hvis du har brug for at spore brugen af en LWC, afhænger tilgængeligheden af den køreklare LWC af, hvor du bruger den pågældende LWC. Hvis det er på en Lightning, gælder alt, hvad der er tilgængeligt for sporing af Lightning, for dit LWC. Det samme gælder for LWC'er, der er integreret i forløb.

Dynamiske formularer i sig selv kan ikke spores, selvom du kan spore brugen af den overordnede Lightning-side gennem Lightning-anvendelsesobjekter. Hvis du vil spore Lightning-standardsider, skal du bruge den tilpassede rapporttype Brugere med Lightning-anvendelse efter sidemetrikker. For det samme på tilpassede Lightning-sider skal du bruge den tilpassede rapporttype Brugere med Lightning-anvendelse efter FlexiPage Metrics.

For sporing af ibrugtagning af din specifikke formular (ikke kun den side, den findes på), har forløbet dig dækket. Brug "Eksempelforløbsrapport: Skærmforløb" til at besvare spørgsmål som:

• Hvad er fuldførelsesfrekvensen for denne formular? Anvendes det korrekt?
• Hvor lang tid tager det brugere at udfylde denne formular?
• Hvilken skærm bruger brugerne mest tid på?
• Hvor ofte navigerer brugerne bagud?
• Hvor ofte forekommer der fejl?

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

Hvis du bruger den pakkebaserede Omniscript-kørsel, kan du bruge OmniStudio for Vlocity Tracking Service. Denne tjeneste sporer enhver type begivenhed. Du kan f.eks. spore den tid, det tager at fuldføre trinene i et Omniscript for at identificere procesforbedringer. Det er på OmniStudio-teamets oversigt at understøtte denne tjeneste i Standard OmniStudio.

Hvis du vil spore det samme for en LWC, der ikke er integreret i et skærmforløb, Omniscript eller en Lightning, er der ingen indstilling, der er klar til brug. Du kan opbygge en tilpasset løsning ved brug af Apex.

Når du har brug for at implementere din løsning i højere miljøer til test eller implementering til produktion, kan du bruge ændringssæt eller DevOps Center til at gøre det. Dynamiske formularer, forløb og LWC'er understøttes fuldt ud i disse implementeringsindstillinger. OmniStudio kræver et separat værktøj: IDX Workbench.

• Hvordan planlægger du at implementere din formular?
• Vil din formular blive distribueret til mere end en Salesforce-organisation?

Hvis du er ISV eller en partner, der planlægger at pakke din løsning op til distribution på AppExchange, anbefaler vi, at du først ser på dynamiske formularer, forløb og LWC'er. OmniStudio understøtter ikke pakning.

Denne vejledning har været fokuseret på at hjælpe dig med at forstå, hvilken funktionalitet og niveau af tilpasning der er muligt med dynamiske formularer, skærmforløb, OmniStudio og LWC. På et højt niveau:

• LWC er den mest tilpassede og robuste indstilling til opbygning af en formular, men den har de færreste vagter på plads. Det er op til dig at opbygge en komponent på en måde, der sikrer sikkerhed og skalerbarhed.
• Dynamiske formularer er de mindst fleksible, men der er langt færre muligheder for fejltrin.
• Forløb og OmniStudio er et sted i midten – mere effektivt end dynamiske formularer, men ikke helt på niveau med LWC. På samme måde har de færre guardrails end dynamiske formularer, men er sværere at bryde end tilpasset kode.

Hvis flere værktøjer passer til fakturaen, kommer beslutningen ned til, hvilket værktøj der er det rigtige for dit team. Andre Arkitekt beslutningsvejledninger introducerer yderligere aspekter at overveje, når du træffer denne beslutning.

Vi vil ikke gå i detaljer med hvert af disse aspekter her, men hvad vi vil gøre, er at fortolke dem for de specifikke værktøjer, som dette dokument vurderer.

Special Skills: Hvor meget ekspertise har dit team i de værktøjer, du sammenligner? Hvor mange oprettere er velkendte og bekendte med LWC eller JavaScript? Hvad med oprettere, der er eksperter i Flow Builder eller har udtrykt en interesse i at nedsætte tæerne? Generelt er færdigheder for dynamiske formularer og forløb mere tilgængelige for en bredere population af personer, der opbygger formularer. Dynamiske formularer er det mest deklarative formularopbygningsværktøj og vil altid være nemmere at lære end forløb. Når det er sagt, er forløbsteamet forpligtet til at få denne søjle så lav som muligt. Med hensyn til kompleksitet ligger OmniStudio et eller andet sted mellem forløb og LWC og tilbyder betydelige superkræfter for opbygning af formularer.

Delegation af levering: Bare fordi nogle af dine krav kræver LWC, betyder det ikke, at hele din løsning skal bygges med LWC. Overvej, hvordan du kan opbygge din løsning modulært, så de dele, der kræver LWC, er kodet, og de dele, der ikke er bygget i en lav kode-løsning. Ved at gøre det maksimeres effektiviteten af et forskelligt team og sikrer, at hver enkelt løser problemer, der er relevante for deres speciale.

Lad os nu tale om forløb og LWC. Med reaktive skærmkomponenter kan skærmforløbskomponenter nu tale med hinanden på den samme skærm og låse op for en helt ny værktøjskasse for arkitekter, administratorer og udviklere. Udviklere kan nu oprette målrettede, modulære komponenter, der kan genbruges på tværs af organisationen, hvilket øger produktiviteten for alle i teamet. Udviklere kan fokusere på at løse nye udfordringer og spare tid ved at bruge en blanding af standardforløbskomponenter og tilpassede forløbskomponenter for at opnå formdynamik. Med reaktive komponenter i forløb har der aldrig været et mere passende tidspunkt at blande forløb og LWC, når du opbygger dine formularer.

Vedligeholdelse og langsigtet ejerskab: Hvis du har en formular med flere trin, er det en god ide at starte med forløb eller en blanding af forløb og LWC. Hvis du har et low-code-team, der vedligeholder løsningen, skal du tænke over, hvordan du kan gøre løsningen så konfigurerbar og udvidelig som muligt for den pågældende målgruppe. Uanset hvilket værktøj du vælger, kan du organisere din løsning i komponerbare enheder for at forbedre vedligeholdeligheden og stabiliteten.

Den anbefalede måde at konfigurere registreringsdetaljesider på er dynamiske formularer i Lightning App-konstruktør ved brug af Lightning. Det er længe siden, vi har forbedrede sidelayouts, og denne tendens vil fortsætte. Her er årsagen:

• Dynamiske formularer er mere fleksible – du kan placere felter og afsnit, hvor du vil, direkte i Lightning App-konstruktør, hvor du kan drage fordel af afsnit, faner og harmonika. Og ligesom du kan gøre med komponenter på Lightning, kan du kontrollere synligheden af dine felter og afsnit uden at definere flere sidelayouts eller registreringstyper.
• Med harmonika- og fanekomponenter kan du begrænse antallet af felter, der vises til en start. Gæt hvad det betyder? Hurtigere sideindlæsningstider.
• Layoutstyring er enklere med Lightning, da du kan administrere alt om dine sider fra Lightning App-konstruktør – uanset om det er indholdet af siden, eller hvilke brugere der har adgang til siden. Det er ikke længere nødvendigt at foretage opdateringer i dit sidelayout for at få en ændring til at ske på din Lightning. Med styrken i synlighedsregler behøver du ikke længere oprette flere sider (eller sidelayouts) for at kontrollere, hvem der ser hvilke felter, når. Og det betyder også, at du kun skal tildele brugere en Lightning i stedet for at tildele både en Lightning og et sidelayout.

Vi anbefaler, at du bruger dynamiske formularer, når det er muligt, og kun vender tilbage til sidelayouts, når det er nødvendigt. Som altid byder vi velkommen til feedback i Idea-udvekslingen om de forbedringer, der vil have størst indflydelse på din organisation.

Alle overvejelser i forbindelse med ydeevne, der er relateret til dynamiske formularer, skærmforløb, OmniStudio og LWC, fokuserer på, hvilken struktur disse teknologier selv er baseret på. De, der er baseret i LWC (udover selvfølgelig et LWC), klarer sig bedre end dem, der er baseret i Aura. LWC-strukturen tilbyder bedre ydeevne, fordi kernefunktioner implementeres som standard i websystemer i stedet for i JavaScript via strukturabstraktioner. Hvis du ikke er bekendt, så giv denne blogindlæg en læsning.

Tilbage i 2019 lavede vi en sagsstudie, der sammenlignede ydeevnen af den samme funktionalitet i Aura vs. i LWC. Som et resultat af konverteringen af DreamHouse fra Aura til LWC var udviklingsoplevelsen ikke kun meget mere i overensstemmelse med de aktuelle webfrontend-udviklingsstandarder og -mønstre, men effektivitetsforøgelserne var betydelige. Lab-målinger viste gevinster i området fra 2,4 procent til 24,7 procent for kold cache og gevinster i området fra 31,83 procent til 63,32 procent for varm cache på de samme to sider.

Hvilken struktur bruger vores formularteknologier? Med andre ord: Hvilke formeteknologier drager fordel af denne overlegne ydeevne?

• Dynamiske formularer, der er integreret i Lightning sider metadata, er bygget på et fundament, der bruger LWC stack, som vil gøre det muligt for os at implementere nogle længe ønskede funktioner. Som en præstationsbonus bruger dynamiske formularer progressiv gengivelse, hvilket resulterer i forbedret sideindlæsningstider for sider, der har et stort antal felter.
• Skærmforløb er bygget på LWC med de fleste af de individuelle komponenter, der er klar til brug, nu konverteret til LWC med undtagelse af to komponenter, der er klar til brug: Filupload og billede. Mens forløbsteamet konverterede forløbskørselsklienten til LWC samt de fleste af dets komponenter, skal kunderne stadig konvertere deres Aura-skærmkomponenter til LWC. Ikke kun det, men Salesforce understøtter kun LWC-komponenter i den nye reaktive komponentstruktur i skærmforløb. Der er et fremragende Trailhead modul, der forklarer, hvordan du gør det: Lightning Web-komponenter til Aura-udviklere. Det siger sig selv: Hvis du overvejer at opbygge en tilpasset komponent til et skærmforløb eller en anden beholder, skal du altid gå til LWC.
• Der er nogle få versioner af OmniStudio tilgængelige. Hvis du er en langvarig kunde, bruger du muligvis Angular. Vi opfordrer alle nye kunder til at starte med LWC-baserede Omniscripts og FlexCards, og at eksisterende kunder kan migrere fra Angular.
• LWC bygger på ... LWC selvfølgelig. Dette er en freebie.

Som arkitekt er det vigtigt at have en solid forståelse af alle de muligheder, der er tilgængelige for dig, og hvordan du kan anvende dem i din specifikke anvendelsessituation. For opbygning af formularer på Salesforce spænder mulighederne fra lav kode (brug af dynamiske formularer i Lightning App-konstruktør, skærmforløb i Flow Builder og Omniscripts i OmniStudio) til pro-code (brug af LWC-strukturen), med en kombination af skærmforløb eller Omniscripts og LWC i midten. Husk på denne vejledning, og brug den som en reference, når du planlægger at opbygge eller omdesigne formularer i Salesforce. Hvis du leder efter vejledning i, hvordan du designer strømlinede og nyttige formularer, kan du se Salesforce Well-Architected: Engagerende.

Hjælp os med at sikre, at vi udgiver det, der er mest relevant for dig: tag vores undersøgelse for at give feedback om dette indhold og fortæl os, hvad du gerne vil se som det næste.