Wilt u formulieren samenstellen op het Salesforce Platform? U hebt meerdere opties, die het gehele continuüm van low-code tot pro-code bestrijken. Dynamische formulieren in Lightning Appsamensteller en schermstromen in Flow Builder vertegenwoordigen weinig code. In het midden van het continuüm hangt de mogelijkheid om schermstromen uit te breiden met LWC's en klantgerichte formulieren samen te stellen met OmniStudio. En pro-code wordt vertegenwoordigd door het LWC-framework en de steeds groeiende bibliotheek van basiscomponenten.

Opties zijn geweldig, maar hoe bepaal je welke (of welke combinatie) de juiste optie is? Dat is waar deze handleiding om de hoek komt kijken.

• Afhaalmaaltijd #1: Gebruik bij het samenstellen van lay-outs voor maken/bewerken/weergeven voor Lightning pagina's Dynamische formulieren. Mogelijk ziet u dat er paginalay-outs ontbreken in de vergelijkingstabellen in deze handleiding. In de toekomst is het gebruik van Dynamische formulieren in Lightning Appsamensteller de aanbevolen manier om recorddetailpagina's te configureren. Zie het gedeelte over paginalay-outs voor meer informatie over waarom we verwachten deze niet verder te verbeteren.
• Afhaalmaaltijd #2: Als u een maak- of bewerkingsformulier voor precies één object moet samenstellen, begint u met Lightning pagina's en Dynamische formulieren. Dit is de eenvoudigste manier om formulieren samen te stellen op het Salesforce-platform. Het biedt ook enkele extra functionaliteit, zoals de mogelijkheid om de zichtbaarheid van het veld te bepalen. Als uw vereisten geavanceerder zijn, lees dan verder. Screen Flow, OmniStudio of Lightning Web Components (LWC) zijn wellicht geschikter.
• Afhaalmaaltijd #3: Als u een formulier van meerdere pagina's of een wizard samenstelt en geen strikte UX- of brandingvereisten hebt, begint u met een schermstroom. Schermstromen bieden een raamwerk voor lineaire navigatie voor het orkestreren van meerdere formulieren samen. U kunt LWC gebruiken om uw eigen raamwerk te maken voor het navigeren tussen formulieren, maar we raden u aan om Flow het zware werk voor u te laten doen, zodat u zich kunt richten op de formulieren zelf in plaats van u zorgen te maken over de vormstatus.
• Afhaalmaaltijd #4: Als u extra logica of acties achter het formulier nodig hebt, gebruikt u een schermstroom, OmniStudio of LWC. Alle drie de tools bieden manieren voor uw oplossing om meer te doen dan één record maken of bewerken. Dat "meer" kan meer geavanceerde logica zijn, zoals vertakking of herhaling, of het kan meer acties zijn, zoals integreren met externe systemen, e-mailberichten verzenden of kennisgevingen pushen naar de mobiele app van een gebruiker.
• Afhaalmaaltijd #5: Hebt u geavanceerde UX-vereisten? Wilt u dynamisch meer dan zichtbaarheid afhandelen? Gebruik LWC of Omniscript. Als aan uw vereisten kan worden voldaan met eenvoudige thema's en op kolommen gebaseerde lay-outs, kunt u uw formulieren rechtstreeks in een samensteller met weinig code samenstellen. Voor meer verfijnde controle over de stijl van uw formulier hebt u de ultieme flexibiliteit van LWC nodig. Als u een Industries-klant bent en pixelperfecte branding nodig hebt of complexe hiërarchische gegevens hebt, gebruikt u OmniStudio, waarmee u formulieren voor consumentenkwaliteit kunt samenstellen die complexe bedrijfslogica en gegevenstransformaties kunnen afhandelen.
• Afhaalmaaltijd #6: Als u testautomatisering nodig hebt, begint u met Lightning Web Components. U kunt eenheidstests schrijven voor elke LWC, ongeacht waar u deze wilt inbedden. Dit biedt u de mogelijkheid om een robuustere teststrategie te maken, die bulktests met meerdere records en negatieve tests kan omvatten. Zie Salesforce Well-Architected - Testing Strategy voor meer informatie over het maken van tests die u helpen te zien hoe goed uw formulieren aansluiten op uw functionele en niet-functionele vereisten.

Houd er rekening mee dat uw keuze niet een of-of hoeft te zijn - u kunt de kracht van meerdere opties combineren. Als u bijvoorbeeld zowel het ingebouwde navigatiesysteem van Flow als de volledige stileringsflexibiliteit van LWC nodig hebt, gebruikt u ze samen.

De onderstaande tabel geeft een overzicht van de tools die beschikbaar zijn voor het samenstellen van formulieren met Salesforce, samen met hun vereiste vaardigheden en licentieoverwegingen. Later gaan we dieper in op de specifieke voorzieningen die voor elke tool worden ondersteund, en hoe u kunt kiezen tussen op klikken gebaseerde tools en op code gebaseerde tools (en wanneer u deze combineert):

De onderstaande tabel bevat een overzicht van de beslissingspunten waar u aan moet denken bij het maken van uw productselecties, samen met vragen die u zich bij elke beslissing moet stellen. In de rest van deze handleiding gaan we dieper in op elk van deze onderwerpen.

Dit zijn de termen die we gebruiken in de vergelijkingstabellen, samen met hun definities:

• Beschikbaar: Werkt prima met basisoverwegingen.
• Niet ideaal: Kan wel werken maar is niet het optimale gereedschap.
• Roadmap: Geschatte ondersteuning binnen de komende twaalf maanden (juni 2025).
• Toekomst: Geschatte ondersteuning na de komende twaalf maanden.
• Niet beschikbaar: Geen plannen om deze mogelijkheid binnen de komende twaalf maanden te ondersteunen.

Zoals beloofd, laten we eens diep ingaan op een verscheidenheid aan vergelijkingspunten en functionele verschillen tussen Dynamische formulieren, Schermstromen, OmniStudio, Schermstromen met ingebedde LWC's en het LWC-framework zelf.

Als uw formulier werkt met één Salesforce-object, werken alle tools die we vergelijken. Dingen worden een beetje ingewikkelder met kruisobject- of objectonafhankelijke formulieren. Met objectonafhankelijk bedoelen we invoer die niet is toegewezen aan een Salesforce-object. Misschien vertegenwoordigt uw formulier een gegevensstructuur die u naar een externe service stuurt, zoals Stripe of DocuSign. Of misschien gebruikt u verschillende invoer in uw formulier om een waarde te berekenen en legt u die waarde vervolgens vast in de database.

• Op basis van welke objecten werkt het formulier?
• Is het slechts één object of zijn er meerdere objecten?
• Werkt u met specifieke objecten (zoals Account, Contactpersoon, Opportunity, Lead en Case) of moet uw formulier ook met andere objecten werken?

Voor zowel kruisobject- als objectonafhankelijke formulieren zijn Flow en OmniStudio beide solide opties. De componenten die beschikbaar zijn in stroomschermen, zijn van nature agnostisch, waardoor u achter de schermen zelf kunt kiezen wat u met die gegevens wilt doen. Gebruik de gegevens die u op één formulier hebt ingevoerd bijvoorbeeld om achter de schermen meerdere records te maken of gebruik de gegevens voor het uitvoeren van andere acties zoals Chatter posts genereren, Slack-berichten verzenden, e-mailberichten verzenden of verbinden met externe services.

Voor eenvoudige cases kan het gebruik van bestaande LWC-componenten, zoals Lightning Record-Form, een eenvoudige manier zijn om code te verlagen die nodig is om een robuuste oplossing te bieden. Voor scenario's waarin meerdere objecten betrokken zijn, biedt Stroom echter uitgebreide controle voor alle objecten en hoeven ontwikkelaars geen complexe relaties en afhankelijkheden meer te doorlopen.

OmniStudio gaat nog een stap verder en is volledig objectonafhankelijk. Het scheidt de vorm die een gebruiker ziet van het onderliggende gegevensmodel. In plaats daarvan manipuleert OmniStudio onderliggende JSON die vervolgens wordt toegewezen aan Salesforce-objecten (of externe gegevens) met behulp van tools zoals Data Mapper en Integration Procedures. Gegevenstoewijzing en Integratieprocedures zijn twee belangrijke componenten bij het verbinden van uw OmniStudio-formulieren met gegevens intern en extern naar Salesforce. Met behulp van elementen met slepen en neerzetten kunt u werken met complexe hiërarchische gegevens in een extern systeem en de gegevens vervolgens transformeren naar uw behoeften, afhankelijk van waar de gegevens naartoe moeten. Ze laten u ook formules gebruiken om wiskundige en logische berekeningen uit te voeren op arrays of lijsten van gegevens, zoals Apex.

OmniStudio-integraties

Als u al uw gebruikersinvoer kunt ophalen uit een formulier met één scherm, begint u met Dynamische formulieren. Hoewel Dynamische formulieren op recordpagina's de voorziening Traject kunnen gebruiken om de verschillende fasen in uw bedrijfsproces losjes weer te geven, past deze mogelijk niet bij de meerderheid van uw gebruikscases.

