Vill du bygga formulär på Salesforce Platform? Du har flera alternativ, som sträcker sig över hela lågkoden till pro-kodkontinuum. Representerande lågkod är dynamiska formulär i Lightning och skärmflöden i Flow Builder. Att hänga i mitten av kontinuumet är möjligheten att utöka skärmflöden med LWC och bygga kundvända formulär med OmniStudio. Och att representera pro-kod är LWC-ramverket och dess ständigt växande bibliotek av baskomponenter.

Alternativ är bra, men hur avgör du vilket (eller vilken kombination) som är rätt alternativ? Det är där denna guide kommer in.

• Takeaway #1: Använd dynamiska formulär när du bygger skapa/redigera/visa layouter för Lightning-sidor. Du kanske märker att sidlayouter saknas i jämförelsetabellerna i denna guide. Det rekommenderade sättet att konfigurera postdetaljsidor framåt är att använda dynamiska formulär i Lightning Appbyggare. Se avsnittet om sidlayouter för mer information om varför vi inte förväntar oss att förbättra dem ytterligare.
• Takeaway #2: Om du behöver bygga ett formulär för att skapa eller redigera exakt ett objekt, börja med Lightning sidor och dynamiska formulär. Detta är det enklaste sättet att bygga formulär på Salesforce Platform. Den har även ytterligare funktioner, till exempel möjligheten att styra fältsynlighet. Om dina krav är mer avancerade, fortsätt läsa. Skärmflöde, OmniStudio eller Lightning Web Components (LWC) kan passa bättre.
• Takeaway #3: Om du bygger ett flersidigt formulär eller en guide och inte har strikta UX- eller varumärkeskrav, börja med ett skärmflöde. Skärmflöden tillhandahåller ett linjärt navigeringsramverk för att orkestrera flera formulär tillsammans. Du kan använda LWC för att skapa ditt eget ramverk för att navigera mellan formulär, men vi rekommenderar att låta Flöde göra grovjobbet åt dig så att du kan fokusera på själva formulären istället för att oroa dig för formulärstatus.
• Takeaway #4: Om du behöver ytterligare logik eller åtgärder bakom formuläret, använd ett skärmflöde, OmniStudio eller LWC. Alla tre verktygen erbjuder sätt för din lösning att göra mer än att skapa eller redigera en enskild post. Denna "mer" kan vara mer avancerad logik, som förgreningar eller upprepningar, eller så kan det vara fler åtgärder som att integrera med externa system, skicka e-postmeddelanden eller pusha notiser till en användares mobilapp.
• Takeaway #5: Har du sofistikerade UX-krav? Behöver du dynamiskt hantera mer än synlighet? Använd LWC eller Omniscript. Om dina krav kan uppnås med enkla teman och kolumnbaserade layouter kan du bygga dina formulär direkt i en byggare med låg kod. För mer precis kontroll över ditt formulärs stil behöver du den ultimata flexibiliteten hos LWC. Om du är en Branschkund och behöver pixelperfekt varumärkning eller har komplexa hierarkiska data, använd OmniStudio, som låter dig bygga formulär för konsumentbetyg som kan hantera komplex affärslogik och datatransformationer.
• Takeaway #6: Om du behöver testautomatisering, börja med Lightning-webbkomponenter. Du kan skriva enhetstester för alla LWC, oavsett var du planerar att bädda in den. Detta ger dig möjligheten att skapa en mer robust teststrategi, som kan inkludera masstest med flera poster och negativa tester. Se Salesforces välarkitekterade teststrategi för mer information om att skapa tester som hjälper dig se hur väl dina formulär kommer att uppfylla dina funktionella och icke-funktionella krav.

Kom ihåg att ditt val inte behöver vara antingen eller - du kan kombinera kraften hos flera alternativ. Till exempel, om du behöver både Flows inbyggda navigeringssystem och den fullständiga stylingflexibilitet som LWC erbjuder, använd dem tillsammans.

Tabellen nedan beskriver de verktyg som är tillgängliga för att bygga formulär med Salesforce, tillsammans med deras kompetenskrav och överväganden vad gäller licenser. Senare kommer vi att fördjupa oss i de specifika funktioner som stöds för varje verktyg, samt hur man väljer mellan klickbaserade verktyg och kodbaserade verktyg (och när man kombinerar dem):

Tabellen nedan innehåller en översikt av beslutspunkterna att tänka på när du gör dina produktval, tillsammans med frågor som du bör ställa dig själv om var och en av dem. Vi kommer att fördjupa oss i vart och ett av dessa ämnen i resten av denna guide.

Här är de termer vi använder i jämförelsetabellerna tillsammans med deras definitioner:

• Tillgänglig: Fungerar bra med grundläggande överväganden.
• Inte idealiskt: Kan fungera men är inte det optimala verktyget.
• Vägkarta: Beräknat stöd inom de kommande tolv månaderna (juni 2025).
• Framtid: Uppskattad support efter de kommande tolv månaderna.
• Inte tillgängligt: Inga planer på att stödja denna kapacitet under de kommande tolv månaderna.

Som utlovat, låt oss starta en djupdykning i en mängd olika jämförelsepunkter och funktionella skillnader mellan dynamiska formulär, skärmflöden, OmniStudio, skärmflöden med inbäddade LWCs och själva LWC-ramverket.

Om ditt formulär fungerar mot ett enskilt Salesforce-objekt kommer alla verktyg vi jämför att fungera. Saker blir lite mer komplicerade med korsobjekt eller objektagnostiska formulär. Med objektagnostisk menar vi inmatningar som inte mappar till något Salesforce-objekt. Ditt formulär kanske representerar en datastruktur som du skickar till en extern tjänst, som Stripe eller DocuSign. Eller så kanske du använder flera inmatningar i ditt formulär för att beräkna ett värde och sedan överlämnar detta värde till databasen.

• Vilka objekt kommer formuläret att arbeta mot?
• Är det bara ett objekt eller finns det flera objekt?
• Arbetar du med specifika objekt (t.ex. Konto, Kontakt, Säljprojekt, Lead och Kundcase) eller behöver ditt formulär även fungera med andra objekt?

För både korsobjekt och objektagnostiska formulär är Flöde och OmniStudio solida alternativ. Komponenterna som är tillgängliga i flödesskärmar är agnostiska till sin natur, så du kan välja vad du vill göra med dessa data bakom kulisserna. Använd till exempel de data som angetts i ett formulär för att skapa flera poster bakom kulisserna, eller använd dessa data för att utföra andra åtgärder som att skapa Chatter, skicka Slack-meddelanden, skicka e-postmeddelanden eller ansluta till externa tjänster.

För enkla fall kan användning av befintliga LWC-komponenter, som Lightning postform, vara ett enkelt sätt att sänka kod som behövs för att ge en robust lösning. För scenarion där flera objekt är inblandade ger Flöde omfattande kontroll för alla objekt och tar bort behovet för utvecklare att gå igenom komplexa relationer och beroenden.

OmniStudio tar saker och ting ett steg längre och är helt objektagnostiskt — det separerar formuläret en användare ser från den underliggande datamodellen. Istället manipulerar OmniStudio underliggande JSON som sedan mappas till Salesforce-objekt (eller externa data) med hjälp av verktyg som Datamappning och integreringsprocesser. Datamappning och integreringsprocesser är två nyckelkomponenter i att ansluta dina OmniStudio-formulär med data interna och externa för Salesforce. Med dra-och-släpp-element kan du arbeta med komplexa hierarkiska data i ett externt system och sedan transformera data så att de passar dina behov beroende på vart datan behöver hamna. De låter dig även använda formler för att utföra matematik och logik på matriser, eller datalistor, ungefär som Apex.

OmniStudio-integreringar

Om du kan få alla dina användarinmatningar från ett formulär med en enda skärm, börja med dynamiska formulär. Dynamiska formulär på postsidor kan använda funktionen Väg för att löst representera de olika faserna i din verksamhetsprocess, men det kanske inte passar de flesta av dina användningsfall.

