Formulaires web à plusieurs signataires

Les comptes qui utilisent des formulaires web peuvent désormais autoriser plusieurs destinataires externes dans le processus de signature.

Les destinataires supplémentaires sont définis par le signataire initial :

Utilisation de modèles de bibliothèque pour créer des formulaires web

Les auteurs peuvent désormais utiliser les modèles de bibliothèque existants pour créer des formulaires web. Le fichier est importé avec tous les champs intacts :

Activation du « Liquid Mode » pour le remplissage de formulaires sur mobile

Liquid Mode est une fonctionnalité facultative permettant de créer une version de vos accords Adobe Sign améliorée pour l’affichage et le remplissage sur appareil mobile.

La version Liquid Mode du document existe parallèlement à la version PDF standard du document.

Adobe Sign utilise le format approprié en fonction de l’appareil utilisé par le destinataire.

Pour plus d’informations sur le Liquid Mode, cliquez ici >

Verrouillage de la valeur Nom pour les utilisateurs connus utilisant une signature manuelle ou une image

Dans certains cas, il n’est pas souhaitable de pouvoir modifier le nom du destinataire pendant le processus de signature. Adobe Sign offre une certaine souplesse à cet égard, par respect de la préférence de nom du signataire.  Dans les environnements les plus normalisés, cette flexibilité est inacceptable. Il existe donc une nouvelle commande permettant de verrouiller les noms des destinataires dans l’accord.

Les administrateurs peuvent désormais empêcher les destinataires dont les valeurs Nom sont connues de modifier ces valeurs lorsqu’ils appliquent une signature manuelle ou une image.

Cas où la valeur Nom est connue :

• Lors de l’envoi à un destinataire avec un ID Adobe Sign
• Lors de l’envoi du nom via l’API
• Lorsque les champs d’informations sur les signataires sont renseignés lors du remplissage du formulaire
• Si le nom est verrouillé lors de l’exécution d’une authentification fondée sur les connaissances (KBA) ou d’une authentification par pièce d’identité officielle

Améliorations de l’authentification fondée sur les connaissances

Des commandes ont été ajoutées à la méthode d’authentification fondée sur les connaissances (KBA) : désormais, il peut être exigé de l’expéditeur qu’il fournisse un nom de destinataire et que cette valeur Nom soit verrouillée tout au long du processus de signature.

Options pour améliorer la sécurité des emails

Deux nouvelles options sont disponibles pour améliorer la sécurité des emails. Ces deux paramètres sont activés par défaut :

• Ajouter un lien dans les e-mails pour afficher le contrat signé
  
  • Option activée par défaut.
  • Lorsque cette option est activée, un lien vers le document signé est fourni dans l’email final envoyé aux destinataires de l’accord.
• Inclure une image de la première page du contrat dans les e-mails
  • Option activée par défaut.
  • Lorsque cette option est activée, un aperçu de la première page de l’accord est visible dans certaines messageries
    .

Mises à jour de l’API REST v6

En-têtes standard dans chaque demande API REST v6

Par défaut, chaque demande API REST v6 comporte désormais les en-têtes standard suivants :

/agreements

• Tous les points d’entrée /agreements qui ont un chemin d’identifiant d’accord renvoient désormais un code d’erreur 404 AGREEMENT_DESTROYED si l’accord a été supprimé via les outils du RGPD.

Modèles de bibliothèque

• PUT /libraryDocuments/{libraryDocumentId} : inclut désormais le nouveau champ ownerId
  .

• GET /libraryDocuments : inclut désormais le nouveau champ ownerEmail.
  

• GET /libraryDocuments/{libraryDocumentId} : inclut désormais les nouveaux champs ownerId, ownerEmail et ownerName.

Nouveaux champs dans l’objet LibraryDocumentInfo :

Champs avec un nouveau comportement :

Formulaires web (/widgets)

• POST /widgets - L’utilisation d’un libraryDocumentId pour créer un formulaire web est désormais prise en charge avec un identifiant valide.

Code d’état ajouté :

• PUT /widgets - L’utilisation d’un libraryDocumentId pour créer un formulaire web est désormais prise en charge avec un identifiant valide.

Code d’état ajouté :

• PUT /widgets/{widgetId} : inclut désormais le nouveau champ ownerId
  .

Code d’état ajouté :

• GET /widgets/{widgetId} : inclut désormais les nouveaux champs ownerId, ownerEmail, ownerName et creatorName
  .

