Le VP des Ventes exige que toute Opportunity présentant une remise supérieure à 30 % soit approuvée avant de pouvoir progresser. Quelle solution l'administrateur doit-il mettre en place, et quelles en sont les étapes clés de configuration ?

L'administrateur doit créer un Approval Process sur l'objet Opportunity. Les étapes clés sont les suivantes : (1) Définir les critères d'entrée du processus : le champ 'Discount %' doit être supérieur à 30 % ; (2) Désigner le VP des Ventes comme approbateur (via un utilisateur spécifique, un champ de manager ou une file d'attente) ; (3) Configurer les actions d'approbation (par exemple, verrouiller l'enregistrement pendant la révision) et les actions de rejet (notification au commercial, réinitialisation du champ). Pour permettre aux approbateurs de répondre par e-mail, l'administrateur doit activer l'option 'Enable email approval response' dans les Process Automation Settings. Cette configuration est globale et ne se fait pas dans le processus d'approbation lui-même. Il est important de noter que Process Builder et les Workflow Rules sont en cours de retrait : l'Approval Process reste le mécanisme natif recommandé pour ce type de flux de validation hiérarchique.

L'administrateur doit automatiser deux actions : envoyer un e-mail de rappel aux propriétaires d'Opportunities 7 jours avant la date de clôture, et créer automatiquement un Order dès qu'une Opportunity est marquée 'Closed Won'. Quels outils d'automatisation utiliser pour chacune de ces actions, et pourquoi ?

Pour le rappel à 7 jours avant la clôture : l'administrateur doit utiliser un Flow Builder avec un Scheduled Path configuré sur l'objet Opportunity. Le déclencheur est la Close Date, avec un chemin planifié à -7 jours. Une action 'Send Email Alert' est ensuite ajoutée, utilisant un Email Template préalablement créé (obligatoire avant toute Email Alert). Process Builder et Workflow Rules ne doivent pas être utilisés car ils sont en cours de retrait. Pour la création automatique d'un Order lors du closing : l'administrateur doit créer un Record-Triggered Flow sur l'objet Opportunity, déclenché lorsque le champ 'Stage' passe à 'Closed Won' (ou 'Won = TRUE'). Une action 'Create Records' est ajoutée pour instancier automatiquement l'enregistrement Order en reprenant les données de l'Opportunity. Cette approche élimine le délai de 2 jours ouvrés constaté avec le processus manuel. Le Flow Trigger Explorer peut être utilisé pour vérifier l'ordre de déclenchement des Flows existants sur l'objet Opportunity et éviter les conflits.

Les deux équipes commerciales (produits et services) doivent suivre des étapes de vente différentes et collecter des informations distinctes. Comment l'administrateur doit-il configurer Salesforce pour répondre à cette exigence sans créer de confusion pour les utilisateurs ?

L'administrateur doit combiner trois éléments : (1) Deux Sales Processes distincts, chacun définissant les étapes d'Opportunity pertinentes pour l'équipe concernée (les valeurs disponibles dans le Sales Process proviennent du champ picklist 'Stage') ; (2) Deux Page Layouts distincts, chacun incluant uniquement les champs nécessaires à l'équipe correspondante, évitant ainsi les mises en page encombrées ; (3) Deux Record Types sur l'objet Opportunity, chacun associé à un Sales Process et à un Page Layout spécifique, puis assignés aux profils des équipes concernées. Les Record Types contrôlent également les valeurs de picklist disponibles et le Path affiché sur l'enregistrement. Cette architecture garantit que chaque équipe voit uniquement les informations dont elle a besoin, conformément au principe de configuration recommandé dans Salesforce pour gérer des processus métier différents sur un même objet.

L'administrateur doit créer les 15 comptes utilisateurs des nouveaux commerciaux sans les activer immédiatement, car leur prise de poste officielle est dans trois semaines. Quelles sont les deux méthodes disponibles pour atteindre cet objectif, et quelles précautions faut-il prendre ?

