Non. Si vous avez construit un Blueprint sur un certain champ de statut, vous ne pouvez pas modifier ce champ pendant qu'un enregistrement se trouve encore dans le Blueprint. Cependant, vous pouvez utiliser une solution simple pour revenir à un état précédent.
Cette réponse est fournie en deux parties.
- Pourquoi nous ne rendons pas les champs Blueprint modifiables
- Solution pour revenir à des états précédents.
L'idée originale d'un Blueprint est de rationaliser un processus dans toute l'organisation. Donc, quand vous avez établi des directives étape par étape, vous ne voudriez pas que vos équipes s'écartent de ce chemin. De plus, si vous avez exigé certains champs et pièces jointes pour qu'un utilisateur puisse passer d'un état à un autre, permettre à l'utilisateur de mettre à jour un champ de statut sans respecter les spécifications de ce changement irait à l'encontre de l'objectif. Par exemple, pour qu'un utilisateur déplace une transaction de Négociation à Contrat, vous avez exigé des NOTES. Mais l'utilisateur met à jour la valeur du champ (modification) sans fournir ces notes. Ce qui va à l'encontre de l'objectif d'un Blueprint en premier lieu. C'est la raison pour laquelle les champs de statut sur lesquels vous créez un Blueprint ne sont pas modifiables tant que l'enregistrement se trouve dans le Blueprint. Le système déplacera automatiquement les enregistrements vers les étapes suivantes une fois que vous aurez terminé les actions obligatoires invitées par le système à chaque étape.
Cela dit, il pourrait y avoir des cas exceptionnels où vous souhaiteriez déplacer l'enregistrement vers un état précédent. Ce cas est en cours d'évaluation par nos équipes et vous devriez avoir une réponse bientôt.
Néanmoins, pour y parvenir, il existe une solution utilisant les Transitions communes.
Les Transitions communes sont celles qui peuvent être réutilisées à tout moment du processus pour atteindre une certaine étape. Par exemple, dans un processus de suivi de transaction, la fermeture d'une transaction (gagnée/perdue) se produit généralement à la fin du processus, après avoir franchi 6-7 étapes. Mais en réalité, un client peut exprimer son désintérêt à tout moment du processus, pas nécessairement au stade du contrat. Vous pouvez donc avoir ce que nous appelons une Transition commune appelée « Abandon de transaction », de sorte que ce bouton soit visible à toutes les étapes du processus. Vous pouvez simplement effectuer cette transition pour marquer la transaction comme perdue et sortir du processus.
Cette transition commune peut être utilisée comme solution dans votre cas.
Étape 1 : Créez votre flux de processus.
Étape 2 : Une fois que vous avez défini tous les états et transitions pour un scénario idéal, créez maintenant un État appelé « Restauré » (vous pouvez le renommer comme bon vous semble).
Étape 3 : Créez une transition de n'importe quel état vers cet État « Restauré ». Nommez la Transition « Restaurer ».
Étape 4 : Cochez la case Transition commune.
Maintenant cette Transition « Restaurer » sera disponible à n'importe quel stade du Blueprint. Donc, si vous souhaitez modifier le statut du lead, cliquez sur la transition Restaurer, et votre enregistrement sortira complètement du Blueprint.
Le champ Statut du lead devient à présent modifiable. Vous pouvez modifier la valeur pour choisir l'étape souhaitée et réintégrer le Blueprint à partir de cette étape.
Il existe plusieurs raisons pour lesquelles vos enregistrements n'intègrent pas le Blueprint bien qu'ils répondent aux critères. Veuillez vérifier les points suivants :
-
Un Blueprint est désactivé par défaut. Assurez-vous qu'il est activé.
-
Un Blueprint peut être créé pour des dispositions spécifiques. Vérifiez que l'enregistrement en question appartient à la disposition spécifiée dans les paramètres du Blueprint.
-
Si vos critères d'entrée du Blueprint contiennent un État inutilisé dans le Blueprint, l'enregistrement aurait intégré le processus, mais les transitions ne s'afficheraient pas pour cet enregistrement, car l'État ne fait pas partie du Blueprint.
Si un enregistrement répond aux critères de plusieurs Blueprints, lequel s'exécute en premier ?
L'ordre dans lequel les Blueprints sont listés détermine l'ordre d'exécution. Si un enregistrement répond aux critères de plusieurs Blueprints, le Blueprint qui figure en tête de liste s'exécute. Vous pouvez réorganiser les Blueprints à tout moment selon le Blueprint qui devrait être considéré en premier pour l'exécution.
Puis-je imposer la mise à jour du statut d'une Task dans les paramètres « During Transition » ?