• Hebt u één scherm nodig of moet de gebruiker tussen meerdere schermen navigeren om een taak te voltooien?
• Wilt u dat uw gebruikers een visuele weergave zien van hoe ver ze zijn met het invullen van uw formulier?
• Moeten uw gebruikers de informatie op elk scherm in een specifieke volgorde invullen of moeten ze naar behoefte heen en weer kunnen schakelen tussen schermen?

Als u meer functionaliteit nodig hebt dan Dynamische formulieren biedt, hangt de keuze tussen Stroom, OmniStudio en LWC ook af van enkele andere vragen:

• Welke vaardigheden heeft uw team? Voor een organisatie met meer beheerders wordt aangeraden om te beginnen met Flow. Als u Industries-oplossingen hebt, uw team al vertrouwd is met OmniStudio en uw project strenge UX-vereisten heeft, begint u met OmniStudio.
• Is het oké om een navigatiebalk onder aan het formulier weer te geven? Als de schermstroom en Omniscript-navigatie-ervaring ongewenste UX zijn, neigt u naar LWC.
• Wat moet er achter het formulier gebeuren? Als u de werking wilt configureren door een beheerder, stelt u een stroom samen of, voor basiswijzigingen zoals het wijzigen van veldlabels, een Omniscript. Anders stelt u voor complexe relaties met meerdere objecten een Omniscript of LWC samen.
• Als u kiest voor Flow of OmniStudio, moet u mogelijk toch een LWC samenstellen om de juiste UX te verkrijgen. Als u al een LWC maakt om uw formulier correct van stijl te voorzien, overweeg dan of het inbedden van die component in een stroom overdreven is.

Als uw oplossing er daarentegen uitziet als een wizard, waarbij de gebruiker tussen meerdere schermen navigeert, kunt u Flow of OmniStudio overwegen. Stromen en OmniStudio zijn voorzien van een ingebouwd navigatiemodel, waardoor u geen LWC's hoeft samen te stellen en te onderhouden die aan elkaar zijn gekoppeld. De navigatie is lineair, met acties voor vooruitgaan, acties voor teruggaan en een mechanisme voor het opslaan van het formulier voor later. U kunt ook een formulier samenstellen met niet-lineaire navigatie als dit past bij uw doeleinden. Bekijk het pakket Digital Store Audit van Salesforce Labs voor een goed voorbeeld daarvan met behulp van schermstromen.

OmniStudio biedt een belangrijk navigatievoordeel door voortgangsindicatoren te bieden van standaardnavigatie die 'stappen' in het formulier zichtbaar maakt. Deze stapweergave geeft automatisch weer waar een gebruiker zich bevindt op een bepaald formulier met meerdere stappen. In tegenstelling tot Stroom kunnen gebruikers tussen schermen 'springen' door op verschillende stappen van het formulier te klikken.

Ongeacht of u formulieren met één scherm of met meerdere schermen maakt, zorg ervoor dat uw formulieren gestroomlijnd zijn zodat ze gemakkelijk te navigeren zijn voor uw gebruikers.

Als u een formulier inbedt op een standaard Lightning recordpagina, werken alle tools die we vergelijken, met het voorbehoud dat Dynamische formulieren momenteel alleen beschikbaar is op de desktop. Als u echter een omgeving wilt bieden waarin gebruikers formulieren kunnen openen vanaf andere locaties, moet u mogelijk alternatieve opties overwegen.

• Hebben gebruikers toegang tot het formulier nodig via desktop, mobiel of beide?
• Moeten gebruikers het formulier overal in uw app kunnen openen via een balk voor hulpprogramma's?
• Wilt u snelle acties gebruiken zodat gebruikers uw formulier kunnen invullen zonder de pagina te hoeven verlaten waarop ze zich op dat moment bevinden?
• Moet uw formulier beschikbaar zijn op een externe website?

Aangezien ze recordcontext vereisen, worden Dynamische formulieren alleen ondersteund op Lightning recordpagina's. Dynamische formulieren wordt echter niet ondersteund op Experience Cloud-pagina's. Deze beperking geldt omdat Experience Cloud niet het onderliggende framework gebruikt waarvan Dynamische formulieren afhankelijk is: Lightning pagina's. We evalueren dit op basis van verzoeken voor Dynamische formulieren in Experience Cloud.

U kunt stromen samenstellen die een recordcontext vereisen of stromen die globaal werken. Op deze manier kunt u stromen op verschillende locaties inbedden. Voor recordcontextuele stromen kan dat een Lightning recordpagina, een Experience Cloud-recordpagina, een objectspecifieke actie of een implementatie van Acties & Aanbevelingen zijn. Voor de globale stroom kan dat de balk voor hulpprogramma's, andere Lightning of Omgevingssamensteller-pagina's, een Snap of een externe toepassing zijn. Stromen worden momenteel niet ondersteund als globale acties, maar als alternatief kunt u de stroom opnemen in een Aura-component.

Met OmniStudio kunt u samenstelbare FlexCards en Omniscripts samenstellen die u bijna overal kunt plaatsen waar u een stroom kunt plaatsen. Hoewel ze samenstelbaar zijn, kunnen ze niet in een pakket worden opgenomen.

LWC ondersteunt een hoge mate van herbruikbaarheid, omdat u componenten maakt die aan doelen kunnen worden gekoppeld via metagegevens in Salesforce, Community's en zelfs in open-sourceprojecten. LWC-componenten kunnen ook worden ingebed in uw eigen website via Lightning Out.

Lightning Out op externe sites

Lightning webcomponenten worden momenteel niet ondersteund als snelle acties (objectspecifiek of globaal), maar als alternatief kunt u een LWC in een Aura-component opnemen (net zoals u dat met stromen kunt doen). LWC componenten kunnen ook stromen starten met de lightning-flow component.

OmniStudio blinkt uit in het zichtbaar maken van inhoud op uw externe sites via de OmniOut-voorziening. Met OmniStudio en OmniOut kunt u uw Omniscript-formulieren en FlexCard-componenten compileren in standaardcomponenten en deze off-platform uitvoeren in sites of apps van derden.

Geen van de formuliertechnologieën die in deze handleiding worden behandeld, wordt vandaag officieel ondersteund in Mobile SDK-sjablonen. Als de Mobile SDK essentieel is voor uw gebruikscase, kunt u uw formulier beter zelf samenstellen in uw mobiele toepassing of een Visualforce pagina samenstellen, waarbij u rekening houdt met de richtlijnen voor Salesforce Well-Architected form factor.

Stappenplannotitie: Het Mobile SDK-team werkt actief aan de ondersteuning van LWC's binnen Visualforce pagina's.

Dynamische formulieren is perfect als u de waarden in uw formulier moet gebruiken om een record te maken of bij te werken. Voor andere mogelijkheden moet u gebruikmaken van Flow, OmniStudio of LWC. Deze mogelijkheden omvatten mogelijk een beslissingslaag of herhaling, of het genereren van Slack-posts of -e-mailberichten met behulp van de invoer van het formulier.

• Welke acties of logica wilt u achter de schermen laten uitvoeren?
• Bevat uw gegevensmodel hiërarchische gegevens?
• Moet uw formulier bewerkingen voltooien binnen één transactie of binnen meerdere transacties?
• Moet u integreren met externe systemen?
• Wat zijn uw vereisten voor herbruikbaarheid en modulariteit?

Stroom biedt standaardacties voor posten naar Slack, verzenden van e-mail en interactie met Quip documenten, zodat u geen code hoeft te schrijven voor deze bewerkingen. LWC biedt rijke interacties met afzonderlijke records en gerelateerde objecten door het gebruik van draadadapters die een interactie hebben met de gebruikersinterface-API. LWC kan ook met meerdere records werken wanneer de wire voor getListInfoByName wordt gebruikt.

Lightning Web Components Interactie via draadadapters

Zoals hierboven vermeld, gebruikt OmniStudio Integratieprocedures en Gegevenstoewijzing om gemakkelijk gegevens extern en intern in Salesforce op te halen en te transformeren. Het schittert in het afvlakken en uitbreiden van gegevenssets met verschillende niveaus van relaties dankzij talrijke codevrije functies die u kunt gebruiken.

Stappenplannotitie: Stroom ondersteunt binnenkort de mogelijkheid om verzamelingen records in te voegen en hiërarchische gegevens te beheren.

Flow, OmniStudio en LWC zijn allemaal geïntegreerd met Apex, zodat u gemakkelijk eventuele hiaten kunt dichten in de oplossing die u kiest. Als u bijvoorbeeld records wilt filteren vanuit een LWC, kunt u altijd de wire-adapter voor Apex gebruiken om complexe SOQL-query's te maken. Als u onder de indruk bent van de op klikken gebaseerde story, overweeg dan Flow of OmniStudio als haalbare alternatieven voor een Apex controller voor uw server-side behoeften.

Een secundaire vraag is of u acties onmiddellijk wilt uitvoeren of wilt uitstellen naar een bepaald deel van uw formulier. Dit is met name relevant als u een formulier van meerdere pagina's gebruikt. Stroom maakt het gemakkelijk om invoer uit meerdere formulieren (stroomschermen) te combineren en deze veel later in de wizard (stroom) te gebruiken om bepaalde bewerkingen uit te voeren. We raden zelfs aan om stromen op die manier te ontwerpen (voer acties aan het einde uit) voor het geval de gebruiker heen en weer gaat tussen schermen en zijn of haar antwoorden wijzigt.