Deux méthodes permettent de créer des utilisateurs inactifs dans Salesforce : (1) Via la création manuelle depuis Setup > Users : lors de la création de chaque utilisateur, l'administrateur doit décocher la case 'Generate New Password and Notify User Immediately'. Cela empêche l'envoi d'un e-mail d'activation et laisse le compte inactif. Cette méthode est adaptée pour un faible volume d'utilisateurs mais fastidieuse pour 15 personnes ; (2) Via Data Loader avec un fichier CSV correctement formaté : l'administrateur inclut le champ 'IsActive = false' pour chaque ligne du fichier, ce qui crée les utilisateurs avec un statut inactif. Cette méthode est plus efficace pour un volume de 15 utilisateurs. À noter : Salesforce permet d'ajouter jusqu'à 10 utilisateurs simultanément via la page 'Add Multiple Users', ce qui ne suffit pas pour 15 utilisateurs en une seule opération. Une fois les utilisateurs créés, il faudra veiller à les activer avant l'expiration du lien d'activation (7 jours par défaut) lorsque le moment sera venu, ou procéder à une réinitialisation manuelle du mot de passe.

La direction souhaite renforcer la sécurité des connexions : les utilisateurs doivent être automatiquement déconnectés après 24 heures d'inactivité, et toute connexion depuis une adresse IP hors des plages de confiance définies doit être bloquée ou challengée. Comment l'administrateur doit-il configurer ces deux exigences ?

Pour la gestion du timeout de session : l'administrateur doit accéder aux Session Settings dans Setup et (1) définir le délai d'expiration de session à 24 heures, puis (2) activer l'option 'Force logout on session timeout' pour s'assurer que les utilisateurs inactifs sont effectivement déconnectés à l'expiration. Sans cette option activée, la session expire mais l'utilisateur peut rester connecté. Pour la gestion des restrictions IP : l'administrateur dispose de deux mécanismes complémentaires. Les Trusted IP Ranges (Network Access) s'appliquent à l'ensemble de l'organisation : si un utilisateur se connecte depuis une IP dans cette plage, aucun challenge n'est envoyé. Si l'IP est hors de cette plage, l'utilisateur reçoit un défi de vérification (email ou SMS) mais n'est pas bloqué. Les restrictions IP au niveau du profil sont plus strictes : si une IP se trouve hors de la plage définie dans le profil, la connexion est directement refusée, même si l'IP est dans les Trusted IP Ranges de l'organisation. Pour bloquer les connexions suspectes depuis l'étranger, l'administrateur devra configurer des restrictions IP au niveau des profils concernés.

L'administrateur doit accorder des permissions supplémentaires à Andy (suppression de Candidatures) et à quatre utilisateurs marketing (modification des Accounts), sans créer de nouveaux profils. Quelle approche recommandez-vous et pourquoi est-elle préférable à la création de profils personnalisés ?

L'administrateur doit utiliser des Permission Sets dans les deux cas, car ils permettent d'étendre les accès fonctionnels d'utilisateurs spécifiques sans modifier leur profil ni créer de nouveaux profils. Pour Andy : créer un Permission Set incluant la permission de suppression sur l'objet Candidature (objet personnalisé), puis l'assigner uniquement à Andy. Ses collègues du profil 'Recruitment Team' conservent leurs accès actuels sans être impactés. Pour les quatre utilisateurs marketing : créer un Permission Set accordant l'accès en modification sur l'objet Account, puis l'assigner aux quatre utilisateurs concernés. Les autres utilisateurs marketing conservent leur accès en lecture via leur profil. Si plusieurs Permission Sets doivent être assignés à un même groupe d'utilisateurs (par exemple des Super Utilisateurs nécessitant 'Export Reports', 'Delete Public List Views' et 'Delete Accounts'), l'administrateur devra créer un Permission Set Group regroupant ces Permission Sets existants, puis assigner le groupe à chaque Super Utilisateur en une seule opération. Cette approche est plus maintenable et évite la prolifération de profils, conformément à la bonne pratique Salesforce qui recommande de minimiser le nombre de profils personnalisés.

TechAssist reçoit un volume croissant de spam via son formulaire Web-to-Case, et les clients légitimes ne reçoivent aucune confirmation de réception de leur demande. Quelles sont les deux fonctionnalités Salesforce à configurer pour résoudre ces deux problèmes simultanément ?

