Résumé

  • La suppression d'un champ personnalisé retire ses attributs d'unicité et de saisie obligatoire. Leur rétablissement fait partie du travail après restauration.
  • Une formule restaurée reste désactivée jusqu'à sa modification et son enregistrement. Les mises en page modifiées et les dépendances retirées demandent également une reprise.
  • La récupération reste possible jusqu'à l'effacement définitif ou l'expiration de quinze jours, au premier de ces termes. Une opération destinée à libérer des champs peut fermer cette fenêtre plus tôt.

Une référence de commande peut revenir dans Salesforce sans retrouver ce qui la rendait unique. La colonne est là, les anciennes valeurs aussi. Mais si l'entreprise comptait sur l'attribut d'unicité pour refuser un numéro déjà utilisé, il reste à rétablir cet attribut. Le ticket de restauration peut être vert avant que le prochain doublon rencontre un feu rouge.

Dans Salesforce, le champ et cette promesse ne reviennent pas nécessairement ensemble. Le guide de restauration manuelle des attributs l'indique sans détour : supprimer un champ personnalisé retire automatiquement ses attributs d'unicité et de saisie obligatoire. Après l'avoir rétabli, il faut remettre ceux qui restent nécessaires.

Le logiciel rend donc une partie du travail. L'entreprise doit savoir laquelle il lui laisse.

La bonne question est parfois un refus

Prenons une situation hypothétique : une équipe retrouve un champ de référence après l'avoir supprimé, puis reprend la saisie. Si elle comptait sur l'attribut d'unicité de ce champ pour empêcher les doublons, cette protection attend son rétablissement. D'autres validations peuvent exister ; il faut vérifier ce que faisait précisément l'attribut retiré.

Une capture montrant les anciennes références prouve leur présence. Pour vérifier la règle, il faut observer le rejet d'une valeur que cette règle interdisait. Même logique pour un champ obligatoire : retrouver son contenu d'hier ne prouve pas que le système exigera une valeur demain.

Cette différence donne un rôle à l'équipe métier. L'administrateur connaît la procédure de restauration. La personne qui rapproche les commandes sait pourquoi le numéro devait être unique. Le responsable d'un processus sait quelle information manquante bloque le travail suivant. Une remise en service qui ne réunit pas ces connaissances peut réussir son opération technique et transmettre sa facture au service d'après.

Le travail déplacé n'aura pas forcément le nom de l'incident initial. Il apparaîtra comme une recherche de doublons, une reprise de saisie, une explication demandée sur un rapport. Une clôture rapide du ticket peut ainsi cohabiter avec des heures de correction ailleurs. Le tableau de bord de l'un sera vert ; le planning de l'autre sera plein.

Les calculs aussi ont besoin de revenir travailler

La gestion des champs supprimés décrit un autre retour incomplet : les champs de formule sont restaurés dans un état désactivé. Ils affichent #Error! jusqu'à ce qu'on les modifie et les enregistre. L'enregistrement déclenche une vérification syntaxique ; les erreurs éventuelles doivent être corrigées.

La formule peut donc être présente sans produire les nouveaux résultats attendus. Pour une équipe qui vit de ces résultats, le nombre de champs récupérés est un indicateur assez pauvre de sa capacité à reprendre le travail.

Le nom technique peut également avoir changé. À la suppression, Salesforce ajoute _del au nom développeur, sauf si un champ supprimé possède déjà ce nom. Le suffixe reste après restauration. Un libellé familier sur une page ne dispense pas de rapprocher le nom développeur de la configuration qui l'utilise.

La recherche a son propre retard : le champ rétabli et ses données ne réapparaissent pas immédiatement dans les résultats. Il peut s'écouler un court délai. Recherche, calcul et validation doivent donc être vérifiés pour ce qu'ils montrent effectivement, sans demander à un seul écran de certifier toute la reprise.

Le guide des attributs ajoute une dimension souvent oubliée : ce qui a changé pendant l'absence. Une mise en page modifiée durant la suppression doit retrouver le champ manuellement. Si rapports et mises en page n'ont pas été modifiés, le champ restauré y reste. Les dépendances retirées doivent être redéfinies. Le retour d'une relation à une relation maître-détail suppose de renseigner les données nécessaires dans les enregistrements concernés.