Transacties en gouverneurslimieten zijn een manier van leven op het Salesforce Platform. Als uw gebruikscase vrij eenvoudig is, is het wellicht niet zo belangrijk om te bepalen in welke transactie een bepaalde bewerking plaatsvindt. Er zijn echter enkele gebruikscases waarin u mogelijk meerdere bewerkingen wilt combineren tot één transactie in plaats van ze uit te voeren voor meerdere transacties. Enkele voorbeelden:

• Terugdraaien of niet terugdraaien: Dat is de vraag. Stel dat uw formulier achter de schermen meerdere records maakt. Als het maken van de derde record mislukt, moeten de eerste twee records dan worden teruggedraaid? Als al uw acties onafhankelijk van elkaar zijn, kunt u ze gerust uitvoeren in afzonderlijke transacties. Als ze echter afhankelijk zijn en u wilt dat de ene fout ook de andere terugdraait, implementeert u ze in één transactie. Als uw formulier voorkomt in Stroom, kunt u het element Terugdraaien in een fouttraject gebruiken om uw transactie terug te draaien en de gegevensintegriteit te waarborgen.
• Invloed stroomafwaarts op limieten van gouverneurs: Vooral wanneer uw formulier een record maakt of bijwerkt, moet u nagaan wat de gevolgen zijn van die bewerking verderop in de stroom. Welke processen, werkstroomregels, stroomtriggers, Apex triggers of andere items in de opslagorder worden geactiveerd op basis van deze recordwijziging? En hoe beïnvloeden die collectieve wijzigingen de beheerlimieten die in die transactie worden verbruikt? Als een bepaalde recordwijziging resulteert in veel wijzigingen verderop in de stroom, die van invloed zijn op uw limieten, kunt u overwegen om die recordwijziging te isoleren in een eigen transactie.
• Batchverwerking: Zelfs in een UI-context moet u mogelijk meerdere updates tegelijk batchgewijs uitvoeren. Stel dat uw formulier met meerdere schermen zich herhaalt over een grote groep records. In plaats van na elk scherm een recordupdate uit te voeren, wacht u tot u de updates voor alle records hebt verzameld en dient u vervolgens één verzoek in om alle records bij te werken.

Wanneer u Dynamische formulieren gebruikt om een record te maken of bewerken, voert u slechts één bewerking uit en die bewerking is altijd het begin van een nieuwe transactie.

Bij het samenstellen van een schermstroom hebt u een aanzienlijke controle over wat er in een bepaalde transactie gebeurt. Schermen en Lokale acties fungeren als grenzen tussen transacties. Hier volgt een samenvatting op hoog niveau van de manier waarop transacties worden beheerd in de schermstroomarchitectuur.

1. De eindgebruiker heeft een interactie met een scherm en klikt vervolgens op Volgende.
2. De client post een verzoek naar de API met de invoer.
3. De API ontvangt het verzoek en er wordt een transactie- en databaseverbinding geopend. De API roept vervolgens de stroomengine aan om het verzoek aan te roepen.
4. De stroomengine neemt het over en volgt het juiste pad in de stroomdefinitie — totdat deze een knooppunt Scherm of Lokale actie bereikt. De engine retourneert vervolgens informatie over dat knooppunt naar de API.
5. De API maakt een responsobject dat de details bevat van het volgende scherm dat moet worden weergegeven, en retourneert dat object naar de client. Op dit punt worden databasewijzigingen doorgevoerd (cue de uitvoering van de order) en worden de databaseverbinding en transactie gesloten.
6. De client gebruikt de API-respons om het volgende scherm weer te geven waarmee de gebruiker kan werken.
7. Herhaal vanaf stap 1.

Met andere woorden, schermen "breken" transacties. Wanneer dat gebeurt, worden alle in behandeling zijnde acties of DML vastgelegd, wordt de voorafgaande transactie gesloten en begint een nieuwe transactie.

Het juiste ontwerp — welke bewerkingen u groepeert in een bepaalde transactie — is uw beslissing. Laten we enkele voorbeelden bekijken.

Links ziet u een stroom die invoer over meerdere schermen verzamelt en vervolgens verschillende acties in één transactie uitvoert.

De stroom rechts voert elke bewerking in een afzonderlijke transactie uit.

Stel dat u een stroom hebt die records maakt, records bijwerkt en vervolgens meer records maakt, zoals wordt geïllustreerd in de volgende stroom rechts.

Als in dit scenario de eerste twee elementen slagen en de laatste mislukt, zullen de eerste twee DML-bewerkingen nog steeds die records maken en bijwerken, terwijl de derde dat niet doet.

Door middel van het element Records terugdraaien kunt u ervoor zorgen dat de gehele transactie wordt teruggedraaid als alle drie bewerkingen samen moeten plaatsvinden — zoals te zien is in de laatste stroom links.

Zie Stromen in transacties en Bulkverwerking van stromen in transacties voor meer informatie. De sectie Geautomatiseerd van Salesforce Well-Architected gaat hier ook dieper op in bij Gegevensverwerking.

Uw vermogen om de transactie te controleren vanuit een LWC komt neer op de onderliggende services die LWC gebruikt voor het uitvoeren van haar bewerkingen. Als u de basiscomponent Lightning gebruikt, vindt de onderliggende bewerking (het maken of bijwerken van de record) plaats in een zelfstandige transactie zodra het formulier wordt ingediend.

In het algemeen gelden de volgende regels:

• Elke UI-API-aanroep wordt geïsoleerd in een eigen transactie.
• Als u meerdere bewerkingen binnen één transactie moet uitvoeren, stuurt u de invoer naar een server-side technologie, zoals een Apex controller of een stroom. De reguliere transactieregels voor die technologie zijn van toepassing.

Flow, OmniStudio en LWC ondersteunen alle platformevents (voor eventgestuurde architectuur) en API-integraties. Naast aangepaste Apex code ondersteunen zowel Flow als OmniStudio declaratieve mechanismen om een API te integreren.

Als u verbinding moet maken met een Mulesoft-API of RPA-bot, gebruikt u Mulesoft Services. Dit genereert een Externe service.

Externe integraties via MulesoftExterne integraties via Mulesoft API's en RPA Bots __

Als de API een OpenAPI-schema heeft, maakt u een Externe service.

integraties met API's met OpenAPI-schema's

Gebruik anders de voorziening HTTP-aanroep in Stroom of HTTP-actie in OmniStudio. De HTTP-aanroep van Flow wordt aangestuurd door Externe services.

integraties via HTTP

OmniStudio biedt een rijke set integratiemogelijkheden die externe systemen kunnen aanroepen met Integratieprocedures en de gegevens kunnen transformeren met Data Mapper. (Zie Objectimpact voor meer informatie)

Ongeacht of u deze implementeert met aangepaste Apex of een externe service, een aanroep is een aanroep. Dit is wat u moet weten.

1. Een aanroep kan lang duren.
2. Wanneer een aanroep synchroon wordt uitgevoerd, wordt deze uitgevoerd terwijl een databasetransactie open is.
3. Salesforce laat u geen databasetransactie openhouden als u databasebewerkingen in behandeling hebt.

De belangrijkste beperking om in gedachten te houden is het gevaar van zogenaamde vuile transacties, waarbij u een bewerking voor maken, bijwerken of verwijderen uitvoert en vervolgens in dezelfde transactie een aanroep uitvoert. Dit patroon is niet toegestaan vanwege overweging #3 hierboven, die natuurlijk wel bestaat vanwege overwegingen #1 en #2.

In Flow kunt u deze beperking omzeilen door de transactie te verbreken. Vergeet niet dat schermen en lokale acties beide de browsercontext opnieuw introduceren, waardoor de transactie wordt verbroken. Hoewel u schermen en lokale acties kunt gebruiken bij het werken met externe aanroepen, wordt aangeraden Transactiebeheer in te schakelen in aanroepbare geavanceerde instellingen. Transactiebeheer is een voorziening van aanroepbare acties waarmee u de transactie automatisch kunt beëindigen voordat een aanroep wordt gedaan. U kunt Transactiebeheer inschakelen door Altijd een nieuwe transactie starten te selecteren in de sectie Geavanceerd van een aangeroepen actie.

Zie de Architectenhandleiding voor gegevensintegratie met Salesforce voor meer gedetailleerde richtlijnen over Apex-aanroepen, externe services en gegevensintegratiemogelijkheden in het algemeen.

Dynamische formulieren biedt geen ondersteuning voor hergebruik. Elk dynamisch formulier is gekoppeld aan een specifieke Lightning recordpagina voor een specifiek object (hoewel u die Lightning recordpagina kunt toewijzen aan meerdere apps, profielen, enzovoort).

Zoals u bibliotheken, hulpprogramma's en componenten kunt schrijven die bedoeld zijn voor gebruik binnen meerdere andere componenten, kunt u soortgelijke ontwerppatronen toepassen bij het maken van stromen met de kracht van substromen. Sla uw stromen op in kleinere, meer modulaire buckets en roep ze vervolgens aan vanuit andere stromen met behulp van het element Substroom. Als uw ontwerp hierom vraagt, kunt u een stroom samenstellen die zowel op zichzelf staat als nuttig is als substroom van een andere stroom.