Pour lutter contre le spam sur le formulaire Web-to-Case : l'administrateur doit activer l'option 'Require reCAPTCHA Verification' dans la configuration Web-to-Case. Cette option ajoute un widget reCAPTCHA au formulaire, obligeant les clients à cocher une case avec succès avant de pouvoir soumettre leur demande. Cela filtre efficacement les robots automatisés responsables du spam, sans friction excessive pour les utilisateurs humains. Pour l'envoi d'une confirmation automatique aux clients : l'administrateur doit configurer des Auto-Response Rules sur l'objet Case. Ces règles permettent d'envoyer automatiquement un e-mail de confirmation dès qu'un Case est créé via Web-to-Case ou Email-to-Case. Avant de créer une Auto-Response Rule, l'administrateur doit s'assurer qu'un Email Template est préalablement configuré, car les Email Alerts (et par extension les réponses automatiques) nécessitent un template existant définissant l'objet et le corps du message envoyé au client. Les deux configurations sont indépendantes et complémentaires : le reCAPTCHA réduit le bruit entrant, et l'Auto-Response Rule améliore l'expérience client légitime.

Les agents perdent toutes les données collectées dans un Screen Flow lorsqu'un client doit rappeler en cours d'entretien. Comment l'administrateur peut-il résoudre ce problème, et quelle fonctionnalité complémentaire peut être utilisée pour guider les agents lors des appels de support ?

Pour le problème de perte de données lors d'un rappel : l'administrateur doit configurer le Screen Flow pour permettre sa mise en pause. En activant la fonctionnalité de pause dans le Flow, un bouton 'Pause' apparaît sur chaque écran du Flow pour lequel cette option est activée. Lorsqu'un agent met le Flow en pause, toutes les données déjà saisies sont sauvegardées dans un 'Paused Flow Interview'. Lors du rappel du client, l'agent peut reprendre le Flow exactement là où il s'était arrêté, sans perdre aucune information collectée précédemment. Pour guider les agents lors de la collecte d'informations : l'administrateur doit utiliser un Screen Flow. Les Screen Flows permettent de définir précisément les champs à renseigner, leur ordre d'affichage, et d'inclure des instructions contextuelles (texte enrichi, questions à poser au client, procédures à suivre). Cette solution est plus efficace qu'un simple composant de texte enrichi sur la page de mise en page, car elle guide l'agent pas à pas de manière interactive et structurée, réduisant les erreurs de collecte et le temps de traitement par Case.

La responsable support souhaite que les Cases soient automatiquement assignés au bon agent selon le type de compte, et que les Cases complexes impliquant plusieurs contacts puissent être organisés. Quelles fonctionnalités Salesforce permettent de répondre à ces deux besoins ?

Pour l'attribution automatique des Cases : l'administrateur doit configurer des Case Assignment Rules. Ces règles permettent de définir des critères d'attribution (par exemple, le type de compte = 'Client', 'Prospect' ou 'Partenaire') et d'associer chaque critère à un utilisateur spécifique ou à une file d'attente (Queue). Salesforce évalue les entrées de règle dans l'ordre défini et attribue le Case à la première entrée dont les critères correspondent. Si un Case correspond à plusieurs entrées, c'est toujours la première entrée correspondante (selon l'ordre de traitement) qui détermine l'attribution. Il est donc essentiel de définir correctement l'ordre des entrées de règle. Pour la gestion des Cases complexes impliquant plusieurs contacts : l'administrateur dispose de deux fonctionnalités complémentaires. Les Contact Roles permettent d'associer plusieurs contacts à un Case et de définir le rôle de chacun (décisionnaire, utilisateur final, etc.), facilitant l'identification de la bonne personne à contacter à chaque étape. Les Case Hierarchies permettent de relier des Cases entre eux via le champ 'Parent Case', créant une relation parent-enfant utile pour regrouper des Cases liés à un même incident complexe ou multi-étapes.

L'équipe IT doit importer 42 000 Leads et 3 200 enregistrements d'objets personnalisés. Quel outil d'import utiliser pour chacun de ces deux besoins, et quelles en sont les limites techniques à connaître ?

