Formulieren samenstellen

Er zijn meerdere opties voor het samenstellen van formulieren op het Agentforce 360 Platform en ze omvatten een continuüm van benaderingen met weinig code tot benaderingen met pro-code. Aan de ene kant van het continuüm kunnen Dynamische formulieren in Lightning Appsamensteller en schermstromen in Flow Builder worden gebruikt voor oplossingen met weinig code. Aan de andere kant wordt het Lightning Web Component (LWC) framework gebruikt voor pro-code oplossingen. Binnen het continuüm kunnen tools op een aantal manieren worden gemengd met behulp van schermstromen die worden uitgebreid met LWC’s en klantgerichte formulieren die zijn samengesteld met behulp van Omnistudio.

Deze handleiding biedt een beslissingskader en richtlijnen voor het samenstellen van formulieren voor UI-oplossingen. Het gebruikt met name een tiental run-time en niet-functionele beslissingspunten om de beste technologie voor een bepaalde gebruikscase goed te selecteren.

• Wanneer u lay-outs maakt/bewerkt/weergeeft voor Lightning pagina’s, gebruikt u Dynamische formulieren. In de toekomst wordt aangeraden om Dynamische formulieren in Lightning Appsamensteller te gebruiken om recorddetailpagina’s te configureren.

• Als u een formulier voor één object moet samenstellen, maken of bewerken, gebruikt u Lightning-pagina’s en Dynamische formulieren. Dit is de gemakkelijkste manier om formulieren samen te stellen op het Agentforce 360 Platform. Het biedt ook extra functionaliteit (bijvoorbeeld veldzichtbaarheidscontrole).

• Als u een formulier van meerdere pagina’s of een wizard samenstelt en u geen strenge UX- of brandingvereisten hebt, gebruikt u een schermstroom. Schermstromen bieden een raamwerk voor lineaire navigatie voor het orkestreren van meerdere formulieren. U kunt LWC’s gebruiken om uw eigen raamwerk te maken voor het navigeren tussen formulieren, maar het wordt aanbevolen om Flow het werk te laten doen, zodat u zich kunt richten op de formulieren zelf in plaats van u te richten op de status van het formulier.

• Als u extra logica of acties nodig hebt om het formulier te ondersteunen, gebruikt u een schermstroom, Omnistudio of LWC’s. Elk van deze tools biedt verschillende manieren om uw oplossing te verbeteren door deze verder te laten gaan dan het maken of bewerken van één record. In dit geval kan de term meer verwijzen naar geavanceerde logica (bijvoorbeeld vertakking of herhaling), of naar acties zoals integreren met externe systemen, het verzenden van e-mailberichten of het pushen van kennisgevingen naar de mobiele app van een gebruiker.

• Als u geavanceerde UX-vereisten hebt of als u dynamisch meer dan UI-zichtbaarheid moet beheren, gebruikt u LWC of Omniscript. Voor vereisten waaraan kan worden voldaan door thema’s en op kolommen gebaseerde lay-outs te gebruiken, kunt u uw formulieren rechtstreeks in een samensteller met weinig code samenstellen. Maar fijnmazige controle over de stijl van uw formulier vereist de flexibiliteit van LWC. Als u een Industries-klant bent, en u hebt pixelperfecte branding nodig of u hebt complexe hiërarchische gegevens, gebruikt u Omnistudio, waarmee u formulieren op consumentenniveau kunt samenstellen die complexe bedrijfslogica en gegevenstransformaties kunnen afhandelen.

• Als u testautomatisering moet implementeren, gebruikt u LWC. U kunt eenheidstests schrijven voor elke LWC, ongeacht waar u deze inbedt. Dit biedt de mogelijkheid om een robuustere teststrategie te maken, die zowel bulktests met meerdere records als negatief testen kan omvatten.

• U bent niet gebonden aan “of/of” beslissingen. U kunt meerdere opties combineren om de beste oplossing voor uw gebruikscases te vinden (als u bijvoorbeeld het ingebouwde navigatiesysteem van Flow en de volledige stileringsflexibiliteit van LWC nodig hebt, kunt u ze samen gebruiken).

De volgende tools worden vaak gebruikt voor het implementeren en uitbreiden van formulieromgevingen.

Deze tabel geeft een overzicht van de tools die beschikbaar zijn voor het samenstellen van formulieren via Salesforce, samen met hun vereiste vaardigheden en licentieoverwegingen.

Opmerking: We gaan dieper in op de specifieke voorzieningen die voor elke tool worden ondersteund, hoe u kunt kiezen tussen op klikken gebaseerde tools en op code gebaseerde tools, en wanneer u deze combineert in een latere sectie.

Er zijn een aantal beslissingspunten om in gedachten te houden wanneer u product- en toolselecties maakt. Deze tabel geeft een overzicht van diverse beslissingspunten en biedt richtlijnen op hoog niveau.

Opmerking: In daaropvolgende beslissingsvergelijkingstabellen zijn er een handvol waarden die zijn gekoppeld aan een willekeurig paar tools/voorzieningen:

• Beschikbaar: De tool/voorziening werkt met basisoverwegingen.

• Niet beschikbaar: Er zijn geen plannen om binnen de komende twaalf maanden ondersteuning toe te voegen.

• Niet ideaal: Deze tool/voorziening werkt dan wel, maar is niet de optimale tool.

• Niet van toepassing: De tool is niet van toepassing op de specifieke gebruikscase.

Gebruik deze scenario’s om toolingkeuzes te vergelijken op basis van bereik, UX en operationele behoeften.

Als u al uw gebruikersinvoer kunt ophalen uit een formulier met één scherm, begint u met Dynamische formulieren. Houd er rekening mee dat Dynamische formulieren op recordpagina’s de voorziening Traject kunnen gebruiken om gefaseerde bedrijfsprocessen te ondersteunen.

• 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 in het proces bij 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 af van enkele aanvullende vragen:

• Is het oké om een navigatiebalk onder aan het formulier weer te geven? Als de navigatieomgeving Schermstroom en Omniscript een ongewenste UX biedt, neigt u naar LWC.

• Wat moet er achter het formulier gebeuren? Als u de werking wilt configureren door een beheerder, gebruikt u een stroom. Gebruik voor complexe relaties met meerdere objecten Omniscript of LWC.

Als u kiest voor Flow of Omnistudio, moet u mogelijk ook een LWC samenstellen om de juiste UX te bereiken. Als u al een LWC maakt om uw formulier correct van stijl te voorzien, overweeg dan of het nodig is om die component in een stroom in te bedden.

Navigatie in wizardstijl

Aan de andere kant, als uw oplossing eruitziet als een wizard—waarbij de gebruiker tussen meerdere schermen navigeert—overweeg dan Flow of Omnistudio. Stromen en Omnistudio hebben een ingebouwd navigatiemodel, zodat u geen LWC’s hoeft te maken en 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.

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