OmniStudio is inherent gebouwd voor modulariteit. Gegevenstoewijzingen, Omniscripts, FlexCards en Integratieprocedures zijn alle onafhankelijk samengesteld en kunnen onderling uitwisselbaar werken. Bovendien kunnen FlexCards worden samengesteld als LWC-componenten die kunnen worden ingebed in andere LWC's, Omniscripts, recordpagina's en Experience Cloud-sites.

Schermstromen, Omniscripts en LWC's kunnen allemaal worden samengesteld voor hergebruik en worden ingebed op verschillende locaties, waaronder externe sites en Lightning Out-toepassingen. Wanneer u uw oplossingen zo ontwerpt dat ze samenstelbaar zijn, krijgt u extra voordelen zoals aanpassingsvermogen en stabiliteit.

Alle technologieën die worden gebruikt om een record te maken of bij te werken, voldoen aan validatie op systeemniveau – of dat nu klassieke validatieregels zijn of aangepaste validatie die is ingebouwd in een Apex trigger. Ongeacht de technologie die u gebruikt om een recordwijziging uit te voeren, elke wijziging verloopt via de opslagorder. Dit betekent dat naast validatieregels de recordwijziging wordt verwerkt door een willekeurig aantal stromen vóór of na opslaan, vóór of na triggers, escalatieregels, toewijzingsregels en meer. Als u dit nog niet hebt gedaan, zorg er dan voor dat u een bladwijzer maakt en uzelf vertrouwd maakt met de Apex volgorde van uitvoering.

• Heeft uw formulier aanvullende vereisten naast validatie op systeemniveau?
• Moet u velden dynamisch verplicht of alleen-lezen instellen binnen het formulier?

Invoer in een stroomscherm of Omniscript-stap is van nature ongebonden, waardoor het formulier zelf niet voldoet aan validatie op systeemniveau die is gekoppeld aan een bepaald object. De waarden die u gebruikt om records te maken of bij te werken, worden echter verwerkt door de opslagorder, wat betekent dat ze door de validatie op systeemniveau van het object gaan. Houd er echter rekening mee dat niet alle schermstroomcomponenten invoervalidatie ondersteunen. Met ingang van Summer '24 zijn de resterende schermcomponenten die invoervalidatie niet ondersteunen Keuzerondjes, Keuzelijst, Keuzelijst met meervoudige selectie, Groep selectievakjes en Keuze opzoeken.

Net als bij paginalay-outs kunt u met Dynamische formulieren de verplichtheid en alleen-lezen status instellen op paginaniveau. U kunt instellingen op systeemniveau echter niet overschrijven.

Stroom biedt flexibiliteit voor het aanpassen van validatie voor de invoer van een formulier. Hoewel bepaalde controles worden uitgevoerd in de client (zoals het signaleren van ontbrekende verplichte velden of incompatibele waarden), blokkeert geen van de validaties aan de clientzijde de gebruiker om te proberen te navigeren. De echte validatie vindt plaats op de server. Wanneer een gebruiker op Volgende klikt, verzendt Stroom de invoer naar de server voor validatie. Als invoer als ongeldig wordt geretourneerd, wordt navigatie geblokkeerd en wordt de juiste fout weergegeven. De server valideert de invoer door te controleren:

1. De instelling voor de verplichtheid van de invoer of de ingevoerde waarde compatibel is met het onderliggende gegevenstype.
2. Aangepaste validatie voor die invoer: Verschillende standaardcomponenten (Selectievakje, Valuta, Datum, Datum/tijd, Lange-tekstgebied, Getal, Wachtwoord en Tekst) ondersteunen aangepaste validatie per scherm. Geef een booleaanse formule-uitdrukking en een foutbericht op dat moet worden weergegeven wanneer niet aan de formule-uitdrukking wordt voldaan.
3. Aangepaste validatie voor de onderliggende component: Als u een aangepaste LWC maakt voor een stroom, voegt u uw eigen validatiecode toe aan de methode validate().

OmniStudio biedt een rijke afhandeling van fouten en validatie via de actie Fout instellen in combinatie met Voorwaardelijke weergaven en de component Berichtenverkeer.

Aan de LWC-zijde voeren de meeste basiscomponenten hun eigen validaties aan clientzijde uit. Zo houdt Lightning Record-Form zich wel aan de vereisten op systeemniveau, maar niet aan de vereisten op paginaniveau. Voor uw aangepaste componenten kunt u Build Your Own validatiemechanismen samenstellen.

Velden waarvoor gebruikers gegevens moeten invoeren, moeten vroeg in uw formulieren worden weergegeven. Valideer indien mogelijk gebruikersinvoer aan de clientzijde voordat formulieren worden ingediend. Zie voor meer best practices voor het stroomlijnen van uw formulieren de richtlijnen voor formulieren in Salesforce Goed ontworpen - Betrokken.

Beveiliging is een complex onderwerp in het algemeen en als het gaat om het samenstellen van formulieren, zijn er een aantal overwegingen waar u misschien niet eens aan hebt gedacht. Op basisniveau wilt u ervoor zorgen dat het formulier in de juiste context wordt uitgevoerd en dat gebruikers de machtigingen hebben die ze nodig hebben om met de onderliggende gegevens ervan te werken. Maar daarnaast wilt u mogelijk ook extra maatregelen nemen om potentieel schadelijke code of URL's uit rich-text-velden te verwijderen, te voorkomen dat bepaalde gebruikers in het geheel toegang hebben tot het formulier of beperkingen op te leggen aan de typen plaatsen waar beheerders het formulier in de toekomst potentieel kunnen inbedden. Zorg ervoor dat u uw beveiligingsvereisten grondig documenteert voordat u een tool kiest. De Salesforce Well-Architected Security Policy Template bevat richtlijnen voor dit type documentatie.

• Moet het formulier de toegang van de gebruiker controleren voordat bepaalde bewerkingen worden uitgevoerd?
• Moet u gebruikersinvoer opschonen?
• Wilt u bepalen wie toegang heeft tot het formulier?
• Wilt u bepalen waar het formulier kan worden ingebed?

Wanneer iets wordt uitgevoerd in gebruikerscontext, dwingt Salesforce een reeks toegangscontroles af, waaronder het verifiëren van beveiliging op veldniveau, CRUD-machtigingen en recordtoegang op basis van de regels voor delen van uw organisatie. Zo zouden gebruikers alleen een case-updateformulier kunnen uitvoeren als ze de mogelijkheid hebben om cases bij te werken, de juiste beveiliging op veldniveau en toegang tot de desbetreffende record hebben. Maar wat als u wilt dat gebruikers een bepaalde bewerking kunnen uitvoeren wanneer ze uw formulier gebruiken, maar niet via een ander formulier of een andere interactie? Dat is waar systeemcontext om de hoek komt kijken.

Systeemcontext is een manier om de machtigingen van de huidige gebruiker te verhogen voor de duur van de sessie, zodat de gebruiker bijvoorbeeld geen toegang Bijwerken tot het object Case nodig heeft om uw case-updateformulier te voltooien. Dit is met name handig voor niet-geauthenticeerde community's. In plaats van gastgebruikers potentieel gevaarlijke vaardigheden te verlenen, stelt u uw formulier in op uitvoering in systeemcontext.

Natuurlijk is systeemcontext een zwaard met twee snijpunten en moet u het alleen gebruiken wanneer dat nodig is. Wanneer een formulier in systeemcontext wordt uitgevoerd, omzeilt elke afzonderlijke CRUD-bewerking beveiliging op object- en veldniveau en delen, niet alleen de specifieke bewerking die u belangrijk vindt. Systeemcontext heeft ook geen invloed op wie Salesforce als actor beschouwt: de naam die u ziet in het veld Laatst gewijzigd door. Voor elke bewerking die uw formulier uitvoert, zoals de case-update, is de actor de huidige gebruiker, zelfs als het formulier in een andere context wordt uitgevoerd.

Dynamische formulieren, Omniscripts en LWC's worden altijd uitgevoerd in gebruikerscontext en er is geen manier om deze werking te overschrijven.

Schermstromen worden standaard uitgevoerd in gebruikerscontext, maar u kunt ze instellen op uitvoering in systeemcontext. Het is uw keuze of de stroom toegang moet verlenen tot alle gegevens of dat deze nog steeds toegang op recordniveau moet afdwingen, zoals delen.

• Als u een Lightning component inbedt in een stroom die wordt uitgevoerd in systeemcontext, overschrijft de stroom niet de context van de component. Als u gebruikerstoegangscontroles moet omzeilen, wordt aangeraden om de stroom te gebruiken om die bewerkingen uit te voeren en de juiste gegevens door te geven aan of uit de Lightning component. Sommige kant-en-klare componenten (zoals Opzoeken) kunnen niet werken in systeemcontext.
• Als uw stroom Apex acties aanroept, zijn er nog enkele nuances die u moet begrijpen. Als de Apex klasse is ingesteld op overgenomen delen, wordt deze uitgevoerd in systeemcontext met delen, ongeacht waarop de stroom is ingesteld. Als de klasse geen expliciete declaratie voor delen heeft, wordt deze uitgevoerd in systeemcontext zonder delen, ongeacht waarop de stroom is ingesteld. Als de klasse is ingesteld op delen of zonder delen, wordt dit gedaan en wordt de context van de stroom overschreven.