Nouveaux champs dans l’objet WidgetInfo :

Champs avec un nouveau comportement :

/MegaSignature

NOUVEAU :

• GET /megaSigns/{megaSignId}/formFields : récupère les détails des champs de formulaire d’un accord parent Mega Sign.

Paramètres:

Objet de réponse :

• PUT /megaSigns/{megaSignId}/formFields : met à jour les champs de formulaire d’un accord Mega Sign.

Paramètres:

Objet de réponse :

MISE À JOUR :

• POST /megaSigns - AUTHORING a été ajouté en tant que valeur state pour prendre en charge la création d’un modèle Mega Sign.
  • Paramètre modifié :

• PUT /megaSigns/{megaSignId}/state - AUTHORING a été ajouté en tant que valeur state pour prendre en charge la création d’un modèle Mega Sign. Par conséquent, megaSignCancellationInfo n’est plus un champ obligatoire
  .

Modifications de l’expérience pour les utilisateurs

Les nouvelles pages Accueil et Gérer ont été activées pour tous les comptes restants.

L’ensemble de commandes de tous les comptes a été mis à jour afin d’activer les nouvelles pages Accueil et Gérer pour les utilisateurs.

Les commandes du menu Administrateur restent disponibles pour les comptes qui doivent revenir à l’expérience classique :

Niveau de service et ID de compte Adobe Sign affichés dans le menu Administrateur

Les administrateurs peuvent désormais trouver leur ID de compte sur la page Paramètres généraux :

L’ID de groupe se trouve sur la page Paramètres du groupe :

Configuration HIPAA explicite

Une nouvelle page est disponible pour indiquer clairement quand le compte est activé pour gérer les accords soumis aux exigences HIPAA.  

• Cette commande est uniquement affichée au niveau du compte. Les administrateurs de groupe n’y ont pas accès.
• Cette commande est en lecture seule pour indiquer clairement quand le compte est configuré.
  • Contactez votre gestionnaire du succès client ou l’assistance pour activer la configuration HIPAA.
  Plus d’informations concernant les paramètres HIPAAA sont disponibles ici >
  

Délégation d’accords avec des signatures numériques

La possibilité de déléguer un accord avec des signatures numériques apposées a été améliorée. Désormais, la délégation de la notification par e-mail d’origine au destinataire est possible par délégation automatique lorsqu’elle est configurée par un utilisateur, et via l’action Remplacer le signataire actuel sur la page Gérer.

Interface mise à jour pour l’intégration des paiements

L’interface Paiements a été mise à jour afin que les commandes d’authentification soient plus visibles. Le processus de configuration est ainsi plus simple.

La valeur maximale de gouvernance des données a été portée à 5 475 jours (15 ans)

Les clients qui utilisent des règles de gouvernance des données pour supprimer automatiquement les accords du système Adobe Sign peuvent désormais définir cette date de suppression sur un maximum de 15 ans (cette valeur était limitée à 10 ans auparavant).

Le libellé de texte au niveau du champ pour valider le numéro de sécurité sociale américain a été mis à jour

Le libellé de texte au niveau du champ pour la validation du N° de sécurité sociale a été mis à jour pour préciser que le numéro de sécurité sociale provient des États-Unis :

Rappel : l’authentification sociale a été supprimée

Comme annoncé en novembre, la méthode d’authentification utilisant l’identité sociale a été supprimée de la liste des méthodes d’authentification dans le menu Administrateur.

Rappel : l’intégration du compte Twitter personnel a été supprimée

Comme annoncé en décembre, la possibilité pour les utilisateurs d’établir des connexions personnelles authentifiées avec Twitter a été supprimée.

Les fonctionnalités Twitter au niveau du compte et du groupe restent inchangées.

Les utilisateurs inactifs reçoivent une notification par email lorsqu’ils sont inclus dans un accord

Les utilisateurs qui ont un statut Inactif reçoivent désormais une notification par e-mail leur demandant de déléguer l’accord à un autre utilisateur.

Problèmes résolus

Fonctionnalité améliorée

Verrouillage de la valeur Nom pour les utilisateurs connus utilisant une signature manuelle ou une image

Dans certains cas, il n’est pas souhaitable de pouvoir modifier le nom du destinataire pendant le processus de signature. Adobe Sign offre une certaine souplesse à cet égard, par respect de la préférence de nom du signataire.  Dans les environnements les plus normalisés, cette flexibilité est inacceptable. Il existe donc une nouvelle commande permettant de verrouiller le nom dans l’accord.

