Guide d'utilisation Annuler

Guide du développeur Adobe Acrobat Sign pour Salesforce

  1. Intégrations d’Adobe Acrobat Sign
  2. Nouveautés
  3. Versions de produit et cycle de vie
  4.  Acrobat Sign pour Saleforce
    1. Guide d’installation
    2. Guide de l’utilisateur
    3. Guide du développeur
    4. Guide de personnalisation avancée
    5. Guide de mappage de champs et modèles
    6. Instructions relatives au Process Builder
    7. Guide de Document Builder
    8. Guide de mise à niveau
    9. Notes de mise à jour
    10. Articles supplémentaires
  5. Acrobat Sign pour Microsoft
    1. Acrobat Sign pour Microsoft 365
      1. Guide d’installation
    2. Acrobat Sign pour Outlook
      1. Guide de l’utilisateur
    3. Acrobat Sign pour Word/PowerPoint
      1. Guide de l’utilisateur
    4. Acrobat Sign pour Teams
      1. Guide de l’utilisateur
      2. Notes de mise à jour
      3. Approbations Microsoft Teams
    5. Acrobat Sign pour Microsoft PowerApps et Power Automate
      1. Guide de l’utilisateur
      2. Notes de mise à jour
    6. Connecteur Acrobat Sign pour Microsoft Search
      1. Guide de l’utilisateur
    7. Acrobat Sign pour Microsoft Dynamics
      1. Présentation
      2. Dynamics en ligne : guide d’installation
      3. Dynamics en ligne : guide de l’utilisateur
      4. Dynamics sur site : guide d’installation
      5. Dynamics sur site : guide de l’utilisateur
      6. Guide de workflow de Dynamics
      7. Dynamics 365 pour Talent
      8. Guide de mise à niveau
      9. Notes de mise à jour
    8. Acrobat Sign pour Microsoft SharePoint
      1. Présentation
      2. SharePoint sur site : guide d’installation
      3. SharePoint sur site : guide de mappage de modèles
      4. SharePoint sur site : guide de l’utilisateur
      5. SharePoint sur site : notes de mise à jour
      6. SharePoint en ligne : guide d’installation
      7. SharePoint en ligne : guide de mappage de modèles
      8. SharePoint en ligne : guide de l’utilisateur
      9. SharePoint en ligne : guide de mappage de formulaires web
      10. SharePoint en ligne : notes de mise à jour
  6.  Acrobat Sign pour ServiceNow
    1. Présentation
    2. Guide d’installation
    3. Notes de mise à jour
  7. Acrobat Sign pour les RH ServiceNow
    1. Guide d’installation
  8. Acrobat Sign pour SAP SuccessFactors
    1. Guide d’installation de Cockpit
    2. Configuration du recrutement Guide
    3. Guide de l’utilisateur pour le recrutement
    4. Guide d’installation de Cloud Foundry
  9.  Acrobat Sign pour Workday
    1. Guide d’installation
    2. Guide de démarrage rapide
    3. Tutoriel de configuration
  10. Acrobat Sign pour NetSuite
    1. Guide d’installation
    2. Notes de mise à jour
  11. Acrobat Sign pour SugarCRM
  12. Acrobat Sign pour VeevaVault
    1. Guide d’installation
    2. Guide de l’utilisateur
  13. Acrobat Sign pour Coupa BSM Suite
    1. Guide d’installation
  14. Documentation du développeur Acrobat Sign
    1. Présentation
    2. Webhooks
    3. Balises de texte

Présentation

Le Guide du développeur Adobe Acrobat Sign pour Salesforce est conçu pour aider les développeurs Salesforce à en savoir plus sur les objets et les paramètres requis pour intégrer votre package Salesforce à Adobe Acrobat Sign.

Attention :

Les objets Adobe Acrobat Sign pour Salesforce peuvent changer dans une version ultérieure. Si vous créez une solution personnalisée dépendant d’objets qui sont modifiés, vous devrez peut-être mettre à jour votre personnalisation.