La restauration rencontre ainsi un environnement qui a pu continuer à bouger. Retrouver la pièce n'assure pas que toutes les attaches sont encore à leur place.

La liste des usages a ses angles morts

Avant la suppression, « Where is this used? » permet de chercher les références au champ : formules, mises en page, Apex, règles de validation actives et rapports. Le produit fournit une liste ; l'administrateur doit en connaître les frontières.

Certains usages de rapports à travers une relation de clé étrangère n'y figurent pas. Les rapports inaccessibles à l'utilisateur et les rapports joints échappent aussi à cette recherche. Dans une organisation abonnée, les références déjà présentes dans un package géré sont absentes ; celles créées localement après installation peuvent apparaître. Le résultat est limité aux 2 000 premières entrées, triées par type de référence. Pour retrouver le reste, il faut compléter cet inventaire avec les propriétaires des processus concernés.

La procédure de suppression possède ses propres freins : les références d'un autre champ, d'une mise à jour de champ ou d'Apex empêchent la suppression. Un traitement en arrière-plan qui actualise le champ peut également bloquer l'opération. Ces contrôles et la liste des usages ont des fonctions différentes. Le premier négocie avec le produit ; la seconde aide à retrouver les personnes et les configurations dont dépendra la reprise.

Effacer pour faire de la place : le quota a son calendrier

Deux responsables peuvent alors se disputer le même champ supprimé. Celui du nouveau projet attend une place disponible ; celui du processus précédent veut conserver une marche arrière. Jusqu'à la fin de la suppression définitive, le champ occupe encore le quota des champs personnalisés et celui de son type. Le garder récupérable a donc un coût immédiat pour le projet entrant.

La récupération des données et du champ s'arrête à la suppression définitive par l'organisation ou au terme de quinze jours, selon le premier événement. Accélérer l'effacement échange cette possibilité de retour contre une place future. Future, car la purge envoie les champs prêts à être effacés dans un traitement de suppression définitive. Lancer ce traitement et le terminer sont deux états distincts. Sa durée dépend de la charge du système ; les tâches en arrière-plan permettent de suivre son avancement.

L'opération peut donc produire un intervalle assez ingrat : le retour n'est plus disponible, la nouvelle place n'est pas encore utilisable. Le calendrier du projet doit distinguer l'autorisation d'effacer, la fin du traitement et la création effective du champ attendu. Trois lignes valent mieux qu'une promesse de place immédiate.

Le dernier nettoyage dépasse parfois l'objet qui se plaint

Salesforce publie un cas d'assistance pour les erreurs persistantes après suppression définitive. Pour ces erreurs d'accès ou de colonnes disponibles à la création de champs, le support demande l'identifiant de l'organisation, la précision production ou environnement de test, puis l'autorisation d'une suppression physique. Son périmètre mérite une lecture avant signature : cette suppression physique des champs personnalisés ne peut pas être limitée à un objet. Elle porte sur l'ensemble de l'organisation.

Le responsable qui manque d'une place sur son objet ne détient donc pas, à lui seul, toutes les conséquences de cette autorisation. Il faut identifier les champs concernés ailleurs et les possibilités de récupération auxquelles leurs propriétaires renoncent. C'est la taille du nettoyage décrit par le support, et non celle du formulaire qui affiche l'erreur, qui détermine qui doit décider.

Pour un champ restauré, la réception peut rester beaucoup plus précise. Dans notre exemple hypothétique de référence de commande, une nouvelle référence valide doit être acceptée ; une référence déjà utilisée doit être refusée si l'unicité est requise ; une valeur vide doit être refusée si la saisie est obligatoire. Si le processus dépend d'une formule, son résultat attendu doit aussi être obtenu. Les définitions sauvegardées et les usages réels du champ fixent ces attentes.

La capture d'écran montre que les anciennes commandes ont retrouvé leur numéro. Le refus du doublon montre que la suivante ne pourra pas emprunter celui de sa voisine. C'est ce second résultat que le responsable métier a intérêt à signer.