Les administrateurs peuvent désormais empêcher les destinataires dont les valeurs Nom sont connues de modifier ces valeurs lorsqu’ils appliquent une signature manuelle ou une image.

Cas où la valeur Nom est connue :

• Lors de l’envoi à un destinataire avec un ID Adobe Sign
• Lors de l’envoi du nom via l’API
• Lorsque les champs d’informations sur les signataires sont renseignés lors du remplissage du formulaire
• Si le nom est verrouillé lors de l’exécution d’une authentification fondée sur les connaissances (KBA) ou d’une authentification par pièce d’identité officielle

Modifications de l’expérience pour les utilisateurs

Le texte des alertes pour les accords sur la page après envoi a été clarifié afin de mieux préciser quand les alertes se déclencheront :

Le nouveau texte s’aligne sur le langage utilisé dans les commandes de configuration :

Problèmes résolus

Configuration de règles de gouvernance des données pour la suppression automatique d’accords

Les clients qui préfèrent conserver leurs enregistrements d’accord sur leur propre système et qui souhaitent supprimer les documents d’origine des systèmes Adobe Sign peuvent installer une « stratégie de rétention » pour déterminer la durée pendant laquelle Adobe Sign doit conserver la transaction après quoi l’accord (et éventuellement les données d’audit/personnelles qui l’accompagnent) sera supprimé d’Adobe Sign.

Les règles de rétention sont définies par un administrateur au niveau du compte dans la section Gouvernance des données du menu d’administration.

Amélioration du rapport d’identité du signataire

Le rapport d’identité du signataire (SIR) généré avec la méthode d’authentification par pièce d’identité officielle est en cours d’amélioration afin de permettre l’accès à sa version provisoire tant qu’il est en cours.

Accédez au SIR à partir de la page Gérer en sélectionnant l’accord (pour ouvrir le rail Actions situé à droite) et en sélectionnant l’action Télécharger le rapport d’identité.

Un mot de passe doit être défini pour télécharger le SIR, ce même mot de passe étant requis pour consulter le fichier PDF obtenu :

Le SIR indique clairement si le rapport est provisoire ou final :

Délégation d’accords avec des signatures numériques

La possibilité de déléguer un accord avec des signatures numériques apposées a été ajoutée à la page de signature électronique du destinataire.

Suppression de la page Envoyer/Envoi via les workflows uniquement

Les comptes peuvent supprimer la page Envoyer et acheminer tous les accords par le biais de workflows contrôlés, conçus par les administrateurs.

La fonction Remplacer le destinataire s’applique désormais au rôle Chargé de remplissage

La possibilité de remplacer le destinataire actuel inclut désormais le rôle de destinataire Chargé de remplissage :

Champ du motif de refus étendu

La capacité de saisie du champ que l’utilisateur peut utiliser pour indiquer le motif de refus a augmenté pour atteindre 1 000 caractères (contre 255 précédemment).

Amélioration de l’authentification pour la capture de signature mobile

La fonctionnalité de capture de signature mobile obligatoire a été améliorée pour détecter si le numéro de téléphone fourni est considéré comme utilisable. S’il est avéré que le numéro est inapproprié pour saisir un message textuel, un avertissement s’affiche. L’utilisateur a la possibilité d’annuler ou de poursuivre :

La fonctionnalité d’aide intégrée au produit a été mise à jour

Le système d’aide intégrée au produit a été mis à jour dans cette version pour améliorer l’expérience utilisateur sur la nouvelle interface des pages Accueil et Gérer.

Les comptes pour lesquels la fonctionnalité est activée verront que l’onglet Aide interactive flottant sur le bord droit de la fenêtre a été remplacé par une icône de point d’interrogation moins gênante :

Les administrateurs peuvent activer ou désactiver le système d’aide intégrée au niveau du compte et du groupe :

Modifications de l’expérience pour les utilisateurs

Les e-mails destinés aux clients ne contiennent plus le lien vers support@echosign.com

Les notifications par e-mail aux utilisateurs (e-mails de réinitialisation de mot de passe, par ex.) ne contiennent plus le lien vers l’ancienne adresse e-mail de l’équipe de support afin d’encourager l’adoption de notre stratégie de contact actuelle.

L’e-mail d’annulation a été clarifié en ce qui concerne les personnes informées de l’annulation en question

Le texte de tous les modèles d’annulation a été revu pour préciser que seules les parties ayant participé jusqu’à présent à l’accord seront informées de l’annulation :