Directives relatives à l’intégration

  • S’il vous faut savoir quand l’accord est intégralement signé, implémentez un déclencheur Apex sur l’objet echosign_dev1__SIGN_Agreement__c avant ou après la mise à niveau (en fonction des exigences et du cas d’utilisation). Lorsque le champ echosign_dev1__Status__c passe en statut Signé ou Approuvé ou en un autre statut, l’accord est terminé. 
  • S’il vous faut savoir quand chaque PDF signé de façon individuelle est inséré, si par exemple, vous devez obtenir chaque PDF intermédiaire signé, implémentez un déclencheur Apex sur les objets Attachment (Pièce jointe) ou ContentVersion (Version du contenu), après insertion et recherchez un accord parent et un nom qui se termine par « - signed.pdf » ou « - approved.pdf » ou par un autre statut final
  • S’il vous faut savoir quand un destinataire individuel a signé ou a approuvé un document, implémentez un déclencheur Apex sur l’objet echosign_dev1__SIGN_Recipients__c, avant ou après la mise à niveau (en fonction des exigences et du cas d’utilisation). Lorsque le champ echosign_dev1__Status__c passe en Signé ou Approuvé ou en un autre statut, le destinataire est terminé.  
  • S’il vous faut savoir quand un événement particulier faisant partie du processus de signature se produit, tel qu’un accord envoyé pour signature ou un rappel envoyé, un déclencheur peut être créé sur l’objet des événements de l’accord.(echosign_dev1__SIGN_AgreementEvent__c) et peut vérifier le type de l’événement
  • Les noms du statut de l’accord final pour un accord complet sont : « Signé », « Approuvé », « Accepté », « Formulaire-rempli » et « Livré »
  • Les noms du statut de l’accord final pour un accord annulé sont : « Annulé/Refusé » et « Expiré »

Ordre des mises à jour

Dans la version 21, l’ordre des mises à jour a changé. Vous trouverez ci-dessous la séquence dans laquelle l’accord et ses objets associés sont mis à jour :

  1. Pièces jointes 
  2. Destinataires 
  3. Accord (statut et autres attributs)
  4. Événements de l’accord
  5. Flux Chatter 

Services Apex

Méthode Apex en vigueur

À partir de la version 21.0 d’Acrobat Sign pour Salesforce, tous les processus asynchrones (notamment les mises à jour automatiques et les mappages de données) sont passés des méthodes futures à en attente, une approche recommandée par Salesforce.

Avec ce changement, toutes les personnalisations au sein de l’organisation de l’abonné qui ajoutent des tâches à la file d’attente de Salesforce dans le cadre de la mise à jour automatique ou du processus de mappage des données déclencheront une erreur : « System.LimitException : trop de tâches pouvant être mises en attente ajoutées à la file d’attente : 2 ».

L’erreur se produit parce qu’un processus en attente ne peut ajouter qu’un enfant en attente, ce qui est déjà pris en charge par Acrobat Sign. Pour plus d’informations, voir Limitations d’Apex en attente.

Erreur :« Lors de l’enchaînement de tâches, vous ne pouvez ajouter qu’une seule tâche d’une tâche en cours d’exécution avec System.enqueueJob, ce qui signifie qu’une seule tâche enfant peut exister pour chaque tâche parent en attente. Le démarrage de plusieurs tâches enfant de la même tâche pouvant être mise en attente n’est pas pris en charge ».

L’erreur ci-dessus se produit lorsque l’état de l’accord ne change pas ou que le mappage de données ne s’exécute pas correctement. Pour résoudre cette erreur, recherchez le déclencheur concerné, le gestionnaire de processus ou le workflow et désactivez-le ou basculez-le pour utiliser un appel synchrone, ou bien encore planifiez-le pour plus tard.

Service de modèle d’accord

Le service de modèle d’accord est proposé comme service Apex global par le package géré. Cela permet au code Apex, en dehors du package géré, de charger des accords en fonction des modèles d’accord existants. La classe et l’ensemble des méthodes affichées sont déclarées comme global pour permettre l’accès à celles-ci.

Le service Apex est affiché via la classe d’appel : echosign_dev1.AgreementTemplateService.

Remarque :

Le chargement d’un modèle d’accord des modèles de bibliothèque de signature électronique n’est actuellement pas pris en charge. Nous vous suggérons de déplacer les modèles de document vers une bibliothèque de documents Salesforce.

  Méthodes

global

static Id load()

Charge un accord en utilisant un modèle d’accord par défaut qui ne contient pas de type d’objet principal.

global

static Id load(String templateId)

Charge un accord avec l’ID de modèle d’accord spécifié qui ne contient pas de type d’objet principal.

 

global

static Id load(String templateId, String masterId)

Charge un accord avec l’ID de modèle d’accord et l’ID d’enregistrement principal spécifiés, dont le type doit correspondre au type d’objet principal configuré dans le modèle d’accord spécifié.

