Byggnadsformulär

Det finns flera alternativ för att bygga formulär på Agentforce 360 Platform och de sträcker sig över ett kontinuerligt flöde från lågkod till prokod. I ena änden av kontinuumet kan dynamiska formulär i Lightning och skärmflöden i Flow Builder användas för lösningar med låg kod. I andra änden används ramverket Lightning Web Component (LWC) för prokodlösningar. Inom kontinuumet kan verktyg blandas på flera olika sätt med hjälp av skärmflöden som utökas med LWC och kundvända formulär som byggs med Omnistudio.

Denna guide presenterar ett beslutsramverk och riktlinjer för att bygga formulär för användargränssnittslösningar. Specifikt använder den ett dussin runtime och icke-funktionella beslutspunkter för att korrekt välja den bästa tekniken för ett givet användningsfall.

• Använd dynamiska formulär när du bygger skapa/redigera/visa layouter för Lightning-sidor. Vi rekommenderar att du använder dynamiska formulär i Lightning-appbyggaren för att konfigurera postdetaljsidor.

• Om du behöver bygga, skapa eller redigera ett formulär för ett objekt, använd Lightning-sidor och dynamiska formulär. Detta är det enklaste sättet att bygga formulär på Agentforce 360 Platform. Den ger även ytterligare funktionalitet (till exempel fältsynlighetskontroll).

• Om du bygger ett flersidigt formulär eller en guide och du inte har strikta UX- eller varumärkeskrav, använd ett skärmflöde. Skärmflöden tillhandahåller ett linjärt navigeringsramverk för att orkestrera flera formulär. 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 jobbet så att du kan fokusera på själva formulären istället för att fokusera på formulärläget.

• Om du behöver ytterligare logik eller åtgärder för att stödja formuläret, använd ett skärmflöde, Omnistudio eller LWC. Vart och ett av dessa verktyg erbjuder olika sätt att förbättra din lösning genom att låta den expandera utöver att skapa eller redigera en enskild post. I detta fall kan termen mer referera till avancerad logik (till exempel förgreningar eller upprepningar), eller till åtgärder som att integrera med externa system, skicka e-postmeddelanden eller pusha notiser till en användares mobilapp.

• Om du har sofistikerade UX-krav, eller om du dynamiskt behöver hantera mer än användargränssnittets synlighet, använd LWC eller Omniscript. För krav som kan uppfyllas genom att använda teman och kolumnbaserade layouter kan du bygga dina formulär direkt i en byggare med låg kod. Detaljerad kontroll över ditt formulärs stil kräver dock 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 av konsumentkvalitet som kan hantera komplex affärslogik och datatransformationer.

• Om du behöver distribuera testautomatisering, använd LWC. Du kan skriva enhetstester för alla LWC, oavsett var du bäddar in den. Detta ger möjligheten att skapa en mer robust teststrategi, vilket kan inkludera masstest med flera poster, samt negativa tester.

• Du är inte bunden av "antingen/eller" beslut. Du kan kombinera flera alternativ för att nå den bästa lösningen för dina användningsfall (till exempel om du behöver Flows inbyggda navigeringssystem och den fullständiga stilflexibilitet som LWC erbjuder kan du använda dem tillsammans).

Följande verktyg används ofta för att implementera och utöka formulärupplevelser.

Denna tabell visar de verktyg som är tillgängliga för att bygga formulär via Salesforce, tillsammans med deras kompetenskrav och överväganden vad gäller licenser.

Obs! Vi går djupare in i de specifika funktioner som stöds för varje verktyg, hur man väljer mellan klickbaserade verktyg och kodbaserade verktyg, och när man kombinerar dem i ett senare avsnitt.

Det finns ett antal beslutspunkter att tänka på när du gör produkt- och verktygsval. Denna tabell sammanfattar olika beslutspunkter och ger vägledning på hög nivå.

Obs! I efterföljande beslutsjämförelsetabeller finns det en handfull värden som är associerade med alla verktygs-funktionspar:

• Tillgänglig: Verktyget/funktionen fungerar med grundläggande överväganden.

• Inte tillgängligt: Det finns inga planer på att lägga till support inom de kommande tolv månaderna.

• Inte idealiskt: Detta verktyg/funktion kanske fungerar, men det är inte det optimala verktyget.

• Ej tillämpligt: Verktyget gäller inte för det specifika användningsfallet.

Använd dessa scenarion för att jämföra verktygsval baserat på omfattning, UX och operativa behov.

Om du kan få alla dina användarinmatningar från ett formulär med en enda skärm, börja med dynamiska formulär. Kom ihåg att dynamiska formulär på postsidor kan använda funktionen Väg för att stödja fasade verksamhetsprocesser.

• 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 när de fyller 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 Flöde, Omnistudio och LWC på några ytterligare frågor:

• Är det OK att visa ett navigeringsfält längst ner i ditt formulär? Om navigeringsupplevelsen för skärmflöden och Omniscript ger en oönskad UX, luta dig mot LWC.

• Vad behöver inträffa bakom formuläret? Om du vill att beteendet ska kunna konfigureras av en administratör, använd ett flöde. För komplexa relationer med flera objekt, använd Omniscript eller LWC.

Om du väljer Flöde eller Omnistudio kan du även behöva bygga en LWC för att uppnå rätt UX. Om du redan bygger en LWC för att utforma ditt formulär korrekt, överväg om du behöver bädda in den komponenten i ett flöde.

Navigering i guidestil

Å andra sidan, om din lösning 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 har en inbyggd navigeringsmodell, så du behöver inte bygga och underhålla LWC:er 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.

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

Oavsett om du bygger formulär med en eller flera skärmar är det viktigt att säkerställa att dina formulär är effektiva så att de är enkla för dina användare att navigera i.