La page Paiements de l’interface utilisateur a été mise à jour

Des modifications mineures de texte et de mise en page ont été apportées à la page Intégration des paiements :

Problèmes résolus

Action avec sélection multiple sur la page Gérer : Masquer/Afficher

La nouvelle page Gérer permet désormais de sélectionner plusieurs enregistrements d’accord, de formulaire web et Mega Sign.

• Lorsqu’un enregistrement est sélectionné, le rail droit s’ouvre pour afficher toutes les actions disponibles pour l’enregistrement.
• Si plusieurs enregistrements sont sélectionnés, le rail droit est filtré pour afficher uniquement les actions qui peuvent être appliquées à tous les enregistrements sélectionnés.

La page post-signature par défaut (pour les destinataires non enregistrés) a été mise à jour pour supprimer le contenu marketing

Tous les comptes ont une nouvelle page post-signature par défaut pour les destinataires qui ne sont pas des utilisateurs Adobe Sign enregistrés.

Le message de réussite et un lien permettant de télécharger une copie de ce qui vient d’être signé sont maintenus pour informer le destinataire et lui donner accès à l’accord.

Tous les liens et contenus marketing permettant de s’inscrire à un compte actif ont été supprimés.

URL de redirection pour post-signature personnalisée

Les administrateurs ont la possibilité de définir l’URL vers laquelle leurs destinataires sont redirigés une fois qu’ils ont terminé leurs actions sur l’accord.

L’URL de la page post-signature peut être configurée au niveau du compte ou au niveau du groupe.

• Les paramètres au niveau du groupe remplacent les paramètres au niveau du compte.
• Les paramètres d’appel API remplacent les paramètres au niveau du compte/groupe.
  

Redirection post-signature définie sur zéro seconde par défaut

À compter de cette version, toutes les redirections vers une nouvelle page ont un délai par défaut de 0 seconde.

• Cela s’applique aux redirections automatiques (la page post-signature, intégrations, etc.) et aux appels API.
• Les appels API peuvent configurer le délai de redirection dans l’appel API si un délai plus important est souhaité.
  

Message de redirection post-signature ajouté au pied de page de signature électronique

Si une redirection est configurée pour un accord (via l’interface utilisateur ou l’API), un message est ajouté au pied de page Cliquez pour signer de la page de signature électronique pour avertir le destinataire qu’il sera redirigé après signature.

• Message de redirection : « Lors de la signature, l’expéditeur vous demande d’être redirigé vers domain.com ».
  • domain.com correspond au nom de domaine fourni dans l’URL de redirection spécifique.

Améliorations de l’authentification par pièce d’identité officielle

L’option Authentification par pièce d’identité officielle a été améliorée et inclut désormais des fonctionnalités supplémentaires :

• L’Authentification par pièce d’identité officielle est désormais disponible pour les comptes clients basés dans le Cloud Microsoft Azure (EU2 et NA3).
• La carte d’identité nationale et le permis de séjour allemands ont été ajoutés à la liste des documents pris en charge pour l’identification.

Amélioration des rapports pour le champ de lien hypertexte

Lors de l’extraction du rapport .csv pour un accord ou un modèle, la valeur du champ de lien hypertexte indique désormais l’URL que le lien a fournie au destinataire, pour les liens de pointage externes ainsi que le numéro de page pour les liens de pointage internes.

Si l’utilisateur ne clique pas sur le lien, le champ reste vide.

• Ceci remplace la politique d’utilisation précédente qui voulait que la valeur « TRUE » soit utilisée si l’utilisateur avait cliqué sur le champ.
  

Nouvelles méthodes d’API REST v6

Deux nouvelles méthodes ont été ajoutées à l’API REST v6 :

• GET /libraryDocuments/{libraryDocumentId}/formFields : pour récupérer les détails des champs de formulaire sur un modèle de bibliothèque.
• PUT /libraryDocuments/{libraryDocumentId}/formFields : pour mettre à jour les détails des champs de formulaire sur un modèle de bibliothèque.

Mise à jour de l’API REST v5 pour remplacer le signataire

L’API REST v5 a été mise à jour afin que seul l’expéditeur d’un accord puisse remplacer les destinataires. Ce changement semblera significatif aux clients habitués à remplacer les destinataires pour le compte d’autres utilisateurs.

Ce changement a un impact particulièrement important pour les intégrations qui utilisent l’API REST v5 (Salesforce, par ex.).