• Behöver du en enda skärm, eller behöver användaren gå mellan flera skärmar för att utföra en uppgift?
• Vill du att dina användare ska se en visuell bild av hur långt de kommit i processen att fylla i ditt formulär?
• Kommer dina användare att behöva fylla i informationen på varje skärm i en specifik ordning eller ska de kunna flytta fram och tillbaka mellan skärmarna efter behov?

Om du behöver mer funktionalitet än vad dynamiska formulär erbjuder beror valet mellan Flow, OmniStudio och LWC även på några andra frågor:

• Vilka kompetenser har ditt team? För en mer administratörstung organisation rekommenderar vi att börja med Flöde. Om du har Branschlösningar, ditt team redan är bekant med OmniStudio och ditt projekt har strikta UX-krav, börja med OmniStudio.
• Är det OK att visa ett navigeringsfält längst ner i ditt formulär? Om skärmflödet och Omniscript-navigeringsupplevelsen är oönskad UX, luta dig mot LWC.
• Vad behöver hända bakom formuläret? Om du vill att beteendet ska kunna konfigureras av en administratör, bygg ett flöde eller — för grundläggande ändringar som att ändra fältetiketter — ett Omniscript. Annars, för komplexa relationer med flera objekt, bygg ett Omniscript eller LWC.
• Om du väljer Flow eller OmniStudio kan du behöva bygga en LWC ändå för att uppnå rätt UX. Om du redan bygger en LWC för att utforma ditt formulär korrekt, överväg om det är överdrivet att bädda in den komponenten i ett flöde.

Om din lösning däremot ser ut som en guide där användaren går mellan flera skärmar, överväg Flöde eller OmniStudio. Flöden och OmniStudio levereras med en inbyggd navigeringsmodell, så du behöver inte bygga och underhålla LWC som är kopplade tillsammans. Navigeringen är linjär, med åtgärder framåt, bakåt och en mekanism för att spara formuläret till senare. Du kan även bygga ett formulär med icke-linjär navigering om det passar dina syften. För ett bra exempel på detta med skärmflöden, se paketet Digital butiksgranskning från Salesforce Labs.

OmniStudio erbjuder en viktig navigeringsfördel genom att tillhandahålla förloppsindikatorer från standardnavigering som lyfter fram "steg" i formuläret. Denna stegvy visar automatiskt var en användare är i ett givet flerstegsformulär. Till skillnad från Flöde låter det användare "hoppa" mellan skärmar genom att klicka på olika steg i formuläret.

Oavsett om du bygger formulär med en skärm eller flera skärmar, se till att dina formulär är strömlinjeformade så att de är enkla att navigera i för dina användare.

Om du bäddar in ett formulär på en standardpostsida i Lightning fungerar alla verktyg vi jämför, med reservationen att dynamiska formulär för närvarande endast är tillgängliga i skrivbordsversionen. Om du vill tillhandahålla en upplevelse som låter användare komma åt formulär från andra platser kan du dock behöva överväga alternativa alternativ.

• Behöver användare åtkomst till formuläret via skrivbord, mobil eller båda?
• Ska användare kunna komma åt formuläret från var som helst i din app via ett verktygsfält?
• Vill du använda snabbåtgärder så att användare kan fylla i ditt formulär utan att behöva lämna den sida de för tillfället är på?
• Behöver ditt formulär vara tillgängligt på en extern webbplats?

Eftersom de kräver postsammanhang stöds dynamiska formulär endast på Lightning. Dynamiska formulär stöds dock inte på Experience Cloud-sidor. Denna begränsning finns eftersom Experience Cloud inte använder det underliggande ramverket som dynamiska formulär är beroende av: Lightning sidor. Vi utvärderar detta baserat på begäranden om dynamiska formulär i Experience Cloud.

Du kan bygga flöden som kräver ett postsammanhang eller flöden som fungerar globalt. Som sådan kan du bädda in flöden på flera olika platser. För postsammanhangsflöden kan det vara en Lightning, en Experience Cloud-postsida, en objektspecifik åtgärd eller en distribuering av Åtgärder och rekommendationer. För det globala flödet kan det vara verktygsfältet, andra Lightning eller Upplevelsebyggarsidor, en Snap eller ett externt program. Flöden stöds för närvarande inte som globala åtgärder, men som en lösning kan du omge flödet med en Aura-komponent.

OmniStudio låter dig bygga komponerbara FlexCards och Omniscripts som du kan placera nästan var som helst där du kan placera ett flöde. Även om de är komponerbara går de dock inte att paketera.

LWC har stöd för en hög grad av återanvändning, eftersom du skapar komponenter som kan associeras med mål via metadata i Salesforce, diskussionsgrupper och till och med i projekt med öppen källkod. LWC-komponenter kan även bäddas in på din egen webbplats via Lightning Out.

Lightning ut på externa webbplatser

Lightning stöds för närvarande inte som snabbåtgärder (objektspecifika eller globala), men som en lösning kan du omge en LWC i en Aura-komponent (ungefär som du kan med flöden). LWC-komponenter kan även starta flöden med komponenten Lightning-flöde.

OmniStudio är utmärkt på att exponera innehåll på dina externa webbplatser genom OmniOut-funktionen. Med OmniStudio och OmniOut kan du kompilera dina Omniscript-formulär och FlexCard-komponenter till standardkomponenter och köra dem utanför plattformen i webbplatser eller appar från tredje part.

Ingen av de formulärtekniker som omfattas av denna guide stöds officiellt i Mobile SDK-mallar idag. Om Mobile SDK är viktigt för ditt användningsfall är det bättre att bygga ditt formulär inbyggt i din mobilapp eller bygga en Visualforce-sida, samtidigt som du tänker på vägledning för formulärfaktorer i Salesforce Well-Architected.

Färdplansanteckning: Mobile SDK-teamet arbetar aktivt med att stödja LWCs på Visualforce sidor.

Dynamiska formulär är perfekt om du behöver använda värdena i ditt formulär för att skapa eller uppdatera en post. För kapacitet utöver det måste du använda Flow, OmniStudio eller LWC. Dessa kapaciteter kan inkludera ett lager av beslut eller upprepningar, eller skapandet av Slack-inlägg eller e-postmeddelanden med indata från formuläret.

• Vilka åtgärder eller logik vill du ska utföras bakom kulisserna?
• Innehåller din datamodell hierarkiska data?
• Behöver ditt formulär utföra sina åtgärder inom en enskild transaktion eller över flera transaktioner?
• Behöver du integrera med externa system?
• Vilka är dina krav på återanvändning och modularitet?

Flödet erbjuder standardåtgärder för att göra inlägg i Slack, skicka e-post och interagera med Quip dokument, så du behöver inte skriva kod för dessa operationer. LWC erbjuder rika interaktioner med enskilda poster och relaterade objekt genom att använda kabeladapters som interagerar med User Interface API. LWC kan även interagera med flera poster vid användning av tråden för getListInfoByName.

Lightning-webbkomponenters interaktion via kabeladapters

Som nämnts ovan använder OmniStudio integreringsprocesser och Datamappning för att enkelt hämta och transformera data externa och interna till Salesforce. Den glänser i att platta ut och utöka datauppsättningar med olika nivåer av relationer tack vare många kodfria funktioner som du kan använda.

Färdplansanteckning: Flödet kommer snart att stödja möjligheten att infoga samlingar av poster igen, samt hantera hierarkiska data.

Flöde, OmniStudio och LWC integreras med Apex så att du enkelt kan åtgärda eventuella luckor i den lösning du väljer. Om du till exempel behöver filtrera poster från en LWC kan du alltid använda kabeladaptern för Apex för att skapa komplexa SOQL-frågor. Om du påverkas av den klickbaserade berättelsen, överväg Flow eller OmniStudio som användbara alternativ till en Apex kontroller för dina behov på serversidan.