Om du bäddar in ett formulär på en standardpostsida i Lightning fungerar alla verktyg vi jämför. För närvarande är dynamiska formulär dock endast 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 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 aktivera 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 det kräver postsammanhang stöds funktionen Dynamiska formulär endast på Lightning. Dynamiska formulär stöds dock inte på Experience Cloud-sidor.

Du kan bygga flöden som kräver ett postsammanhang, eller flöden som fungerar globalt. Med andra ord kan du bädda in flöden på flera olika platser. För postsammanhangsflöden kan platser inkludera: Lightning, Experience Cloud-postsidor, objektspecifika åtgärder eller distribueringar av Åtgärder och rekommendationer. För globala flöden kan platser inkludera: verktygsfältet, andra Lightning eller Upplevelsebyggarsidor, Snap eller externa program. För närvarande stöds inte flöden som globala åtgärder, men du kan kringgå detta genom att linda in flöden i en Aura-komponent.

Omnistudio låter dig bygga kompabilitetsbara FlexCards och Omniscripts som du kan placera nästan var som helst där du kan placera ett flöde, men även om de är kompabilitetsbara går de inte att paketera.

LWC erbjuder en hög grad av återanvändbarhet för att skapa komponenter som kan associeras med mål via metadata i Salesforce, diskussionsgrupper och projekt med öppen källkod. LWC-komponenter kan även bäddas in på din egen webbplats med Lightning Out 2.0.

LWC-komponenter kan även starta flöden med komponenten Lightning-Flow.

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

För närvarande stöds inte någon av de formulärtekniker som omfattas av denna guide officiellt i Mobile SDK-mallar. Om Mobile SDK är viktigt för ditt användningsfall rekommenderar vi att bygga ditt formulär inbyggt i din mobilapp eller bygga en Visualforce, med formulärfaktorn i åtanke.

Dynamiska formulär är perfekta om du behöver använda värdena i ditt formulär för att skapa eller uppdatera en post. Du måste använda Flöde, Omnistudio eller LWC för kapacitet utanför detta omfång, inklusive att skapa besluts- eller upprepningslager, eller skapa Slack-inlägg eller e-postmeddelanden med indata från formuläret.

• Vilka åtgärder eller logik behöver utföras bakom kulisserna?

• Behöver du använda värden från en relaterad post?

• 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, och du behöver inte skriva kod för någon av dessa operationer. LWC erbjuder rika interaktioner med enskilda poster och relaterade objekt via kabeladapters som interagerar med User Interface API. LWC kan även interagera med flera poster med tråden för getListInfoByName.

Omnistudio använder integreringsprocesser och Data Mapper för att hämta och transformera data (både externa och interna till Salesforce). På grund av många kodfria funktioner är den utmärkt på att platta ut och utöka datauppsättningar med olika nivåer av relationer.

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

Du bör även överväga om du vill utföra åtgärder omedelbart eller skjuta upp dem till en viss del av ditt formulär. Detta är särskilt relevant om du använder ett formulär med flera sidor. Flöde gör det enkelt att kombinera inmatningar från flera formulär (flödesskärmar) och använda dem senare i guiden (flöde) för att utföra vissa operationer, vilket är exakt hur vi rekommenderar att utforma flöden. Utför åtgärder i slutet (om användare studsar fram och tillbaka mellan skärmar för att ändra sina svar).

Transaktioner och chefsgränser är integrerade i Agentforce 360 Platform. Om ditt användningsfall är ganska enkelt kanske det inte är lika viktigt att styra transaktionen där en viss operation inträffar. Det finns dock några få användningsfall där du vill kombinera flera operationer i en enda transaktion istället för att utföra dem över flera transaktioner.

Här är några exempel:

• Rollback: Låt säga att ditt formulär skapar flera poster bakom kulisserna. Om skapandet av en tredje post misslyckas, ska de första två posterna dras tillbaka? Om var och en av dina åtgärder är oberoende av varandra kan du utföra dem som separata transaktioner. Men om de är beroende av varandra — och du vill att en ska misslyckas för att även ta tillbaka de andra — bör du implementera dem som en enskild transaktion. Om ditt formulär är i Flöde kan du använda elementet Återställning i sökvägen Fel för att ta tillbaka din transaktion och säkerställa dataintegritet.

• Påverkan nedströms på styrande gränser: När ditt formulär skapar eller uppdaterar en post är det viktigt att tänka på vad operationen innebär längre ner:

  • Vilka processer, arbetsflödesregler, flödesutlösare, Apex utlösare eller andra objekt inom sparordern kan aktiveras baserat på de föreslagna poständringarna?

  • Hur påverkar dessa kollektiva ändringar de styrande begränsningar som används inom denna transaktion?

  • Om en viss poständring kan resultera i många ändringar längre ner som påverkar dina gränser kan det vara bäst att isolera den poständringen i sin egen transaktion.

• Batchbearbetning: Du kan behöva bunta ihop flera uppdateringar (även inom ett användargränssnittsammanhang). 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 sker inom 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 inom skärmflödesarkitekturen.

1. Slutanvändaren interagerar med en skärm och klickar sedan på Nästa.

2. Klienten publicerar en inmatningsbegäran till API.

3. API tar emot begäran och öppnar en transaktions- och databasanslutning. Sedan anropar API Flow-motorn 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ärm eller lokal åtgärdsnod. Sedan returnerar motorn 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 (per körningen av sparordern) och databasanslutningen och transaktionen avslutas.

6. Klienten använder API-svaret för att återge nästa skärm som användaren interagerar med.

7. Börja från steg 1 och upprepa processen.