Query's uitvoeren op records in systeemcontext met Experience Cloud-sites:

Als u een stroom uitvoert in systeemcontext op een Experience Cloud-site, met name niet-geauthenticeerd, wordt aangeraden om alleen specifieke velden op te slaan in uw elementen Records ophalen. Wanneer u met Flow werkt en de resultaten van een element Records ophalen doorgeeft aan een substroom, aanroepbare actie of een Lightning component, kunnen alle velden van dat object worden geïnspecteerd via de ontwikkelaarstools van de browser. Hierdoor worden velden mogelijk beschikbaar voor gebruikers van uw Experience Cloud-site die u mogelijk niet van plan bent. Door specifieke velden op te geven in uw elementen Records ophalen, kunt u ervoor zorgen dat alleen de juiste velden zichtbaar zijn, zelfs als de systeemcontext is ingeschakeld.

Omniscript-logica wordt uitgevoerd aan de clientzijde, waardoor aanvallers de verwachte uitvoering van een Omniscript kunnen wijzigen en responsen op integratieprocedures, gegevenstoewijzingen en Apex methodeaanroepen kunnen weergeven met behulp van de ontwikkelaarstools van de browser. Wanneer u Omniscript gebruikt, raden we aan om bedrijfslogica waar mogelijk uit te voeren aan de serverzijde en invoervalidatieregels te implementeren voor alle Apex methoden die zichtbaar zijn via een @InvocableMethod annotatie.

Invoer desinfecteren:

Als u uw organisatie wilt beschermen tegen kwaadwillenden, kunt u ook overwegen om invoer op te schonen. Stel dat u invoer hebt voor een openbaar toegankelijk formulier dat kan worden toegewezen aan een rich-text-veld in uw organisatie. Wellicht wilt u automatisering overwegen die HTML verwijdert die schadelijke URL's kan verbergen. Over het algemeen is het niet ideaal om deze opschoning op formulierniveau te implementeren, omdat u een willekeurig aantal bronnen naar deze velden kunt laten schrijven. U wordt aangeraden om een stroom Snelle veldupdate te maken (vóór opslaan) of een bestaande Apex Trigger voor het object te gebruiken om alle potentiële HTML te verwijderen of te wijzigen die in het formulier kan worden ingevoerd.

Best practices:

• Laat stromen uitvoeren in hun standaardcontext, tenzij u de toegang van de huidige gebruiker voor een specifieke bewerking moet verhogen.
• Vermijd het uitvoeren van stromen in systeemcontext voor gastgebruikers om veiligheidsredenen. Maak in plaats daarvan machtigingensets met beperkte veldtoegang die zijn toegewezen aan het gastgebruikersprofiel van de Experience Cloud-site.
• Sla bij een query op records in door systeemcontext uitgevoerde stromen op Experience Cloud-sites alleen de velden op die u nodig hebt in uw element Records ophalen of Aanroepbare acties.
• Als een stroom verschillende bewerkingen uitvoert en niet alle ervan verhoogde toegang vereisen, gebruikt u substromen om de bewerkingen te isoleren die in systeemcontext moeten worden uitgevoerd.
• Als u van plan bent om een formulier in te bedden in een externe webpagina, overweeg dan om gebruikersinvoer op te schonen om HTML te verwijderen met behulp van een Fast Field Update Flow of Apex Trigger als deze uiteindelijk worden toegewezen aan Rich Text-velden om potentiële phishing-aanvallen van kwaadwillende actoren te voorkomen.

• Omniscripts, FlexCards en LWC's worden standaard uitgevoerd in gebruikerscontext.
• LWC's worden standaard uitgevoerd in gebruikerscontext en stromen worden uitgevoerd in gebruikerscontext, maar u kunt dat overschrijven in een Apex controller.
• Bewerkingen die worden uitgevoerd via de UI-API, worden uitgevoerd in gebruikerscontext.
• Bewerkingen die worden uitgevoerd via een Apex controller zijn afhankelijk van die klasse. Als u deze bewerkingen in de systeemmodus wilt uitvoeren, stelt u de Apex klasse in op met of zonder delen.

Als u controle nodig hebt over wie toegang heeft tot uw formulier, kunt u vaak kijken naar de container waarin het formulier is ingebed. Zo kunt u Lightning pagina's toewijzen om beschikbaar te zijn voor bepaalde apps, recordtypen of profielen. Als bepaalde invoer in uw formulier gevoelig is, gebruikt u zichtbaarheidsregels om verder te bepalen wat aan wie wordt weergegeven. Deze voorziening is van toepassing op zowel Dynamische formulieren als schermstromen.

U kunt een stroom beperken tot bepaalde profielen of machtigingensets, op dezelfde manier als een Apex klasse of Visualforce pagina. Standaard zijn stromen onbeperkt, wat betekent dat elke gebruiker met de gebruikersmachtiging Stromen uitvoeren deze kan uitvoeren.

Als u OmniStudio gebruikt, kunt u een Apex klassenmachtigingencontroleur configureren om ervoor te zorgen dat gebruikers expliciete toegang nodig hebben tot de Apex klasse die de externe actie beheert die wordt aangeroepen vanuit een Omniscript, Flexcard, Classic Card of REST API.

• Opmerking Machtigingencontroles voor Apex klassen zijn standaard ingeschakeld voor nieuw gemaakte scripts. Ze moeten echter handmatig worden ingeschakeld voor alle bestaande scripts
• Houd er ook rekening mee dat Apex klasse machtigingscontroles alleen van toepassing zijn op Apex klassen. U wordt aangeraden om ook machtigingen op profielniveau in te stellen voor integratieprocedures en gegevenstoewijzingen.

Zie voor meer details en best practices over gastgebruikersmachtigingen:

• Best practices voor toegang tot gastgebruikersrecords
• Veilige sites ontwikkelen: Geauthenticeerde en gastgebruikers

Best practices:

• Als u een stroom zichtbaar maakt voor gastgebruikers, verleent u het gastgebruikersprofiel alleen toegang tot de stromen die ze nodig hebben. Hoewel het mogelijk is om Stromen uitvoeren toe te voegen aan het gastgebruikersprofiel, vinden we dat een riskante praktijk.
• Wees vooral voorzichtig met stromen die in systeemcontext werken. We raden u sterk aan om die stromen te beperken tot een bepaalde groep gebruikers, omdat ze minder controles en saldi hebben om uw gegevens te beschermen.
• Zorg ervoor dat elk Omniscript dat Apex uitvoert in een gastgebruikerscommunity "with sharing" (met delen) heeft in de Apex klassedefinitie.
• Wijs in uw profiel Gastgebruiker alleen die Apex klassen toe die gastgebruikers moeten kunnen aanroepen, anders riskeert u onbedoeld extra bedrijfslogica bloot te stellen aan gastgebruikers.

Voor LWC's kunt u de machtigingstoewijzingen van de huidige gebruiker controleren om te bevestigen of deze een bepaalde standaard- of aangepaste machtiging heeft. U kunt Salesforce-machtigingen rechtstreeks vanuit JavaScript importeren vanuit de modules met bereik @salesforce/userPermission en @salesforce/customPermission. Of u kunt Apex gebruiken om hetzelfde te controleren.

Lightning webcomponenten zijn alleen beschikbaar op een bepaalde locatie wanneer ze zijn toegevoegd als een geldig doel. Zo kunt u een component wel beschikbaar maken op recordpagina's, maar niet als balkitem voor hulpprogramma's.

Zodra een schermstroom is geactiveerd, is deze beschikbaar op alle locaties waar schermstromen worden ondersteund, ongeacht of u van plan was deze overal beschikbaar te maken. De Flow Builder ondersteunt echter meerdere typen stromen die schermen hebben. Het brood-en-botertype is Schermstroom, maar er zijn nog enkele andere gespecialiseerde typen die beperkt zijn tot specifieke locaties. Zo ondersteunt de mobiele Field Service-app alleen - u raadt het al - Field Service Mobile-stromen. Hetzelfde geldt voor Contactverzoekstromen, die alleen worden ondersteund in Experience Cloud.

Ongeacht het stroomtype heeft het individu dat de stroom maakt, geen controle over waar de stroom kan worden ingebed. De stroom is beschikbaar op elke locatie die voor dat stroomtype wordt ondersteund.

Als u Salesforce Industries gebruikt, is er een kleine waarschuwing bij Omniscript: Hoewel u geen doel kunt opgeven voor een Omniscript zelf, kunt u er wel een opgeven voor de FlexCards die u erin wilt inbedden.

Statische vormen behoren tot het verleden. Vandaag de dag draait het allemaal om het dynamisch bijwerken van het formulier met de juiste eigenschappen en waarden voor deze gebruiker, deze keer, deze plaats. Laten we eens kijken wat er in deze geest mogelijk is voor de tools voor het samenstellen van formulieren van Salesforce.

• Welke typen interacties of voorwaarden moeten dynamische reacties binnen uw formulier activeren?
• Moet u bewerkingen buiten het scherm uitvoeren op de achtergrond terwijl uw formulier wordt ingevuld?
• Moet u velden instellen als zichtbaar, verplicht, alleen-lezen of uitgeschakeld, of de opmaak wijzigen op basis van formulierinvoer?