Remarque : le Partage de compte avancé peut être utilisé pour contourner cette nouvelle restriction (en activant Modifier).

Problèmes résolus

Fonctionnalité améliorée

Modification d’éléments d’accord dans l’interface de création

L’environnement de création contient désormais un bouton Précédent, qui permet à l’utilisateur de revenir à la page de composition précédente afin d’effectuer des modifications.

Les éléments qui peuvent être modifiés sont les suivants :

• Le nom et le message de l’accord
• Les adresses électroniques des destinataires
• Les fichiers joints à l’accord (ajout, suppression et réorganisation)

Une fois les modifications terminées, l’utilisateur clique sur le bouton Suivant pour revenir à l’environnement de création (avec les mises à jour appliquées).

Les champs précédemment placés conservent leurs valeurs configurées et leur valeur Affecté(s) à (par exemple : Participant 1).

• Si l’adresse e-mail d’un participant a changé, la nouvelle valeur de l’adresse e-mail est remplacée, sans perturber la configuration des champs.
• Le remplacement de fichiers supprime tout placement de champ pour les fichiers supprimés.
  

Champs de lien hypertexte obligatoires

Les champs Lien hypertexte peuvent désormais être configurés en tant que champ Obligatoire pendant le cycle de signature.

Lorsque l’option Obligatoire est cochée, deux nouveaux paramètres sont ajoutés aux propriétés du champ :

• Affecté à  : définit le destinataire qui doit cliquer sur le champ pendant son action sur l’accord.
  • Un destinataire peut être explicitement requis, ce qui oblige uniquement ce destinataire à cliquer sur le champ avant de terminer son action sur l’accord.
    • Le lien reste cliquable pour tous les destinataires qui ne sont pas tenus de cliquer dessus.
  • Tout le monde est un nouveau rôle disponible exclusivement dans le champ Lien hypertexte, qui exige que tous les destinataires cliquent sur le lien avant de terminer leur action.
    
• Info-bulle : affiche une info-bulle de texte à l’attention du destinataire lorsque le champ devient actif.
  

Amélioration des champs calculés avec le formatage de devise

Les champs calculés qui affichent leurs valeurs formatées en tant que Devise ont de nouvelles règles qui déterminent quel symbole de devise est affiché dans la valeur calculée.

Notez que les valeurs de devise calculées peuvent être dérivées d’un ou plusieurs champs source qui valident leurs valeurs en tant que Nombre ou Devise.

• Si les champs source contiennent une validation de devise pour les États-Unis, la valeur calculée affiche le symbole du dollar américain : $
• Si les champs source contiennent une validation de devise pour le Royaume-Uni, la valeur calculée affiche le symbole de la livre sterling : £

Amélioration des options de refus pour les destinataires

L’option permettant à un destinataire de refuser un accord a été étendue pour :

• Afficher le bouton Refuser dans le pied de page de la page ESign pour tous les destinataires avec le rôle Accepteur.

• Autoriser les administrateurs de groupe et de compte à définir explicitement une liste de motifs que le destinataire peut choisir lors du refus de l’accord.

En savoir plus sur les options de refus >

Le partage de compte avancé permet d’activer l’action Masquer pour les accords partagés avec des autorisations de modification

Les comptes qui ont activé le Partage de compte avancé avec des autorisations de modification verront désormais l’option Masquer/Afficher pour les accords sur les comptes partagés.

• Cette action est effectuée au nom du propriétaire, ce qui signifie que les accords masqués le sont dans la vue du propriétaire (et de tous les autres).
  

Mises à jour de l’API REST v6

Définir la durée de vie d’une URL de signature

L’appel d’API REST v6 GET /agreements/{agreementId}/signingUrls comprend un nouveau paramètre : expiry.

• Ce paramètre accepte une valeur comprise entre 30 et 315 360 000 secondes ( environ 10 ans).
• La durée d’expiration par défaut pour les nouveaux clients est de 1 209 600 secondes (14 jours).
  
  • La valeur par défaut pour les clients existants sera définie sur 3 650 jours.
    • Les clients existants qui souhaitent que leur valeur par défaut soit réduite doivent contacter leur responsable du succès client ou le support technique pour que le paramètre soit mis à jour.
      

Positionnement relatif des champs via REST v6

L’appel d’API REST v6 POST /agreements a été étendu pour inclure un nouvel attribut facultatif : formFieldGenerators. Les champs peuvent ainsi être positionnés par programmation par rapport aux chaînes spécifiées dans le document PDF chargé.