Med andra ord bryter skärmar transaktioner. När detta inträffar utförs alla väntande åtgärder eller DML, den föregående transaktionen avslutas och en ny transaktion påbörjas. Kom ihåg att de specifika designelementen (vilka operationer du grupperar i en given transaktion) är upp till dig.

Här är några exempel:

• När du börjar ser du ett flöde som samlar in indata över flera skärmar och sedan utför flera åtgärder inom en transaktion.
• Nästa flöde utför varje operation i en separat transaktion.
• Flöden kan även använda Återkalla poster för att låta dig ta tillbaka en hel transaktion om en enskild operation misslyckas inom en serie databasoperationer. Låt säga att du har ett flöde som skapar poster, uppdaterar poster och sedan skapar ytterligare poster (illustrerat i nästa flöde).

I detta scenario, om de två första elementen lyckas och det sista misslyckas, skapar och uppdaterar de två första DML-operationerna fortfarande de relevanta posterna, men inte den tredje. Genom att använda elementet Återställ poster kan du säkerställa att hela transaktionen dras tillbaka om alla tre operationer måste utföras kollektivt (som visas i det slutgiltiga flödet).

Obs! Mer information finns i Flöden i transaktioner och Flödesbuntning i transaktioner.

Din möjlighet att styra transaktionen från en LWC baseras på de underliggande tjänster som LWC använder för att utföra sin verksamhet. Om du använder baskomponenten Lightning inträffar den underliggande åtgärden (skapa eller uppdatera posten) i en fristående transaktion när 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 kontroll eller ett flöde). Kom ihåg att de vanliga transaktionsreglerna för den tekniken fortfarande 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 Flow och Omnistudio deklarativa stödmekanismer som även kan integreras med API:er.

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

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

För alla andra instanser, använd funktionen HTTP-anrop (driven av externa tjänster) i Flöde eller HTTP-åtgärden i Omnistudio.

Omnistudio har en omfattande uppsättning integreringsfunktioner som kan anropa externa system med hjälp av integreringsprocesser för att transformera data via Data Mapper.

Oavsett om du använder egen Apex kod eller en extern tjänst för implementering är ett anrop fortfarande ett anrop.

Detta behöver du veta.

• Ett anrop kan ta lång tid att bearbeta.

• När ett anrop utförs synkront utförs det medan en databastransaktion är öppen.

• Salesforce låter dig inte hålla en databastransaktion öppen om du har några väntande databasoperationer.

Kom ihåg att den största begränsningen är risken att lämna data i ett inkonsekvent läge, vilket inträffar när du utför en åtgärd för att skapa, uppdatera eller ta bort och sedan utför ett anrop inom samma transaktion. Detta mönster är inte tillåtet på grund av det tredje övervägandet som nämns ovan, som finns på grund av de två första övervägandena.

I Flöde kan du kringgå denna begränsning genom att bryta transaktionen. Kom ihåg att fönster och lokala åtgärder återinför webbläsarsammanhanget. Du kan använda skärmar och lokala åtgärder när du arbetar med externa anrop, men vi rekommenderar att aktivera Transaktionskontroll i åberopbara avancerade inställningar. Transaktionskontroll låter dig automatiskt avsluta transaktionen innan ett anrop görs. För att aktivera transaktionskontroll, välj “Påbörja alltid en ny transaktion” i sektionen Avancerat i den åberopade åtgärden. LWC hjälper till att förenkla påverkan av anrop på transaktionen. Med andra ord, utför dina dataåtgärder med Lightning Data Service (LDS) och använd sedan en Apex kontroll för att göra det externa anropet. Eftersom LDS-anropet är isolerat i sin egen transaktion (separat från Apex) skyddar detta dig från resulterande datainkonsekvens.

Dynamiska formulär har inte stöd för återanvändning. Var och en är knuten till en specifik Lightning för ett specifikt objekt. Du kan dock tilldela denna Lightning till flera appar, profiler och så vidare.

På samma sätt som du kan skriva bibliotek, verktyg och komponenter som kan användas över flera komponenter kan du även tillämpa liknande designmönster när du skapar flöden genom att utnyttja kraften hos underflöden. För att göra detta, spara dina flöden i mindre, modulära hinkar och anropa dem sedan från andra flöden med elementet Underflöde. Om din design kräver det kan du bygga ett flöde som är användbart på egen hand och som ett underflöde.

Omnistudio är byggt för modularitet. Datamappningar, Omniscripts, FlexCards och integreringsprocesser byggs alla oberoende av varandra, men de kan även fungera utbytbart. FlexCards kan även byggas som LWC-komponenter som kan bäddas in i andra LWC, Omniscripts, 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 kompositerbara får du även fördelar vad gäller anpassning och stabilitet.

All teknik som används för att skapa eller uppdatera poster måste följa systemnivåvalidering, oavsett om det är klassiska valideringsregler eller egna valideringar som är inbyggda i en Apex. Oavsett vilken teknik du använder för att utföra poständringar måste varje ändring gå igenom sparordningen. Detta innebär att utöver valideringsregler bearbetas även poständringar av ett antal flöden före eller efter sparande, före eller efter utlösare, omflyttningsregler, tilldelningsregler och så vidare.

Obs! Om du inte redan har gjort det, granska och bokmärk Apex ordning för utförande.

• Har ditt formulär några ytterligare krav utöver validering på systemnivå?

• Behöver du ange obligatoriska eller skrivskyddade fält dynamiskt i formuläret?

Vanligtvis är inmatningar på en flödesskärm eller ett Omniscript-steg obundna, så själva formuläret följer inte den validering på systemnivå som är associerad med ett visst objekt. Värdena som du använder för att skapa eller uppdatera poster bearbetas dock i sparordningen, vilket innebär att de går igenom objektets validering på systemnivå.