En sekundär fråga här är om du vill utföra åtgärder direkt eller skjuta upp dem till en viss del av ditt formulär. Detta är särskilt relevant om du har ett formulär med flera sidor. Flödet gör det enkelt att kombinera inmatningar från flera formulär (flödesskärmar) och använda dem mycket senare i guiden (flödet) för att utföra vissa åtgärder. Vi rekommenderar faktiskt att utforma flöden på precis det sättet – utföra åtgärder i slutet – om användaren studsar fram och tillbaka mellan skärmar och ändrar sina svar.

Transaktioner och chefsgränser är ett sätt att leva på Salesforce Platform. Om ditt användningsfall är ganska enkelt kanske det inte är lika viktigt att styra vilken transaktion en viss operation sker i. Det finns dock några få användningsfall där du kanske vill kombinera flera operationer i en enda transaktion istället för att utföra dem över flera transaktioner. Några exempel:

• Att rollbacka eller inte rollbacka: Det är frågan. Låt säga att ditt formulär skapar flera poster bakom kulisserna. Om den tredje posten inte kan skapas, ska de två första posterna dras tillbaka? Om var och en av dina åtgärder är oberoende av varandra kan du utföra dem i separata transaktioner. Om de är beroende och du vill att en ska misslyckas med att även ta tillbaka de andra, implementera dem i en enda transaktion. Om ditt formulär är i Flöde kan du använda Rollback-elementet i en sökväg för fel för att ta tillbaka din transaktion och säkerställa dataintegritet.
• Påverkan nedströms på styrande gränser: Speciellt när ditt formulär skapar eller uppdaterar en post, tänk på vilka konsekvenser operationen har längre ner. Vilka processer, arbetsflödesregler, flödesutlösare, Apex utlösare eller andra objekt i sparordern kommer att aktiveras baserat på denna poständring? Och hur påverkar dessa kollektiva ändringar de styrande begränsningar som används i denna transaktion? Om en viss poständring kommer att resultera i många ändringar längre ner som påverkar dina gränser, överväg att isolera den poständringen till en egen transaktion.
• Batchbearbetning: Även i ett användargränssnittsammanhang kan du behöva bunta ihop flera uppdateringar. Låt säga att ditt flerskärmsformulär upprepas över en stor grupp poster. Istället för att göra en postuppdatering efter varje skärm, vänta tills du har samlat uppdateringarna för alla poster och skicka sedan in en begäran om att uppdatera alla poster.

När du använder dynamiska formulär för att skapa eller redigera en post utför du bara en operation och den operationen är alltid början på en ny nettotransaktion.

När du bygger ett skärmflöde har du betydande kontroll över vad som händer i en given transaktion. Skärmar och lokala åtgärder fungerar som gränser mellan transaktioner. Här är en övergripande sammanfattning av hur transaktioner hanteras i skärmflödesarkitekturen.

1. Slutanvändaren interagerar med en skärm och klickar sedan på Nästa.
2. Klienten publicerar en begäran till API med indata.
3. API tar emot begäran och en transaktions- och databasanslutning öppnas. API anropar sedan flödesmotorn för att åberopa begäran.
4. Flödesmotorn tar över och följer lämplig väg i flödesdefinitionen — tills den når en skärmnod eller lokal åtgärdsnod. Motorn returnerar sedan information om noden till API.
5. API skapar ett svarsobjekt som innehåller detaljerna för nästa skärm att återge och returnerar objektet till klienten. Vid denna tidpunkt utförs databasändringar (inled körningen av sparordern) och databasanslutningen och transaktionen avslutas.
6. Klienten använder API-svaret för att återge nästa skärm för användaren att interagera med.
7. Upprepa från steg 1.

Med andra ord, skärmar "bryter" transaktioner. När detta händer utförs alla väntande åtgärder eller DML, den föregående transaktionen avslutas och en ny transaktion startar.

Den rätta designen — vilka operationer du grupperar i en given transaktion — är ditt samtal. Vi går igenom några exempel.

Till vänster kan du se ett flöde som samlar indata över flera skärmar och sedan utför flera åtgärder i en transaktion.

Flödet till höger utför varje operation i en separat transaktion.

Anta att du har ett flöde som skapar poster, uppdaterar poster och sedan skapar fler poster — vilket illustreras i nästa flöde till höger.

I detta scenario, om de två första elementen lyckas och det sista misslyckas, kommer de två första DML-operationerna fortfarande att skapa och uppdatera dessa poster medan det tredje inte gör det.

Genom att använda elementet Dra tillbaka poster kan du säkerställa att hela transaktionen dras tillbaka om alla tre operationer måste inträffa tillsammans — enligt det slutgiltiga flödet till vänster.

Mer information finns i Flöden i transaktioner och Flödesbuntning i transaktioner. Sektionen Automatiserad i Salesforce Well-Architected går också in mer på djupet i detta i Datahantering.

Din möjlighet att styra transaktionen från en LWC kommer ner till de underliggande tjänster som LWC använder för att utföra sin verksamhet. Om du använder Lightning inträffar den underliggande åtgärden (skapa eller uppdatera posten) i en fristående transaktion så fort formuläret skickas.

I allmänhet gäller dessa regler:

• Varje UI API-anrop isoleras i sin egen transaktion.
• Om du behöver utföra flera operationer inom en enskild transaktion, skicka indata till en teknik på serversidan, till exempel en Apex kontroller eller ett flöde. De vanliga transaktionsreglerna för den tekniken gäller.

Flow, OmniStudio och LWC har alla stöd för plattformshändelser (för händelsedriven arkitektur) och API-integreringar. Utöver egen Apex kod har både Flow och OmniStudio stöd för deklarativa mekanismer för att integrera en API.

Om du behöver ansluta till en Mulesoft API- eller RPA-bot, använd Mulesoft Services. Detta skapar en extern tjänst.

Externa integreringar via Mulesoft API:n och RPA-botar

Om API har ett OpenAPI-schema, skapa en extern tjänst.

Externa integreringar till API med OpenAPI-scheman

Använd annars funktionen HTTP-anrop i Flöde eller HTTP-åtgärd i OmniStudio. Flödets HTTP-anrop drivs av externa tjänster.

Externa integreringar via HTTP

OmniStudio har en omfattande uppsättning integreringsfunktioner som kan anropa externa system med integreringsprocesser och transformera data med Data Mapper. (Se Objektpåverkan för mer information)

Oavsett om du implementerar det med egen Apex eller en extern tjänst är ett anrop ett anrop. Detta behöver du veta.

1. Ett anrop kan ta lång tid.
2. När ett anrop utförs synkront utförs det medan en databastransaktion är öppen.
3. Salesforce låter dig inte hålla en databastransaktion öppen om du har väntande databasoperationer.

Den största begränsningen att tänka på är risken för så kallade smutsiga transaktioner, där du utför en åtgärd för att skapa, uppdatera eller ta bort och sedan, i samma transaktion, utför ett anrop. Detta mönster är inte tillåtet på grund av överväganden #3 ovan, som naturligtvis finns på grund av överväganden #1 och #2.

I Flöde kan du kringgå denna begränsning genom att bryta transaktionen. Kom ihåg att skärmar och lokala åtgärder båda återinför webbläsarsammanhanget, vilket bryter transaktionen. Även om du kan använda skärmar och lokala åtgärder när du arbetar med externa anrop rekommenderar vi att aktivera Transaktionskontroll i åberopbara avancerade inställningar. Transaktionskontroll är en funktion i åberopbara åtgärder som låter dig avsluta transaktionen automatiskt innan ett anrop görs. Du kan aktivera transaktionskontroll genom att välja Starta alltid en ny transaktion i sektionen Avancerat i en åberopad åtgärd.

Mer ingående vägledning om Apex-anrop, externa tjänster och dataintegreringsfunktioner i allmänhet finns i Arkitektens guide till dataintegrering med Salesforce.

Dynamiska formulär har inte stöd för återanvändning. Varje dynamiskt formulär är knutet till en specifik Lightning för ett specifikt objekt (du kan dock tilldela denna Lightning till flera appar, profiler och så vidare).