global

static Id load(String templateId, String masterId, Map<String,AgreementTemplateVariable> agreementTemplateVariables)

Charge un accord avec l’ID de modèle d’accord et l’ID d’enregistrement principal spécifiés, dont le type doit correspondre au type d’objet principal configuré dans le modèle d’accord spécifié. Fournit également les variables d‘exécution spécifiées comme paires nom/valeur.

 

global

static List<AgreementTemplateService.AgreementTemplateBasicInfo> getAgreementTemplateList(AgreementTemplateListOptions options)

Obtenez la liste des modèles d’accord en fonction des options de filtrage. Renvoie une liste vide si aucun modèle d’accord n’est trouvé avec les options de filtrage.

global

static AgreementTemplateService.AgreementTemplateDetails getAgreementTemplateDetails(String templateId)

Obtenez les détails du modèle d’accord portant l’identifiant indiqué.

Renvoie un objet vide si aucun modèle d’accord n’est trouvé.

global

static String getAgreementTemplateUrl(String templateId)

Obtenez l’URL pour modifier le modèle d’accord portant l’identifiant indiqué.

global

static String getNewAgreementTemplateUrl()

Obtenez l’URL pour créer un nouveau modèle d’accord dans Adobe Sign.

 Constructeurs (1)

Accès

Signature

global

AgreementTemplateListOptions()

global

AgreementTemplateListOptions(String masterObjectType, Boolean isActive, Boolean hasAttachment, Boolean hasRecipient, Boolean autoSend)

global class AgreementTemplateService.AgreementTemplateListOptions

Propriétés (5)

Accès

Nom

global

masterObjectType

global

isActive

global

hasAttachment

global

hasRecipient

global

autoSend

Remarque :

Aucun filtre n’est appliqué sur le champ correspondant en cas de demande de modèles d’accord si la valeur d’un des champs susmentionnés est nulle.

global class AgreementTemplateService.AgreementTemplateBasicInfo

Propriétés (6)

Accès

Nom

global

Nom

global

recordId

global

url

global

isDefault

global

daysUntilExpiration

global

langue

global class AgreementTemplateService.AgreementTemplateDetails

Propriétés (6)

Accès

Nom

global

message

global

ccList

global

dataMappingName

global

mergeMappingName

global

url

global

destinataires

global class AgreementTemplateService.RecipientInfo

Propriétés (4)

Accès

Nom

global

recipientRole

global

recipientType

global

recipientName

global

signOrder

  Variables d’exécution

La classe globale echosign_dev1.AgreementTemplateVariable possède deux champs globaux.

  • name : nom de la variable, qui doit correspondre à une variable d’exécution configurée dans le modèle d’accord.
  • value : valeur de cette variable, qui sera utilisée lors du chargement du modèle. La valeur dépend de l’emplacement où la variable a été utilisée. Par exemple, pour un destinataire, cela peut être l’ID d’enregistrement ou l’adresse électronique d’un contact, d’un prospect ou d’un utilisateur. Pour une variable de document, cela doit être l’ID d’enregistrement d’une pièce jointe.

Résultat

Chaque méthode retourne soit l’ID de l’enregistrement d’accord créé, soit une exception avec un message d’erreur détaillé si un problème survient au cours du chargement.

Service API

Le service de modèle d’API de signature électronique Adobe est proposé comme service Apex global par le package géré. Cela permet au code Apex, y compris en dehors du package géré, d’invoquer un ensemble d’API de signature électronique Adobe par le biais de ces enveloppes. Les enveloppes simplifient considérablement l’appel des API. En effet, les consommateurs n’ont pas besoin de créer de modèle de données de requête et de réponse. Ceux-ci n’ont pas non plus à gérer la transformation des données Salesforce en modèles de données de signature électronique. Pour le consommateur, tout est simplifié. Par exemple, pour envoyer un accord, il suffit au consommateur de fournir l’ID d’enregistrement d’accord. Le service prend en charge la requête : il extrait les données pertinentes, les renseigne dans l’API et analyse le résultat.

La classe et l’ensemble des méthodes affichées sont déclarées comme global pour permettre l’accès à celles-ci.

  • La version 17 et les versions antérieures invoquent les API SOAP.
  • La version 18 et les versions supérieures invoquent les API REST.

Le service Apex est affiché via la classe d’appel : echosign_dev1.EchoSignApiService.

Méthodes

global

static void cancelDocument(Id agreementId)

Annule l’accord correspondant à l’ID d’accord spécifié.