Appel d’API de formulaire web personnalisé

L’appel d’API REST v6 existant POST /widgets/{widgetId}/views a été étendu pour inclure un nouveau paramètre : personalizedSigningViewConfiguration.

Ce paramètre permet de personnaliser les formulaires web.

Créer/Renommer/Supprimer des groupes

Trois nouveaux appels d’API REST v6 ont été ajoutés pour aider à gérer les groupes via REST v6 :

• Créer un groupe : POST /groups. Crée un groupe dans un compte.
  
• Renommer un groupe : PUT /groups/{groupId}. Met à jour un groupe existant.
  
• Supprimer un groupe : DELETE /groups/{groupId}. Supprime un groupe existant.
  

Modifications de l’expérience pour les utilisateurs

API : amélioration des appels DELETE de REST v6 pour les administrateurs des informations personnelles

Les administrateurs des informations personnelles peuvent désormais appeler DELETE /agreements/{agreementId}/documents sans l’en-tête x-api-user lors de l’utilisation d’un jeton de portée de compte.

Modification du texte du rapport d’audit pour l’entrée finale

Le rapport d’audit n’énumère plus explicitement la liste des participants (et leurs adresses e-mail) dans son dernier enregistrement.

L’événement final du rapport d’audit affiche désormais l’accord terminé avec l’horodatage de l’événement (en GMT) :

Amélioration des champs calculés avec le formatage de devise

Les champs calculés qui affichent leurs valeurs formatées en tant que Devise ont de nouvelles règles qui déterminent quel symbole de devise est affiché dans la valeur calculée.

Notez que les valeurs de devise calculées peuvent être dérivées d’un ou plusieurs champs source qui valident leurs valeurs en tant que Nombre ou Devise.

• Si les champs source contiennent une validation de devise pour les États-Unis, la valeur calculée affiche le symbole du dollar américain : $
• Si les champs source contiennent une validation de devise pour le Royaume-Uni, la valeur calculée affiche le symbole de la livre sterling : £

Dates d’expiration de Mega Sign

Les accords Mega Sign respectent désormais les valeurs par défaut d’expiration automatique du niveau compte/groupe.

S’il existe une valeur par défaut définie au niveau du compte ou du groupe, cette valeur est importée dans le processus de création de Mega Sign et conférée aux accords enfants :

La modification de la date d’expiration de l’objet Mega Sign (parent) s’applique à la date d’expiration de tous les accords enfants restants (qui sont toujours en cours).

• La modification de la date d’expiration d’un accord enfant est autorisée et se fait directement au niveau de l’accord enfant.
• La modification de l’objet Mega Sign parent, après la modification d’un accord enfant, applique à l’accord enfant la nouvelle date définie sur l’objet Mega Sign parent.
  

La recherche d’accords renvoie désormais des enregistrements triés par pertinence

La recherche dans Adobe Sign renvoie désormais dans les résultats les enregistrements les plus pertinents en haut, la date de dernière modification étant le dernier critère de tri.

Ce réglage améliore la recherche avec plusieurs termes en plaçant les accords qui correspondent à davantage de termes en haut de la liste d’enregistrements renvoyée.

Concepteur de workflow produisant des messages d’erreur

En raison de l’amélioration de la sécurité du partage des ressources de bibliothèques, certains workflows peuvent commencer à renvoyer un message d’erreur de serveur lors de la modification du workflow après la mise à jour de septembre :

Les expéditeurs qui tentent d’utiliser un workflow avec ce problème reçoivent un message d’erreur indiquant que le workflow contient des documents qui ne sont pas à leur portée :

Cette erreur signifie que ce workflow n’a plus l’autorisation d’utiliser un ou plusieurs des modèles de bibliothèque joints. Cela se produit généralement lorsque les droits d’accès au modèle sont modifiés, passant de l’autorisation d’accès au compte/groupe à la limitation de l’accès au propriétaire.

Les administrateurs doivent annuler ce message d’erreur plutôt que de recharger la page.

Pour corriger l’erreur :

• Le propriétaire du modèle doit modifier ses autorisations pour que le compte/groupe auquel le workflow est lié puisse y accéder.
• Le propriétaire du workflow peut remplacer le modèle par un modèle doté des autorisations nécessaires.  Pour ce faire, annulez l’opération ayant déclenché l’erreur ci-dessus, puis modifiez le workflow et remplacez le document.

Problèmes résolus