Precis som du kan skriva bibliotek, verktyg och komponenter som är avsedda att användas över flera andra komponenter kan du tillämpa liknande designmönster när du skapar flöden med kraften hos underflöden. Spara dina flöden i mindre, mer modulära hinkar och anropa dem sedan från andra flöden genom att använda elementet Underflöde. Om din design kräver det kan du bygga ett flöde som både står för sig självt och är användbart som ett underflöde till ett annat.

OmniStudio är byggt för modularitet. Datamappningar, Omniscripts, FlexCards och integreringsprocesser byggs alla oberoende av varandra och kan fungera utbytbart. Utöver det kan FlexCards byggas som LWC-komponenter som går att bädda in i andra LWC, Omniscript, postsidor och Experience Cloud-webbplatser.

Skärmflöden, Omniscripts och LWCs kan alla byggas för återanvändning och bäddas in på flera olika platser, inklusive externa webbplatser och Lightning Out-program. När du utformar dina lösningar så att de är komponerbara får du ytterligare fördelar som anpassningsförmåga och stabilitet.

All teknik som används för att skapa eller uppdatera en post följer validering på systemnivå – oavsett om det är klassiska valideringsregler eller egen validering inbyggd i en Apex. Oavsett vilken teknik du använder för att utföra en poständring går varje ändring igenom sparordningen. Detta innebär att utöver valideringsregler bearbetas poständringen av valfritt antal flöden före eller efter sparande, före eller efter utlösare, omflyttningsregler, tilldelningsregler, med mera. Om du inte redan har gjort det, se till att bokmärka och bekanta dig med Apex ordning för utförande.

• Har ditt formulär ytterligare krav utöver validering på systemnivå?
• Behöver du ange att fält ska vara obligatoriska eller skrivskyddade dynamiskt i formuläret?

Inmatningar på en flödesskärm eller ett Omniscript-steg är av naturen obundna, så själva formuläret följer inte inbyggt systemnivåvalidering som är associerad med ett visst objekt. Vilka värden du än använder för att skapa eller uppdatera poster bearbetas dock av sparordern, vilket innebär att de går igenom objektets validering på systemnivå. Observera dock att inte alla skärmflödeskomponenter har stöd för validering av indata. Från och med utgåvan Summer '24 är de återstående skärmkomponenterna som inte har stöd för validering av indata Radioknappar, Kombinationsruta, Flervalskombinationsruta, Kryssrutegrupp och Valsökning.

Precis som med sidlayouter låter dynamiska formulär dig ange krav och skrivskyddat läge på sidnivå. Du kan dock inte åsidosätta inställningar på systemnivå.

Flödet ger flexibilitet för att anpassa validering av ett formulärs inmatningar. Vissa kontroller utförs i klienten (som att flagga saknade obligatoriska fält eller inkompatibla värden), men ingen validering på klientsidan blockerar användaren från att försöka navigera. Den riktiga valideringen sker på servern. När en användare klickar på Nästa skickar Flödet indata till servern för validering. Om några inmatningar returneras som ogiltiga blockeras navigeringen och lämpligt fel visas. Servern validerar indata genom att kontrollera:

1. Inmatningens inställning för krav, eller om det angivna värdet är kompatibelt med den underliggande datatypen.
2. Egen validering för denna indata: Flera standardkomponenter (kryssruta, valuta, datum, datum/tid, långt textområde, nummer, lösenord och text) har stöd för egen validering per skärm. Ange ett booleskt formeluttryck och ett felmeddelande att visa om formeluttrycket inte uppfylls.
3. Egen validering för den underliggande komponenten: Om du bygger en egen LWC för ett flöde, lägg till din egen valideringskod i metoden validate().

OmniStudio har funktioner för omfattande fel- och valideringshantering via åtgärden Ange fel i kombination med villkorliga vyer och komponenten Meddelanden.

På LWC-sidan utför de flesta baskomponenter sina egna valideringar på klientsidan. Till exempel respekterar Lightning postformulär systemnivåkrav, men inte sidnivåkrav. För dina egna komponenter kan du Build Your Own Valideringsmekanismer.

Fält som kräver att användare anger data bör visas tidigt i dina formulär. Validera användarinmatningar på klientsidan när så är möjligt innan formulär skickas in. Mer rekommenderade metoder för att effektivisera dina formulär finns i Vägledning för formulär i Salesforce Väl arkitektoniskt - engagerande.

Säkerhet är ett komplext ämne i allmänhet, och när det kommer till att bygga formulär finns det ett antal överväganden som du kanske inte ens har tänkt på. På den grundläggande nivån vill du se till att formuläret körs i rätt sammanhang och att användare har de behörigheter de behöver för att arbeta med dess underliggande data. Men utöver det kanske du även vill vidta extra åtgärder för att ta bort potentiellt skadlig kod eller URL:er från rich text-fält, förhindra vissa användare från att komma åt formuläret alls eller sätta begränsningar för vilka typer av platser som administratörer kan bädda in formuläret på i framtiden. Se till att dokumentera dina säkerhetskrav noggrant innan du väljer ett verktyg. Salesforces välutformade säkerhetspolicymall innehåller riktlinjer för denna typ av dokumentation.

• Ska formuläret kontrollera användarens åtkomst innan vissa operationer utförs?
• Ska du rengöra användarinmatningar?
• Vill du styra vem som har åtkomst till formuläret?
• Vill du styra var formuläret kan bäddas in?

När något körs i ett användarsammanhang tillämpar Salesforce en serie åtkomstkontroller, inklusive att verifiera fältnivåsäkerhet, CRUD-behörigheter och poståtkomst baserat på din organisations delningsregler. Så till exempel skulle användare endast kunna köra ett uppdateringsformulär för kundcase om de har möjlighet att uppdatera kundcase, lämplig fältnivåsäkerhet och åtkomst till posten i fråga. Men vad händer om du vill att användare ska kunna utföra en viss åtgärd när de använder ditt formulär, men inte genom något annat formulär eller interaktion? Det är där systemsammanhang kommer in.

Systemsammanhang är ett sätt att höja den aktuella användarens behörigheter under sessionen, så att användaren till exempel inte behöver Uppdatera-åtkomst till objektet Kundcase för att slutföra ditt formulär för kundcaseuppdatering. Detta är särskilt användbart för ej inloggade diskussionsgrupper. Istället för att bevilja gästanvändare potentiellt farliga förmågor, ange att ditt formulär ska köras i systemsammanhang.

Naturligtvis är systemsammanhang ett tveeggat svärd och du bör endast använda det vid behov. När ett formulär körs i systemsammanhang kringgår varje enskild CRUD-operation objekt- och fältnivåsäkerhet och delning — inte bara den specifika operation du bryr dig om. Observera även att systemsammanhang inte har någon betydelse för vem Salesforce anser vara aktören – namnet du ser i fältet Senast ändrad av. För varje operation som ditt formulär utför, till exempel kundcaseuppdateringen, är aktören den aktuella användaren även om formuläret körs i ett annat sammanhang.

Dynamiska formulär, Omniscripts och LWCs körs alltid i användarsammanhang och det finns inget sätt att åsidosätta detta beteende.

Skärmflöden körs i användarsammanhang som standard, men du kan ställa in dem att köras i systemsammanhang. Det är ditt val om flödet ska bevilja åtkomst till alla data eller om det fortfarande ska tillämpa åtkomst på postnivå, till exempel delning.

• Om du bäddar in en Lightning i ett flöde som körs i systemsammanhang åsidosätter inte flödet komponentens sammanhang. Om du behöver kringgå användaråtkomstkontroller rekommenderar vi att använda flödet för att utföra dessa operationer och skicka lämpliga data till eller från Lightning. Vissa färdiga komponenter (som Sök) kan inte fungera i systemsammanhang.
• Om ditt flöde anropar Apex åtgärder finns det några fler nyanser att förstå. Om Apex klassen är inställd på ärvd delning körs den i systemsammanhang med delning oavsett vad flödet är inställt till. Om klassen inte har någon uttrycklig delningsdeklaration körs den i systemsammanhang utan delning oavsett vad flödet är inställt till. Om klassen är inställd till med delning eller utan delning gör den det och åsidosätter flödets sammanhang.