global

static void delegateSigner(Id agreementId, String delegatedEmail)

Délègue la signature à l’adresse électronique fournie.

global

static void delegateSigner(Id agreementId, String delegatedEmail, String message)

Délègue la signature à l’adresse électronique fournie, avec le message spécifié.

global

static echosign_dev1.EchoSignApiService.DocumentInfo getDocumentInfo(Id agreementId)

Récupère des informations détaillées pour l’ID d’accord spécifié.

global

static List<EchoSignApiService.SigningUrl>

getSigningUrls(Id agreementId) 

Récupère l’ensemble des URL de signature pour l’ID d’accord spécifié.

global

static void removeDocument(Id agreementId)

Annule l’accord correspondant à l’ID d’accord spécifié et supprime l’enregistrement de l’accord dans Salesforce (l’accord n’est pas supprimé du compte de signature électronique Adobe).

global

static void replaceSigner(Id replacementRecipientId)

Remplace le signataire spécifié.

global

static void replaceSigner(Id replacementRecipientId, String message)

Remplace le signataire spécifié, avec le message spécifié.

global

static echosign_dev1.EchoSignApiService.

SendDocumentResult sendDocument(Id agreementId)

Envoie l’accord avec l’ID d’accord spécifié et renvoie le résultat avec la clé et l’URL du document.

global

static void sendReminder(Id agreementId)

Envoie un rappel au signataire actuel pour l’ID d’accord spécifié.

global static void updateAgreement(Id agreementId)  Met à jour l’accord correspondant à l’ID d’accord spécifié.
global static EchoSignApiService.AgreementViewUrl getViewAgreementUrl(Id agreementId)
Extrait la page view/manage de Sign pour l’ID d’accord spécifié, qui possède une propriété viewURL.
Remarque : pour des raisons de sécurité, l’URL de l’accord généré a uniquement une durée de vie temporaire. Un appel REST-HTTPS est donc généré pour obtenir une nouvelle URL à partir des services Adobe Sign.

Classes internes

global class DocumentHistoryEvent

Propriétés (2)

Accès

Nom

global

String eventType

global

String participantEmail

Constructeurs (1)

Accès

Signature

global

DocumentHistoryEvent()


global class DocumentInfo

Propriétés (5)

Accès

Nom

global

Map<string,list> historyByEmail

global

Map participantsByEmail

global

Map participantsByName

global

String senderEmail

global

String status

  Constructeurs (1)

Accès

Signature

global

DocumentInfo()

global class ParticipantInfo

Propriétés (5)

Accès

Nom

global

String company

global

String email

global

String name

global

String status

global

String title

  Constructeurs (1)

Accès

Signature

global

ParticipantInfo()

global class SendDocumentResult

Propriétés (3)

Accès

Nom

global

String documentKey

global

Exception error

global

String url

Constructeurs (1)

Accès

Signature

global

SendDocumentResult()

global class SigningUrl

Propriétés (3)

Accès

Nom

global

String email

global

String esignUrl

global

String simpleEsignUrl

Constructeurs (1)

Accès

Signature

Global

 

Services Apex par lot

Expose les principales actions des accords de signature électronique à un niveau global, ce qui permet d’effectuer une même opération sur un ensemble d’accords. Cette classe implémente l’interface Salesforce Database.Batchable. Elle peut traiter tous les enregistrements, quel que soit le nombre. Ceux-ci sont rassemblés par lots de cinq et ces lots sont traités comme une transaction individuelle, ce qui permet de respecter les limitations du gouverneur.

Le service Apex par lot est affiché via la classe d’appel : echosign_dev1.EchoSignActionBatch.

Paramètres

Les paramètres suivants doivent être spécifiés pour initialiser une opération par lots :

La liste des ID d’enregistrement des accords sur lesquels effectuer l’action. L’action à exécuter, parmi les valeurs prises en charge ci-dessous :

  • Remind
  • Send
  • Cancel
  • Delete
  • Update

L’ID de session de l’utilisateur actuel. (Requis uniquement pour une mise à jour du type d’action.)

Enregistrement utilisateur de l’émetteur : utilisé pour avertir l’utilisateur par courrier électronique une fois le traitement global terminé.

Exemple d’utilisation

User submitterUser = UserInfo.getUserId();

EchoSignActionBatch batch = new EchoSignActionBatch( agreementIds, 'Remind', UserInfo.getSessionId(), submitterUser); syncProcessId = Database.executeBatch(batch, 5);