Interactiviteit met schermstromen is nu een realiteit dankzij reactieve schermen. Met reactiviteit kunnen afzonderlijke componenten op een stroomscherm met elkaar communiceren, waardoor schermstromen oneindig krachtiger worden.

Gegevensbewerkingen buiten het scherm uitvoeren: Schermstromen bieden een declaratieve benadering voor het ophalen van gegevens op hetzelfde scherm via Schermacties. Met schermacties kunt u automatisch gestarte stromen activeren bij elke wijziging in het scherm of wanneer een gebruiker op een component Actieknop klikt. Vervolgens kunt u de resultaten van deze automatisch gestarte stromen toewijzen aan hetzelfde scherm, waardoor gebruikers niet meer naar een ander scherm hoeven te navigeren.

LWC biedt een volledige reeks wire-adapters waarmee u toegang hebt tot Salesforce-gegevens om gegevens dynamisch in te vullen in de componenten van uw formulier, en stelt ontwikkelaars in staat om records bij te werken, te verwijderen en te maken via Apex controllers.

Lightning webcomponenten Off-screen gegevensbewerkingen

Zichtbaarheid: De zichtbaarheid kan dynamisch worden bepaald in alle tools voor het samenstellen van formulieren. Dynamische formulieren, Flow Builder en OmniStudio lossen dit op met voorzieningen voor de zichtbaarheid van componenten. Hiermee kunt u velden declaratief tonen of verbergen op basis van andere waarden op het formulier of ongeacht of de gebruiker zich op een mobiel apparaat bevindt.

• Met Dynamische formulieren kan de zichtbaarheid worden bepaald op basis van recordveldwaarden, records die zijn gerelateerd via opzoekvelden en omvang.
• Met Stroom kunt u een zichtbaarheidsregel baseren op andere invoer op het scherm, evenals andere resources die eerder in de stroom zijn ingevuld, zoals formules of waarden uit andere records.
  • Op apparaat gebaseerde regels: Het is niet meteen duidelijk, maar u kunt een formule gebruiken om een bepaald veld te tonen of verbergen wanneer de gebruiker op een mobiel apparaat werkt. Schrijf een stroomformule die de waarde van de globale variabele $User.UIThemeDisplayed controleert. Als de waarde Theme4t is, bevindt de gebruiker zich in de mobiele Salesforce-app.
  • Andere resources evalueren: Handmatige variabelen en formuleverwijzingen worden alleen op de server geëvalueerd. Dus welke waarde die resource heeft wanneer het scherm voor het eerst wordt weergegeven, is de waarde die deze heeft totdat u naar een ander scherm navigeert. Tijdens navigatie dient de stroomrun-time een aanvraag in bij de stroomengine (de server) en haalt de nieuwste waarden van de handmatige variabelen en formules op. Als u verwacht dat uw zichtbaarheidsregel wordt bijgewerkt terwijl de gebruiker door één scherm gaat (bijvoorbeeld onscherpte), zorgt u ervoor dat u alleen naar waarden uit de andere componenten op het scherm verwijst.
• Met OmniStudio kunt u componenten voorwaardelijk tonen of verbergen door een eigenschap Voorwaardelijke weergave in te stellen. U kunt echter niet meer dan één eigenschap voor voorwaardelijke weergave toevoegen voor een invoer.

Voorwaardelijke invoerstatussen: Als u dynamisch andere eigenschappen wilt bepalen, zoals of een veld verplicht, uitgeschakeld of alleen-lezen is, hebt u enkele opties. Zoals verwacht biedt LWC u volledige, reactieve controle over uw invoerstatus. Met reactieve schermstroomcomponenten kunt u componentkenmerken zoals Alleen-lezen, Uitgeschakeld en Verplicht dynamisch aansturen voor standaardcomponenten die dit ondersteunen, terwijl OmniStudio het volledige spectrum van componentspecifieke kenmerken ondersteunt. Als uw vereisten vereisen dat u Flow nodig hebt en de component geen ondersteuning biedt voor een specifieke kenmerkstatus, kunt u een inbedbaar LWC maken om een dynamische invoerstatus te bereiken.

Als u dynamisch andere eigenschappen wilt aansturen, zoals of een veld verplicht of alleen-lezen is, kunt u het beste op korte termijn LWC kiezen, waarbij u volledige controle hebt. Dit geldt met name als u specifieke vereisten hebt voor de manier waarop u onblur of onclick moet afhandelen.

Reactieve LWC's in schermstromen: Wanneer u LWC's samenstelt die zowel kunnen reageren op als andere componenten kunnen wijzigen in een schermstroom, raadpleegt u deze LWC Best Practices for Screen Flows Guide om ervoor te zorgen dat uw componenten goed integreren binnen de run-time engine van de stroom en in de toekomst werken zoals verwacht.

Nu aangepaste events. Als sommige van uw invoer of het gehele formulier moet communiceren met iets anders op de pagina, is LWC uw enige optie.

• Gebruik voor communicatie binnen dezelfde DOM-structuur de CustomEvent-interface.
• Gebruik Lightning Messaging Service om binnen het DOM te communiceren.
• Als Lightning Messaging Service niet wordt ondersteund voor uw doelcontainer, gebruikt u de pub/sub-module.

• Zie Communiceren met events en Communiceren binnen het DOM in de Lightning Web Components Dev Guide voor meer informatie.
• Raadpleeg voor OmniStudio Communiceren met Omniscript vanuit een Lightning webcomponent.

Voor de beste gebruikerservaring moet u ervoor zorgen dat de stijl van uw formulier consistent is met de rest van de app of site waarin het is ingebed. Dit kan van alles betekenen, van het gebruik van standaardsjablonen van Salesforce tot het maken van aangepaste CSS die elke pixel in het ontwerp volledig benut om een scherper uiterlijk te bieden.

• Hoe geavanceerd is uw gewenste styling en CSS?
• Hebt u aangepaste, tot op de pixel nauwkeurige stilering nodig of bent u tevreden met standaardthema's?

FlexCards is het enige product dat in deze handleiding wordt behandeld en waarmee u de stilering en lay-out van de UI die u samenstelt, rechtstreeks in de tool kunt bepalen - of dat nu de marges en opvulling, typografie, kleuren, enz. zijn.

Zowel Dynamische formulieren als stromen respecteren declaratieve themavoorzieningen. Als u controle nodig hebt die verder gaat dan wat Salesforce-thema's, Experience Builder-brandingsets of LWR Experience Cloud-sites ondersteunen, overweeg dan een programmatische oplossing.

Voor teams die vertrouwd zijn met CSS, hebt u een aantal opties:

• Stromen en LWC's nemen standaardontwerptokens over.
• Omniscripts en FlexCards omvatten ondersteuning voor een aanpasbaar ontwerpsysteem: Newport.
• Met LWC kunt u uw eigen componenten schrijven en de HTML en CSS ervoor volledig beheren.

Waar mogelijk raden we aan thema's en ontwerpsystemen te gebruiken, zodat uw uiterlijk consistent wordt toegepast op al uw inhoud.

Herinnering: U kunt Lightning componenten inbedden in stromen. Dus als u tot op de pixel nauwkeurige controle nodig hebt over het uiterlijk van uw formulier, maar de andere voordelen van stromen, zoals het navigatiemodel, wilt gebruiken, kunt u het beste van twee werelden krijgen. Hetzelfde principe geldt voor Omniscripts en FlexCards.

Het kiezen van een goede lay-out is cruciaal voor het ontwerpen van gestroomlijnde formulieren die snelle en efficiënte gegevensinvoer mogelijk maken en de gegevensintegriteit vergroten. Zie Salesforce Well-Architected - Forms voor meer informatie over dit onderwerp.

• Hoe kunt u de lay-out van uw formulier gebruiken om gebruikerservaringen te optimaliseren?
• Hoe kunt u bestaande gegevens aan uw gebruikers presenteren op een manier die het voor hen gemakkelijker maakt om nieuwe gegevens in te voeren in uw formulieren?

Dynamische formulieren ondersteunt tweekolomslay-outs en kan worden opgesplitst in afzonderlijke secties met velden. Deze secties kunnen worden geplaatst in componenten zoals tabbladen en accordeons om gebruiksvriendelijke en georganiseerde lay-outs te maken.

Stromen kunnen optioneel worden weergegeven met behulp van de component Sectie. Met secties kunt u maximaal vier kolommen en zo veel secties toevoegen als u wilt op het stroomscherm. De component is ook responsief op schermbreedte, zodat deze kan werken op kleinere schermen. Ten slotte kunt u voorwaardelijke zichtbaarheid toepassen op de gehele sectie, waardoor het gemakkelijker wordt om in bulk zichtbaarheid toe te passen op meerdere velden binnen de sectie. Stroomsecties ondersteunen ook kolomkoppen en bieden een accordeonachtige ervaring waarin gebruikers de gehele sectie kunnen samenvouwen door op het label te klikken.

Omniscripts bieden een verscheidenheid aan lay-outopties voor het weergeven van velden en gegevens. U kunt secties met gegevens maken met maximaal 12 kolommen, inclusief voorwaardelijk samenvouwbare accordeons.

Met LWC kunt u Lightning Record-[edit|view]-form en het ondersteunende Lightning [input|output]-veld gebruiken om de lay-out te bepalen. De enige lay-outbeperkingen zijn die uit HTML/CSS. Lightning respecteert de sectieconfiguratie in de gekoppelde paginalay-out; als een sectie bijvoorbeeld twee kolommen in de paginalay-out heeft, is het twee kolommen in deze component.