Fråga efter poster i systemsammanhang med Experience Cloud-webbplatser:

Om du kör ett flöde i systemsammanhang på en Experience Cloud-webbplats, särskilt ej autentiserat, rekommenderar vi att endast lagra specifika fält i dina Hämta poster-element. När du arbetar med Flöde och skickar resultaten av ett Hämta poster-element till ett underflöde, åberopbar åtgärd eller en Lightning kan alla fält från det objektet inspekteras via webbläsarens utvecklarverktyg. Detta kan göra fält tillgängliga för dina Experience Cloud-webbplatsanvändare som du kanske inte vill. Genom att specificera specifika fält i dina Hämta poster-element kan du säkerställa att endast rätt fält visas även med systemsammanhang aktiverat.

Observera att Omniscript-logik körs på klientsidan, vilket gör det möjligt för hackers att ändra det förväntade utförandet av ett Omniscript och se svar på integreringsprocesser, datamappningar och Apex metodanrop med hjälp av webbläsarens utvecklarverktyg. När du använder Omniscript rekommenderar vi att köra verksamhetslogik på serversidan när så är möjligt och implementera valideringsregler för indata på alla Apex metoder som exponeras via en @InvocableMethod-annotering.

Saneringsinmatningar:

För att skydda din organisation från dåliga aktörer, överväg även sanering av indata. Anta att du har en inmatning i ett offentligt tillgängligt formulär som kan mappas till ett rich text-fält i din organisation. Du kanske vill överväga automatisering som tar bort all HTML som kan dölja skadliga URL:er. I allmänhet är det inte idealiskt att implementera denna sanering på formulärnivå, eftersom du kan låta hur många källor som helst skriva till dessa fält. Vi rekommenderar att skapa ett snabbt fältuppdateringsflöde (innan du sparar) eller använda en befintlig Apex på objektet för att ta bort eller ändra eventuell HTML som kan anges i formuläret.

Rekommenderade metoder:

• Låt flöden köras i sitt standardsammanhang om du inte behöver höja den aktuella användarens åtkomst för en specifik operation.
• Undvik att köra flöden i systemsammanhang för gästanvändare av säkerhetsskäl. Skapa behörighetsuppsättningar med begränsad fältåtkomst tilldelade till Experience Cloud-webbplatsens gästanvändarprofil istället.
• När du frågar efter poster i systemsammanhangsdrivna flöden på Experience Cloud-webbplatser, lagra endast de fält du behöver i ditt element Hämta poster eller Åberopbara åtgärder.
• Om ett flöde utför flera olika operationer och inte alla kräver förhöjd åtkomst, använd underflöden för att isolera de operationer som ska köras i systemsammanhang.
• Om du planerar att bädda in ett formulär på en extern webbsida, överväg att rengöra användarinmatningar för att ta bort HTML med ett snabbt fältuppdateringsflöde eller Apex-utlösare om de så småningom kommer att mappas till rich text-fält för att förhindra eventuella nätfiskeattacker från dåliga aktörer.

• Omniscripts, FlexCards och LWC körs i användarsammanhang som standard.
• LWC körs i användarsammanhang som standard och flöden körs i användarsammanhang, men du kan åsidosätta det i en Apex kontroll.
• Operationer som utförs genom UI API körs i användarsammanhang.
• Operationer som utförs via en Apex kontroll beror på den klassen. För att utföra dessa operationer i systemläge, sätt Apex till med delning eller utan delning.

Om du behöver kontroll över vem som har åtkomst till ditt formulär kan du ofta titta på behållaren som formuläret är inbäddat i. Du kan till exempel tilldela Lightning att vara tillgängliga för vissa appar, posttyper eller profiler. Om vissa inmatningar i ditt formulär är känsliga, använd visningsregler för att ytterligare styra vad som visas för vem. Denna funktion gäller för både dynamiska formulär och skärmflöden.

Du kan begränsa ett flöde till specifika profiler eller behörighetsuppsättningar, precis som du kan göra med en Apex klass eller Visualforce sida. Som standard är flöden obegränsade, vilket innebär att alla användare med användarbehörigheten Kör flöden kan köra dem.

Om du använder OmniStudio kan du konfigurera en Apex klassbehörighetskontroll för att säkerställa att användare kräver uttrycklig åtkomst till den Apex klass som administrerar fjärråtgärden som anropas från ett Omniscript, Flexcard, Classic Card eller REST API.

• Observera Apex klassbehörighetskontroller är aktiverade som standard för nyligen skapade skript. De måste dock aktiveras manuellt för alla befintliga skript
• Observera även att behörighetskontroller för Apex klasser endast gäller för Apex klasser. Vi rekommenderar att även ange behörigheter på profilnivå för integreringsprocesser och datamappningar.

Mer information och rekommenderade metoder för gästanvändarbehörigheter finns i:

• Rekommenderade metoder för gästanvändarpoståtkomst
• Utveckla säkra webbplatser: Inloggade användare och gästanvändare

Rekommenderade metoder:

• Om du exponerar ett flöde för gästanvändare, ge endast gästanvändarprofilen åtkomst till de flöden de behöver. Även om det är möjligt att lägga till Kör flöden i gästanvändarprofilen anser vi att detta är en riskabel metod.
• Var särskilt försiktig med flöden som fungerar i systemsammanhang. Vi rekommenderar starkt att du begränsar dessa flöden till en specifik uppsättning användare, eftersom de har färre kontroller och saldon för att skydda dina data.
• Se till att alla Omniscript som kör Apex i en gästanvändardiskussionsgrupp har "with sharing" i Apex klassdefinition.
• Tilldela endast de Apex klasser som du vill att gästanvändare ska kunna anropa på din gästanvändarprofil, annars riskerar du att oavsiktligt exponera ytterligare affärslogik för gästanvändare.

För LWC kan du kontrollera den aktuella användarens behörighetstilldelningar för att bekräfta om de har en viss standardbehörighet eller egen behörighet. Direkt från JavaScript kan du importera Salesforce-behörigheter från omfattningsmodulerna @salesforce/userPermission och @salesforce/customPermission. Eller så kan du använda Apex för att kontrollera samma sak.

Lightning-webbkomponenter är endast tillgängliga på en given plats när de har lagts till som ett giltigt mål. Du kan till exempel göra en komponent tillgänglig på postsidor och inte som ett verktygsfältobjekt.

När ett skärmflöde har aktiverats är det tillgängligt på alla platser som skärmflöden stöds, oavsett om du vill att det ska vara tillgängligt överallt eller inte. Flow Builder har dock stöd för flera typer av flöden som har skärmar. Bröd-och-smör-typen är Skärmflöde, men det finns några andra specialiserade typer som är begränsade till specifika platser. Till exempel har Field Service Mobile-appen endast stöd för - du gissade det - Field Service Mobile-flöden. Samma sak gäller för kontaktbegäranflöden, som endast stöds i Experience Cloud.

Oavsett flödestyp har individen som skapar flödet ingen kontroll över var flödet kan bäddas in. Flödet kommer att vara tillgängligt på alla platser som stöds för den flödestypen.

Om du använder Salesforce Industries finns det en viss varning när det gäller Omniscript: Du kan inte specificera ett mål för ett Omniscript, men du kan specificera ett för de FlexCards som du kanske vill bädda in i det.

Statiska formulär hör till det förflutna. Idag handlar det om att dynamiskt uppdatera formuläret med rätt egenskaper och värden för denna användare, denna gång denna plats. Låt oss prata om vad som är möjligt i denna stil för Salesforces formulärbyggarverktyg.

• Vilka typer av interaktioner eller villkor ska utlösa dynamiska svar i ditt formulär?
• Behöver du utföra åtgärder utanför skärmen i bakgrunden medan ditt formulär fylls i?
• Behöver du ange fält som synliga, obligatoriska, skrivskyddade eller inaktiverade eller ändra formatering baserat på formulärinmatningar?