Modèle d’accord par lot

Accepte une requête SOQL et un ID d’enregistrement de modèle d’accord. La requête est exécutée de façon à récupérer un ensemble d’enregistrements d’objet principal. Ceux-ci sont ensuite exécutés dans le modèle d’accord fourni, pour générer un enregistrement d’accord. Cette classe implémente l’interface Salesforce Database.Batchable. Elle peut traiter tous les enregistrements, quel que soit le nombre. Ceux-ci sont rassemblés par lots de cinq et ces lots sont traités comme une transaction individuelle, ce qui permet de respecter les limitations du gouverneur.

Les types d’enregistrements renvoyés par la requête SOQL doivent correspondre au type d’objet principal du modèle d’accord fourni. Le service de modèle d’accord est invoqué pour chaque enregistrement.

Le service Apex par lot est affiché via la classe d’appel :

echosign_dev1.AgreementTemplateBatch

Paramètres

Les paramètres suivants doivent être spécifiés pour initialiser une opération par lots :

Requête de SOQL à exécuter : doit inclure l’ID d’enregistrement comme champ sélectionné. Les autres champs sont facultatifs.

ID d’enregistrement de modèle d’accord : utilisé conjointement à l’ID d’enregistrement principal pour charger un accord.

Exemple d’utilisation

String agreementTemplateId = [SELECT Id from echosign_dev1__Agreement_Template__c where Name = 'Default Template']; String soqlQuery = 'SELECT Id from Contact where Account.IsActive = true';

AgreementTemplateBatch batch = new AgreementTemplateBatch(soqlQuery, agreementTemplateId); syncProcessId = Database.executeBatch(batch, 5);

Service de modèle d’accord par lot

Accepte une liste d’ID d’enregistrement d’objet principal et le type d’objet principal. L’ensemble est ensuite interrogé et exécuté dans le modèle d’accord fourni, pour générer un enregistrement d’accord. Cette classe implémente l’interface Salesforce Database.Batchable. Elle peut traiter tous les enregistrements, quel que soit le nombre. Ceux-ci sont rassemblés par lots de cinq et ces lots sont traités comme une transaction individuelle, ce qui permet de respecter les limitations du gouverneur.

Le type d’objet principal donné doit correspondre au type d’objet principal du modèle d’accord fourni. Le service de modèle d’accord est invoqué pour chaque enregistrement.

Le service Apex par lot est affiché via la classe d’appel :

echosign_dev1.AgreementTemplateServiceBatch

Paramètres

Les paramètres suivants doivent être spécifiés pour initialiser une opération par lots :

  • La liste des ID d’enregistrements principaux
  • L’ID d’enregistrement de modèle d’accord, utilisé conjointement aux enregistrements principaux pour charger un accord
  • Le nom de l’objet principal pour pouvoir formuler une requête pour les enregistrements principaux

Exemple d’utilisation

String agreementTemplateId = [SELECT Id from echosign_dev1__Agreement_Template__c where Name = 'Default Template'];

AgreementTemplateBatch batch = new AgreementTemplateServiceBatch(new List<Id>{'01p50000000HoMB'}, agreementTemplateId, 'Contact');
syncProcessId = Database.executeBatch(batch, 5);

Services REST

Service de modèle d’accord

Le service de modèle d’accord est proposé comme service web REST de Salesforce par le package géré. Cela permet aux systèmes externes, en dehors de l’organisation Salesforce, de charger des accords en fonction des modèles d’accord existants. Consultez Création d’API REST avec Apex REST (en anglais) pour plus d’informations sur l’accès et l’invocation des services Apex REST personnalisés depuis Salesforce. Les appels doivent fournir un ID de session valide pour le processus d’authentification et d’autorisation.

Le service web est disponible à l’adresse suivante :

https://<nom_instance>.salesforce.com/services/apexrest/echosign_dev1/template/load/<template_id>?masterId=<master_id>&varName1=varValue1&varName2=varValue2

Remarque :
  • Le nom d’instance change en fonction de l’instance de votre organisation.
  • https://_<instance_name>_.salesforce.com/services/apexrest/echosign_dev1/template/load/<template_id> est une méthode HTTP POST pour les versions de package 20.0 et postérieures.
    • Les versions avant la version v20 utilisent une méthode GET.

ID de modèle