Obs! Inte alla skärmflödeskomponenter har stöd för validering av indata.

Precis som med sidlayouter låter dynamiska formulär dig ange obligatoriskt och skrivskyddat läge på sidnivå. Kom ihåg att du inte kan åsidosätta inställningar på systemnivå.

Flödet ger flexibilitet för att anpassa validering av formulärinmatning. Flera kontroller utförs på klientnivå (till exempel flagga obligatoriska fält som saknas och datatypkontroller samt kompatibla formler inom valideringsregler för indata). Som en extra säkerhetsnivå utvärderas även indatavalidering på servern. När en användare klickar på Nästa skickar Flödet indata till servern för validering igen. Om några ogiltiga inmatningar returneras blockeras navigeringen och lämpligt fel visas.

Servern validerar indata genom att kontrollera:

• Inmatningens kravinställning, eller om det angivna värdet är kompatibelt med den underliggande datatypen.

• Den egna valideringen av indata. Du måste ange ett booleskt formeluttryck och ett felmeddelande att visa om formeluttrycket inte uppfylls.

• Den egna valideringen av den underliggande komponenten. Om du bygger en egen LWC för ett flöde måste du lägga till din egen valideringskod i metoden validate().

Du kan även tillhandahålla tillgängliga användarvarningar via komponenten Meddelande i skärmflöden, men detta hindrar inte en användare från att gå till andra sidor eller till nästa steg i ett guidat flöde. Felläget i komponenten Meddelande används bäst på dedikerade felskärmar som utlöses via en felsökväg när navigering är inaktiverad.

Omnistudio har robust fel- och valideringshantering via åtgärden Ange fel i kombination med villkorliga vyer och komponenten Meddelanden.

För LWC utför de flesta av baskomponenterna 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.

Kom ihåg att fält som kräver att användare anger data ska visas i början av dina formulär. Validera användarinmatningar på klientsidan innan formulär skickas in (om möjligt).

Statiska formulär är inaktuella. Idag har fokus flyttats till att dynamiskt uppdatera formulär med rätt egenskaper och värden för en specifik användare, vid en specifik tidpunkt, på en specifik plats. Låt oss ta en närmare titt på vad som är möjligt via Salesforces formulärbyggarverktyg.

• Vilka typer av interaktioner eller villkor ska utlösa dynamiska svar i ditt formulär?

• Behöver du utföra operationer utanför skärmen (bakgrund) medan ditt formulär fylls i?

• Behöver du ange fält som synliga, obligatoriska, skrivskyddade eller inaktiverade, eller behöver du ändra formatering baserat på formulärinmatningar?

Reaktiva skärmar aktiverar interaktivitet för skärmflöden. Återaktivitet låter enskilda komponenter på en flödesskärm kommunicera med varandra, vilket gör skärmflöden mer kraftfulla.

Utföra dataoperationer utanför skärmen

Skärmflöden ger en deklarativ metod för att hämta data på samma skärm via skärmåtgärder. Skärmåtgärder låter dig utlösa autostartade flöden för ändringar på skärmen eller när en användare klickar på en komponent i åtgärdsknappen. Du kan mappa autostartade flödesresultat till samma skärm, vilket eliminerar behovet för användare att navigera till en annan skärm.

LWC tillhandahåller en fullständig uppsättning kabeladapters som ger åtkomst till Salesforce-data för att dynamiskt fylla i data i formulärkomponenter, vilket låter utvecklare uppdatera, ta bort och skapa poster via Apex kontroller.

Synlighet

Synlighet kan styras dynamiskt i alla formulärbyggarverktyg. Dynamiska formulär, Flow Builder och Omnistudio hanterar detta med hjälp av komponentsynlighetsfunktioner. Du kan deklarativt visa eller dölja fält baserat på andra värden i formuläret, eller om användaren fyller i formuläret på en mobil enhet.

• Dynamiska formulär styr synligheten baserat på postfältvärden, sökfält och formulärfaktor.

• Med Flöde kan du basera en visningsregel på andra skärminmatningar samt andra resurser som fylls i tidigare i flödet (till exempel formler eller värden från andra poster).

  • Enhetsbaserade regler: Det kanske inte är 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 fyller användaren i formuläret med Salesforce-mobilappen.

  • Utvärdera andra resurser: Manuella variabel- och formelreferenser utvärderas endast på servern. Detta innebär att det värde som resursen har när skärmen först återges är det värde som den kommer att ha tills du går till en annan skärm. Under navigering skickar flödeskörningen en begäran till flödesmotorn (servern) och returnerar de senaste manuella värdena och formelvärdena. Om du förväntar dig att din visningsregel ska uppdateras medan användaren passerar genom en enda skärm (till exempel onblur), måste du säkerställa 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.

Villkorliga indatalägen

Om du behöver styra andra egenskaper dynamiskt (till exempel om ett fält är obligatoriskt, inaktiverat eller skrivskyddat) finns några olika alternativ. LWC ger fullständig, reaktiv kontroll över din indatastatus. Med Reaktivt skärmflöde-komponenter kan du dynamiskt styra komponentattribut (till exempel skrivskyddade, inaktiverade och obligatoriska) 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), använd LWC kortsiktigt eftersom du har fullständig 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

Om du bygger LWC som kan reagera på och ändra andra komponenter i ett skärmflöde, se guiden Rekommenderade metoder för LWC för skärmflöden för att säkerställa att dina komponenter integreras med flödeskörningsmotorn och fungerar som de ska.

För egna händelser, om vissa av dina inmatningar (eller hela formuläret) behöver kommunicera med ett annat element 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 modulen pub/sub.