Interaktivitet för skärmflöde är nu verklighet tack vare Reaktiva skärmar. Återaktivitet låter enskilda komponenter på en flödesskärm kommunicera med varandra – vilket gör skärmflöden oändligt mycket mer kraftfulla.

Utföra dataoperationer utanför skärmen: Skärmflöden erbjuder en deklarativ metod för att hämta data på samma skärm genom skärmåtgärder. Skärmåtgärder kan låta dig utlösa autostartade flöden för ändringar på skärmen eller när en användare klickar på en komponent för åtgärdsknappen. Du kan sedan mappa resultaten av dessa autostartade flöden till samma skärm, vilket eliminerar behovet för användare att navigera till en annan skärm.

LWC erbjuder en fullständig uppsättning kabeladapters som låter dig komma åt Salesforce-data för att fylla i data i ditt formulärs komponenter dynamiskt, och låter utvecklare uppdatera, ta bort och skapa poster via Apex kontroller.

Lightning-webbkomponenter Dataoperationer utanför skärm

Synlighet: Synlighet kan styras dynamiskt i alla formulärbyggverktyg. Dynamiska formulär, Flow Builder och OmniStudio hanterar detta med funktioner för komponentsynlighet. Med detta kan du deklarativt visa eller dölja fält baserat på andra värden i formuläret eller om användaren är på en mobil enhet eller inte.

• Med dynamiska formulär kan synlighet styras baserat på postfältvärden, poster relaterade via sökfält och formulärfaktor.
• Med Flöde kan du basera en visningsregel på andra inmatningar på skärmen, samt andra resurser som fyllts i tidigare i flödet, som formler eller värden från andra poster.
  • Enhetsbaserade regler: Det är inte självklart från början, men du kan använda en formel för att visa eller dölja ett visst fält när användaren är på en mobil enhet. Skriv en flödesformel som kontrollerar värdet på den globala variabeln $User.UIThemeDisplayed. Om värdet är Theme4t är användaren i Salesforce-mobilappen.
  • Utvärdera andra resurser: Manuella variabel- och formelreferenser utvärderas endast på servern. Så det värde som resursen har när skärmen först återges är det värde den kommer att ha tills du går till en annan skärm. Vid navigering skickar flödesruntime en begäran till flödesmotorn (servern) och får tillbaka de senaste värdena för de manuella variablerna och formlerna. Om du förväntar dig att din visningsregel ska uppdateras medan användaren passerar genom en enda skärm (till exempel onblur), se till att du endast refererar värden från de andra komponenterna på skärmen.
• Med OmniStudio kan du villkorligt visa eller dölja komponenter genom att konfigurera egenskapen Villkorlig vy. Du kan dock inte lägga till mer än en egenskap för villkorlig vy för en indata.

Stater för villkorlig indata: Om du behöver styra andra egenskaper dynamiskt, till exempel om ett fält är obligatoriskt, inaktiverat eller skrivskyddat, har du några olika alternativ. Som förväntat ger LWC dig fullständig, reaktiv kontroll över din indatastatus. Med återaktiva skärmflödeskomponenter kan du dynamiskt styra komponentattribut som Skrivskyddad, Inaktiverad och Krävs för standardkomponenter som har stöd för det, medan OmniStudio har stöd för hela spektrumet av komponentspecifika attribut. Om dina krav kräver att du behöver Flöde och komponenten inte har stöd för ett specifikt attributläge kan du skapa en inbäddbar LWC för att uppnå ett dynamiskt indataläge.

Om du behöver styra andra egenskaper dynamiskt, till exempel om ett fält är obligatoriskt eller skrivskyddat, är din bästa insats på kort sikt LWC, där du har full kontroll. Detta gäller särskilt om du har skräddarsydda krav för hur onblur eller onclick ska hanteras.

Reaktiva LWC i skärmflöden: När du bygger LWC som både kan reagera på och ändra andra komponenter i ett skärmflöde, se denna guide för rekommendationer för LWC för skärmflöden för att säkerställa att dina komponenter integreras väl i flödeskörningsmotorn och fungerar som förväntat i framtiden.

Nu för egna händelser. Om några av dina inmatningar eller hela formuläret behöver kommunicera med något annat på sidan är LWC ditt enda alternativ.

• För att kommunicera inom samma DOM-träd, använd CustomEvent-gränssnittet.
• För att kommunicera över DOM, använd Lightning Messaging Service.
• Om Lightning Meddelandetjänst inte stöds för din målbehållare, använd pub/under-modulen.

• Mer information finns i Kommunicera med händelser och Kommunicera över DOM i Lightning Web Components Dev Guide.
• För OmniStudio, konsultera Kommunicera med Omniscript från en Lightning-webbkomponent.

För att ge den bästa användarupplevelsen måste du säkerställa att ditt formulärs stil är enhetlig med resten av appen eller webbplatsen där det är inbäddat. Att uppnå detta kan innebära allt från att använda standardmallar som tillhandahålls av Salesforce till att skapa egen CSS som helt använder varje pixel i designen för att ge ett skarpare utseende och känsla.

• Hur sofistikerad är din önskade stil och CSS?
• Behöver du egen, pixelperfekt styling eller är du ok med standardteman?

FlexCards är den enda produkt som omfattas av denna guide som låter dig deklarativt styra stilen och layouten för det användargränssnitt du bygger i verktyget direkt – oavsett om det är marginaler och utfyllnad, typografi, färger etc.

Både dynamiska formulär och flöden respekterar deklarativa temafunktioner. Om du behöver kontroll utöver vad Salesforce-teman, varumärkningsuppsättningar för Upplevelsebyggaren eller LWR Experience Cloud-webbplatser har stöd för, överväg en programmatisk lösning.

För team som är bekväma med att arbeta med CSS finns några olika alternativ:

• Flöden och LWC ärver standarddesigntokens.
• Omniscripts och FlexCards innehåller stöd för ett anpassningsbart designsystem: Newport.
• Med LWC kan du skriva dina egna komponenter och helt styra HTML och CSS för dem.

När så är möjligt rekommenderar vi att använda teman och designsystem så att ditt utseende tillämpas enhetligt i allt ditt innehåll.

Påminnelse: Du kan bädda in Lightning i flöden. Så om du behöver pixelperfekt kontroll över utseendet på ditt formulär men vill använda de andra fördelarna med flöden, som navigeringsmodellen, kan du få det bästa av två världar. Samma princip gäller för Omniscripts och FlexCards.

Att välja en bra layout är viktigt för att utforma effektiva formulär som möjliggör snabb och effektiv datainmatning och ökar dataintegriteten. Se Salesforce Välarkitektade formulär för mer information om detta ämne.

• Hur kan du använda ditt formulärs layout för att optimera användarupplevelser?
• Hur kan du presentera befintliga data för dina användare på ett sätt som gör det enklare för dem att ange nya data i dina formulär?

Dynamiska formulär har stöd för layouter med två kolumner och kan delas upp i enskilda sektioner med fält. Dessa sektioner kan placeras i komponenter som flikar och dragspel för att skapa lättanvända och organiserade layouter.

Flöden kan om du vill återges med komponenten Sektion. Med sektioner kan du lägga till upp till fyra kolumner och så många sektioner du vill på flödesskärmen. Komponenten svarar även på skärmbredd, så den kan fungera på mindre skärmar. Slutligen ger det dig möjligheten att tillämpa villkorlig visning för hela sektionen, vilket gör det enklare att masstillämpa visning för flera fält inom sektionen. Flödessektioner har även stöd för kolumnrubriker och ger en dragspelsliknande upplevelse där användare kan minimera hela sektionen genom att klicka på etiketten.

Omniskript har en mängd olika layoutalternativ för att visa fält och data. Du kan skapa datasektioner med upp till 12 kolumner, inklusive villkorligt döljbara dragspel.

Med LWC kan du använda Lightning och det stödjande Lightning för att styra layouten. De enda layoutbegränsningarna är de från HTML/CSS. Lightning respekterar sektionskonfigurationen i den associerade sidlayouten. Till exempel, om en sektion har två kolumner i sidlayouten är det två kolumner i denna komponent.