Als uw formulier toegankelijk is voor gebruikers in verschillende regio's of die verschillende talen spreken, moet u ervoor zorgen dat de tool die u gaat gebruiken om het formulier samen te stellen, voldoet aan uw lokalisatievereisten. Zie Salesforce Well-Architected - Localization voor aanvullende richtlijnen en aanbevelingen. Specifiek voor formulieren omvatten lokalisatievereisten doorgaans het vertalen van tekstelementen in andere talen.

• Wordt uw formulier in meer dan één land of regio gebruikt?
• Moet de tekst in uw formulier worden gelokaliseerd naar andere talen?

Als u uw aangepaste velden hebt gelokaliseerd, worden die vertaalde labels gerespecteerd in Dynamische formulieren. Dynamische formulieren respecteert ook aangepaste labels die u hebt toegewezen aan componentlabels en -kenmerken in Lightning Appsamensteller.

Met de kracht van Translation Workbench ondersteunt Flow vertaling van gebruikersgerichte labels voor alle standaard- en aangepaste schermcomponenten. U kunt het label, de Help-tekst en het foutbericht van deze schermcomponenten lokaliseren: Tekst, Lange-tekstgebied, Getal, Valuta, Selectievakje, Keuzelijst, Keuzelijst met meervoudige selectie, Groep selectievakjes, Wachtwoord, Datum en Datum/tijd.

Er is geen ingebouwde vertaalondersteuning voor kant-en-klare acties, zoals E-mail verzenden of Posten naar Chatter. Er is echter een oplossing! Als u de vertaalde labels definieert met een aangepast label, kunt u naar dat aangepaste label verwijzen in de actie of component wanneer u het configureert in Flow Builder. Maak een stroomformule die verwijst naar het aangepaste label en verwijs naar die formule op de juiste plaatsen in uw stroom.

Omniscripts maken gebruik van aangepaste labels voor vertalingen. Raadpleeg dit Help-document om uw Omniscripts meertalig te maken.

Nu LWC. Bepaalde basiscomponenten nemen automatisch vertalingen over van de velden, Help-tekst en validatieberichten van het gekoppelde object als deze zijn geconfigureerd in het Vertaalcentrum (bijvoorbeeld: Lightning Record-Form).

Als u nieuwe vertaalbare labels in uw code moet introduceren, zijn aangepaste labels nog steeds de miskende held. Declareer het aangepaste label dat u nodig hebt en importeer het vervolgens in uw component vanuit de module @salesforce/label scoped.

Er zijn verschillende end-to-end testautomatiseringstools beschikbaar (bijvoorbeeld Selenium), waarmee u kunt simuleren hoe de gebruiker met uw formulier omgaat. U kunt deze tests schrijven voor elke standaard of aangepaste UI, inclusief Lightning pagina's en schermstromen. Het is echter belangrijk om te weten dat deze typen tests niet de uitvoer kunnen verifiëren van elke methode die wordt uitgevoerd. Zorg ervoor dat u hiermee rekening houdt bij het nadenken over uw vereisten voor UI-testautomatisering.

• Hebt u geautomatiseerde tests nodig voor uw formulier?
• Welke typen tests moet u uitvoeren?
• Welk niveau van fijnkorreligheid hebt u nodig in uw testautomatiseringen?

Denk aan uw vereisten voor UI-testautomatisering.

Eenheidstests maken meer fijnmazige automatisering en validatie mogelijk die werkt met CI/CD-systemen en tools van de industriestandaard, die de bedrijfslogica van de componenten, de JavaScript-controller en de uitvoer ervan kunnen testen. Als u uitsluitend kiest voor low-code, kunt u tests niet zelf schrijven, maar Salesforce test onze end-to-end aanbiedingen grondig.

Als de methoden van uw component complex genoeg zijn om afzonderlijk te worden getest, plaatst u de methoden in speciale JavaScript-bestanden. Op die manier kunt u ze importeren in een LWC en in een Jest-test met bijvoorbeeld import { sort } from 'c/utils';.

Zie UI-testautomatisering voor Salesforce voor een vergelijking van de verschillende opties die u hebt voor het samenstellen van end-to-end automatisering voor Salesforce. Hieronder vallen overwegingen bij het gebruik van een oplossing zonder code vanuit een ISV, Build Your Own Custom Test Automation-oplossing of het gebruik van een open source testframework zoals Selenium WebDriver of WebdriverIO. Deze oplossingen zijn geldig voor elke UI-interactie in Salesforce, of dat nu een Dynamisch formulier op een Lightning pagina is, een schermstroom in een balk voor hulpprogramma's of een LWC in een stroom in een snelle actie.

Nadat u uw formulier hebt geïmplementeerd naar een productieomgeving, wilt u ervoor zorgen dat het effectief wordt gebruikt. Afhankelijk van uw gebruikscase kan dit van alles betekenen, van het eenvoudig bijhouden van het aantal malen dat het is ingevuld tot de hoeveelheid tijd die gebruikers besteden aan het invullen ervan voordat ze hun gegevens indienen. Zorg ervoor dat u de KPI's identificeert die u wilt bijhouden voordat u een tool kiest.

• Moet u het gebruik van uw formulier bijhouden?
• Welke KPI's bepalen of uw formulier effectief wordt gebruikt?

Als u het algemene gebruik en de acceptatie van uw formulier wilt bijhouden, begint u met de tools voor weinig code. Zowel Dynamische formulieren als Schermstromen kunnen worden bijgehouden met behulp van kant-en-klare aangepast-rapporttypen, hoewel de rapporten voor het bijhouden van schermstromen fijnmaziger zijn. Als u het gebruik van een LWC moet bijhouden, is de kant-en-klare beschikbaarheid afhankelijk van waar u dat LWC gebruikt. Als het op een Lightning pagina staat, is alles wat beschikbaar is voor het bijhouden van Lightning paginagebruik van toepassing op uw LWC. Hetzelfde geldt voor LWC's die zijn ingebed in stromen.

Dynamische formulieren zelf kunnen niet kant-en-klaar worden bijgehouden, hoewel u het gebruik van de bovenliggende Lightning pagina kunt bijhouden via Lightning gebruiksobjecten. Gebruik voor het bijhouden van de standaard Lightning pagina's het aangepast-rapporttype Gebruikers met Lightning Gebruik op paginameetgegevens. Gebruik voor hetzelfde op aangepaste Lightning pagina's het aangepast-rapporttype Gebruikers met Lightning Gebruik op FlexiPage-meetgegevens.

Voor het bijhouden van de acceptatie van uw specifieke formulier (niet alleen de pagina waarin het zich bevindt), biedt Flow uitkomst. Gebruik het voorbeeldstroomrapport: Schermstromen" voor het beantwoorden van vragen zoals:

• Wat is het voltooiingspercentage voor dit formulier? Is het goed geadopteerd?
• Hoe lang duurt het voordat gebruikers dit formulier hebben ingevuld?
• Op welk scherm brengen gebruikers de meeste tijd door?
• Hoe vaak navigeren gebruikers terug?
• Hoe vaak doen zich fouten voor?

Als het standaardrapport niet voldoet aan uw behoeften, kloont u het om uw eigen wijzigingen aan te brengen of Build Your Own helemaal opnieuw met behulp van het rapporttype Schermstromen.

Als u de op een pakket gebaseerde Omniscript-run-time gebruikt, kunt u de OmniStudio for Vlocity Tracking Service gebruiken. Deze service houdt elk type event bij. Zo kunt u de tijd bijhouden die nodig is om de stappen in een Omniscript te voltooien om procesverbeteringen te identificeren. Het staat op de roadmap van het OmniStudio-team om deze service te ondersteunen in Standard OmniStudio.

Als u hetzelfde wilt bijhouden voor een LWC dat niet is ingebed in een schermstroom, Omniscript of Lightning pagina, is er geen kant-en-klare optie. U kunt een aangepaste oplossing samenstellen met behulp van Apex.

Wanneer u uw oplossing moet implementeren naar hogere omgevingen om te testen of implementeren naar productie, bent u wellicht gewend om hiervoor wijzigingssets of DevOps Center te gebruiken. Dynamische formulieren, stromen en LWC's worden volledig ondersteund in die implementatieopties. OmniStudio vereist een afzonderlijke tool: IDX Workbench.

• Hoe wilt u uw formulier implementeren?
• Wordt uw formulier naar meer dan één Salesforce-organisatie gedistribueerd?

Als u een ISV of partner bent die van plan is om uw oplossing op te nemen in een pakket voor distributie op AppExchange, raden we aan om eerst Dynamische formulieren, stromen en LWC's te bekijken. OmniStudio biedt geen ondersteuning voor pakketten.

Deze handleiding is erop gericht u te helpen begrijpen welke functionaliteit en welk niveau van aanpassing mogelijk is met Dynamische formulieren, schermstromen, OmniStudio en LWC. Op hoog niveau:

• LWC is de meest aanpasbare en robuuste optie voor het samenstellen van een formulier, maar heeft de minste vangrails. Het is aan u om een component samen te stellen op een manier die beveiliging en schaalbaarheid garandeert.
• Dynamische formulieren is het minst flexibel, maar er zijn veel minder kansen op misstappen.
• Flow en OmniStudio zitten ergens in het midden – krachtiger dan Dynamische formulieren, maar niet helemaal op het niveau van LWC. Op dezelfde manier hebben ze minder vangrails dan Dynamische formulieren, maar zijn ze moeilijker te breken dan aangepaste code.

Als er meerdere tools zijn die passen bij het plaatje, komt de beslissing neer op de juiste tool voor uw team. Andere Architect Decision Guides introduceren extra aspecten om rekening mee te houden bij het nemen van die beslissing.

We zullen hier niet ingaan op de details van elk van deze aspecten, maar we zullen ze interpreteren voor de specifieke tools die dit document beoordeelt.

Gespecialiseerde vaardigheden: Hoeveel expertise heeft uw team in de tools die u vergelijkt? Hoeveel makers zijn goed bekend met LWC of JavaScript? Hoe zit het met makers die experts zijn in Flow Builder of die interesse hebben getoond in het dompelen van hun tenen? Over het algemeen zijn Dynamische formulieren en Stroom-vaardigheden beter bereikbaar voor een bredere populatie van mensen die formulieren samenstellen. Dynamische formulieren is de meest declaratieve tool voor het samenstellen van formulieren en is altijd gemakkelijker te leren dan Flow. Het Flow-team streeft er echter naar om die lat zo laag mogelijk te leggen. Qua complexiteit zit OmniStudio ergens tussen Flow en LWC in en biedt het aanzienlijke superkrachten voor het samenstellen van formulieren.

Delegatie van levering: Omdat sommige van uw vereisten LWC vereisen, betekent dit niet dat uw gehele oplossing met LWC moet worden samengesteld. Bedenk hoe u uw oplossing modulair kunt samenstellen, zodat de onderdelen die LWC vereisen, worden gecodeerd en de onderdelen die dat niet doen, worden samengesteld in een oplossing met weinig code. Dit maximaliseert de efficiëntie van een divers team en zorgt ervoor dat elk individu problemen oplost die passen bij zijn of haar specialisatie.

Laten we het nu hebben over Flow en LWC. Met reactieve schermcomponenten kunnen schermstroomcomponenten nu met elkaar praten op hetzelfde scherm, waardoor een geheel nieuwe toolkist wordt ontgrendeld voor architecten, beheerders en ontwikkelaars. Ontwikkelaars kunnen nu doelgerichte, modulaire componenten maken die binnen de hele organisatie kunnen worden hergebruikt, wat de productiviteit voor iedereen in het team verhoogt. Ontwikkelaars kunnen zich richten op het oplossen van nieuwe uitdagingen en tijd besparen door een mix van standaard- en aangepaste stroomcomponenten te gebruiken om vormdynamiek te bereiken. Met reactieve componenten in Flow is er nooit een geschikter moment geweest om Flow en LWC te combineren bij het samenstellen van uw formulieren.

Onderhoudbaarheid en eigendom op lange termijn: Als u een formulier met meerdere stappen hebt, is het een goed idee om te beginnen met Flow of een mix van Flow en LWC. Als u een low-code team hebt dat de oplossing onderhoudt, bedenk dan hoe u de oplossing zo configureerbaar en uitbreidbaar mogelijk kunt maken voor die doelgroep. Welke tool u ook kiest, organiseer uw oplossing in samenstelbare eenheden om de onderhoudbaarheid en stabiliteit te verbeteren.

In de toekomst is Dynamische formulieren in Lightning Appsamensteller met behulp van Lightning pagina's de aanbevolen manier om recorddetailpagina's te configureren. Het is lang geleden dat we paginalay-outs hebben verbeterd, en die trend zal zich voortzetten. Dit is waarom:

• Dynamische formulieren zijn flexibeler: u kunt velden en secties waar u maar wilt rechtstreeks in Lightning Appsamensteller plaatsen, waar u secties, tabbladen en accordeons kunt benutten. En net zoals u kunt doen met componenten op de Lightning pagina, kunt u de zichtbaarheid van uw velden en secties bepalen zonder meerdere paginalay-outs of recordtypen te definiëren.
• Met accordeon- en tabbladcomponenten kunt u het aantal velden beperken dat aanvankelijk wordt weergegeven. Raad eens wat dat betekent? Snellere laadtijden van pagina's.
• Lay-outbeheer is eenvoudiger met Lightning pagina's, omdat u alles over uw pagina's kunt beheren vanuit Lightning Appsamensteller - of dat nu de inhoud van de pagina is of welke gebruikers toegang tot de pagina hebben. Het is niet langer nodig om updates aan te brengen in uw paginalay-out om een wijziging aan te brengen in uw Lightning pagina. En niet te vergeten, met de kracht van zichtbaarheidsregels hoeft u niet langer meerdere pagina's (of paginalay-outs) te maken om te bepalen wie welke velden wanneer ziet. En dat betekent ook dat u aan gebruikers alleen een Lightning pagina hoeft toe te wijzen in plaats van zowel een Lightning pagina als een paginalay-out.

U wordt aangeraden Dynamische formulieren waar mogelijk te gebruiken en alleen terug te vallen op paginalay-outs wanneer dat nodig is. Zoals altijd verwelkomen we feedback in de Ideeënuitwisseling over de verbeteringen die het meest impactvol zouden zijn voor uw organisatie.

Alle prestatieoverwegingen met betrekking tot Dynamische formulieren, schermstromen, OmniStudio en LWC richten zich op het framework waarin deze technologieën zelf zich bevinden. Degenen die zijn gebaseerd in LWC (naast natuurlijk een LWC) zullen beter presteren dan degenen die zijn gebaseerd in Aura. Het LWC-framework biedt betere prestaties omdat kernvoorzieningen native worden geïmplementeerd in webengines in plaats van in JavaScript via frameworkabstracties. Als je niet bekend bent, lees dan deze blogpost.

In 2019 hebben we een casestudy gedaan waarin we de prestaties van dezelfde functionaliteit in Aura vergeleken met die in LWC. Als gevolg van de conversie van DreamHouse van Aura naar LWC was niet alleen de ontwikkelervaring veel beter afgestemd op de huidige web front-end ontwikkelstandaarden en -patronen, maar waren de prestaties aanzienlijk verbeterd. Labmetingen toonden winsten van 2,4 procent tot 24,7 procent voor koud cachegeheugen en winsten van 31,83 procent tot 63,32 procent voor warm cachegeheugen op dezelfde twee pagina's.

Welk framework gebruiken onze formuliertechnologieën? Met andere woorden, welke vormtechnologieën profiteren van deze superieure prestaties?

• Dynamische formulieren, dat is geïntegreerd in de metagegevens van Lightning pagina's, is gebaseerd op een basis die de LWC-stack gebruikt, waardoor we enkele lang gevraagde voorzieningen kunnen implementeren. Als prestatiebonus gebruikt Dynamische formulieren progressieve weergave, wat resulteert in een verbeterde laadtijd voor pagina's die een groot aantal velden hebben.
• Schermstromen zijn gebaseerd op LWC, waarbij de meeste afzonderlijke kant-en-klare componenten nu zijn geconverteerd naar LWC, met uitzondering van twee kant-en-klare componenten: Bestand uploaden en afbeelding. Hoewel het Flow-team de run-time client van de stroom heeft geconverteerd naar LWC en de meeste componenten ervan, moeten klanten hun Aura-schermcomponenten nog steeds converteren naar LWC. Niet alleen dat, maar Salesforce ondersteunt alleen LWC-componenten in het nieuwe framework voor reactieve componenten in schermstromen. Er is een uitstekende Trailhead module die uitlegt hoe je dit doet: Lightning webcomponenten voor Aura-ontwikkelaars. Het spreekt voor zich: Als u van plan bent om een aangepaste component te maken voor een schermstroom of een andere container, gaat u altijd naar LWC.
• Er zijn enkele versies van OmniStudio beschikbaar. Als u al langer klant bent, gebruikt u mogelijk Angular. We raden alle nieuwe klanten aan om te beginnen met op LWC gebaseerde Omniscripts en FlexCards, en voor bestaande klanten om Angular te migreren.
• LWC is gebouwd op ... LWC natuurlijk. Dit is een freebie. 🤓

Als architect is het belangrijk om een goed inzicht te hebben in alle opties die u hebt en hoe u deze kunt toepassen in uw specifieke gebruikscase. Voor het samenstellen van formulieren in Salesforce variëren de opties van low-code (met behulp van Dynamische formulieren in Lightning Appsamensteller, Schermstromen in Flow Builder en Omniscripts in OmniStudio) tot pro-code (met behulp van het LWC-framework), met een combinatie van schermstromen of Omniscripts en LWC in het midden. Houd deze handleiding in gedachten en gebruik deze als naslagwerk wanneer u van plan bent om formulieren voor Salesforce samen te stellen of opnieuw te ontwerpen. Als u begeleiding zoekt bij het ontwerpen van gestroomlijnde en handige formulieren, raadpleegt u Goed ontworpen van Salesforce: Bezig.

Help ons ervoor te zorgen dat we publiceren wat het meest relevant voor u is: doe onze enquête om feedback te geven over deze inhoud en vertel ons wat u als volgende wilt zien.