Of u nu formulieren met één scherm of met meerdere schermen samenstelt, het is belangrijk dat u ervoor zorgt 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. Dynamische formulieren zijn momenteel echter alleen beschikbaar op de desktop. Als u een omgeving wilt bieden waarin gebruikers toegang hebben tot formulieren 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 inschakelen 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 deze recordcontext vereist, wordt de voorziening Dynamische formulieren alleen ondersteund op Lightning recordpagina’s. Dynamische formulieren wordt echter niet ondersteund op Experience Cloud-pagina’s.

U kunt stromen samenstellen die een recordcontext vereisen, of stromen die globaal werken. Met andere woorden, u kunt stromen op verschillende locaties inbedden. Voor recordcontextuele stromen kunnen locaties het volgende omvatten: Lightning recordpagina’s, Experience Cloud recordpagina’s, objectspecifieke acties of implementaties van Acties en aanbevelingen. Voor globale stromen kunnen locaties omvatten: de balk voor hulpprogramma’s, andere Lightning of Omgevingssamensteller-pagina’s, Snaps of externe toepassingen. Momenteel worden stromen niet ondersteund als globale acties, maar u kunt stromen als tussenoplossing 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, maar die wel samenstelbaar zijn, maar niet in een pakket kunnen worden opgenomen.

LWC biedt een hoge mate van herbruikbaarheid voor het maken van componenten die kunnen worden gekoppeld aan doelen via metagegevens in Salesforce, Community’s en open-sourceprojecten. LWC-componenten kunnen ook binnen uw eigen website worden ingebed met behulp van Lightning Out 2.0.

LWC-componenten kunnen ook stromen starten met de component Lightning Flow.

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

Momenteel wordt geen van de formuliertechnologieën die in deze handleiding worden behandeld, officieel ondersteund in Mobile SDK-sjablonen. Als de Mobile SDK essentieel is voor uw gebruikscase, wordt aangeraden om uw formulier native in uw mobiele toepassing te maken of een Visualforce pagina te maken, waarbij u rekening houdt met de omvang van het formulier.

Dynamische formulieren zijn perfect als u de waarden in uw formulier moet gebruiken om een record te maken of bij te werken. U moet Flow, Omnistudio of LWC gebruiken voor mogelijkheden buiten dat bereik, inclusief het maken van beslissings- of herhalingslagen of het genereren van Slack-posts of -e-mailberichten met behulp van de invoer van het formulier.

• Welke acties of logica moeten achter de schermen worden uitgevoerd?

• Moet u waarden uit een gerelateerde record gebruiken?

• 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-mailberichten en werken met Quip documenten, en u hoeft geen code te schrijven voor een van deze bewerkingen. LWC biedt rijke interacties met afzonderlijke records en gerelateerde objecten via wire-adapters die een interactie hebben met de gebruikersinterface-API. LWC kan ook met meerdere records werken met behulp van de wire voor getListInfoByName.

Omnistudio gebruikt integratieprocedures en Data Mapper voor het verkrijgen en transformeren van gegevens (zowel extern als intern voor Salesforce). Dankzij talrijke codevrije functies blinkt het uit in het afvlakken en uitbreiden van gegevenssets met verschillende niveaus van relaties.