Pour les 42 000 Leads : le Data Import Wizard ne peut pas être utilisé car il est limité à 50 000 enregistrements maximum — bien que le volume soit sous ce seuil, cette limitation est un point de vigilance. Cependant, le Data Import Wizard supporte bien l'objet Lead et inclut une fonctionnalité de correspondance automatique des champs, ce qui simplifie le mapping. Pour ce volume (42 000), les deux outils sont techniquement viables, mais le Data Loader est préférable pour un usage récurrent ou automatisé. Pour les 3 200 enregistrements d'objets personnalisés : le Data Import Wizard supporte également les objets personnalisés et reste adapté pour ce volume inférieur à 50 000 enregistrements. Il est accessible directement depuis l'interface Salesforce sans installation préalable, ce qui le rend plus simple à utiliser pour des opérations ponctuelles. Le Data Loader, en revanche, peut importer jusqu'à 5 000 000 d'enregistrements et est indispensable pour les volumes importants, les objets non supportés par le Wizard, ou les opérations nécessitant une automatisation via ligne de commande. À noter : les deux outils supportent les objets personnalisés et la correspondance automatique des champs.

Lors de la migration, plusieurs champs doivent changer de type : passage d'un champ Texte vers un champ Numérique, et d'une Picklist simple vers une Picklist multi-sélection. L'équipe juridique demande également que le champ 'Numéro de contrat' soit obligatoire et unique. Quels risques l'administrateur doit-il anticiper, et comment configurer l'exigence juridique ?

Concernant les risques de perte de données lors du changement de type de champ : le passage d'un champ Texte vers un champ Numérique entraîne une perte de données, car Salesforce ne peut pas garantir la conversion de toutes les valeurs textuelles en valeurs numériques valides. De même, toute conversion vers un champ Number depuis n'importe quel autre type est identifiée comme un scénario à risque de perte de données. L'administrateur doit donc exporter et sauvegarder les données existantes avant d'effectuer ces conversions, puis vérifier la qualité des données post-migration. À noter que le passage d'une Multi-select Picklist vers un autre type entraîne également une perte de données — mais ici c'est l'inverse (passage depuis une Picklist simple vers une Multi-select Picklist), ce qui ne présente pas le même risque. Pour l'exigence juridique sur le champ 'Numéro de contrat' : l'administrateur doit configurer une Validation Rule sur l'objet Contract pour garantir l'unicité (en vérifiant qu'aucun autre enregistrement ne possède la même valeur via une formule VLOOKUP). Le caractère obligatoire peut être défini directement dans les propriétés du champ sur le Page Layout (champ marqué comme 'Required') ou via une Validation Rule déclenchée lors de l'enregistrement si aucune valeur n'est renseignée. Les Validation Rules se déclenchent lors de la sauvegarde d'un enregistrement et vérifient que les données respectent les règles définies avant de permettre l'enregistrement.

La direction souhaite une sauvegarde hebdomadaire automatique des données Salesforce, et 12 managers doivent chacun accéder à un tableau de bord affichant uniquement les données de leur périmètre. Comment l'administrateur doit-il configurer ces deux exigences de manière optimale ?

Pour la sauvegarde hebdomadaire : l'administrateur doit utiliser le Data Export Service disponible dans Setup. Cette fonctionnalité native permet de planifier une exportation automatique des données Salesforce selon une fréquence hebdomadaire. Les fichiers exportés au format CSV contiennent l'ensemble des données de l'organisation et peuvent être stockés comme sauvegarde externe. C'est la solution recommandée pour répondre à une exigence de backup périodique sans développement custom. Pour les tableaux de bord personnalisés par manager : la solution optimale est de configurer des Dynamic Dashboards. Grâce aux Dynamic Dashboards, l'administrateur peut créer un seul Dashboard au lieu de 12 tableaux de bord distincts. Chaque manager qui consulte le Dashboard voit automatiquement uniquement les données auxquelles il a accès selon ses paramètres de sécurité et de partage (rôle, OWD, règles de partage). La configuration se fait en modifiant les propriétés du Dashboard pour définir que les données s'affichent selon les droits de l'utilisateur connecté ('Run as logged-in user'). Cette approche est bien plus maintenable que de créer et maintenir 12 tableaux de bord individuels, et garantit que chaque manager respecte les règles de visibilité des données définies dans l'organisation.

NovaTech génère des Leads depuis trois sources nécessitant chacune un processus de qualification différent. Comment l'administrateur doit-il configurer Salesforce pour gérer ces trois processus distincts, et quels éléments sont nécessaires à cette configuration ?

