Best practices en overwegingen bij het gebruik van een standaardeigenaar voor gastrecords

Algemene best practices en overwegingen

• Iedere actieve gebruiker in een organisatie (uitgezonderd gastgebruikers) kan worden toegewezen als standaardeigenaar van records die door gastgebruikers zijn gemaakt. Alleen gebruikers die ten minste leestoegang tot de records hebben, hebben er toegang toe. Zorg dat de gebruiker die als standaardeigenaar wordt ingesteld, ten minste leestoegang heeft voor de records die door gastgebruikers worden gemaakt.
• Hoewel het nieuwe veld voor de standaardgastgebruiker handig is voor het toewijzen van een recordeigenaar aan records die door gastgebruikers worden gemaakt, wordt het niet als best practice beschouwd om het veld als enige manier te gebruiken om gebruikers toe te wijzen. Stel toewijzingsregels, processen of triggers in om records op de juiste manier toe te wijzen aan verschillende gebruikers of wachtrijen op basis van een object of criteria.
• Zorg dat meerdere personen worden toegewezen als eigenaar van records die door gastgebruikers worden gemaakt. Als maar één persoon eigenaar is van alle records die door gasten worden gemaakt, leidt dit tot prestatieproblemen en ontstaan er fouten als de gebruiker niet meer actief is in de organisatie.
• Probeer wanneer mogelijk wachtrijen te maken en deze toe te wijzen als eigenaar van records die door gastgebruikers worden gemaakt.
• In Experience Cloud-sites kunt u een standaardeigenaar instellen voor records die zijn gemaakt door gastgebruikers.
• Alles kant-en-klaar aanvinken
• Wijs records in uw organisatie die eigendom zijn van de gastgebruiker opnieuw toe. Gebruik Data Loader om bestaande records die het eigendom zijn van gastgebruikers, te migreren naar een nieuw toegewezen gebruiker in de organisatie.
• Gebruik geen toekomstige Apex-methoden om ContentVersion in te voegen voor gastgebruikers.

Het veld OwnerID versus CreatedByID

• Bestaande voorwaarden in regels en processen (zoals toewijzingsregels, processen, op criteria gebaseerde regels voor delen, stromen en lijstweergaven) die zijn gebaseerd op een OwnerId die gelijk is aan de gastgebruikers-ID, moeten worden bijgewerkt naar CreatedByID. Verwijder alle regels en processen met de gastgebruikers-ID als eigenaar.
• Controleer de interne processen en ga na of werknemers en teams nog toegang hebben tot gastgebruikersrecords.

Apex zonder delen

Hoewel Apex kan worden gebruikt zonder delen, moet u dit zo min mogelijk en met de grootst mogelijke zorg doen.

• Alle Apex-code waarmee een record wordt gemaakt en bijgewerkt (in één transactie) als gast, moet worden uitgevoerd zonder delen, oftewel in de systeemmodus. In deze gevallen, wanneer Apex-code wordt uitgevoerd zonder delen, mag de gastgebruiker alleen records bijwerken die hij of zij net heeft gemaakt, en verder geen enkele andere record in Salesforce.
  

  Opmerking Zie Aangepaste component maken voor gastgebruikersstromen voor een voorbeeld van een componentcode voor stromen die een Apex-klasse gebruiken zonder delen.
• U kunt een stroom met meerdere stappen instellen voor gastgebruikers die een record maken en de record vervolgens bijwerken. Als u de gastgebruiker wilt toestaan de stroom uit te voeren, slaat u de stroom op met de optie Systeemcontext zonder delen—Toegang tot alle gegevens.
• Voor aangepaste implementaties waarbij een record wordt gemaakt die later wordt weergegeven of bijgewerkt, moet gebruik worden gemaakt van een versleutelde sleutel om de record te identificeren en er toegang toe te verkrijgen (gewoonlijk een versleutelde record-ID), Apex zonder delen, en extra controles in de Apex-klasse (voor het opeenvolgende VIEW- of UPDATE-proces) om de zichtbaarheid van de record te beperken. Beperk het bereik van de versleuteling en beperk de velden die kunnen worden bijgewerkt, zodat alleen specifieke gebruikscases worden bijgewerkt. Controleer altijd of de record is gemaakt door de gastgebruiker.

Andere werking na maken van records

• Als in uw implementatie geen wijzigingen zijn aangebracht in de standaardprocedure voor het maken van records, zien gastgebruikers die een record maken, een "toast"-bericht en gaan ze terug naar de pagina die actief was vóór het maken van de record. Als gastgebruikers iets anders te zien moeten krijgen, kunt u stromen gebruiken in de systeemmodus om ze na het maken van een record om te leiden naar een ander aangepast scherm.
• In uw aangepaste implementatie heeft een gastgebruiker eventueel de mogelijkheid een record te maken waarna de gastgebruiker automatisch de recorddetailpagina ziet van de record die net is gemaakt. De gastgebruiker verliest echter de toegang tot de net gemaakte record omdat de recordeigenaar is toegewezen aan een andere gebruiker in de organisatie. Overweeg in dit geval om de implementatie te wijzigen zodat de gastgebruiker naar een ander deel van de site gaat na het maken van een record.
• Gastgebruikers hebben mogelijk de optie om een nieuw gemaakte record te koppelen aan een bovenliggende record via een opzoekopdracht (bijvoorbeeld een contactpersoon maken en die aan een account koppelen). Als gastgebruikers een nieuwe bovenliggende record maken via een opzoekopdracht, zien ze een fout in de organisatie (omdat de gastgebruiker bij het maken de toegang tot de bovenliggende record verliest). Als u foutberichten wilt vermijden, kunt u het volgende doen:
  • Zorg dat uw organisatie een bovenliggende record heeft gedeeld met gastgebruikers via een regel voor delen, zodat de nieuw gemaakte record hieraan kan worden gekoppeld. De bovenliggende record mag geen gevoelige gegevens bevatten.
  • Of schakel de toegang tot objectmachtigingen uit voor gastgebruikers.