La dernière partie de l’URL est l’ID de l’enregistrement de modèle d’accord de l’organisation Salesforce actuelle devant être utilisé pour charger l’accord. Cette partie de l’URL est facultative. Si cette partie est omise, c’est le modèle d’accord par défaut qui est chargé. Si l’ID de modèle est omis et qu’aucun modèle d’accord n’est désigné par défaut, un message d’erreur apparaît.

Un ID de modèle comprend 15 ou 18 caractères.

ID principal

Le paramètre masterId définit l’enregistrement principal devant être utilisé pour charger l’accord depuis un modèle d’accord spécifique. Ce paramètre est facultatif, mais il doit être défini pour tout modèle d’accord spécifiant un type d’objet principal dont il est fait référence dans le modèle.

Un ID principal comprend 15 ou 18 caractères.

Variables d’exécution

Tous les paramètres supplémentaires sont utilisés en tant que variables d’exécution, comme paires nom-valeur, pour alimenter les variables d’exécution spécifiées dans le modèle d’accord.

Résultat

Le service web REST renvoie un objet LoadResult qui contient les champs suivants :

  • agreementId : lorsque le chargement de l’accord est réussi, contient l’ID de l’enregistrement de l’accord créé.
  • error : en cas d’erreur lors du chargement de l’accord, contient un message d’erreur détaillé.

Service d’arrière-plan

Le service d’arrière-plan permet aux utilisateurs de package d’invoquer plusieurs actions pour un objet d’accord, en mettant à jour la valeur correspondante dans le champ Action d’arrière-plan (echosign_dev1 Background_Actions c). Une fois la valeur vide ou la valeur contenue dans le champ remplacée par l’une des valeurs suivantes, l’action est activée par un déclencheur inclus dans le package géré de signature électronique.

  • Remind
  • Send
  • Cancel
  • Delete
  • Update

L’ensemble des actions s’exécute en mode futur asynchrone. Par conséquent, l’état est stocké dans le champ Erreur de l’accord.

Modifications de la rétrocompatibilité

  • Le statut de l’accord est désormais mis à jour une fois les documents et les destinataires mis à jour
    • Avant la version 21, le statut était défini avant.
  • L’objet Accord signé (contenant les URLs des images) n’est maintenant plus du tout inséré
    • Avant la version 21, il était inséré une fois toutes les autres mises à jour terminées.
  • La taille maximale d’une requête ou d’une réponse d’appel est limitée à 12 Mo pour l’Apex asynchrone selon les limitations du gouverneur Salesforce : https://developer.salesforce.com/docs/atlas.en-us.210.0.apexcode.meta/apexcode/apex_gov_limits.htm
    • Les documents dont la taille excède 12 Mo ne peuvent pas être récupérés d’Adobe Sign en raison de la limite ci-dessus.
  • Les descriptions des événements de l’accord ont changé. Elles correspondent désormais à la description renvoyée par l’API Sign avec les rapports d’audit.
  • Le processus de mise à jour s’exécute désormais comme un processus par lots Apex natif (qui est un processus asynchrone) dans Salesforce
    • Avant, il s’agissait d’une mise à jour effectuée à l’aide d’appels API provenant de l’extérieur de Salesforce
    • Il n’est désormais plus possible de déclencher ces mises à jour de statut qui lançaient les processus asynchrones, car Salesforce limite l’appel à un autre processus asynchrone à partir d’un processus asynchrone en cours d’exécution.
  • Avant la version 21, les mises à jour des attributs de l’accord étaient divisées entre des appels distincts de mises à jour. Désormais, l’objet de l’accord est entièrement mis à jour lors d’une seule transaction.
  • Avant la version 21, les accords qui avaient échoués ne pouvaient être récupérés qu’en effectuant une mise à jour manuelle de Salesforce
    • Désormais, les mises à jour sont plus fiables puisque le back-end Sign récupère automatiquement les événements ayant échoué selon un nombre de fois spécifié.
  • Les mises à jour manuelles mettent désormais à jour tous les aspects des accords, y compris les objets associés.
  • Les accords Push s’exécutent désormais en mode asynchrone, comme les mises à jour régulières et les attributs supplémentaires sont mis à jour également de la même façon que les mises à jour régulières.
  • De nouveaux paramètres ont été introduits pour activer la désactivation des mises à jour de différents aspects de l’accord.
  • Lorsqu’un fichier PDF signé est archivé dans Salesforce, aucun descripteur (-signé ou -approuvé) n’est désormais ajouté à la fin du nom du fichier PDF.
Logo Adobe

Accéder à votre compte