• Mer detaljerad information finns i Kommunicera med händelser och Kommunicera över DOM i Lightning Web Components Dev Guide.

• För Omnistudio, se Kommunicera med Omniscript från en Lightning-webbkomponent.

För att ge den bästa användarupplevelsen är det viktigt att säkerställa att din formulärstyling är enhetlig med resten av appen eller webbplatsen där den är inbäddad. Detta kan innebära att använda standardmallar som tillhandahålls av Salesforce, eller att skapa en egen CSS som använder varje pixel i designen för att ge ett skarpare utseende och känsla.

Administratörer kan konfigurera en begränsad uppsättning åsidosättningar av skärm- och komponentstyling (till exempel färger, kanter och knapputseenden), för skärmbehållaren eller för enskilda komponenter. Dessa åsidosättningar tillämpas efter teman och varumärkning, vilket låter byggare göra riktade visuella justeringar utan att påverka resten av programmet.

Åsidosättningar av formatering är avsedda för lokaliserade visuella undantag (till exempel att markera en bekräftelseskärm eller betona en specifik uppmaning till åtgärd (CTA), de är inte ett fullständigt formateringssystem. De ger inte kontroll på CSS-nivå och de är inte utformade för att återanvändas över skärmar eller flöden.

Ur ett arkitektoniskt perspektiv bör styling följa denna prioritetsordning:

1. Teman och varumärkning: Lightning, Upplevelsebyggarens varumärkesuppsättningar eller LWR-webbplatstema

2. Åsidosättningar av flödesstyling: Riktade skärm- eller komponentjusteringar

3. Egna komponenter (LWC): när pixelperfekt kontroll eller återanvändbara designmönster krävs

Att använda teman och designsystem hjälper till att säkerställa att styling förblir enhetlig, skalbar och enkel att underhålla över tid.

• Hur sofistikerad är din önskade stil och CSS?

• Behöver du egen, pixelperfekt styling eller standardteman?

FlexCards är den enda produkten i denna guide som låter dig deklarativt styra stil och layout för det användargränssnitt du bygger i verktyget (till exempel marginaler och utfyllnad, typografi, färger och så vidare).

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

Team som är bekväma med att arbeta med CSS har flera alternativ:

• Flöden och LWC ärver standarddesigntokens.

• Omniscripts och FlexCards inkluderar anpassningsbart stöd för designsystem via Newport.

• Med LWC kan du skriva dina egna komponenter och helt styra deras HTML och CSS.

När det är möjligt rekommenderar vi att använda teman och designsystem för att säkerställa ett enhetligt utseende i allt ditt innehåll.

Obs! Du kan bädda in Lightning i flöden. Om du behöver pixelperfekt kontroll över utseendet på ditt formulär, men du vill även använda de andra fördelarna med flöden (till exempel 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.

• Hur kan du strukturera formulärlayouter för att optimera användarupplevelser?

• Hur kan du presentera befintliga data för 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 som kan delas upp i enskilda sektioner inom fält. Dessa sektioner kan placeras inom komponenter (till exempel flikar och dragspel) för att skapa organiserade, lättanvända layouter.

Flöden kan även återges med komponenten Sektion. Du kan lägga till upp till fyra kolumner och ett obegränsat antal sektioner på flödesskärmen. Komponenten Sektioner svarar även på skärmbredd, så den fungerar även på mindre skärmar. Det ger 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 kommer från HTML och CSS. Komponenten Lightning-postformulär respekterar sektionskonfigurationen i den associerade sidlayouten (till exempel, om en sektion har två kolumner i sidlayouten har den även två kolumner i komponenten).

Om ditt formulär måste kunna kommas åt av användare i olika regioner eller som talar olika språk måste du se till att det verktyg du använder för att bygga det uppfyller dina lokaliseringskrav.

Obs! För 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 lokaliserar egna fält respekterar dynamiska formulär de översatta etiketterna. Dynamiska formulär respekterar även egna etiketter som är tilldelade till komponentetiketter och attribut i Lightning Appbyggare.

Flödet har stöd för översättning av användarvända etiketter för alla standardkomponenter och egna skärmkomponenter via Translation Workbench.

Du kan lokalisera etiketter, hjälptext och felmeddelanden på dessa skärmkomponenter:

• Text
• Långt textområde
• Nummer
• Valuta
• Kryssruta
• Radioknappar
• Kombinationsruta
• Kombinationsruta med flerval
• Lösenord för kryssrutagrupp
• Datum
• Datum/tid

Det finns inget inbyggt översättningsstöd för färdiga åtgärder (till exempel Skicka e-post eller Gör inlägg till Chatter), men det finns en lösning. Om du använder en egen etikett för att definiera de översatta etiketterna kan du referera till den egna etiketten i åtgärden eller komponenten när du konfigurerar den i Flow Builder. För att göra detta måste du skapa en flödesformel som refererar den egna etiketten och sedan referera till den formeln på lämpliga platser i ditt flöde.

Omniskript använder egna etiketter för översättningar. Mer information finns i detta hjälpdokument för att säkerställa att dina Omniscripts är redo för flera språk.

För LWC ärver vissa baskomponenter 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 rätt väg att gå. Ange den egna etikett du behöver och importera den sedan till din komponent från modulen @salesforce/label scope.

Använd denna sektion för att utvärdera säkerhet, kvalitet och operativa begränsningar innan implementering.

Säkerhet är ett komplext ämne, och när det gäller att bygga formulär finns det ett antal överväganden som kanske inte är uppenbara. På den grundläggande nivån måste du säkerställa 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. Utöver detta 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 eller begränsa vilka typer av platser som administratörer kan bädda in formuläret i i framtiden.

Se till att dokumentera dina säkerhetskrav noggrant innan du väljer ett verktyg. Mer information om denna typ av dokumentation finns i Salesforces välutformade säkerhetspolicymall.

• 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 ett program körs i ett användarsammanhang tillämpar Salesforce en serie åtkomstkontroller, som inkluderar att verifiera fältnivåsäkerhet, CRUD-behörigheter och poståtkomst baserat på din organisations delningsregler (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).

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 via något annat formulär eller interaktion? Det är där systemsammanhang kommer in i bilden!

Systemsammanhang låter dig höja en användares behörigheter under sessionen (till exempel behöver användaren inte uppdatera åtkomsten till kundcaseobjektet 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.

Systemsammanhang ska endast användas när det är absolut nödvändigt. När ett formulär körs i systemsammanhang kringgår varje CRUD-operation objekt- och fältnivåsäkerheten och delningskomponenterna. Systemsammanhanget påverkar inte heller vem Salesforce anser vara aktören (namnet du ser i fältet Senast ändrad av). För varje åtgärd som ditt formulär utför (till exempel en kundcaseuppdatering) är aktören den aktuella användaren (även om formuläret körs i ett annat sammanhang).

Obs! 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. Du kan bestämma om flödet ska bevilja åtkomst till alla data eller om det ska tillämpa åtkomst på postnivå.

• 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, använd flödet för att utföra dessa operationer och skicka lämpliga data till eller från Lightning. Vissa färdiga komponenter (till exempel Sök) kan inte fungera inom systemsammanhang.

• Om ditt flöde anropar Apex åtgärder är andra nyanser involverade.

  • Om Apex-klassen är inställd på ärvd delning kommer den att köras i systemsammanhang med delning oavsett hur flödet är inställt.

  • Om klassen inte har någon uttrycklig delningsdeklaration kommer den att köras i systemsammanhang utan delning oavsett hur flödet är inställt.

  • Om klassen är inställd till med delning eller utan delning åsidosätter den flödets sammanhang.

Frågeposter i systemsammanhang med Experience Cloud-webbplatser

Om du kör ett flöde i systemsammanhang på en Experience Cloud-webbplats (särskilt om det inte är autentiserat), lagra endast specifika fält i dina element Hämta poster. När du arbetar med Flöde och skickar resultaten av ett element för Hämta poster till ett underflöde, åberopbar åtgärd eller en Lightning-komponent kan alla fält från det objektet inspekteras av webbläsarens utvecklarverktyg. Trots dina avsikter kan detta göra fält tillgängliga för Experience Cloud-användare. För att säkerställa att endast rätt fält visas när systemsammanhang är aktiverat, specificera dessa specifika fält i dina element Hämta poster.

Obs! 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 via webbläsarens utvecklarverktyg. När du använder Omniscript är det viktigt att köra verksamhetslogik på serversidan (om möjligt) och implementera valideringsregler för indata för alla Apex metoder som exponeras via en @InvocableMethod-annotering.

Sanera indata

För att skydda din organisation från dåliga aktörer, använd sanering av indata. Låt säga 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 att aktivera automatisering som tar bort all HTML som kan dölja skadliga URL:er.

Det är inte idealiskt att implementera sanering på formulärnivå eftersom du kan ha hur många källor som helst som skriver till dessa fält. För att motverka detta problem, skapa ett snabbfältuppdateringsflöde (innan sparande) eller använd en befintlig Apex-utlösare för att ta bort eller ändra eventuell HTML som kan anges i formuläret.

• 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. Skapa behörighetsuppsättningar med begränsad fältåtkomst och tilldela dem till Experience Cloud-gästanvändarens profil.

• När du frågar poster i Systemsammanhangskörningsflöden på Experience Cloud-webbplatser, lagra endast de fält du behöver i elementet Hämta poster eller Åberopbara åtgärder.

• Om ett flöde utför flera olika operationer—som alla inte kräver förhöjd åtkomst—använd underflöden för att isolera de operationer som ska köras inom systemsammanhang.

• Om du bäddar in ett formulär på en extern webbsida kan det behöva mappas till Rich Text-fält för att förhindra potentiella nätfiskeattacker. För att göra detta, sanera användarinmatningar för att ta bort HTML med ett snabbt fältuppdateringsflöde eller Apex-utlösare.

• Omniscripts, FlexCards och LWC körs i användarsammanhang som standard.

• LWC körs i användarsammanhang som standard.

• Flöden körs i användarsammanhang, men du kan åsidosätta det genom att använda en Apex kontroll.

• Operationer som utförs inom användargränssnittets API körs i användarsammanhang.

• Operationer som utförs med en Apex kontroll beror på den specifika klassen. För att utföra dessa operationer i systemläge, sätt Apex-klassen till med delning eller utan delning.

Om du behöver styra vem som har åtkomst till ett formulär, gå igenom behållaren där formuläret är inbäddat (till exempel kan du tilldela Lightning att vara tillgängliga för vissa appar, posttyper eller profiler). Om vissa inmatningar är känsliga, använd visningsregler för att ytterligare styra vad som visas för vem. Denna funktion gäller för dynamiska formulär och skärmflöden.

Du kan begränsa ett flöde till vissa profiler eller behörighetsuppsättningar (liknande Apex class eller Visualforce sidor). Flöden är obegränsade som standard, vilket innebär att alla användare med användarbehörigheten Kör flöden har åtkomst till dem.

Om du använder Omnistudio kan du konfigurera en Apex klassbehörighetskontroll som kräver att användare har uttrycklig åtkomst till den Apex klass som administrerar fjärråtgärder från Omniscript, Flexcard, Classic Card eller REST API.

Obs! Behörighetskontroller för Apex klasser gäller endast för Apex klasser. Du bör även ange behörigheter på profilnivå för integreringsprocesser och datamappningar.

• Om du exponerar ett flöde för gästanvändare ska du endast bevilja gästanvändarprofilåtkomst till de flöden som de absolut behöver. Det går att lägga till Kör flöden i gästanvändarprofiler, men detta kan vara riskabelt.

• Var försiktig när du arbetar med flöden som arbetar i systemsammanhang. Du bör begränsa 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 med delning som listas i Apex klassdefinition.

• För gästanvändarprofiler, tilldela endast de Apex klasser som du vill att gästanvändare ska kunna anropa. Genom att följa denna metod hjälper det till att förhindra att ytterligare affärslogik oavsiktligen exponeras 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. Du kan importera Salesforce-behörigheter från omfattningsmodulerna @salesforce/userPermission och @salesforce/customPermission direkt i JavaScript. Du kan även använda Apex för att kontrollera behörigheter.

LWC är endast tillgängliga på en given plats efter att de har lagts till som ett giltigt mål (till exempel kan du göra en komponent tillgänglig på postsidor och inte tillgänglig 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. Flow Builder har stöd för flera typer av flöden som har skärmar. Den mest framträdande 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 Field Service Mobile-flöden). Detta liknar kontaktbegäranflöden, som endast stöds i Experience Cloud.

Oavsett Flödestyp har personen som skapar flödet ingen kontroll över var flödet är inbäddat. Flöden är tillgängliga på alla platser där den specifika flödestypen stöds.

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 mål för de FlexCards du vill bädda in.

På Salesforce finns flera verktyg för testautomatisering från början till slut (se till exempel Salesforce UTAM) som låter dig simulera hur en användare interagerar med dina formulär. Du kan skriva tester för alla standardgränssnitt eller egna användargränssnitt, inklusive Lightning och skärmflöden.

Obs! Dessa typer av tester kan inte verifiera utdata för de metoder som utförs. Tänk på detta när du konfigurerar dina krav på automatisering av användargränssnitttest.

• Behöver du automatiserade tester för dina formulär?

• Vilka typer av tester planerar du att utföra?

• Vilken detaljnivå behövs för testautomatiseringar?

Överväg automatiseringskrav för användargränssnitttest

Enhetstester ger detaljerad automatisering och validering som överensstämmer med system och verktyg av branschstandard CI/CD, som testar verksamhetslogik, JavaScript-kontroller och utdata för specifika komponenter. Om du väljer en metod med låg kod kommer du inte att kunna skapa egna tester. Salesforce testar dock alla erbjudanden från början till slut noggrant.

Om din komponents metoder är komplexa kan du SMS:a dem individuellt genom att placera metoderna i dedikerade JavaScript-filer. Detta låter dig importera dem till en LWC och sedan till ett Jest-test (till exempel importera { sort } från 'c/utils';).

Du kan använda en ingen-kod-lösning från en ISV, bygga en egen testautomatiseringslösning eller använda ett testramverk med öppen källkod (till exempel Selenium WebDriver eller WebdriverIO) för end-to-end-automatisering. Dessa lösningar är giltiga för alla Salesforces användargränssnittinteraktioner (till exempel ett dynamiskt formulär på en Lightning, ett skärmflöde i ett verktygsfält eller en LWC i ett snabbåtgärdsflöde).

När du har distribuerat ditt formulär till en produktionsmiljö måste du säkerställa att det används effektivt. Beroende på ditt användningsfall kan detta innebära att följa antalet gånger ditt formulär har fyllts i till den tid den genomsnittliga användaren lägger på att fylla i formuläret innan de skickar in sin information. Det är viktigt att identifiera dina spårbara nyckeltal innan du väljer ett verktyg.

• Behöver du följa formuläranvändning?

• Vilka nyckeltal kan avgöra om formuläret används effektivt?

Om du behöver följa den övergripande användningen och användningen av formulär, använd verktyg med låg kod. Dynamiska formulär och skärmflöden kan spåras via färdiga egna rapporter. Skärmflödesspårningsrapporter ger dock ytterligare detaljnivå. Om du behöver följa LWC-användning beror den färdiga tillgängligheten på var du använder LWC. Om det är på en Lightning gäller alla tillgängliga spårningselement för Lightning även för din LWC. Detta gäller även för LWC som är inbäddade i flöden.

Dynamiska formulär går inte att spåra färdiga. Du kan dock följa användningen av den överordnade Lightning-sidan via Lightning användningsobjekt. För att följa standardsidor i Lightning, använd den egna rapporten Användare med Lightning Usage efter sidmått. För egna Lightning-sidor, använd den egna rapporten Användare med Lightning Usage efter FlexiPage-mått.

Flöden kan hjälpa dig följa användning av specifika formulär. Använd exempelflödesrapporten: Skärmflöden för att besvara dessa typer av frågor:

• Vad är ifyllningsresultatet för detta formulär? Är det för närvarande välantaget?

• Hur lång tid tar det för användare att fylla i detta formulär?

• Vilken skärm lägger användare mest tid på att slutföra?

• Hur ofta går användare till tidigare fönster?

• Hur ofta inträffar fel?

Om standardrapporten inte uppfyller dina behov kan du klona den och göra ändringar eller Build Your Own Report från grunden med hjälp av rapporten Skärmflöden.

Om du använder den paketbaserade Omniscript-runtime kan du även använda Omnistudio för Vlocity Tracking Service. Denna tjänst följer alla typer av händelser (till exempel kan du följa tiden det tar att slutföra stegen i ett Omniscript, vilket hjälper till att identifiera processförbättringar).

Obs! Det finns inget färdigt alternativ för att följa en LWC som inte är inbäddad i ett skärmflöde, Omniscript eller Lightning, men du kan bygga en egen lösning med Apex.

Du kanske känner till att använda ändringsanvisningar eller DevOps Center för att distribuera din lösning till testmiljöer eller till produktion. Dessa distributionsalternativ har fullständigt stöd för dynamiska formulär, flöden och LWC. Omnistudio kräver dock ett separat verktyg, IDX Workbench.

• Hur planerar du att distribuera formuläret?

• Måste formuläret distribueras till mer än en Salesforce-organisation?

Om du är en ISV eller en partner som planerar att paketera din lösning för distribution på AppExchange, se Dynamiska formulär, flöden och LWC. Kom ihåg att Omnistudio inte har stöd för paketering.

Denna guide är tänkt att visa dig vilka funktionalitets- och anpassningsnivåer som är tillgängliga via dynamiska formulär, skärmflöden, Omnistudio och LWC. Här är en översikt på hög nivå.

• När det gäller att bygga formulär är LWC det mest robusta, anpassningsbara alternativet, men det har det lägsta skyddsräcket på plats. Därför är det viktigt att bygga dina komponenter med tanke på säkerhet och skalbarhet.

• Dynamiska formulär är det minst flexibla alternativet, men det har mycket färre möjligheter till felsteg.

• Flöde och Omnistudio hamnar något i mitten. De är mer kraftfulla än dynamiska formulär, men de når inte upp till LWC-nivån. De har dock färre skyddsräcken än dynamiska formulär och de är svårare att bryta än egen kod.

Du kan upptäcka att flera verktyg passar dina behov. I sådana fall beror beslutet i slutändan på vilket verktyg som är bäst för ditt team. Mer information om ytterligare aspekter att tänka på finns i dessa riktlinjer för arkitektbeslut.

• När du jämför verktyg är det viktigt att bedöma hur mycket expertis ditt team har om varje verktyg?
• Hur många av dina utvecklare är väl insatta i LWC eller JavaScript?
• Finns det några utvecklare i ditt team som är experter på Flow Builder eller som har uttryckt intresse för att lära sig mer?

Även om vi inte kommer att gå in på specifika detaljer, här är lite mer information om hur dessa specifika verktyg relaterar till de bedömningar vi har täckt hittills.

Leveransdelegering

Kom ihåg att även om vissa av dina krav kräver LWC kräver det inte att hela lösningen byggs med LWC. Det är viktigt att avgöra hur du kan bygga din lösning modulärt. För att göra detta måste du identifiera vilka delar som kräver kodad LWC och vilka delar som inte behöver det. De delar som inte kräver LWC ska byggas med en lågkodslösning.

När det gäller Flöde och LWC finns det olika komponenter (till exempel Reaktiva skärmkomponenter och Skärmflöde) som kan synkroniseras med varandra på samma skärm för att låsa upp nya verktyg för arkitekter, administratörer och utvecklare. Utvecklare kan nu skapa ändamålsenliga, modulära komponenter som kan återanvändas i hela organisationen, vilket hjälper till att öka teamets produktivitet. Detta låter utvecklare spara tid genom att använda en blandning av standard och egna flödeskomponenter för att uppnå formulärdynamik, vilket ger dem mer tid att fokusera på att lösa nya utmaningar. Med introduktionen av 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 formulär.

Långsiktigt ägande och underhållbarhet

Om du skapar ett formulär i flera steg, börja med Flöde eller en blandning av Flöde och LWC. Om teamet som underhåller formuläret är ett team med låg kod, se till att lösningen är så konfigurerbar och utökningsbar som möjligt för din avsedda målgrupp. För att förbättra stabilitet och underhåll är det viktigt att organisera din lösning i komponerbara enheter, oavsett vilket verktyg du väljer.

Prestandaöverväganden som relaterar till dynamiska formulär, skärmflöden, Omnistudio eller LWC baseras på det ramverk där teknikerna finns. Teknologier som baseras på LWC tenderar att överträffa de som baseras på Aura. På grund av flera kärnfunktioner som implementeras inbyggt i webbmotorer (istället för JavaScript via ramverksabstraktioner), ger LWC utökade prestandafördelar.

Så hur utnyttjar vi dessa prestandafördelar för våra formulärtekniker i Salesforce? Låt oss ta en närmare titt.

• Dynamiska formulär (integrerade i Lightning page-metadata) bygger på en LWC-stackgrund, vilket gör att vi kan implementera flera efterlängtade funktioner. Som en extra prestandabonus använder dynamiska formulär progressiv återgivning, vilket förbättrar inläsningstiden för sidor som har ett stort antal fält.

• Skärmflöden byggs på LWC. De flesta av de individuella färdiga komponenterna har nu konverterats till LWC med undantag för komponenterna Filuppladdning och Bild. Även om flödesteamet har konverterat flödeskörningsklienten till LWC (och de flesta av dess komponenter), måste kunder fortfarande konvertera sina Aura-skärmkomponenter till LWC. Kom ihåg att Salesforce endast har stöd för LWC-komponenter inom ramverket för reaktiva komponenter i skärmflöden. Mer information finns i modulen Lightning Web Components for Aura Developer Trailhead. Om du överväger att bygga en egen komponent för ett skärmflöde (eller någon annan behållare), välj LWC!

• Det finns flera versioner av Omnistudio som är tillgängliga. Om du är en gammal kund kanske du använder Angular. Vi uppmuntrar alla nya kunder att använda LWC-baserade Omniscripts och FlexCards. Vi uppmuntrar även befintliga kunder att migrera från Angular.

• LWC bygger på LWC.