Pour gérer trois processus de qualification distincts selon la source de Lead, l'administrateur doit combiner trois éléments : (1) Créer trois Lead Processes distincts : chaque Lead Process définit les valeurs disponibles du champ picklist 'Lead Status' pour ce processus. Les valeurs sélectionnées dans un Lead Process déterminent les étapes de qualification disponibles pour les Leads de ce type. (2) Créer trois Page Layouts adaptés : chaque mise en page inclut les champs spécifiques à collecter pour la source correspondante (par exemple, des champs différents pour un Lead web versus un Lead télémarketing). (3) Créer trois Record Types sur l'objet Lead : chaque Record Type est associé à un Lead Process et à un Page Layout spécifique, puis assigné aux profils des utilisateurs concernés. Lors de la création d'un Lead, le Record Type approprié est sélectionné (manuellement ou automatiquement via un Flow), ce qui détermine automatiquement les étapes disponibles et la mise en page affichée. Cette architecture garantit que chaque équipe commerciale suit le processus de qualification adapté à la source du Lead, sans mélanger les étapes et les informations entre les différentes origines.

L'équipe finance souhaite un champ picklist 'Catégorie budgétaire' avec des valeurs identiques sur plusieurs objets (Opportunity, Account, Contact et objets personnalisés). En parallèle, le bureau français demande à travailler en français. Quelles fonctionnalités Salesforce permettent de répondre à ces deux besoins ?

Pour le champ picklist partagé entre plusieurs objets : l'administrateur doit créer un Global Value Set (ensemble de valeurs global). Un Global Value Set permet de définir un ensemble centralisé de valeurs picklist réutilisables sur plusieurs objets et champs personnalisés. Lors de la création d'un champ picklist personnalisé sur chaque objet (Opportunity, Account, Contact, objets personnalisés), l'administrateur sélectionne 'Use Global Value Set' et choisit le Global Value Set 'Catégorie budgétaire'. Par défaut, tout champ picklist utilisant ce Global Value Set est automatiquement limité aux valeurs définies dans celui-ci, garantissant la cohérence entre tous les objets. Si une valeur est modifiée dans le Global Value Set, elle est automatiquement répercutée sur tous les champs qui l'utilisent. Pour la langue du bureau français : l'administrateur dispose de deux approches complémentaires. La langue par défaut de l'organisation est définie dans Company Information — elle s'applique à tous les utilisateurs sauf configuration individuelle. L'administrateur peut définir le français comme langue par défaut lors de la création ou modification des enregistrements utilisateurs des collaborateurs français. Les utilisateurs peuvent également modifier leur langue préférée eux-mêmes via leurs paramètres personnels (My Settings). Il est recommandé de configurer la langue au niveau de l'utilisateur pour les bureaux étrangers afin de ne pas modifier la langue par défaut de l'ensemble de l'organisation.

Lors de la conversion des Leads, les commerciaux doivent savoir qu'une Opportunity n'est pas obligatoire et comprendre les objets créés automatiquement. Par ailleurs, certains commerciaux terrain travaillent dans des zones sans connexion internet. Comment l'administrateur doit-il accompagner ces deux situations ?

Pour la conversion des Leads : lors de la conversion d'un Lead qualifié dans Salesforce, trois objets sont impliqués : un Account, un Contact sont créés automatiquement, et une Opportunity est créée de manière optionnelle. Le commercial peut décocher la case de création d'Opportunity lors du processus de conversion si le Lead ne justifie pas encore une opportunité commerciale. Dans le scénario de NovaTech où seulement 65 % des conversions génèrent une Opportunity, il est important de former les commerciaux sur cette option. L'administrateur peut utiliser les fonctionnalités Path et Rich Text Component sur la page Opportunity pour guider les commerciaux sur le processus de conversion, avec des instructions contextuelles à chaque étape. Pour les commerciaux terrain sans connexion internet : l'administrateur doit configurer l'application mobile Salesforce pour le mode hors connexion. Deux actions sont possibles : (1) Activer l'option 'Enable caching in Salesforce for Android and iOS' dans les paramètres Mobile, qui permet aux données d'être mises en cache localement sur l'appareil pour consultation hors connexion ; (2) Configurer le Mobile Offline (si disponible dans la licence) pour permettre également la modification des données sans connexion. Ces deux fonctionnalités permettent aux commerciaux terrain de continuer à consulter et mettre à jour les enregistrements clients même dans les zones à faible connectivité, avec synchronisation automatique au retour en ligne.