Probleemsleutel
Laatst bijgewerkt op
2 apr. 2026
Aanvullende informatie over Adobe Sign: 2021
Adobe Sign: maart 2021
Verbeterde functionaliteit
Webformulieren voor meerdere ondertekenaars
Accounts die webformulieren gebruiken hebben nu de mogelijkheid om meerdere externe ontvangers toe te staan in het ondertekeningsproces.
Extra ontvangers worden gedefinieerd door de eerste ondertekenaar:
Gebruik bibliotheeksjablonen om webformulieren te maken
Auteurs kunnen nu bestaande bibliotheeksjablonen gebruiken om nieuwe webformulieren te maken.Het bestand wordt geïmporteerd met alle velden intact:
"Liquid Mode" in Adobe Sign voor mobiele weergave
Liquid Mode is een optionele functie voor het genereren van een responsieve weergave, zodat u de weergave van uw documenten kunt aanpassen aan het apparaattype van de ondertekenaar voor een optimale leeservaring.
Het ondertekende document wordt opgeslagen in de standaard "PDF"-versie terwijl de ontvangers de Liquid Mode kunnen bekijken op mobiele telefoons en kunnen schakelen om het originele document te bekijken.
Je kunt nu je HTML-document uploaden en een Liquid Mode-weergave genereren voor mobiele telefoons.
Vergrendel de naamwaarde voor bekende gebruikers bij ondertekenen via afbeelding- of getekende handtekeningmethoden
Er zijn situaties waarin het ongewenst is om de naam van de ontvanger tijdens het ondertekeningsproces te wijzigen. Adobe Sign biedt flexibiliteit in dit opzicht, met respect voor de naamvoorkeur van de ondertekenaar. In omgevingen waar naleving belangrijk is, is dergelijke flexibiliteit niet acceptabel, en is er een nieuw besturingselement waarmee de namen van de ontvangers worden gekoppeld aan de overeenkomst.
Beheerders hebben nu de mogelijkheid om ontvangers met bekende naamwaarden te voorkomen deze waarden te wijzigen wanneer ze een getekende of afbeeldinghandtekening toepassen.
Situaties waarbij de naamwaarde bekend is:
- Bij verzending naar een ontvanger met een Adobe Sign ID
- Bij het verzenden van de naam via de API
- Wanneer de ondertekenaarinfovelden worden ingevuld tijdens het invullen van het formulier
- Wanneer de naam wordt vergrendeld tijdens het voltooien van een KBA of officieel identiteitsbewijs authenticatie
Verbeteringen aan kennisgebaseerde authenticatie
Er zijn besturingselementen toegevoegd aan de KBA-methode van identiteitsauthenticatie die kunnen vereisen dat de afzender een naam voor de ontvanger verschaft en die naamwaarde wordt vergrendeld tijdens het ondertekeningsproces.
Opties voor verbeterde e-mailbeveiliging
Er zijn twee nieuwe opties beschikbaar om de e-mailbeveiliging te verbeteren. Beide instellingen zijn standaard ingeschakeld:
- Een koppeling in e-mails opnemen om de ondertekende overeenkomst weer te geven
- Een afbeelding van de eerste pagina van de overeenkomst opnemen in e-mailberichten
- Standaard ingeschakeld
- Wanneer ingeschakeld, is een afbeelding van de eerste pagina van de overeenkomst zichtbaar in sommige e-mailberichten
v6 REST API-updates
Standaardheaders in elke V6 REST API-aanvraag
Standaard heeft elke v6 REST API-aanvraag nu de onderstaande kopteksten:
/AGREEMENTS
Alle /agreements-eindpunten die een agreement id-pad hebben, retourneren nu een 404 AGREEMENT_DESTROYED-foutcode als de overeenkomst is verwijderd via AVG-tools.
BIBLIOTHEEKSJABLONEN
PUT /libraryDocuments/{libraryDocumentId} - Uitgebreid om het nieuwe veld ownerId op te nemen
Notitie
Alleen de v6 REST API wordt beïnvloed.
Elke v6 REST API-aanroep die deze headers niet bevat, zal deze afwezigheid expliciet documenteren.
- GET /libraryDocuments - Uitgebreid om het nieuwe veld ownerEmail op te nemen
- GET /libraryDocuments/{libraryDocumentId} - Uitgebreid om de nieuwe velden op te nemen: ownerId, ownerEmail en ownerName
Nieuwe velden in LibraryDocumentInfo object:
Velden met bijgewerkt gedrag:
WEBFORMULIEREN (/WIDGETS)
- POST /widgets - Het gebruik van een libraryDocumentId om een webformulier te maken wordt nu ondersteund met een geldige id
Statuscode toegevoegd:
- PUT /widgets - Het gebruik van een libraryDocumentId om een webformulier te maken wordt nu ondersteund met een geldige id
Statuscode toegevoegd:
- PUT /widgets/{widgetId} - Uitgebreid om het nieuwe veld ownerId op te nemen
Statuscode toegevoegd:
Wijzigingen in gebruikerservaring
- GET /widgets/{widgetId} - Uitgebreid om de nieuwe velden op te nemen: ownerId, ownerEmail, ownerName, en creatorName
Nieuwe velden in WidgetInfo object:
Velden met bijgewerkt gedrag:
/MEGA SIGN
NIEUW:
- GET /megaSigns/{megaSignId}/formFields - Haalt de formuliervelddetails op van een bovenliggende Mega Sign-overeenkomst
Parameters:
Reactieobject:
- PUT /megaSigns/{megaSignId}/formFields - Werkt de formuliervelden van een Mega Sign-overeenkomst bij
Parameters:
Reactieobject:
BIJGEWERKT:
- POST /megaSigns - AUTHORING is toegevoegd als een statewaarde om het ontwerpen van een Mega Sign-sjabloon te ondersteunen
Gewijzigde parameter:
- PUT /megaSigns/{megaSignId}/state - AUTHORING is toegevoegd als een state waarde om het ontwerpen van een Mega Sign template te ondersteunen.Als gevolg hiervan is megaSignCancellationInfo niet langer een verplicht veld
De moderne pagina's Start en Beheren zijn ingeschakeld voor alle resterende accounts
Voor alle accounts zijn de besturingselementen bijgewerkt om de moderne startpagina en Beheren-pagina's voor hun gebruikers in te schakelen.
De besturingselementen in het beheerdersmenu blijven beschikbaar voor accounts die moeten terugkeren naar de klassieke ervaring:
Adobe Sign serviceniveau en account-ID weergegeven in beheerdersmenu
Beheerders kunnen nu hun account-ID vinden op de pagina Globale instellingen:
De Groep-ID is te vinden op de Groepsinstellingen-pagina:
Expliciete HIPAA-configuratie
Er is een nieuwe pagina beschikbaar die duidelijk laat zien wanneer het account is ingeschakeld voor het beheer van overeenkomsten die onderhevig zijn aan HIPAA-vereisten.
- Dit besturingselement is alleen te zien op accountniveau. Beheerders op groepsniveau hebben hier geen toegang toe
- Deze controle is alleen-lezen, om duidelijk aan te geven wanneer het account is geconfigureerd
- Neem contact op met uw succesmanager of ondersteuning om de HIPAA-configuratie in te schakelen
De "Call to action"-knop is gewijzigd voor klanten die de Outlook desktop-applicatie gebruiken op Windows-systemen
Ontvangers die een Outlook Desktop-e-mailclient gebruiken, zien een wijziging in de "Oproep tot actie"-knop op Adobe Sign-e-mails.
De nieuwe ervaring verwijdert de blauwe HTML-knop en biedt in plaats daarvan een klikbare tekstkoppeling:
Notitie
Deze wijziging heeft alleen gevolgen voor Outlook desktop-applicaties op Windows-systemen. Bij andere e-mailclients en besturingssystemen is de sjabloon met de blauwe knop niet gewijzigd.
Delegatie van overeenkomsten met digitale handtekeningen
De mogelijkheid om een overeenkomst met toegevoegde digitale handtekeningen te delegeren is verbeterd. Delegatie is nu mogelijk vanuit de oorspronkelijke e-mailmelding naar de ontvanger, via automatische delegatie wanneer geconfigureerd door een gebruiker en via de actie Huidige ondertekenaar vervangen op de Beheren-pagina.
Bijgewerkte interface voor de betalingsintegratie
De Betalingen interface is bijgewerkt om de authenticatiecontroles beter zichtbaar te maken, waardoor een eenvoudiger configuratieproces ontstaat.
De maximale waarde voor Data Governance is verhoogd naar 5475 dagen (15 jaar)
Klanten die data governance-regels gebruiken om overeenkomsten automatisch te verwijderen uit het Adobe Sign-systeem kunnen die verwijderingsdatum nu instellen op maximaal 15 jaar (was tien jaar).
Het tekstlabel op veldniveau voor het valideren van het Amerikaanse burgerservicenummer is bijgewerkt:
Het tekstveld op veldniveau voor het valideren van het Amerikaanse burgerservicenummer is bijgewerkt om te verduidelijken dat het BSN specifiek Amerikaans is:
Herinnering: sociale authenticatie is verwijderd
Zoals aangekondigd in november is de authenticatiemethode met sociale identiteit verwijderd uit de lijst met authenticatiemethoden in het beheermenu.
Herinnering: persoonlijke Twitter-integratie is verwijderd
Zoals in december aangekondigd, is de mogelijkheid van de gebruikers om persoonlijk geverifieerde verbindingen met Twitter te maken, nu verwijderd.
Inactieve gebruikers ontvangen een e-mailbericht wanneer ze worden opgenomen in een overeenkomst
Gebruikers die zijn ingesteld op een Inactieve status ontvangen nu een e-mailbericht met de instructie om de overeenkomst te delegeren aan een andere gebruiker.
Opgeloste problemen
Adobe Sign: mei 2021
Verbeterde functionaliteit
Eigendom van bibliotheeksjablonen en webformulieren overdragen aan een andere gebruiker
Nu kan de eigenaar van een asset worden gewijzigd door elke beheerder in het account die toegang tot de asset heeft.
De beheerder kan het eigendom van het middel toewijzen aan elke gebruiker onder hun bevoegdheid.
- Accountbeheerders hebben toegang tot alle gedeelde assets en alle gebruikers. Daarom kunnen beheerders op accountniveau het eigendom van een bibliotheeksjabloon of webformulier opnieuw toewijzen aan een andere gebruiker in hun account
- Als de asset is geconfigureerd om alleen beschikbaar te zijn voor één gebruiker (de eigenaar), wordt deze niet gedeeld en kan niet opnieuw worden toegewezen aan een nieuwe eigenaar
- Groepsbeheerders hebben alleen toegang tot bibliotheeksjablonen en webformulieren binnen de groepen met beheerdersbevoegdheid
- Groepsbeheerders kunnen een middel alleen opnieuw toewijzen aan een gebruiker wiens primaire groep onder hun beheerbevoegdheid valt
BIJGEWERKTE API-EINDPUNTEN DIE OVERDRACHT VAN MIDDELEN ONDERSTEUNEN
De hieronder beschreven eindpunten zijn alleen beschikbaar in de v6 REST-API.
Uitgebreid met ondersteuning voor een update van de eigenaar van het bibliotheekdocument.
LibraryDocumentInfo:
Aanvullende foutstatuscodes:
Aanvullende foutstatuscodes:
Nieuwe velden in object LibraryDocument :
Nieuwe velden in LibraryDocumentInfo-object:
Velden met bijgewerkt gedrag:
Nieuwe velden in WidgetInfo-object:
Velden met bijgewerkt gedrag:
Wijzigingen in gebruikerservaring
De standaard v6 REST GET /workflows{workflowId} retourwaarde is gewijzigd
De v6 REST GET /workflows{workflowId} API-aanroep is bijgewerkt om de huidige versie van de WorkflowID te retourneren (in plaats van de oorspronkelijke versie-ID, wat de geretourneerde waarde was vóór de mei-release)
Deze update zorgt ervoor dat de standaard API-ervaring overeenkomt met de Webhook-ervaring en biedt dezelfde WorkflowID, wat de ontwikkeling en het beheer van applicaties zou moeten verbeteren.
Als om welke reden dan ook uw account vereist dat de API de oorspronkelijke ID retourneert (zoals het deed vóór de mei-release), neem dan contact op met ondersteuning om te verzoeken dat uw account de basisversie-ID's voor workflows retourneert
Opgeloste problemen
Adobe Sign: juni 2021
Gebruikers in meerdere groepen (UMG)
Beheerders met meerdere groepsaccounts kunnen gebruikers binnen hun account nu toegang verlenen tot meerdere groepen, waardoor groepen kunnen worden gebruikt als een vorm van workflowsjabloon. Zo kunnen specifieke verzend- en ondertekeningscontroles worden afgedwongen voor de bibliotheeksjablonen die beschikbaar zijn voor de groep.
Bestaande accounts voor ondernemingen en bedrijven die willen upgraden, kunnen het upgradeproces hier bekijken >
Een samenvatting van de belangrijke verschillen vindt u hier >
Introductie van Liquid Mode in Sign
Schakel de Liquid Mode in voor mobiele telefoons voor HTML-tekst die via Pagina verzenden of een sendAgreement-API wordt verzonden. De optie om Liquid Mode in Sign voor HTML in te schakelen is nu beschikbaar in de menulijst voor beheer. Dit geldt voor zowel account- als groepsniveau.
Volledige details over Liquid Mode-documenten kunt u hier vinden >
Notitie
Liquid Mode is momenteel alleen beschikbaar in NA1-, NA2- en NA4-omgevingen.
Naadloze updates van webformulieren
Webformulieren in concept-status kunnen op de volgende punten worden bewerkt:
- De webformuliernaam
- het e-mailadres van de medeondertekenaar(s)
- het e-mailadres van de personen in de CC
- De bijgevoegde bestanden die moeten worden bewerkt
- De velden op het webformulier (voorheen beschikbaar)
Als u een actief webformulier bijwerkt, kunt u de formulierelementen bewerken zonder de oorspronkelijke URL te wijzigen. Zo kunt u de inhoud van een webformulier dat al is ingesloten of naar uw doelgroep is verzonden, probleemloos bijwerken. Elementen die kunnen worden bewerkt zijn:
- De bestanden (documenten) en toegepaste velden voor de ontvangers
- Medeondertekenaars (vanaf de pagina Beheren)
- CC-partijen (vanaf de pagina Beheren)
Notitie
Als u naadloze webformulierfunctionaliteit wilt inschakelen, moet u de optie Extra deelnemers toestaan in het menu Algemene instellingen:
Deelnamestempel: weergave van titel en bedrijf controleren
Er zijn controles toegevoegd om de Titel en het Bedrijf van de ontvanger (afgeleid van het gebruikersprofiel) in het veld voor de deelnemersstempel toe te staan of te onderdrukken.
Meer details vindt u op de pagina Veldtypen >
Verbeterde zoekopties: zoeken op identieke voorvoegsels en frasen
Met de nieuwe geavanceerde zoekopties zijn nog specifiekere zoekpatronen mogelijk waardoor de lijst met geretourneerde overeenkomsten beperkt blijft.
Meer details over hoe Zoeken werkt in Adobe Sign vindt u hier >
OAuth 2.0 is de nieuwe standaard
Er is een nieuwe (verbeterde) versie van het OAuth-eindpunt toegevoegd om gebruiksfouten te voorkomen. Met deze versie:
- komt api_access_point / web_access_point alleen terug in het verzoek voor een toegangstoken (in de hoofdtekst)
- accepteert Adobe Sign het geheim niet als een queryparameter
- Client secret rotation wordt ondersteund
Het OAuth v1-eindpunt zal de komende maanden voor bestaande verbindingen blijven werken, zodat de toegang gewaarborgd blijft.
De afschaffing van OAuth v1 wordt aangekondigd op de pagina Technische meldingen zodra deze is gepland.
Rotatie van cliëntgeheimen
Cliëntgeheimen van applicaties kunnen worden geroteerd door elke beheerder met toegang tot de applicatie-ID in de Adobe Sign-gebruikersinterface:
Wijzigingen in gebruikerservaring
Groepsbeheerders kunnen alleen de API-applicaties zien die onder hun beheerdersbevoegdheid vallen
De zichtbaarheid van applicaties die aan de account zijn gekoppeld, is nu beperkt tot alleen die applicaties die onder het beheer van de gebruiker vallen. Alleen groepsbeheerders zullen de gedragswijziging zien:
- Gebruikers zien de applicaties die ze bezitten
- Groepsbeheerders zien de apps onder de groep(en) waarover ze beheerdersbevoegdheid hebben
- Accountbeheerders zien alle applicatie in de account
E-mail naar de afzender wanneer een overeenkomst is voltooid en bijgewerkt
De laatste kennisgeving per e-mail voor een overeenkomst die naar de afzender wordt gestuurd, is bijgewerkt en biedt nu een volledige lijst met alle partijen die van de voltooide overeenkomst op de hoogte zijn gebracht.
Alleen de oorspronkelijke afzender krijgt deze e-mailsjabloon.
Bijgewerkt v6 REST-API-resultaat voor GET /agreements/{agreementId}/signingUrls
Wanneer GET /agreements/{agreementId}/signingUrls wordt aangeroepen in een oudere versie dan de release van juni, wordt direct na het maken van de overeenkomst een 404-fout geretourneerd door de API.
Kort nadat de 404-fout is gewist, wordt vervolgens een niet-404-repons geretourneerd dat alleen de ondertekenings-URL's van de afzender bevat. (Terwijl de deelname van de ondertekenaar nog moet worden vastgesteld.)
Na de lancering in juni 2021 wordt een 404: AGREEMENT_NOT_EXPOSED-code geretourneerd totdat de volledige lijst van ondertekenings-URL's is voltooid. Op dat moment wordt een 200-code geleverd.
Klanten die de API-aanroep niet willen blijven proberen totdat de 200-respons is teruggestuurd, worden aangemoedigd om webhooks te gebruiken en te reageren op de AGREEMENT_CREATED-gebeurtenis.
Opgeloste problemen
Adobe Sign: augustus 2021
Wijziging in de gebruikservaring
- Internationale ondersteuning van Aadhaar: klanten van alle Adobe Sign-versies kunnen nu de optionele Aadhaar-service als digitale-handtekeningenprovider gebruiken. Tot nu toe was dit alleen beschikbaar voor accounts van de IN1-versie. De add-on voor Aadhaar kan worden gekocht tegen een meerprijs per handtekeningtransactie.
- REST v6-update: POST /users: de API-call van REST v6 POST /users is bijgewerkt om de gebruiker in de Standaardgroep van het account te maken als de optionele parameter primaryGroupId niet is gedefinieerd. Alleen de v6 van de REST API wordt door deze wijziging beïnvloed.
Opgeloste problemen
|
|
Beschrijving |
|---|---|
|
4299495 |
Een probleem opgelost in de Workflow Designer waarbij een door de klant gedefinieerde URL in de instructies niet zou werken. |
|
4308294 |
Een probleem gecorrigeerd in het rapport CSV-bestand waarbij de velden Aan en Naam ontvanger leeg zouden kunnen worden gelaten wanneer hetzelfde ontvanger e-mailadres meer dan eens wordt gebruikt in de overeenkomst. |
|
4310569 |
De Adobe Sign-sjablonen zijn gefilterd uit de sandbox-opties. |
|
4311098 |
Een probleem gecorrigeerd waarbij groepsbeheerders gebruikers in een groep niet konden bijwerken via CSV-upload. |
|
4311723 |
Een probleem opgelost waarbij de GET /groups/ID/users API-aanroep zou falen als de gebruiker zich op een andere Adobe Sign-instantie bevond. |
|
4312103 |
Een probleem gecorrigeerd waarbij SAML-gebruikers gemaakt via bulkupload in een status Gemaakt zouden staan (in plaats van Primaire). |
|
4312309 |
Een probleem gecorrigeerd waarbij groepsbeheerders het eigendom van webformulieren niet konden overdragen als andere gebruikers in hun groep deze hadden gemaakt. |
|
4312840 |
Er is een probleem opgelost met het activeren van nieuwe gebruikers wanneer een tweede activatie-e-mail werd verzonden naar de nieuwe gebruiker en die tweede e-mailkoppeling werd gebruikt. |
|
4314751 |
Een probleem gecorrigeerd waarbij de optie om de overeenkomst af te wijzen niet zichtbaar was bij ondertekenen namens een andere gebruiker. |
|
4315033 |
Er is een probleem opgelost waarbij accountbeheerders wachtwoorden niet opnieuw konden instellen wanneer de SAML-modus was ingesteld op Verplicht. |
|
4315605 |
Een probleem gecorrigeerd waarbij afbeeldingen van officieel identiteitsbewijs niet succesvol zouden worden verwerkt. |
|
4316057 |
Er is een probleem opgelost waarbij Officieel identiteitsbewijs een fout zou genereren die aangaf dat de vier hoeken van het document niet konden worden gevonden. |
|
4316474 |
Een probleem gecorrigeerd waarbij Ondertekenen namens zichtbaar was in accounts waar de optie niet was ingeschakeld. |
|
4316659 |
Probleem opgelost waarbij het e-mailadres voor 'actingUserEmail' in een GET /agreements/id-oproep een door het systeem gegenereerde e-mail terugstuurde nadat de overeenkomst volledig was ondertekend. |
|
4317095 |
Een probleem gecorrigeerd waarbij een naam van de ontvanger zou worden geïmporteerd in het label Deelnemer 1 wanneer Knowledge-based Authentication werd gebruikt voor de eerste ondertekenaar. |
|
4317221 |
Een probleem gecorrigeerd waarbij automatische e-mailberichten voor falende webhooks zouden worden verzonden naar de webhook-maker ondanks dat deze is geconfigureerd om de maker niet op de hoogte te stellen. |
|
4317347 |
Er is een probleem opgelost waarbij OAuth-authenticatie in Power Automate de gebruiker zou doorsturen naar de startpagina. |
|
4317429 |
Een probleem opgelost waarbij beheerders de eigenschap 'Can Send' voor gebruikers niet konden bijwerken bij het bijwerken via CSV-upload. |
|
4317548 |
Een probleem opgelost waarbij sommige klanten die de iPad gebruiken de webpagina zouden zien in plaats van de pagina geoptimaliseerd voor mobiele apparaten. |
|
4317629 |
Een weergaveprobleem opgelost met namen die een apostrof bevatten waarbij de HTML-code voor de apostrof werd weergegeven. |
|
4318175 |
Probleem opgelost waarbij gebruikers een foutmelding kregen bij het archiveren van een account via de e-mailkoppeling. |
|
4319012 |
Probleem opgelost waarbij gebruikers die waren gemaakt via REST v5 en v6 POST /users, niet in de standaardgroep werden gemaakt. |
|
4320197 |
Er is een probleem opgelost waarbij het Ondertekenaar-identiteitsrapport niet kon worden gedownload van de Beheren pagina omdat de knop inactief was. |
Adobe Sign: september 2021
Verbeterde functionaliteit
- Sandbox: klanten op het niveau Enterprise kunnen toegang tot een Sandbox-omgeving kopen om sjablonen, klantenworkflows, API-toepassingen en meer te testen. Deze objecten kunnen van productie naar sandbox worden verplaatst voor updates in een veilige omgeving, en vervolgens terug naar productie worden verplaatst zodra de updates zijn geverifieerd en klaar zijn voor implementatie.
- Ondersteuning voor ECDSA-digitale handtekening - Adobe Sign ondersteunt nu veiligere en efficiëntere digitale handtekeningen gebaseerd op het ECDSA-formaat, dat elliptische-curve cryptografie gebruikt zoals gedefinieerd in de ANS X9.62-2005 standaard.
NIST-krommen met SHA-2-hashfuncties, zoals gedefinieerd door FIPS-normen, worden nu ondersteund, waardoor onze partners van Trust Service Providers (TSP) van het Cloud Signature-consortium de optie hebben om ondertekenaars te voorzien van snellere en veiligere referenties van elliptische krommen, waaronder degene die voldoen aan de aanbevolen vereisten voor gebruik door de Amerikaanse federale overheid en de overheid van Singapore.
- Liquid Mode bijgewerkt: De ondertekeningservaring in Liquid Mode is uitgebreid van overeenkomsten naar webformulieren. Formulieren in Liquid Mode kunnen de ervaring van de ondertekenaar drastisch verbeteren doordat deze minder hoeft te pinnen en te zoomen om de content van het formulier te bekijken, terwijl de focus beter wordt gericht op de velden die moeten worden ingevuld.
Daarnaast is Liquid Mode niet langer beperkt tot Noord-Amerikaanse shards. Alle enterprise- en zakelijke accounts hebben nu toegang, ongeacht de locatie.
- Nieuwe TSP's : Cleverbase (Nederland), PrimeSign (Oostenrijk), Sectigo (wereldwijd) en TrustPro (Ierland) zijn de nieuwe Trust Service Providers van het Cloud Signature-consortium die certificaten leveren om veilige digitale handtekeningen toe te passen die voldoen aan de hoogste normen en nalevingseisen.
- De velden Aan en CC in e-mailheaders naar ontvangers aanpassen - Klanten die zich zorgen maken over het lekken van e-mailadressen via de e-mailheaders naar ontvangers kunnen ervoor kiezen om de e-mailadressen in de velden Aan en CC te verbergen.
- Deze optie is beschikbaar voor accounts op enterprise- en businessniveau en kan worden geconfigureerd op account- en groepsniveau.
- Deze functies zijn toegankelijk door te navigeren naar Accountinstellingen > E-mailinstellingen > Velden Aan en CC aanpassen.
Wijzigingen in gebruikerservaring
- Acceptatie van Adobe-gebruiksvoorwaarden op eSign-pagina's - Om te voldoen aan Adobe Legal-vereisten werkt Adobe Sign het acceptatiegedrag van de gebruiksvoorwaarden (ToU) bij op de eSign-pagina. Onder de nieuwe ervaring moeten alle 'onbekende' ontvangers de Adobe Sign ToU en het Privacybeleid accepteren (door op de knop Doorgaan te klikken) voordat ze interactie hebben met de overeenkomst. Deze acceptatie is afzonderlijk van eventuele aangepaste ToU die het klantaccount mogelijk heeft geconfigureerd, die zal blijven functioneren volgens de account TOU/CD-acceptatieconfiguratie.
- Een 'onbekende' ontvanger is elk e-mailadres dat niet het e-mailadres is van een geregistreerde, actieve gebruiker in een vertrouwd account.
- 'Bekende' gebruikers hebben de Adobe Sign ToU aanvaard als onderdeel van het registratieproces toen ze hun gebruikersaccount verifieerden. Aan hen wordt dus niet gevraagd om opnieuw te aanvaarden.
Hieronder staat een voorbeeld van de impliciete toestemmingsflow voor een overeenkomst met een aangepaste ToU die is geconfigureerd door de klant:
- Aanvaard de Adobe Sign ToU door op de knop Doorgaan te klikken (na het openen van de overeenkomst).
- Vul de velden van de overeenkomst in zoals vereist.
- Accepteer de Klantverklaring en aangepaste ToU door de knop Klik om te ondertekenen te selecteren.
- Vergrendeling van naamwaarden uitgebreid naar getypte handtekeningen - In de versie van maart werd een instelling geïntroduceerd om de mogelijkheid van een ontvanger om de naamwaarde te bewerken bij het ondertekenen in of uit te schakelen, mits de naam was verstrekt of bekend was (via API- of gebruikersprofiel). Getypte handtekeningen waren van deze functie uitgesloten, waardoor sommige ondertekenaars de waarde van hun naam tijdens het ondertekeningsproces konden wijzigen. In de versie van september is deze functie bijgewerkt, zodat de instelling voor het vergrendelen van de naam voor alle soorten handtekeningen geldt, ook voor getypte handtekeningen.
- Klanten die Hun naam en initialen typen hebben ingeschakeld en Ondertekenaars kunnen hun naam of initialen wijzigen hebben uitgeschakeld, zullen een gedragsverandering zien – de naamwaarde is niet langer bewerkbaar tijdens het ondertekeningsproces voor getypte handtekeningen.
- Klanten die bewerking van de naamwaarde tijdens het ondertekeningsproces willen toestaan, moeten de instelling Ondertekenaars kunnen hun naam of initialen wijzigen inschakelen (in het menu Voorkeuren handtekening).
- Inactieve gebruikers kunnen overeenkomsten ondertekenen - Adobe Sign behandelt inactieve gebruikers nu alsof ze onbekend zijn in het systeem (voor het doel van het ondertekenen van binnenkomende overeenkomsten). Wanneer een inactieve gebruiker wordt gevraagd een overeenkomst te ondertekenen, wordt een nieuwe, eenmalige gebruikers-ID gemaakt, speciaal om die ene overeenkomst te ondertekenen. De gebruikers-ID voor eenmalig gebruik staat los van de inactieve gebruikers-ID, en van de account waar deze onder valt. Dit heeft verschillende gevolgen:
- Overeenkomsten die naar een inactieve gebruiker worden gestuurd, kunnen worden ondertekend, aangezien de inactieve status niet van toepassing is op de voor de overeenkomst gegenereerde gebruikers-ID voor eenmalig gebruik.
- Overeenkomsten die door de gebruikers-ID voor eenmalig gebruik zijn ondertekend, zijn geen activa van de inactieve gebruikers-ID en bevinden zich niet in het account van de inactieve gebruikers-ID.
- Shares van de inactieve gebruikers-ID zullen geen overeenkomsten weergeven die zijn ondertekend door gebruikers-ID's voor eenmalig gebruik.
- Rapporten van de inactieve gebruikers-ID bevatten geen overeenkomsten die zijn ondertekend door de gebruikers-ID voor eenmalig gebruik.
- Als de inactieve gebruikers-ID opnieuw wordt geactiveerd, zijn de records van de overeenkomsten die zijn ondertekend door de gebruikers-ID voor eenmalig gebruik, niet meer op de beheerpagina te zien.
Er zijn twee uitzonderingen op de bovenstaande gedraging:
- Overeenkomsten die naar de gebruiker zijn gestuurd voordat deze als inactief werd gemarkeerd, kunnen niet worden ondertekend (de overeenkomst was al gebonden aan de inactieve gebruikers-ID).
- Gebruikers die expliciet zijn geconfigureerd om geen overeenkomsten te mogen ondertekenen, zullen nog steeds geen ondertekenacties mogen uitvoeren.
Inactieve gebruikers kunnen zich nog steeds niet aanmelden bij het Adobe Sign-systeem en geen overeenkomsten onder hun bevoegdheid verzenden (op welke manier dan ook).
- Verbeterde beveiliging voor toegang tot webformulieren via wachtwoord: in webformulieren is een vertraging opgenomen na een aantal mislukte pogingen om toegang te krijgen tot een URL die met een wachtwoord is beveiligd.
- Internationale ondersteuning van Aadhaar: klanten van alle Adobe Sign-versies kunnen nu de optionele Aadhaar-service als digitale handtekeningenprovider gebruiken. Tot nu toe was dit alleen beschikbaar voor accounts van de IN1-versie. De add-on voor Aadhaar kan worden gekocht tegen een meerprijs per handtekeningtransactie.
- Beperkt delen van overeenkomsten - Het delen van overeenkomsten is beperkt wanneer de overeenkomst wordt gedeeld met een extern e-mailadres.
- Accounts met meerdere licenties kunnen een overeenkomst tot tien keer delen.
- Individuele accounts kunnen een overeenkomst tot vijf keer delen.
- Het delen van een overeenkomst met interne gebruikers is onbeperkt.
- Accounts met meerdere licenties kunnen een overeenkomst tot tien keer delen.
- Aanpasbare bedrijfsnaam in de verificatie met telefoonnummer is uit de service verwijderd: de waarde voor de aanpasbare bedrijfsnaam die kon worden ingevoegd in de verificatiemethode met telefoonnummer, is uit service verwijderd zoals aangekondigd in de technische melding van juni.
- HIPAA-accounts hebben nu toegang tot de knoppen voor afbeeldingen en koppelingen in e-mails van ontvangers op de pagina Wereldwijd/Groepsinstellingen.
- De volgorde waarin Bestandsbijlagen worden opgenomen in de definitieve PDF is bijgewerkt om eerst te sorteren op paginanummer en vervolgens op veldpositie (bij het lezen van links naar rechts; van boven naar beneden)
- Met de functie Ontvanger vervangen op de nieuwe pagina Beheer kan de afzender nu een optioneel bericht voor de nieuwe ontvanger opnemen.
- Externe ondertekenaars die toegang hebben tot voltooide overeenkomsten, moeten nu een verificatieproces doorlopen wanneer meervoudige verificatie is geconfigureerd voor de overeenkomst (in plaats van te worden gevraagd zich aan te melden bij Adobe Sign).
- Webformulieren rapporteren nu de veldwaarden van niet-geverifieerde webformulieren bij het openen van veldgegevens met behulp van de functie Formulierveldgegevens downloaden op de pagina Beheer.
API-updates
- Optie voor webformulieren om de overeenkomst te lezen: er zijn twee nieuwe REST v6 API-calls beschikbaar die toegang bieden om webformulieren te bekijken:
- GET /widgets/<resourceId>
- GET /widgets/<resourceId>/combinedDocument/url
- GET/workflows/{workflowId} retourneert nu de deelnemersrol in het antwoord.
Opgeloste problemen
| 4292343 | Verbeterde handtekeningen bij gebruik van de optie TYPE-handtekening op mobiele apparaten. |
| 4295123 | Er is een probleem opgelost waardoor digitale handtekeningen niet zichtbaar waren bij het openen in een browser. |
| 4299289 | De ervaring met het vervangen van ontvangers is verbeterd doordat de verzender een bericht aan de nieuwe ontvanger kan toevoegen. |
| 4299857 | Er is een probleem opgelost waardoor het certificaatzegel niet werd aangebracht op een ondertekende overeenkomst. |
| 4304261 | Er is een probleem opgelost waardoor de optie Leesovereenkomst soms niet in het menu Opties verscheen |
| 4308516 | Er is een probleem opgelost waarbij gebruikers steeds om toestemming van de beheerder werd gevraagd bij gebruik van OneDrive |
| 4310225 | Er is een probleem opgelost met overeenkomsten met meerdere handtekeningen die een serverfout konden veroorzaken: Foutbericht: De handtekening op dit document is ongeldig. Verwijder deze en teken opnieuw. |
| 4310416 | De v5 REST-API is bijgewerkt om gebruikers in een actieve status te maken wanneer ze worden gemaakt via POST/gebruikers |
| 4311287 | Er is een probleem opgelost waarbij de knop Groepsnavigatie verdween op UMG-accounts nadat een gebruiker uit een groep was verwijderd. |
| 4311956 | Er is een probleem opgelost waarbij de lettergrootte voor een veld niet werd weergegeven in de ervaring van de ondertekenaar. |
| 4312302 | Er is een probleem opgelost waarbij de optie Wachtwoord opnieuw instellen werd verwijderd als de SAML-modus op Verplicht stond. |
| 4312735 | Er is een probleem opgelost waarbij meldingen van gedeelde gebeurtenissen werden bezorgd wanneer gedeelde meldingen waren uitgeschakeld. |
| 4313025 | Er is een probleem opgelost waarbij een Form Filler-rol niet-toegewezen rollen niet kon invullen wanneer hybride routering was ingeschakeld. |
| 4313030 | Er is een probleem opgelost waarbij UMG-accounts een fout activeerden bij gebruik van een aangepaste workflow als de primaire groep van de afzender niet mocht verzenden. |
| 4313264 | De HIPAA-instelling is bijgewerkt om toegang te verlenen tot de instellingen voor e-mailkoppelingen/afbeeldingen op de pagina Globale instellingen. |
| 4315839 | Er is een probleem gecorrigeerd met aangepaste workflows waarin het vooraf invullen van velden niet was toegestaan wanneer de afzender ook de tweede ontvanger was. |
| 4316058 | De gedraging van rapportvelden is aangepast om voorloopnullen in tekstvelden toe te staan. |
| 4317382 | Er is een probleem gecorrigeerd met keuzerondjes die de HTML-code voor apostrofs in de tooltip weergeven |
| 4317978 | De manier waarop bestandsbijlagen worden geordend in de uiteindelijke PDF, is aangepast: bijlagen worden nu eerst gegroepeerd op basis van het paginanummer van het veld, en daarna op de relatieve positie van het veld (bij lezen van links naar rechts - van boven naar beneden). |
| 4318598 | De GET/workflows/{workflowId} REST v6 API-oproep geeft nu de deelnemersrol weer in de respons. |
| 4318606 | De functie Formulierveldgegevens downloaden op de beheerpagina geeft nu veldwaarden weer voor webformulieren die nog niet zijn geverifieerd. |
| 4318617 | Er is een probleem opgelost waardoor groepsbeheerders in UMG-accounts een uitnodiging niet opnieuw konden verzenden. |
| 4318679 | Er is een incidenteel probleem opgelost waardoor schriftelijke handtekeningdocumenten niet konden worden geüpload. |
| 4318926 | Er is een probleem gecorrigeerd dat een fout kon veroorzaken (De cookiefunctionaliteit is uitgeschakeld in uw browser) bij het genereren van een overeenkomst van een mobiel apparaat. |
| 4318991 | Er is een probleem opgelost waardoor de instelling voor het maximum aantal mislukte aanmeldingen werd genegeerd als SAML was ingesteld op Toegestaan. |
| 4319068 | Externe ontvangers moeten nu een tweede authenticatieproces doorlopen (in plaats van in te loggen bij Adobe Sign) om toegang te krijgen tot voltooide overeenkomsten wanneer multifactorverificatie is geconfigureerd. |
| 4319422 | Er is een probleem opgelost waarbij een ontvanger kon worden vervangen zonder het wachtwoord te bevestigen (voor wachtwoordgeauthenticeerde overeenkomst) |
| 4319455 | Er is een probleem opgelost met geavanceerd delen waarbij de instellingen na niet altijd behouden bleven. |
| 4320123 | Er is een probleem opgelost waarbij een fout kon optreden wanneer u een overeenkomst probeerde te bekijken en goed te keuren op de pagina Beheren. |
| 4320205 | Er is een probleem opgelost waardoor de voortgang niet kon worden opgeslagen bij het vooraf invullen van een overeenkomst via geavanceerd delen. |
| 4320542 | Er is een probleem opgelost voor UMG-accounts waarbij alle groepsverbanden van een gebruiker soms werden verwijderd als één groep werd verwijderd met het gebruik van zoeken. |
| 4321357 | Er is een probleem opgelost dat een fout kon veroorzaken op de verzendpagina wanneer KBA was geselecteerd voor verificatie en Naam vereist bij verzenden was ingeschakeld. |
| 4322445 | Verbeterde authoring om consistente achtergrondkleuring te garanderen. |
| 4322956 | Er is een probleem opgelost met aangepaste e-mailsjablonen waarbij de ontvangers het werkelijke e-mailadres van de ondertekenaar niet te zien kregen. |
| 4323609 | In ontwikkeling - Er is een probleem opgelost waarbij overeenkomsten die werden voltooid door het uploaden van een ondertekend document, niet de AGREEMENT_WORKFLOW_COMPLETED-webhookmelding activeerden. |
| 4323968 | De vergrendelingsfunctie voor handtekeningen is verbeterd, zodat deze nu ook typehandtekeningen omvat wanneer de naamwaarde wordt geleverd via profiel of API. |
Adobe Sign: oktober 2021
Verbeterde functionaliteit
- Koppelingen om misbruik te rapporteren: Accounts voor kleine bedrijven en particulieren hebben nu een koppeling waarmee ontvangers mogelijk misbruik kunnen melden bij binnenkomende verzoeken van een overeenkomst.
- Integratie met Notarize - Door de integratie van Adobe Sign met het RON-platform (Remote Online Notarization) van Notarize, Inc. kunnen klanten een externe online notarisservice toevoegen als onderdeel van hun transacties in Adobe Sign. Dit is beschikbaar voor klanten in de VS op zakelijk en bedrijfsniveau en wordt rechtstreeks door Adobe via het ETLA-programma verkocht. De transacties in Notarize kunnen alleen door deze klanten als een add-on tegen een meerprijs worden gekocht.
- Verzend paginda-updates - Klanten met notarisfunctie kunnen de optie Notariële akte vereist selecteren op de ontvangersrecord, rechts van de verificatiemethode:
- Verzend paginda-updates - Klanten met notarisfunctie kunnen de optie Notariële akte vereist selecteren op de ontvangersrecord, rechts van de verificatiemethode:
Notitie
Klanten die de geïntegreerde pagina Verzenden in hun applicaties of integraties gebruiken, krijgen ook toegang tot de notarisfunctionaliteit.
Nadat de overeenkomst is geconfigureerd en de afzender op Volgende heeft geklikt, krijgt de afzender aanvullende configuratieopties voor het notarisatieproces:
- API-updates - Er zijn belangrijke updates voor de API's om de Notarize-integratie te ondersteunen:
POST /agreements
De POST /agreements-API is bijgewerkt om het versturen van een overeenkomst voor notariële akte te ondersteunen.
- De nieuwe rol, NOTARY_SIGNER, moet worden gebruikt om een deelnemer aan een notariële zitting aan te geven.
- Het nieuwe kenmerk NotaryInfo is toegevoegd aan de AgreementInfo om alle opties te bevatten die geassocieerd zijn met het maken van een nieuwe overeenkomst waarvoor notariële bekrachtiging vereist is.
|
Parameternaam |
REST-object |
Beschrijving |
||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
memberInfos |
ParticipantInfo[] |
Reeks ParticipantInfo-objecten, die deelnemerspecifieke gegevens bevatten (zoals e-mail). Alle deelnemers in de reeks behoren tot dezelfde set. |
||||||||||||||||
|
rol |
|
Rol van alle deelnemers aan de reeks (ondertekenaar, goedkeurder, enz.) |
FileInfo-extensie
De FileInfo-definitie moet worden uitgebreid om aan te geven welke documenten notarieel moeten worden bekrachtigd.
|
Parameternaam |
Type |
Standaard |
Vereist |
Beschrijving |
|---|---|---|---|---|
|
document |
Document |
|
optioneel |
Een document dat is gekoppeld aan de overeenkomst. |
|
label |
Tekenreeks |
|
optioneel |
De unieke labelwaarde van een bestandsinfo-element Bij een aangepaste workflow wordt hierdoor een bestand toegewezen aan het overeenkomstige bestandselement in de workflowdefinitie. |
|
libraryDocumentId |
Tekenreeks |
|
optioneel |
ID voor een bestaand bibliotheekdocument dat aan de overeenkomst zal worden toegevoegd |
|
transientDocumentId |
Tekenreeks |
|
optioneel |
ID voor een tijdelijk document dat aan de overeenkomst zal worden toegevoegd |
|
notarize |
true |
false |
optioneel |
Geeft aan dat dit document notarieel bekrachtigd moet worden. |
ParticipantInfo-extensie
De ParticipantInfo-definitie is uitgebreid om de notaris-authenticatiemethode te specificeren.
|
Parameternaam |
Type |
Standaard |
Vereist |
Beschrijving |
|---|---|---|---|---|
|
|
Tekenreeks |
N.v.t. |
vereist |
E-mailadres van de deelnemer. |
|
notaryAuthentication |
Enum |
MULTI_FACTOR_AUTHENTICATION |
optioneel |
MULTI_FACTOR_AUTHENTICATION - De authenticatie van de notaris wordt uitgevoerd met een twee-factor-verificatiemethode |
NotaryInfo
Een nieuw optioneel veld notaryInfo is toegevoegd aan de AgreementInfo-definitie om het NotaryInfo-kenmerk te bevatten dat aanvullende opties specificeert die verband houden met notariële bekrachtiging.
|
Parameternaam |
Type |
Standaard |
Vereist |
Beschrijving |
|---|---|---|---|---|
|
notaryType |
Enum |
Als alleen Notarize Notary on Demand Service is ingeschakeld in het account, |
vereist |
NOTARIZE_NOTARY - Notarize Service levert de notaris |
|
payment |
Enum |
BY_SENDER |
optioneel |
Alleen van toepassing indien type== NOTARIZE_NOTARY |
|
appointmentStart |
Tekenreeks |
"" |
optioneel |
Geformatteerde tekenreeks ISO_DATE_TIME Zie ISO_ZONED_DATE_TIME |
|
note |
Tekenreeks |
blanco |
optioneel |
Notities voor notariszitting. |
|
notaryEmail |
Tekenreeks |
"" |
optioneel |
e-mail van de breng uw eigen notaris |
Example /agreement
PUT|GET /agreements/{aid}
PUT /agreements/{aid} API zal het bijwerken van een overeenkomst met notariële opties ondersteunen. GET /agreements/{aid} API zal alle opties retourneren die zijn ingesteld voor de notariële overeenkomst. Zie de sectie POST /agreements om bijgewerkte attributen te zien.
Foutcodes
Bestaande foutcodes voor POST /agreements blijven ongewijzigd. Wij hebben een nieuwe foutcode gedefinieerd zoals hieronder:
|
REST-foutcode |
HTTP-statuscode |
Bericht |
Scenario |
|---|---|---|---|
|
PERMISSION_DENIED |
403 |
Gebruikersinstelling of OAuth-scopetoken staan het verzenden van een overeenkomst voor notariële akte niet toe. |
Deze foutmelding wordt weergegeven wanneer de rol op NOTARY_SIGNER is ingesteld en de API-caller (d.w.z. de toekomstige verzender) de notarisfunctie niet heeft geactiveerd en/of wanneer de notarisserviceprovider niet is ingesteld. |
Documentatie-impact
In het AgreementInfo-object van de verzoek bevat het element 'status' de nieuwe overeenkomststatus WAITING_FOR_NOTARIZATION.
POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens
De API kan door klanten (ondertekenaars van notariële akten) worden gebruikt om een ondertekeningstoken te verkrijgen waarmee ze de fase van elektronisch ondertekenen van de flow kunnen voltooien.
- Er is een nieuwe ondertekeningsmogelijkheid toegevoegd om de nieuwe rol vast te leggen - ACCEPT_BEFORE_NOTARIZATION.
- Ondertekeningstokens mogen niet niet worden verkregen om de notariële fase te voltooien.
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status
De API kan door klanten (notariële ondertekenaars) worden gebruikt om de fase van elektronisch ondertekenen van de flow te voltooien. Om aan de nieuwe rol tegemoet te komen is een nieuwe enum-statuswaarde ingevoerd - ACCEPTED_BEFORE_NOTARIZATION
|
Kenmerk |
Type |
Beschrijving |
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Status |
Enum<String>
|
|
||||||||||||||
De ondertekenaar van de notaris kan de onderstaande reeks API-oproepen volgen om de fase voor elektronische ondertekening te voltooien:
- GET /agreements/{agreementId}/members - de deelnemer-ID van de ondertekenaar van de notaris en de deelnemer-set-ID ophalen
- POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens - ondertekeningstoken voor notariële ondertekenaar met ACCEPT_BEFORE_NOTARIZATION-mogelijkheid aanvragen
- POST /transientDocuments - document uploaden dat is beoordeeld
- PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status - beoordeeld document indienen en de fase voor elektronische ondertekening voltooien.
Nieuwe webhook-gebeurtenis
Klanten kunnen lid worden van een nieuwe webhookgebeurtenis, AGREEMENT_READY_FOR_NOTARIZATION, om op de hoogte te worden gesteld wanneer de overeenkomst gereed is voor notariële bekrachtiging. De event is niet zichtbaar in de webhooks-UI en u kunt zich ervoor aanmelden via POST /webhooks API-call.
Documentatie-impact
De volgende API's zijn niet gewijzigd, maar hun documentatie is bijgewerkt met de nieuwe overeenkomststatus WAITING_FOR_NOTARIZATION of de nieuwe rol NOTARY_SIGNER.
GET /agreements
In het UserAgreements/UserAgreement-object bevat het element 'status' nu de overeenkomstige status "WAITING_FOR_NOTARIZATION".
GET /agreements/{agreementId}
In het AgreementInfo-object bevat het element 'status' nu de corresponderende status "WAITING_FOR_NOTARIZATION".
GET /agreements/{agreementId}/events
API is bijgewerkt om nieuwe READY_TO_NOTARIZE- en NOTARIZED-gebeurtenissen te ondersteunen.
In het responsobject Gebeurtenis
- Het element participantRole bevat nu de nieuwe rol NOTARY_SIGNER.
- element 'type' bevat de nieuwe gebeurtenissen READY_TO_NOTARIZE en NOTARIZED. element 'description' wordt respectievelijk Document verzonden voor notariële akte en Notarieel document ontvangen
GET /agreements/{agreementId}/members/participantSets/{participantSetId}
In het responsobject DetailedParticipantSetInfo bevat het element 'status' nu de bijbehorende status WAITING_FOR_NOTARIZATION.
PUT /agreements/{agreementId}
Verzoeksobject AgreementInfo bevat nu de status WAITING_FOR_NOTARIZATION.
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}
De status WAITING_FOR_NOTARIZATION is een van de waarden van het element 'status' in het object DetailedParticipantSetInfo.
POST /agreements/{agreementId}/view
De status WAITING_FOR_NOTARIZATION is toegevoegd als een van de toegestane weergaven.
GET /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingInfo
Als de in het verzoekpad opgegeven deelnemer de rol van notariële ondertekenaar heeft, zal de API de ACCEPT_BEFORE_NOTARIZATION-ondertekeningsconfiguratie retourneren, in overeenstemming met alle andere ondertekeningsconfiguraties voor deze overeenkomst/deelnemer.
Opgeloste problemen
| Probleem | Beschrijving |
| 4308901 | Er is een probleem verholpen waarbij het delegeren van een overeenkomst met telefoonverificatie een fout veroorzaakte als het gedelegeerde telefoonnummer dezelfde landcode had. |
| 4314113 | Er is een probleem verholpen waarbij standaard vervaldatums door gebruikers niet konden worden bewerkt bij het verzenden van een nieuwe overeenkomst |
| 4318558 | Er is een probleem verholpen waarbij het vervangen van een ontvanger met telefoonverificatie de foutmelding De opgegeven ID van de deelnemer is ongeldig opleverde |
| 4319038 | Er is een probleem verholpen waarbij de verzender de optie voor Identiteitscontrole van externe ontvangers niet kreeg bij verzending via de workflow In bulk verzenden. |
| 4319798 | Er is een probleem verholpen waarbij de cursor soms naar een ander veld sprong bij de selectie van een keuzerondje. |
| 4320154 | Er is een probleem verholpen waardoor een bibliotheeksjabloon niet in een nieuwe groepsrelatie kon worden opgeslagen. |
| 4323013 | Er is een probleem verholpen waarbij het openen van een webformulier op de pagina Beheren de volgende fout gaf: Het document is nog niet beschikbaar of er zijn geen pagina's om te bekijken. |
| 4323554 | Er is een probleem verholpen waarbij de tijd- en datumstempels van een gebeurtenis voor het bijwerken van beheerdersrechten twee records met dezelfde tijdwaarde genereerden. |
| 4323609 | Er is een probleem verholpen waarbij het uploaden van een ondertekende overeenkomst in de pagina Beheren de webhook AGREEMENT_WORKFLOW_COMPLETED niet activeerde. |
| 4325142 | Er is een probleem verholpen waarbij aangepaste e-mailsjablonen de juiste naamwaarde voor een deelnemer niet weergaven als deze de overeenkomst annuleerde. |
| 4326747 | Er is een probleem verholpen waardoor de pagina In bulk verzenden het laadproces niet voltooide, waardoor de acties Uploaden en Verzenden niet werden uitgevoerd. |
| 4326855 | Er is een probleem verholpen waardoor ontvangers de goedkeuring van een overeenkomst niet konden weigeren. |
| 4327000 | Er is een probleem verholpen waardoor de inloggegevens van Smart-Id konden mislukken, met de foutmelding dat er geen algoritmen waren gevonden. |
