Donnez une mission claire à l’assistant public
Un assistant de site web peut expliquer les informations produit approuvées, orienter les visiteurs vers des ressources et recueillir une demande via une action configurée. Il ne doit pas révéler de données privées parce qu’une personne fournit une adresse e-mail, un numéro de requête ou un récit qui semble familier.
Salesforce applique des restrictions particulières aux accès des utilisateurs invités. Toute information ou action publique nécessite une conception délibérée pour cette identité partagée ; un visiteur n’est pas automatiquement un utilisateur Salesforce authentifié. Les recommandations de Salesforce sur la sécurité des invités constituent un point de départ utile. [1]
- Identifier la question
- Établir l’identité de l’utilisateur
- Vérifier les accès autorisés
- Répondre ou passer le relais
Une expérience connectée a un point de départ différent
Un portail authentifié peut associer l’interaction à un utilisateur connu. L’implémentation doit toujours déterminer quels enregistrements, champs et actions conviennent à cette identité. Se connecter ne signifie pas que l’utilisateur peut consulter toutes les requêtes de l’entreprise ou tous les documents joints à un compte.
Conservez les tâches sensibles liées aux comptes dans une expérience dotée des contrôles d’identité et d’autorisation appropriés. Si ces contrôles sont indisponibles, expliquez la limite et proposez un relais humain pris en charge.
Exemple concret : « Où en est ma demande ? »
| Contexte du visiteur | Exemple de conception de réponse |
|---|---|
| Site web public | Expliquer le processus général et proposer une connexion ou un moyen de contact. Ne pas révéler un enregistrement à partir d’un identifiant fourni. |
| Portail client authentifié | Récupérer le statut autorisé de la demande et l’expliquer dans le périmètre configuré. |
| Collaborateur interne du service | Utiliser les accès et outils applicables au collègue pour la tâche de service autorisée. |
L’assistant public peut être utile sans divulguer de statut : il peut expliquer où trouver le numéro de référence ou comment joindre l’équipe concernée. Être utile n’exige pas de deviner l’identité du visiteur.
Testez la distinction au lieu de la supposer
- Essayez un identifiant d’enregistrement connu avec une personne qui ne devrait pas y accéder.
- Vérifiez ce qui se passe lorsque l’enregistrement demandé appartient à un autre client.
- Examinez si une action échouée est décrite fidèlement.
- Vérifiez le relais lorsque l’authentification expire ou que les informations sont indisponibles.
Utilisez des enregistrements synthétiques approuvés ou un environnement de test adapté pour ces vérifications. Une démonstration réussie par un administrateur ne remplace pas un test en tant qu’invité ou utilisateur ordinaire du portail.
La place de REDA AI
REDA AI propose des expériences de site web et de portail, configurées autour du travail prévu. Leurs accès et leur comportement d’action dépendent du canal ; aucune ne doit être décrite comme héritant universellement des mêmes autorisations exactes que toutes les autres interfaces.
La page Plateforme décrit les expériences, tandis que Gouvernance et confiance en explique les distinctions. Partez de la question à laquelle votre client a besoin d’une réponse, puis sélectionnez le canal capable d’y répondre convenablement.
Sources
- Salesforce Developers — Give guest users access to read records. Consulté le 22 septembre 2026.