Om ditt formulär kommer att vara tillgängligt för användare i olika regioner eller som talar olika språk måste du säkerställa att det verktyg du kommer att använda för att bygga det uppfyller dina lokaliseringskrav. Se Salesforce Väl arkitektritad - Lokalisering för ytterligare råd och rekommendationer. När det gäller formulär specifikt innefattar lokaliseringskrav vanligtvis att översätta textelement till andra språk.

• Kommer ditt formulär att användas i mer än ett land eller region?
• Behöver texten i ditt formulär lokaliseras till andra språk?

Om du har lokaliserat dina egna fält respekteras dessa översatta etiketter i dynamiska formulär. Dynamiska formulär respekterar även egna etiketter som du har tilldelat till komponentetiketter och attribut i Lightning Appbyggare.

Med kraften hos Translation Workbench har Flow stöd för översättning av användarvända etiketter för alla standardkomponenter och egna skärmkomponenter. Du kan lokalisera etiketten, hjälptexten och felmeddelandet för dessa skärmkomponenter: Text, Långt textområde, Nummer, Valuta, Kryssruta, Radioknappar, Kombinationsruta, Flervalskombinationsruta, Grupp för kryssruta, Lösenord, Datum och Datum/Tid.

Det finns inget inbyggt översättningsstöd för färdiga åtgärder, som Skicka e-post eller Gör inlägg till Chatter. Det finns dock en lösning! Om du definierar de översatta etiketterna med en egen etikett kan du referera till den egna etiketten i åtgärden eller komponenten när du konfigurerar den i Flow Builder. Skapa en flödesformel som refererar den egna etiketten och referera till den formeln på lämpliga platser i ditt flöde.

Omniskript använder egna etiketter för översättningar. Se detta hjälpdokument för att göra dina Omniscripts redo för flera språk.

Nu till LWC. Vissa baskomponenter hämtar automatiskt översättningar av det associerade objektets fält, hjälptext och valideringsmeddelanden om de har konfigurerats i Translation Workbench (till exempel: Lightning).

Om du behöver introducera nya översättningsbara etiketter i din kod är egna etiketter fortfarande den obesjungna hjälten. Ange den egna etikett du behöver och importera den sedan till din komponent från modulen @salesforce/label scoped.

Det finns flera verktyg för testautomatisering från början till slut (till exempel Selenium) som låter dig simulera hur användaren interagerar med ditt formulär. Du kan skriva dessa tester för alla standardgränssnitt eller egna användargränssnitt, inklusive Lightning sidor och skärmflöden. Det är dock viktigt att notera att dessa typer av tester inte kan verifiera utdata för varje metod som utförs. Se till att ta hänsyn till detta när du tänker igenom dina krav för automatisering av användargränssnitt.

• Behöver du automatiserade tester för ditt formulär?
• Vilka typer av tester behöver du utföra?
• Vilken detaljnivå behöver du i dina testautomatiseringar?

Tänk på dina krav för automatisering av användargränssnitttest.

Enhetstester möjliggör mer detaljerad automatisering och validering som fungerar med system och verktyg av branschstandard CI/CD, som kan testa komponenternas verksamhetslogik, dess JavaScript-kontroller och dess utdata. Om du endast använder lågkod kommer du inte att kunna skapa egna tester, men Salesforce testar våra helhetserbjudanden noggrant.

Om din komponents metoder är komplexa nog att du vill att de ska testas individuellt, placera metoderna i dedikerade JavaScript-filer. På så sätt kan du importera dem till en LWC och till ett Jest-test med något som import { sort } from 'c/utils';.

Se Användargränssnitt Testautomatisering i Salesforce för en jämförelse av de olika alternativ du har för att bygga heltäckande automatisering i Salesforce. Detta inkluderar överväganden för när du ska använda en ingen-kod-lösning från en ISV, Build Your Own Test Automation-lösning eller använda ett testramverk med öppen källkod som Selenium WebDriver eller WebdriverIO. Dessa lösningar är giltiga för alla användargränssnittinteraktioner i Salesforce, oavsett om det är ett dynamiskt formulär på en Lightning, ett skärmflöde i ett verktygsfält eller en LWC i ett flöde i en snabbåtgärd.

När du har distribuerat ditt formulär till en produktionsmiljö vill du se till att det används effektivt. Beroende på ditt användningsfall kan detta innebära allt från att bara följa antalet gånger det har fyllts i till hur lång tid användare lägger på att fylla i det innan de skickar in sin information. Se till att identifiera de nyckeltal du vill följa innan du väljer ett verktyg.

• Behöver du följa användningen av ditt formulär?
• Vilka nyckeltal avgör om ditt formulär används effektivt?

Om du behöver följa övergripande användning och användning av ditt formulär, börja med verktygen med låg kod. Både dynamiska formulär och skärmflöden kan spåras med hjälp av färdiga egna rapporttyper, men du får mer detaljerad information från spårningsrapporterna för skärmflöden. Om du behöver följa användningen av en LWC beror färdig tillgänglighet på var du använder denna LWC. Om det är på en Lightning gäller allt som är tillgängligt för att följa Lightning för din LWC. Samma sak gäller för LWC som är inbäddade i flöden.

Dynamiska formulär i sig går inte att spåra färdiga, men du kan följa användningen av den överordnade Lightning-sidan genom Lightning användningsobjekt. För att följa standardsidor i Lightning, använd den egna rapporttypen Användare med Lightning Usage efter sidmått. För samma sak på egna Lightning-sidor, använd den egna rapporttypen Användare med Lightning Usage efter FlexiPage-mått.

För att följa användning av ditt specifika formulär (inte bara sidan det finns på) har Flödet allt du behöver. Använd “Exempelflödesrapport: Skärmflöden” för att svara på frågor som:

• Vad är ifyllningsresultatet för detta formulär? Är det väl adopterat?
• Hur lång tid tar det för användare att fylla i detta formulär?
• Vilken skärm tillbringar användare mest tid på?
• Hur ofta navigerar användare bakåt?
• Hur ofta inträffar fel?

Om standardrapporten inte uppfyller dina behov, klona den för att göra dina egna ändringar eller Build Your Own från grunden genom att använda rapporttypen Skärmflöden.

Om du använder den paketbaserade Omniscript runtime kan du använda OmniStudio för Vlocity Tracking Service. Denna tjänst följer alla typer av händelser. Du kan till exempel följa tiden det tar att slutföra stegen i ett Omniscript för att identifiera processförbättringar. Den finns på OmniStudio-teamets vägkarta för att stödja denna tjänst i Standard OmniStudio.

För att följa samma sak för en LWC som inte är inbäddad i ett skärmflöde, Omniscript eller Lightning finns inget färdigt alternativ. Du kan bygga en egen lösning med Apex.

När du behöver distribuera din lösning till högre miljöer för test eller distribution till produktion kan du vara van att använda ändringsanvisningar eller DevOps Center för att göra detta. Dynamiska formulär, flöden och LWC stöds fullständigt i dessa distributionsalternativ. OmniStudio kräver ett separat verktyg: IDX Workbench.

• Hur planerar du att distribuera ditt formulär?
• Kommer ditt formulär att distribueras till mer än en Salesforce-organisation?

Om du är en ISV eller partner som planerar att paketera din lösning för distribution på AppExchange rekommenderar vi att först titta på dynamiska formulär, flöden och LWC. OmniStudio har inte stöd för paketering.

Denna guide har fokuserats på att hjälpa dig förstå vilken funktionalitet och anpassningsnivå som är möjlig med dynamiska formulär, skärmflöden, OmniStudio och LWC. På hög nivå:

• LWC är det mest anpassningsbara och robusta alternativet för att bygga ett formulär, men har det lägsta antalet skyddsräcken på plats. Det är upp till dig att bygga en komponent på ett sätt som garanterar säkerhet och skalbarhet.
• Dynamiska formulär är det minst flexibla, men det finns mycket färre möjligheter till felsteg.
• Flöde och OmniStudio finns någonstans i mitten – kraftfullare än dynamiska formulär men inte riktigt på nivån LWC. På samma sätt har de färre skyddsräcken än dynamiska formulär men är svårare att bryta än egen kod.

Om flera verktyg passar räkningen avgörs vilket verktyg som är rätt för ditt team. Andra beslutsguider för arkitektur introducerar ytterligare aspekter att tänka på när du fattar detta beslut.

Vi kommer inte att gå in på detaljerna för var och en av dessa aspekter här, men vad vi kommer att göra är att tolka dem för de specifika verktyg detta dokument bedömer.

Specialkompetens: Hur mycket expertis har ditt team i de verktyg du jämför? Hur många tillverkare är väl insatta och bekanta med LWC eller JavaScript? Vad sägs om beslutsfattare som är experter på Flow Builder eller har uttryckt intresse för att doppa tårna? Generellt sett är dynamiska formulär och flödeskompetenser mer uppnåeliga för en bredare population av personer som bygger formulär. Dynamiska formulär är det mest deklarativa verktyget för att bygga formulär och kommer alltid att vara enklare att lära sig än Flöde. Med detta sagt är flödesteamet fast beslutet att få denna stapel så låg som möjligt. När det gäller komplexitet ligger OmniStudio någonstans mellan Flow och LWC och erbjuder betydande superkrafter för att bygga formulär.

Delegering av leverans: Bara för att vissa av dina krav kräver LWC behöver inte hela din lösning byggas med LWC. Tänk på hur du kan bygga din lösning modulärt, till exempel att de delar som kräver LWC är kodade och de delar som inte är byggda i en lågkodslösning. Att göra detta maximerar effektiviteten hos ett mångsidigt team och säkerställer att varje individ löser problem som är lämpliga för deras specialisering.

Låt oss nu prata om Flow och LWC. Med Reaktiva skärmkomponenter kan skärmflödeskomponenter nu prata med varandra på samma skärm och låsa upp en helt ny verktygskista för arkitekter, administratörer och utvecklare. Utvecklare kan nu skapa ändamålsenliga, modulära komponenter som kan återanvändas i hela organisationen, vilket ökar produktiviteten för alla i teamet. Utvecklare kan fokusera på att lösa nya utmaningar och spara tid genom att använda en blandning av standardflödeskomponenter och egna flödeskomponenter för att uppnå formulärdynamik. Med reaktiva komponenter i Flöde har det aldrig funnits ett mer lämpligt tillfälle att blanda Flöde och LWC när du bygger dina formulär.

Underhållbarhet och långsiktigt ägandeskap: Om du har ett formulär med flera steg är det bra att börja med Flöde eller en blandning av Flöde och LWC. Om du har ett team med låg kod som underhåller lösningen, tänk på hur du kan göra lösningen så konfigurerbar och utökningsbar som möjligt för den målgruppen. Oavsett vilket verktyg du väljer, organisera din lösning i komponerbara enheter för att förbättra underhåll och stabilitet.

Framöver är det rekommenderade sättet att konfigurera postdetaljsidor dynamiska formulär i Lightning med Lightning. Det är länge sedan vi har utökade sidlayouter och den trenden kommer att fortsätta. Detta är anledningen:

• Dynamiska formulär är mer flexibla – du kan placera fält och sektioner var du vill direkt i Lightning, där du kan dra nytta av sektioner, flikar och dragspel. Precis som med komponenter på Lightning kan du styra synligheten för dina fält och sektioner utan att definiera flera sidlayouter eller posttyper.
• Med komponenterna Dragspel och Flik kan du begränsa antalet fält som visas inledningsvis. Gissa vad det betyder? Snabbare sidinläsningstider.
• Layouthantering är enklare med Lightning, eftersom du kan hantera allt om dina sidor från Lightning – oavsett om det är innehållet på sidan eller vilka användare som har åtkomst till sidan. Du behöver inte längre göra uppdateringar i din sidlayout för att göra en ändring på din Lightning. För att inte tala om att du med kraften hos visningsregler inte längre behöver skapa flera sidor (eller sidlayouter) för att styra vem som ser vilka fält när. Det innebär också att du endast behöver tilldela användare en Lightning istället för att tilldela både en Lightning och en sidlayout.

Vi rekommenderar att använda dynamiska formulär där det är möjligt och endast gå tillbaka till sidlayouter vid behov. Som alltid välkomnar vi feedback i Idéutbytet om de förbättringar som skulle vara mest effektiva för din organisation.

Eventuella överväganden om prestanda relaterade till dynamiska formulär, skärmflöden, OmniStudio och LWC-center på vilket ramverk dessa tekniker själva sitter. De som är baserade i LWC (förutom, naturligtvis, en LWC) kommer att överträffa de som är baserade i Aura. LWC-ramverket erbjuder bättre prestanda eftersom kärnfunktioner implementeras inbyggt i webbmotorer istället för i JavaScript via ramverksabstraktioner. Om du inte är bekant, läs detta blogginlägg.

2019 gjorde vi en fallstudie där vi jämförde prestandan för samma funktionalitet i Aura jämfört med LWC. Som ett resultat av att konvertera DreamHouse från Aura till LWC överensstämde inte bara utvecklingsupplevelsen mycket bättre med nuvarande standarder och mönster för webbfrontendutveckling, utan prestandaförbättringarna var också betydande. Labbmätningar visade ökningar i intervallet 2,4 procent till 24,7 procent för kall cache och ökningar i intervallet 31,83 procent till 63,32 procent för varm cache på samma två sidor.

Vilket ramverk använder våra formulärtekniker? Med andra ord, vilken form av teknik drar nytta av denna överlägsna prestanda?

• Dynamiska formulär, som är integrerat i Lightning metadata, bygger på en grund som använder LWC-stack, vilket gör att vi kan implementera några funktioner som länge efterfrågats. Som en prestandabonus använder dynamiska formulär progressiv återgivning, vilket resulterar i förbättrad sidinläsningstid för sidor som har ett stort antal fält.
• Skärmflöden är byggda på LWC med de flesta av de individuella färdiga komponenterna nu konverterade till LWC med undantag för två färdiga komponenter: Filuppladdning och bild. Även om flödesteamet konverterade flödeskörningsklienten till LWC och de flesta av dess komponenter måste kunder fortfarande konvertera sina Aura-skärmkomponenter till LWC. Salesforce har även endast stöd för LWC-komponenter i det nya ramverket för reaktiva komponenter i skärmflöden. Det finns en utmärkt Trailhead modul som förklarar hur man gör detta: Lightning-webbkomponenter för Aura-utvecklare. Det säger sig självt: Om du funderar på att bygga en egen komponent för ett skärmflöde eller någon annan behållare, gå alltid LWC.
• Det finns några versioner av OmniStudio. Om du är en långvarig kund kanske du använder Angular. Vi uppmuntrar alla nya kunder att börja med LWC-baserade Omniscripts och FlexCards, och för befintliga kunder att migrera från Angular.
• LWC bygger på ... LWC så klart. Detta är en freebie. 🤓

Som arkitekt är det viktigt att ha en solid förståelse för alla alternativ som finns tillgängliga för dig och hur du kan tillämpa dem i ditt specifika användningsfall. För att bygga formulär i Salesforce varierar alternativen från låg kod (med dynamiska formulär i Lightning, skärmflöden i Flow Builder och Omniscripts i OmniStudio) till pro-kod (med LWC-ramverket), med en kombination av skärmflöden eller Omniscripts och LWC i mitten. Tänk på denna guide och använd den som en referens när du planerar att bygga eller omdesigna formulär i Salesforce. Om du letar efter råd om hur du utformar effektiva och hjälpsamma formulär, se Salesforce Well-Architected: Engagerande.

Hjälp oss se till att vi publicerar det som är mest relevant för dig: Svara på vår undersökning för att ge feedback om detta innehåll och berätta vad du vill se härnäst.