Flow, Omnistudio en LWC zijn allemaal geïntegreerd met Apex, zodat u gemakkelijk eventuele hiaten kunt dichten binnen de oplossing die u kiest (als u bijvoorbeeld records uit een LWC wilt filteren, kunt u de draadadapter voor Apex gebruiken om complexe SOQL-query’s te maken. Als u geïnteresseerd bent in op klikken gebaseerde story’s, kunt u overwegen om Flow of Omnistudio te gebruiken als een levensvatbaar alternatief voor een Apex controller voor uw serverbehoeften.

U moet ook overwegen 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 later in de wizard (stroom) te gebruiken om bepaalde bewerkingen uit te voeren. Dit is precies wat we aanbevelen bij het ontwerpen van stromen. Voer acties aan het einde uit (voor het geval gebruikers heen en weer kaatsen tussen schermen om hun antwoorden te wijzigen).

Transacties en governorlimieten zijn integraal onderdeel van het Agentforce 360 Platform. Als uw gebruikscase vrij eenvoudig is, is het mogelijk niet zo belangrijk om de transactie te controleren waarin een bepaalde bewerking plaatsvindt. Er zijn echter enkele gebruikscases waarin u mogelijk meerdere bewerkingen wilt combineren tot één transactie in plaats van deze uit te voeren voor meerdere transacties.

Hier zijn enkele voorbeelden:

• Terugdraaien: Stel dat uw formulier achter de schermen meerdere records maakt. Als het maken van een derde record mislukt, moeten de eerste twee records dan worden teruggedraaid? Als al uw acties onafhankelijk van elkaar zijn, kunt u ze uitvoeren als afzonderlijke transacties. Als ze echter afhankelijk van elkaar zijn—en u wilt dat het falen van de ene ook de andere terugdraait—moet u ze implementeren als één transactie. Als uw formulier voorkomt in Stroom, kunt u het element Terugdraaien in het fouttraject gebruiken om uw transactie terug te draaien en de gegevensintegriteit te waarborgen.

• Invloed stroomafwaarts op limieten van gouverneurs: Wanneer uw formulier een record maakt of bijwerkt, is het belangrijk om te overwegen wat de gevolgen zijn van die bewerking verderop in de stroom:

  • Welke processen, werkstroomregels, stroomtriggers, Apex triggers of andere items binnen de opslagorder kunnen worden geactiveerd op basis van de voorgestelde recordwijzigingen?

  • Hoe beïnvloeden die collectieve wijzigingen de beheerlimieten die binnen die transactie worden verbruikt?

  • Als een bepaalde recordwijziging kan leiden tot veel wijzigingen verderop in de stroom die van invloed zijn op uw limieten, kunt u overwegen om die recordwijziging te isoleren binnen de eigen transactie.

• Batchverwerking: Mogelijk moet u meerdere updates tegelijk in batches plaatsen (zelfs binnen een UI-context). 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 tot u de updates voor alle records hebt verzameld—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.

Wanneer u een schermstroom samenstelt, hebt u veel controle over wat er binnen 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 binnen de schermstroomarchitectuur.

1. De eindgebruiker heeft een interactie met een scherm en klikt vervolgens op Volgende.

2. De client post een invoerverzoek naar de API.

3. De API ontvangt het verzoek en opent een transactie- en databaseverbinding. Vervolgens roept de API 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 scherm of lokaal actieknooppunt bereikt. Vervolgens retourneert de engine 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 (per 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 communiceert.

7. Begin bij stap 1 en herhaal het proces.

Met andere woorden, schermen verbreken transacties. Wanneer dit gebeurt, worden alle in behandeling zijnde acties of DML vastgelegd, wordt de voorafgaande transactie gesloten en begint een nieuwe transactie. Houd er rekening mee dat de specifieke ontwerpelementen (welke bewerkingen u groepeert in een bepaalde transactie) aan u zijn.

Hier zijn enkele voorbeelden:

• Wanneer u begint, ziet u een stroom die invoer over meerdere schermen verzamelt en vervolgens verschillende acties binnen één transactie uitvoert.
• De volgende stroom voert elke bewerking in een afzonderlijke transactie uit.
• Stromen kunnen ook Records terugdraaien gebruiken om u in staat te stellen een gehele transactie terug te draaien als één bewerking mislukt binnen een reeks databasebewerkingen. Stel dat u een stroom hebt die records maakt, records bijwerkt en vervolgens extra records maakt (geïllustreerd in de volgende stroom).

Als in dit scenario de eerste twee elementen slagen en de laatste mislukt, worden met de eerste twee DML-bewerkingen nog steeds de juiste records gemaakt en bijgewerkt, maar met de derde niet. Door middel van het element Records terugdraaien kunt u ervoor zorgen dat de gehele transactie wordt teruggedraaid als alle drie bewerkingen collectief moeten plaatsvinden (zoals te zien in de definitieve stroom).

Opmerking: Zie Stromen in transacties en Bulkverwerking van stromen in transacties voor meer informatie.

Uw vermogen om de transactie te controleren vanuit een LWC is gebaseerd op de onderliggende services die het LWC gebruikt om zijn bewerkingen uit te voeren. Als u de basiscomponent Lightning gebruikt, vindt de onderliggende bewerking (het maken of bijwerken van de record) plaats binnen een zelfstandige transactie wanneer het formulier wordt ingediend.

In het algemeen gelden de volgende regels:

• Elke UI-API-aanroep is geïsoleerd binnen een eigen transactie.

• Als u meerdere bewerkingen binnen één transactie moet uitvoeren, verzendt u de invoer naar een technologie aan de serverzijde (bijvoorbeeld een Apex controller of een stroom). Houd er rekening mee dat de reguliere transactieregels voor die technologie nog steeds van toepassing zijn.

Flow, Omnistudio en LWC ondersteunen alle platformevents (voor eventgestuurde architectuur) en API-integraties. Naast aangepaste Apex code hebben Flow en Omnistudio declaratieve ondersteuningsmechanismen die ook kunnen worden geïntegreerd met API’s.

Als u verbinding moet maken met een MuleSoft-API of RPA-bot, gebruikt u MuleSoft Services, omdat dit een Externe service genereert.

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

Gebruik voor alle andere gevallen de voorziening HTTP-aanroep (aangedreven door Externe services) in Flow of de HTTP-actie in Omnistudio.

Omnistudio biedt een rijke set integratiemogelijkheden die externe systemen kunnen aanroepen met behulp van integratieprocedures om gegevens te transformeren via Data Mapper.

Ongeacht of u aangepaste Apex code of een externe service gebruikt voor implementatie, een aanroep is nog steeds een aanroep.

Dit is wat u moet weten.

• De verwerking van een aanroep kan veel tijd in beslag nemen.

• Wanneer een aanroep synchroon wordt uitgevoerd, wordt deze uitgevoerd terwijl een databasetransactie open is.

• Salesforce staat niet toe dat u een databasetransactie openhoudt als u databasebewerkingen in behandeling hebt.

Houd er rekening mee dat de belangrijkste beperking het gevaar is dat gegevens inconsistente toestand achterblijven, wat optreedt wanneer u een bewerking maakt, bijwerkt of verwijdert en vervolgens een aanroep uitvoert binnen dezelfde transactie. Dit patroon is niet toegestaan vanwege de derde overweging hierboven, die bestaat vanwege de eerste twee overwegingen.

In Flow kunt u deze beperking omzeilen door de transactie te verbreken. Vergeet niet dat schermen en lokale acties de browsercontext opnieuw introduceren. Hoewel u schermen en lokale acties kunt gebruiken wanneer u met externe aanroepen werkt, wordt aangeraden om Transactiebeheer in te schakelen in de aanroepbare geavanceerde instellingen. Met Transactiebeheer kunt u de transactie automatisch beëindigen voordat een aanroep wordt gedaan. Selecteer voor het inschakelen van Transactiebeheer “Altijd een nieuwe transactie” in de sectie Geavanceerd van de aangeroepen actie. LWC helpt de impact van aanroepen op de transactie te vereenvoudigen. Met andere woorden, voer uw gegevensbewerkingen uit met behulp van de Lightning Data Service (LDS) en gebruik vervolgens een Apex controller om de externe aanroep te doen. Aangezien de LDS-aanroep is geïsoleerd binnen zijn eigen transactie (los van de Apex aanroep), beschermt dit u tegen resulterende gegevensinconsistentie.

Dynamische formulieren biedt geen ondersteuning voor hergebruik. Elke pagina is gekoppeld aan een specifieke Lightning recordpagina voor een specifiek object. U kunt die Lightning recordpagina echter toewijzen aan meerdere apps, profielen, enzovoort.

Net als bij het schrijven van bibliotheken, hulpprogramma’s en componenten die voor meerdere componenten kunnen worden gebruikt, kunt u ook soortgelijke ontwerppatronen toepassen wanneer u stromen maakt door de kracht van substromen te benutten. Hiervoor slaat u uw stromen op in kleinere, modulaire buckets en roept u ze vervolgens aan vanuit andere stromen met behulp van het element Substroom. Als uw ontwerp hierom vraagt, kunt u een stroom samenstellen die op zichzelf en als substroom nuttig is.

Omnistudio is inherent gebouwd voor modulariteit. Gegevenstoewijzingen, Omniscripts, FlexCards en Integratieprocedures zijn alle onafhankelijk samengesteld, maar kunnen ook onderling verwisselbaar werken. FlexCards kunnen ook 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, profiteert u ook van aanpassingsvermogen en stabiliteit.

Alle technologieën die worden gebruikt om records te maken of bij te werken, moeten voldoen aan validatie op systeemniveau, of het nu gaat om klassieke validatieregels of aangepaste validaties die zijn ingebouwd in een Apex trigger. Ongeacht de technologie die u gebruikt om recordwijzigingen uit te voeren, moet elke wijziging de opslagorder doorlopen. Dit betekent dat recordwijzigingen naast validatieregels ook worden verwerkt door een aantal stromen vóór of na opslaan, vóór of na triggers, escalatieregels, toewijzingsregels, enzovoort.

Opmerking: Als u dit nog niet hebt gedaan, controleert u de Apex volgorde van uitvoering en maakt u er een bladwijzer van.

• Heeft uw formulier aanvullende vereisten naast validatie op systeemniveau?

• Moet u verplichte of alleen-lezen velden dynamisch instellen binnen het formulier?

Doorgaans zijn invoer in een stroomscherm of Omniscript-stap ongebonden, waardoor het formulier zelf niet voldoet aan de validatie op systeemniveau die aan een bepaald object is gekoppeld. De waarden die u gebruikt om records te maken of bij te werken, worden echter verwerkt in de opslagvolgorde, hetgeen inhoudt dat ze door de validatie op systeemniveau van het object gaan.

Opmerking: Niet alle schermstroomcomponenten ondersteunen invoervalidatie.

Net als bij paginalay-outs kunt u met Dynamische formulieren de vereistheid en alleen-lezen status instellen op paginaniveau. Houd er rekening mee dat u instellingen op systeemniveau niet kunt overschrijven.

Stroom biedt flexibiliteit voor het aanpassen van formulierinvoervalidatie. Er worden meerdere controles uitgevoerd op clientniveau (bijvoorbeeld het signaleren van ontbrekende verplichte velden en gegevenstypecontroles, evenals compatibele formules binnen invoervalidatieregels). Als extra beveiligingsniveau wordt invoervalidatie ook geëvalueerd op de server. Wanneer een gebruiker op Volgende klikt, verzendt Stroom de invoer opnieuw naar de server voor validatie. Als er ongeldige invoer wordt geretourneerd, wordt de navigatie geblokkeerd en wordt de juiste fout weergegeven.

De server valideert de invoer door te controleren:

• De instelling voor de vereistheid van de invoer of de ingevoerde waarde compatibel is met het onderliggende gegevenstype.

• De aangepaste validatie van de invoer. U moet een Booleaanse formule-uitdrukking en een foutbericht opgeven om weer te geven wanneer niet aan de formule-uitdrukking wordt voldaan.

• De aangepaste validatie van de onderliggende component. Als u een aangepaste LWC maakt voor een stroom, moet u uw eigen validatiecode toevoegen aan de methode validate().

U kunt ook toegankelijke gebruikerswaarschuwingen bieden via de component Bericht in Schermstromen, maar dit verhindert niet dat een gebruiker naar andere pagina’s navigeert of doorgaat naar de volgende stap in een begeleide stroom. De status Fout binnen de component Bericht kan het best worden gebruikt op speciale foutschermen die via een defectenpad worden geactiveerd wanneer navigatie is uitgeschakeld.

Omnistudio biedt robuuste afhandeling van fouten en validatie via de actie Fout instellen in combinatie met Voorwaardelijke weergaven en de component Berichtenverkeer.

Voor LWC voeren de meeste basiscomponenten hun eigen validaties aan clientzijde uit (zo houdt Lightning record-form zich aan de vereisten op systeemniveau, maar niet aan de vereisten op paginaniveau). Voor uw aangepaste componenten kunt u Build Your Own validatiemechanismen samenstellen.

Onthoud dat velden waarvoor gebruikers gegevens moeten invoeren, moeten worden weergegeven aan het begin van uw formulieren. Valideer gebruikersinvoer aan de clientzijde voordat formulieren worden ingediend (indien mogelijk).

Statische vormen zijn verouderd. Tegenwoordig is de focus verschoven naar het dynamisch bijwerken van formulieren met de juiste eigenschappen en waarden voor een specifieke gebruiker, op een specifiek moment, op een specifieke plaats. Laten we eens beter kijken naar wat haalbaar is via Salesforce-tools voor het samenstellen van formulieren.

• Welke typen interacties of voorwaarden moeten dynamische reacties binnen uw formulier activeren?

• Moet u bewerkingen buiten het scherm (achtergrond) uitvoeren terwijl uw formulier wordt ingevuld?

• Moet u velden instellen als zichtbaar, verplicht, alleen-lezen of uitgeschakeld, of moet u de opmaak wijzigen op basis van formulierinvoer?

Reactieve schermen schakelen schermstroominteractiviteit in. Met reactiviteit kunnen afzonderlijke componenten op een stroomscherm met elkaar communiceren, wat schermstromen krachtiger maakt.

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 binnen het scherm of wanneer een gebruiker op een component Actieknop klikt. U kunt automatisch gestarte stroomresultaten toewijzen aan hetzelfde scherm, waardoor gebruikers niet meer naar een ander scherm hoeven te navigeren.

LWC biedt een volledige reeks wire-adapters die toegang bieden tot Salesforce-gegevens voor het dynamisch invullen van gegevens in formuliercomponenten, waarmee ontwikkelaars records kunnen bijwerken, verwijderen en maken via Apex controllers.

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 behulp van voorzieningen voor de zichtbaarheid van componenten. U kunt velden declaratief weergeven of verbergen op basis van andere waarden in het formulier, of op basis van het gegeven of de gebruiker het formulier op een mobiel apparaat invult.

• Dynamische formulieren bepalen de zichtbaarheid op basis van recordveldwaarden, opzoekvelden en omvang.

• Met Stroom kunt u een zichtbaarheidsregel baseren op andere scherminvoer en andere resources die eerder in de stroom worden ingevuld (bijvoorbeeld formules of waarden uit andere records).

  • Op apparaat gebaseerde regels: Het is misschien niet meteen duidelijk, maar u kunt een formule gebruiken om een bepaald veld te tonen of te 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, vult de gebruiker het formulier in met behulp van de mobiele Salesforce-app.

  • Andere resources evalueren: Handmatige variabelen en formuleverwijzingen worden alleen op de server geëvalueerd. Dit betekent dat de waarde die resource heeft wanneer het scherm voor het eerst wordt weergegeven, de waarde is die deze heeft totdat u naar een ander scherm navigeert. Tijdens navigatie dient de stroomrun-time een verzoek in bij de stroomengine (de server) en retourneert deze de nieuwste handmatige variabele- en formulewaarden. Als u verwacht dat uw zichtbaarheidsregel wordt bijgewerkt terwijl de gebruiker door één scherm gaat (bijvoorbeeld onscherpte), moet u ervoor zorgen dat u alleen verwijst naar waarden uit de andere componenten op het scherm.

• 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 Voorwaardelijke weergave toevoegen voor een invoer.

Voorwaardelijke invoerstatussen

Als u dynamisch andere eigenschappen wilt aansturen (bijvoorbeeld of een veld vereist, uitgeschakeld of alleen-lezen is), zijn er enkele opties. LWC biedt volledige, reactieve controle over uw invoerstatus. Met componenten van Reactieve schermstroom kunt u componentkenmerken dynamisch bepalen (bijvoorbeeld alleen-lezen, uitgeschakeld en vereist) voor standaardcomponenten die deze 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 moet aansturen (bijvoorbeeld of een veld verplicht of alleen-lezen is), gebruikt u LWC op korte termijn, aangezien u volledige controle hebt. Dit geldt met name als u specifieke vereisten hebt voor de manier waarop onblur of onclick moet worden afgehandeld.

Reactieve LWC’s in schermstromen

Als u LWC’s maakt die kunnen reageren op en andere componenten kunnen wijzigen in een schermstroom, raadpleegt u de LWC Best Practices for Screen Flows Guide om ervoor te zorgen dat uw componenten integreren met de run-time engine van de stroom en functioneren zoals bedoeld.

Voor aangepaste events, als sommige van uw invoer (of het gehele formulier) moet communiceren met een ander element op de pagina, is LWC uw enige optie.

• Gebruik voor communicatie binnen dezelfde DOM-structuur de CustomEvent-interface.

• Gebruik voor communicatie binnen het DOM de Lightning Messaging Service.

• Als Lightning Messaging Service niet wordt ondersteund voor uw doelcontainer, gebruikt u de pub/sub-module.

• Zie voor meer gedetailleerde informatie Communiceren met events en Communiceren binnen het DOM in de Lightning Web Components Dev Guide.

• Raadpleeg voor Omnistudio Communiceren met Omniscript vanuit een Lightning webcomponent.

Om de beste gebruikerservaring te bieden, is het belangrijk ervoor te zorgen dat de stijl van uw formulier consistent is met de rest van de app of site waarin het formulier wordt ingebed. Dit kan betekenen dat u standaardsjablonen gebruikt die worden geleverd door Salesforce, of dat u een aangepaste CSS maakt die elke pixel in het ontwerp gebruikt om het uiterlijk te verbeteren.

Beheerders kunnen een beperkte set scherm- en componentstijloverschrijvingen configureren (bijvoorbeeld kleuren, randen en knopweergaven), voor de schermcontainer of voor afzonderlijke componenten. Deze overschrijvingen worden toegepast na thema’s en branding, waardoor samenstellers doelgerichte visuele aanpassingen kunnen aanbrengen zonder dat dit gevolgen heeft voor de rest van de toepassing.

Stylingoverschrijvingen zijn bedoeld voor gelokaliseerde visuele uitzonderingen (bijvoorbeeld het markeren van een bevestigingsscherm of het benadrukken van een specifieke call-to-action (CTA); ze vormen geen volledig stileringssysteem. Ze bieden geen besturing op CSS-niveau en zijn niet ontworpen voor hergebruik binnen schermen of stromen.

Vanuit architecturaal perspectief moet stilering deze voorrangsvolgorde hebben:

1. Thema’s en branding: Lightning Thema’s, Omgevingssamensteller-brandingsets of thema’s voor LWR-sites

2. Stroomstilering overschrijft: Gerichte scherm- of componentaanpassingen

3. Aangepaste componenten (LWC): wanneer pixelperfecte controle of herbruikbare ontwerppatronen vereist zijn

Het gebruik van thema’s en ontwerpsystemen helpt ervoor te zorgen dat stilering consistent, schaalbaar en gemakkelijk te onderhouden blijft.

• Hoe geavanceerd is uw gewenste styling en CSS?

• Hebt u aangepaste, tot op de pixel nauwkeurige stilering of standaardthema’s nodig?

FlexCards is het enige product in deze handleiding waarmee u de stilering en lay-out van de UI die u in de tool maakt, declaratief kunt bepalen (bijvoorbeeld marges en opvulling, typografie, kleuren, enzovoort).

Dynamische formulieren en stromen respecteren declaratieve themavoorzieningen. Als u extra controle nodig hebt (naast wat Salesforce-thema’s, Experience Builder-brandingsets of LWR Experience Cloud-sites ondersteunen), overweeg dan een programmatische oplossing.

Teams die vertrouwd zijn met het werken met CSS, hebben verschillende opties:

• Stromen en LWC’s nemen standaardontwerptokens over.

• Omniscripts en FlexCards omvatten aanpasbare ondersteuning voor ontwerpsystemen via Newport.

• Met LWC kunt u uw eigen componenten schrijven en hun HTML en CSS volledig beheren.

Gebruik indien mogelijk thema’s en ontwerpsystemen om te zorgen voor een consistent uiterlijk van al uw inhoud.

Opmerking: U kunt Lightning componenten inbedden in stromen. Als u de pixelperfecte controle over het uiterlijk van uw formulier nodig hebt, maar ook de andere voordelen van stromen wilt gebruiken (bijvoorbeeld het navigatiemodel), 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.

• Hoe kunt u formulierlay-outs structureren om gebruikerservaringen te optimaliseren?

• Hoe kunt u bestaande gegevens aan gebruikers presenteren op een manier die het voor hen gemakkelijker maakt om nieuwe gegevens in te voeren in uw formulieren?

Dynamische formulieren ondersteunen tweekolomslay-outs die kunnen worden opgesplitst in afzonderlijke secties binnen velden. Deze secties kunnen binnen componenten (bijvoorbeeld tabbladen en accordeons) worden geplaatst om georganiseerde, gebruiksvriendelijke lay-outs te maken.

Stromen kunnen ook worden weergegeven met behulp van de component Sectie. U kunt maximaal vier kolommen en een onbeperkt aantal secties toevoegen aan het stroomscherm. De component Secties is ook responsief voor schermbreedte, waardoor deze ook werkt op kleinere schermen. Het biedt u de mogelijkheid om voorwaardelijke zichtbaarheid toe te passen op de gehele sectie, wat het gemakkelijker maakt om zichtbaarheid in bulk 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 afkomstig van HTML en CSS. De component Lightning-record-vorm respecteert de sectieconfiguratie in de gekoppelde paginalay-out (als een sectie bijvoorbeeld twee kolommen in de paginalay-out heeft, is deze ook twee kolommen in de component).

Als uw formulier toegankelijk moet zijn voor gebruikers in verschillende regio’s of voor gebruikers die verschillende talen spreken, moet u ervoor zorgen dat de tool die u gebruikt voor het samenstellen ervan, voldoet aan uw lokalisatievereisten.

Opmerking: 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 aangepaste velden lokaliseert, houdt Dynamische formulieren zich aan de vertaalde labels. Dynamische formulieren respecteren ook aangepaste labels die zijn toegewezen aan componentlabels en -kenmerken in Lightning Appsamensteller.

Stroom ondersteunt de vertaling van gebruikersgerichte labels voor alle standaard- en aangepaste schermcomponenten via het Vertaalcentrum.

U kunt labels, Help-tekst en foutberichten lokaliseren op deze schermcomponenten:

• Tekst
• Lange-tekstgebied
• Getal
• Valuta
• Selectievakje
• Keuzerondjes
• Keuzelijst
• Keuzelijst met meervoudige selectie
• Groepswachtwoord selectievakje
• Datum
• Datum/tijd

Er is geen ingebouwde vertaalondersteuning voor kant-en-klare acties (bijvoorbeeld E-mail verzenden of Posten naar Chatter), maar er is een oplossing. Als u een aangepast label gebruikt om de vertaalde labels te definiëren, kunt u naar dat aangepaste label verwijzen in de actie of component wanneer u het configureert in Flow Builder. Hiervoor moet u een stroomformule maken die verwijst naar het aangepaste label en vervolgens naar die formule verwijzen op de juiste plaatsen binnen uw stroom.

Omniscripts maken gebruik van aangepaste labels voor vertalingen. Raadpleeg dit Help-document voor meer informatie om ervoor te zorgen dat uw Omniscripts geschikt zijn voor meerdere talen.

Voor LWC nemen bepaalde basiscomponenten 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 de juiste keuze. Declareer het aangepaste label dat u nodig hebt en importeer het vervolgens in uw component vanuit de module @salesforce/label.

Gebruik deze sectie voor het evalueren van beveiliging, kwaliteit en operationele beperkingen vóór implementatie.

Beveiliging is een complex onderwerp en als het gaat om het samenstellen van formulieren, zijn er een aantal overwegingen die misschien niet voor de hand liggen. Op basisniveau moet 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. Daarnaast wilt u mogelijk extra maatregelen nemen om potentieel schadelijke code of URL’s uit rich-text-velden te verwijderen, te voorkomen dat bepaalde gebruikers toegang krijgen tot het formulier of beperkingen op te leggen aan de typen locaties waar beheerders het formulier in de toekomst mogelijk kunnen inbedden.

Zorg ervoor dat u uw beveiligingsvereisten grondig documenteert voordat u een tool kiest. Raadpleeg de Salesforce Well-Architected Security Policy Template voor aanvullende 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 een programma 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 (gebruikers zouden bijvoorbeeld 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 record in kwestie).

Wat gebeurt er 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 System Context om de hoek komt kijken!

Met Systeemcontext kunt u de machtigingen van een gebruiker verhogen voor de duur van de sessie (de gebruiker hoeft bijvoorbeeld geen toegang tot het object Case bij te werken om het formulier voor het bijwerken van uw case te kunnen 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.

Systeemcontext mag alleen worden gebruikt wanneer dit absoluut noodzakelijk is. Wanneer een formulier wordt uitgevoerd in Systeemcontext, omzeilt elke CRUD-bewerking de componenten beveiliging op object- en veldniveau en delen. Systeemcontext heeft ook geen invloed op wie Salesforce als de acteur beschouwt (de naam die u ziet in het veld Laatst gewijzigd door). Voor elke bewerking die uw formulier uitvoert (bijvoorbeeld een case-update), is de acteur de huidige gebruiker (zelfs als het formulier in een andere context wordt uitgevoerd).

Opmerking: 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. U kunt zelf bepalen of de stroom toegang tot alle gegevens moet verlenen of dat deze toegang op recordniveau moet afdwingen.

• Als u een Lightning component inbedt binnen een stroom die wordt uitgevoerd in systeemcontext, overschrijft de stroom niet de context van de component. Als u controles van gebruikerstoegang moet omzeilen, gebruikt u de stroom om die bewerkingen uit te voeren en geeft u de juiste gegevens door aan of uit de Lightning component. Sommige kant-en-klare componenten (bijvoorbeeld Opzoeken) werken niet binnen de systeemcontext.

• Als uw stroom Apex acties aanroept, zijn er andere nuances.

  • Als de Apex klasse is ingesteld op overgenomen delen, wordt deze uitgevoerd in systeemcontext met delen, ongeacht hoe de stroom is ingesteld.

  • Als de klasse geen expliciete verklaring voor delen heeft, wordt deze uitgevoerd in systeemcontext zonder delen, ongeacht de manier waarop de stroom is ingesteld.

  • Als de klasse is ingesteld op met of zonder delen, krijgt deze voorrang op de context van de stroom.

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 als deze niet is geauthenticeerd), slaat u alleen specifieke velden op 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 uit dat object worden geïnspecteerd door de ontwikkelaarstools van de browser. Ondanks uw bedoelingen kunnen velden hierdoor beschikbaar worden voor Experience Cloud-gebruikers. Als u ervoor wilt zorgen dat alleen de juiste velden zichtbaar zijn wanneer Systeemcontext is ingeschakeld, geeft u die specifieke velden op in uw elementen Records ophalen.

Opmerking: 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 via de ontwikkelaarstools van de browser. Wanneer u Omniscript gebruikt, is het belangrijk om bedrijfslogica aan de serverzijde uit te voeren (indien mogelijk) en invoervalidatieregels te implementeren voor alle Apex methoden die zichtbaar zijn via een @InvocableMethod annotatie.

Invoer opschonen

Als u uw organisatie wilt beschermen tegen kwaadwillenden, gebruikt u invoersanering. Stel dat u een invoer hebt voor een openbaar toegankelijk formulier dat kan worden toegewezen aan een rich-textveld binnen uw organisatie. U kunt overwegen om automatisering in te schakelen die HTML verwijdert die schadelijke URL’s kan verbergen.

Het is niet ideaal om opschoning op formulierniveau te implementeren, omdat u een willekeurig aantal bronnen kunt hebben die naar deze velden schrijven. Om dit probleem te helpen bestrijden, maakt u een Fast Field Update Flow (Vóór opslaan) of gebruikt u een bestaande Apex Trigger om alle potentiële HTML te verwijderen of te wijzigen die binnen het formulier kan worden ingevoerd.

• Sta toe dat stromen worden uitgevoerd 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. Maak machtigingensets met beperkte veldtoegang en wijs deze toe aan het Experience Cloud-gastgebruikersprofiel.

• Wanneer u een query uitvoert op records in Systeemcontext Stromen uitvoeren op Experience Cloud-sites, slaat u alleen de velden op die u nodig hebt in het element Records ophalen of Aanroepbare acties.

• Als een stroom verschillende bewerkingen uitvoert—die allemaal geen verhoogde toegang vereisen—gebruikt u Substromen om de bewerkingen te isoleren die binnen Systeemcontext moeten worden uitgevoerd.

• Als u een formulier inbedt binnen een externe webpagina, moet het mogelijk worden toegewezen aan rich-textvelden om potentiële phishing-aanvallen te voorkomen. Hiervoor zuivert u gebruikersinvoer op om HTML te verwijderen met behulp van een Fast Field Update Flow of Apex Trigger.

• Omniscripts, FlexCards en LWC’s worden standaard uitgevoerd in gebruikerscontext.

• LWC’s worden standaard uitgevoerd in gebruikerscontext.

• Stromen worden uitgevoerd in gebruikerscontext, maar u kunt deze overschrijven met behulp van een Apex controller.

• Bewerkingen die worden uitgevoerd binnen de UI-API, worden uitgevoerd in gebruikerscontext.

• Bewerkingen die worden uitgevoerd met een Apex controller zijn afhankelijk van de specifieke klasse. Als u deze bewerkingen in de systeemmodus wilt uitvoeren, stelt u de Apex klasse in op met delen of zonder delen.

Als u wilt bepalen wie toegang heeft tot een formulier, controleert u de container waarin het formulier is ingebed (u kunt Lightning pagina’s bijvoorbeeld toewijzen om beschikbaar te zijn voor bepaalde apps, recordtypen of profielen). Als bepaalde invoer gevoelig is, gebruikt u zichtbaarheidsregels om verder te bepalen wat aan wie wordt weergegeven. Deze voorziening is van toepassing op Dynamische formulieren en schermstromen.

U kunt een stroom beperken tot bepaalde profielen of machtigingensets (vergelijkbaar met Apex klasse of Visualforce pagina’s). Stromen zijn standaard onbeperkt, wat betekent dat elke gebruiker met de gebruikersmachtiging Stromen uitvoeren er toegang toe heeft.

Als u Omnistudio gebruikt, kunt u een Apex klassenmachtigingencontroleur configureren die vereist dat gebruikers expliciete toegang hebben tot de Apex klasse die externe acties beheert vanuit Omniscript, Flexcard, Classic Card of REST API’s.

Opmerking: Machtigingencontroles voor Apex klassen zijn alleen van toepassing op Apex klassen. Het is ook raadzaam om machtigingen op profielniveau in te stellen voor Integratieprocedures en Gegevenstoewijzingen.

• Als u een stroom zichtbaar maakt voor gastgebruikers, moet u alleen gastgebruikersprofieltoegang verlenen tot de stromen die ze absoluut nodig hebben. Het is mogelijk om stromen uitvoeren toe te voegen aan gastgebruikersprofielen, maar dit kan riskant zijn.

• Wees voorzichtig bij het werken met stromen die in systeemcontext werken. U moet deze stromen 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 binnen een gastgebruikerscommunity, met delen is vermeld in de Apex klassedefinitie.

• Wijs voor gastgebruikersprofielen alleen de Apex klassen toe die gastgebruikers mogen aanroepen. Door deze praktijk te volgen, voorkomt u dat gastgebruikers onbedoeld extra bedrijfslogica zien.

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 in JavaScript importeren vanuit de modules met bereik @salesforce/userPermission en @salesforce/customPermission. U kunt Apex ook gebruiken om machtigingen te controleren.

LWC’s zijn alleen beschikbaar op een bepaalde locatie nadat ze zijn toegevoegd als een geldig doel (zo kunt u een component beschikbaar maken op recordpagina’s en niet beschikbaar maken als een balkitem voor hulpprogramma’s).

Zodra een schermstroom is geactiveerd, is deze beschikbaar op alle locaties die schermstromen ondersteunen. Flow Builder ondersteunt meerdere typen stromen die schermen hebben. Het meest prominente type is Schermstroom, maar er zijn nog enkele andere gespecialiseerde typen die zijn beperkt tot specifieke locaties (zo ondersteunt de Field Service Mobile-app alleen Field Service Mobile-stromen). Dit lijkt op Contactaanvraagstromen, die alleen worden ondersteund in Experience Cloud.

Ongeacht het type stroom heeft degene die de stroom maakt, geen controle over waar de stroom is ingebed. Stromen zijn beschikbaar op elke locatie waar dat specifieke stroomtype wordt ondersteund.

Als u Salesforce Industries gebruikt, is er een kleine waarschuwing als het gaat om Omniscript.U kunt geen doel voor een Omniscript opgeven, maar u kunt wel een doel opgeven voor de FlexCards die u wilt inbedden.

Salesforce biedt diverse end-to-end testautomatiseringstools (zie bijvoorbeeld Salesforce UTAM) waarmee u kunt simuleren hoe een gebruiker met uw formulieren omgaat. U kunt tests schrijven voor elke standaard of aangepaste UI, inclusief Lightning pagina’s en schermstromen.

Opmerking: Deze typen tests kunnen de uitvoer voor de methoden die worden uitgevoerd, niet verifiëren. Houd hier rekening mee wanneer u de vereisten voor automatisering van UI-tests configureert.

• Hebt u geautomatiseerde tests voor uw formulieren nodig?

• Welke typen tests wilt u uitvoeren?

• Welk detailniveau is noodzakelijk voor testautomatiseringen?

Vereisten voor UI-testautomatisering overwegen

Eenheidstests bieden fijnmazige automatisering en validatie die is afgestemd op CI/CD-systemen en tools van de industriestandaard, die de bedrijfslogica, JavaScript-besturingselementen en uitvoer van specifieke componenten testen. Als u kiest voor een low-code benadering, kunt u tests niet zelf schrijven. Salesforce test echter alle end-to-end aanbiedingen grondig.

Als de methoden van uw component complex zijn, kunt u ze afzonderlijk van elkaar voorzien door de methoden in speciale JavaScript-bestanden te plaatsen. Hierdoor kunt u ze importeren in een LWC en vervolgens in een Jest-test (bijvoorbeeld { sort } importeren vanuit ‘c/utils’;).

U kunt een oplossing zonder code uit een ISV gebruiken, een aangepaste testautomatiseringsoplossing samenstellen of een open-source testframework (bijvoorbeeld Selenium WebDriver of WebdriverIO) gebruiken voor end-to-end automatisering. Deze oplossingen zijn geldig voor alle Salesforce UI-interacties (bijvoorbeeld een Dynamisch formulier op een Lightning pagina, een schermstroom op een balk voor hulpprogramma’s of een LWC in een stroom voor snelle acties).

Nadat u uw formulier hebt geïmplementeerd naar een productieomgeving, moet u ervoor zorgen dat het effectief wordt gebruikt. Afhankelijk van uw gebruikscase kan dit betekenen dat u het aantal malen dat uw formulier is ingevuld, bijhoudt tot de hoeveelheid tijd die de gemiddelde gebruiker besteedt aan het invullen van het formulier voordat hij of zij zijn of haar gegevens indient. Het is belangrijk om uw traceerbare KPI’s te identificeren voordat u een tool kiest.

• Moet u formuliergebruik bijhouden?

• Welke KPI’s kunnen bepalen of het formulier effectief wordt gebruikt?

Als u het algemene gebruik en de acceptatie van formulieren wilt bijhouden, gebruikt u tools met weinig code. Dynamische formulieren en schermstromen kunnen worden bijgehouden via kant-en-klare aangepaste rapporten. Rapporten over het bijhouden van schermstromen bieden echter extra fijnkorreligheid. Als u LWC-gebruik moet bijhouden, is de kant-en-klare beschikbaarheid afhankelijk van waar u de LWC gebruikt. Als deze voorkomt op een Lightning pagina, zijn alle beschikbare elementen voor het bijhouden van Lightning paginagebruik ook van toepassing op uw LWC. Dit geldt ook voor LWC’s die zijn ingebed in stromen.

Dynamische formulieren kunnen niet kant-en-klaar worden bijgehouden; u kunt het gebruik van de bovenliggende Lightning pagina echter wel bijhouden via Lightning gebruiksobjecten. Gebruik voor het bijhouden van standaard Lightning pagina’s het aangepaste rapport Gebruikers met Lightning Gebruik op paginameetgegevens. Gebruik voor aangepaste Lightning pagina’s het aangepaste rapport Gebruikers met Lightning Gebruik op FlexiPage-meetgegevens.

Stromen kunnen u helpen bij het bijhouden van acceptatie voor specifieke formulieren. Gebruik het voorbeeldstroomrapport: Schermstromen om deze typen vragen te beantwoorden:

• Wat is het voltooiingspercentage voor dit formulier? Is het momenteel goed geadopteerd?

• Hoe lang duurt het voordat gebruikers dit formulier hebben ingevuld?

• Aan welk scherm besteden gebruikers de meeste tijd?

• Hoe vaak navigeren gebruikers naar vorige schermen?

• Hoe vaak doen zich fouten voor?

Als het standaardrapport niet aan uw behoeften voldoet, kunt u het klonen en wijzigingen aanbrengen of Build Your Own Report from scratch gebruiken met behulp van het rapport Schermstromen.

Als u de op een pakket gebaseerde Omniscript-run-time gebruikt, kunt u ook de Omnistudio for Vlocity Tracking Service gebruiken. Deze service houdt alle typen events bij (u kunt bijvoorbeeld de tijd bijhouden die nodig is om de stappen te voltooien in een Omniscript, wat helpt bij het identificeren van procesverbeteringen).

Opmerking: Er is geen kant-en-klare optie voor het bijhouden van een LWC die niet is ingebed in een schermstroom-, Omniscript- of Lightning pagina, maar u kunt een aangepaste oplossing samenstellen met behulp van Apex.

Mogelijk bent u vertrouwd met het gebruik van wijzigingssets of het DevOps Center om uw oplossing te implementeren in testomgevingen of productieomgevingen. Deze implementatieopties bieden volledige ondersteuning voor Dynamische formulieren, stromen en LWC’s. Omnistudio vereist echter een aparte tool, de IDX Workbench.

• Hoe wilt u het formulier implementeren?

• Moet het formulier naar meer dan één Salesforce-organisatie worden gedistribueerd?

Als u een ISV of partner bent die van plan is om uw oplossing in een pakket op te nemen voor distributie op AppExchange, raadpleegt u Dynamische formulieren, stromen en LWC’s. Houd er rekening mee dat Omnistudio geen ondersteuning biedt voor pakketten.

Deze handleiding is bedoeld om u te laten zien welke functionaliteit en aanpassingsniveaus beschikbaar zijn via Dynamische formulieren, schermstromen, Omnistudio en LWC. Hier is een overzicht op hoog niveau.

• Als het gaat om het bouwen van formulieren, is LWC de meest robuuste, aanpasbare optie, maar heeft het de minste vangrails. Daarom is het cruciaal om uw componenten te bouwen met beveiliging en schaalbaarheid in gedachten.

• Dynamische formulieren is de minst flexibele optie, maar biedt veel minder kansen op misstappen.

• Flow en Omnistudio vallen iets in het midden. Ze zijn krachtiger dan Dynamische formulieren, maar ze voldoen niet helemaal aan het LWC-niveau. Ze hebben echter minder vangrails dan Dynamische formulieren en zijn moeilijker te breken dan aangepaste code.

Mogelijk komen meerdere tools overeen met uw behoeften. Als dat het geval is, hangt de beslissing uiteindelijk af van welke tool het beste is voor uw team. Raadpleeg deze Architect Decision Guides voor meer informatie over extra aspecten om rekening mee te houden.

• Wanneer u tools vergelijkt, is het belangrijk om te beoordelen hoeveel expertise uw team heeft met betrekking tot elke tool?
• Hoeveel van uw ontwikkelaars zijn goed thuis in LWC of JavaScript?
• Zijn er ontwikkelaars in uw team die experts zijn in Flow Builder of die interesse hebben getoond in meer informatie?

Hoewel we niet ingaan op specifieke details, volgt hier wat meer informatie over hoe deze specifieke tools zich verhouden tot de beoordelingen die we tot nu toe hebben behandeld.

Leveringsdelegatie

Vergeet niet dat, zelfs als sommige van uw vereisten LWC vereisen, dit niet vereist dat de gehele oplossing wordt samengesteld met behulp van LWC. Het is belangrijk om te bepalen hoe u uw oplossing modulair kunt samenstellen. Hiervoor moet u bepalen welke onderdelen gecodeerde LWC vereisen en welke niet. De onderdelen die geen LWC vereisen, moeten worden samengesteld met behulp van een low-code oplossing.

Als het gaat om Flow en LWC, zijn er verschillende componenten (bijvoorbeeld Reactieve schermcomponenten en Schermstroom) die op hetzelfde scherm met elkaar kunnen synchroniseren om nieuwe tools te ontgrendelen voor architecten, beheerders en ontwikkelaars. Ontwikkelaars kunnen nu doelgerichte, modulaire componenten maken die binnen de hele organisatie kunnen worden hergebruikt, wat de productiviteit van het team helpt verhogen. Hierdoor kunnen ontwikkelaars tijd besparen door een mix van standaard- en aangepaste stroomcomponenten te gebruiken om vormdynamiek te bereiken, waardoor ze meer tijd hebben om zich te richten op het oplossen van nieuwe uitdagingen. Met de introductie van reactieve componenten in Flow is er nog nooit een geschikter moment geweest om Flow en LWC te combineren bij het samenstellen van formulieren.

Langdurig eigendom en onderhoudbaarheid

Als u een formulier met meerdere stappen maakt, begint u met Stroom of een combinatie van Stroom en LWC. Als het team dat het formulier onderhoudt een low-code team is, zorg er dan voor dat de oplossing zo configureerbaar en uitbreidbaar mogelijk is voor uw beoogde doelgroep. Om de stabiliteit en onderhoudbaarheid te verbeteren, is het belangrijk om uw oplossing te organiseren in samenstelbare eenheden, ongeacht het gereedschap dat u kiest.

Overwegingen bij prestaties die betrekking hebben op Dynamische formulieren, Schermstromen, Omnistudio of LWC, zijn gebaseerd op het framework waarin de technologieën zijn ondergebracht. Technologieën die zijn gebaseerd op LWC, presteren doorgaans beter dan technologieën die zijn gebaseerd op Aura. Vanwege diverse kernfuncties die native zijn geïmplementeerd in webengines (in plaats van in JavaScript via frameworkabstraties), biedt de LWC verbeterde prestatievoordelen.

Hoe benutten we deze prestatievoordelen voor onze formuliertechnologieën bij Salesforce? Laten we eens wat beter kijken.

• Dynamische formulieren (geïntegreerd in metagegevens van Lightning’s) is gebaseerd op een LWC-stack, waardoor we verschillende langverwachte voorzieningen kunnen implementeren. Als extra prestatiebonus gebruikt Dynamische formulieren progressieve weergave, wat de laadtijd verbetert voor pagina’s die een groot aantal velden hebben.

• Schermstromen zijn gebaseerd op LWC. De meeste afzonderlijke kant-en-klare componenten zijn nu geconverteerd naar LWC, met uitzondering van de 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. Vergeet niet dat Salesforce alleen LWC-componenten ondersteunt binnen het raamwerk van reactieve componenten in schermstromen. Raadpleeg de Lightning Web Components for Aura Developer Trailhead module voor meer informatie. Als u overweegt om een aangepaste component te maken voor een schermstroom (of een andere container), kiest u LWC!

• Er zijn verschillende versies van Omnistudio beschikbaar. Als u al langer klant bent, gebruikt u mogelijk Angular. We raden alle nieuwe klanten aan om op LWC gebaseerde Omniscripts en FlexCards te gebruiken. We raden bestaande klanten ook aan om Angular te verlaten.

• LWC is gebaseerd op LWC.