Eerst gerapporteerd: januari 2022
|
|
Augustus 2022 |
|---|
Het nieuwe IRS-formulier W-4 (2022), getiteld W-4 2022 (Employee's Withholding Certificate), zal naar verwachting worden toegevoegd aan de Adobe Sign-bibliotheek als onderdeel van de release van april 2022.
VEREISTE ACTIE
De nieuwe W-4-formuliersjabloon heeft een nieuwe libraryDocumentId. Als u de libraryDocumentId van de bestaande sjabloon gebruikt in uw toepassingen, dient u deze bij te werken.
De versie van 2021 wordt in juni 2022 uit het systeem verwijderd.
Elke applicatie/API die gebruikmaakt van het verouderde formulier (versie 2021), moet vóór 1 juni worden bijgewerkt om onderbrekingen in de dienstverlening te voorkomen.
De libraryDocumentId zoeken in een API-account:
- Meld u aan als accountbeheerder
- Klik op het tabblad Account > Adobe Sign-API > API-informatie > op de koppeling Documentatie REST-API-methoden
- Klik in de sectie GET /libraryDocuments op de knop OAUTH ACCESS-TOKEN
- Schakel het bereik library_read:self in
- Klik op Probeer het uit!
- Zoek in de hoofdtekst van de reactie naar de nieuwe formuliersjabloon W-4 2022 (Employee's Withholding Certificate) (niet versie 2021) om de waarde van de libraryDocumentId weer te geven.
|
Eerst gerapporteerd: juni 2022 |
Verwijderd uit huidige lijst: juli 2022 |
|---|
Er zijn twee nieuwe webhooks toegevoegd in de release van 14 juni:
- Vervaldatum overeenkomst bijgewerkt (AGREEMENT_EXPIRATION_UPDATED) (Alleen beschikbaar via REST v6-API POST /webhooks) - Wordt geactiveerd wanneer de vervaldatum van een overeenkomst wordt bijgewerkt.
- Naam ondertekenaar overeenkomst gewijzigd door ondertekenaar (AGREEMENT_SIGNER_NAME_CHANGED_BY_SIGNER) - Geactiveerd wanneer een ontvanger zijn naam bij het ondertekenen wijzigt naar een andere waarde dan de naam die is opgegeven toen de overeenkomst werd gemaakt.
Beide webhooks zijn beschikbaar.
|
Eerst gerapporteerd: juni 2022 |
Verwijderd uit huidige lijst: juni 2022 |
|---|
Op 8 juni 2022 heeft Acrobat Sign het kader voor meldingen gemigreerd voor de Microsoft Teams-, Outlook-, Word- en PowerPoint-integraties van callbacks naar webhooks. Dit verbetert de bezorging van meldingen en stelt gebruikers in staat om al hun Acrobat Sign-documentmeldingen te krijgen in hun favoriete integratie, ongeacht waar het document vandaan komt.
Nu de update voltooid is, krijgen eindgebruikers de opdracht om de Acrobat Sign-machtigingen opnieuw te accepteren, inclusief het bekijken, maken/bewerken en verwijderen van webhooks, voordat ze de integraties kunnen blijven gebruiken.
Opnieuw accepteren van de Acrobat Sign-toestemmingen is slechts één keer vereist en is van toepassing op Acrobat Sign in alle Microsoft 365-integraties. Deze toestemming wordt verleend op accountniveau en moet door eindgebruikers worden geaccepteerd.
Bezoek de juiste helppagina hieronder en controleer 'De geauthenticeerde relatie tot stand brengen' voor aanvullende informatie. Voor 'live' Acrobat Sign-ondersteuning, meld je aan bij je Acrobat Sign account en klik op de '?' vervolgens 'Contact opnemen met ondersteuning' om je ondersteuningsopties te bekijken.
De functie voor de klassieke toegangscode is vanaf de release van juni 2022 buiten gebruik gesteld
|
Eerst gerapporteerd: mei 2022 - Bijgewerkt: juni 2022 |
Verwijderd uit huidige lijst: juni 2022 |
|---|
De functie Toegangscode is volledig uit het Acrobat Sign-systeem verwijderd met de release van juni 2022, toen de klassieke pagina Beheren buiten gebruik werd gesteld.
Onderbreking van service voor de Custom Workflow Designer gepland voor 15 juni 2022, voltooid.
|
Eerst gerapporteerd: mei 2022 - Bijgewerkt: juni 2022 |
Verwijderd uit huidige lijst: juli 2022 |
|---|
De Custom Workflow Designer had een korte onderbreking van service om de onderliggende code bij te werken in samenhang met de grote release van 15 juni.
Tussen 15:00 en 15:30 Pacific Time, kon de workflow designer gebruikers mogelijk niet toestaan om een nieuwe workflow te maken of een workflow op te slaan die werd bewerkt.
Het gebruik van workflows om overeenkomsten te genereren werd niet beïnvloed tijdens deze tijd.
|
Eerst gerapporteerd: april 2021 |
Verwijderd uit huidige lijst: juni 2022 |
|---|
Vanaf 31 december 2021 worden Microsoft Internet Explorer 11 en oudere Microsoft Edge-browsers niet meer formeel ondersteund door Adobe Sign. We raden klanten aan om de Adobe Sign-applicatie niet meer te openen via deze browsers. Na 31 december 2021 kunnen klanten die deze browsers gebruiken een verminderde ervaring hebben en sommige functies kunnen ophouden met werken.
De elektronisch ondertekenen pagina van de ontvanger zou goed moeten blijven functioneren op deze browsers om verstoring van de workflows van de ontvanger te voorkomen. We doen er alles aan om deze overgang zo soepel mogelijk te laten verlopen.
|
Eerst gerapporteerd: november 2021 - Bijgewerkt: april 2022 |
Verwijderd uit huidige lijst: juni 2022 |
|---|
Adobe Acrobat Sign heeft de functierelease voltooid die gepland staat voor de eerste week van april 2022. Er was geen onderbreking tijdens deze release
De release van april 2022 bevat functieverbeteringen voor gebruikers en beheerders en biedt oplossingen voor problemen die door meerdere klanten zijn gemeld.
|
Eerst gerapporteerd: februari 2022 |
Verwijderd uit huidige lijst: juni 2022 |
|---|
Acrobat Sign heeft de nieuwe SSL-certificeringen vrijgegeven in de ochtend van 1 april 2022.
Er is geen wijziging aan de publieke sleutel, onderliggende cryptografische protocollen of het schema.
VEREISTE ACTIE
Gebruik van de openbare sleutel
- Als u op maat gemaakte integraties met Acrobat Sign hebt met behulp van de SOAP- of REST-API's en als een van deze integraties de bestaande openbare sleutel heeft "vastgezet", is geen actie vereist.
- Als je SSL-certificeringen van Acrobat Sign gebruikt voor SSO, of als je het certificeringen zelf vastpint (of andere methoden gebruikt), kun je de nieuwe Acrobat Sign-certificeringen vinden in de Adobe Acrobat Sign-systeemvereisten.
- Als uw SSO-configuratie meerdere openbare certificaten/ketens ondersteunt, kunt u de nieuwe certificaten nu toevoegen en de oude openbare certificaten/ketens verwijderen uit uw configuratie na de overstap van april.
- Als uw SSO niet meerdere openbare certificaten/ketens ondersteunt, moet u uw SSL-switch op 1 april 2022 synchroniseren met Acrobat Sign.
De nieuwe SSL-certificaten zijn vanaf 1 april 2022 actief.
|
Eerst gerapporteerd: maart 2022 |
Verwijderd uit huidige lijst: juni 2022 |
|---|
Acrobat Sign heeft op 3 mei 2022 een kleine functie-release voltooid.Er was geen onderbreking tijdens deze release
De mei 2022-release bevat één functieverbetering om op kennis gebaseerde authenticatie mogelijk te maken voor aanvullende deelnemers in webformulieren.
|
Eerst gerapporteerd: maart 2022 |
Verwijderd uit huidige lijst: mei 2022 |
|---|
Op 22 maart 2022 heeft Adobe Acrobat Sign de applicatietenant Acrobat Sign voor Office 365 bijgewerkt, de algemene applicatietenant voor de integraties van Word/PowerPoint, Outlook en Teams.
Vanaf 10.00 uur Eastern Daylight Time zijn beheerders/gebruikers mogelijk gevraagd om een machtigingsverzoek voor de applicatie opnieuw te accepteren voordat toegang wordt toegestaan. De exacte tijd hangt af van wanneer de door Microsoft uitgegeven verificatietoken van het account verloopt (tot 24 uur na het beginpunt).
Gepland onderhoud van de service voor aangepaste e-mailsjablonen (CEMT) van Adobe Sign - Voltooid
Op zaterdag 12 februari 2022, van 18:00 PST tot 19:00 PST, zal de Adobe Sign Custom Email Templates (CEMT) Service een korte verslechtering van service hebben terwijl kerninfrastructuuronderdelen worden geüpgraded. Gedurende deze tijd kunnen klanten standaard e-mailsjablonen zien in plaats van de verwachte aangepaste sjablonen. Er wordt geen uitval verwacht.
| Eerst gerapporteerd: september 2021 - Bijgewerkt: januari 2022 |
Verwijderd uit de actuele lijst: maart 2022 |
Adobe Sign heeft de release van januari 2022 voltooid zonder uitvaltijd in de applicatie.
De januarirelease bevat functieverbeteringen voor gebruikers en beheerders, evenals oplossingen voor meerdere door klanten gemelde problemen.
| Eerst gerapporteerd: september 2021 | Verwijderd uit de actuele lijst: maart 2022 |
Adobe Sign schaft de klassieke ervaringen voor de pagina's Start en Beheer af in de release van januari 2022. Op dat moment zullen alle accounts worden overgezet naar de moderne startpagina en beheer ervaring, zonder optie om terug te keren naar de klassieke interface.
Let op dat we er alles aan doen om deze overgang zo soepel mogelijk te laten verlopen. We hebben functies uitgebracht om het gedrag van de klassieke beheerpagina na te bootsen, waaronder:
- Gericht zoeken op voor- en achternaam.
- Afzenders kunnen nu een bericht toevoegen bij het vervangen van de ondertekenaar.
- Functionaliteit toegevoegd om CC's en ondertekenaars eraan te herinneren dat ze voltooid zijn.
In de release van december verbeteren we de zoekmogelijkheden verder en voegen we een functie voor een snelle blik op metadata toe.
Adobe Sign-verificatie leidt door naar Adobe Identity Management
|
Eerst gerapporteerd: augustus 2020 |
Verwijderd uit huidige lijst: |
|---|
Vanaf de Adobe Sign-release van september wordt de verificatiemethode van sommige gebruikers die zich rechtstreeks bij de Adobe Sign-applicatie verifiëren, omgeleid naar de Adobe Identity Manager.
Adobe standaardiseert deze authenticatiemethode voor het einde van 2020.
| Eerst gerapporteerd: september 2021 | Verwijderd uit huidige lijst: november 2021 |
Adobe Sign heeft de release van oktober 2021 voltooid zonder uitvaltijd in de toepassing.
De release van oktober bevat functieverbeteringen voor gebruikers en beheerders, en biedt oplossingen voor problemen die door meerdere klanten zijn gemeld.
| Eerst gerapporteerd: augustus 2021 | Verwijderd uit huidige lijst: november 2021 |
In de release van maart is een instelling ingevoerd om de mogelijkheid van een ontvanger om zijn naamwaarden te bewerken bij het ondertekenen, in of uit te schakelen, op voorwaarde dat de naam 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 release van september is deze functie bijgewerkt zodat de instelling voor naamvergrendeling nu voor alle soorten handtekeningen geldt, ook voor getypte handtekeningen.
- Klanten die Typen van hun naam en initialen hebben ingeschakeld en Ondertekenaars kunnen hun naam of initialen wijzigen hebben uitgeschakeld, zullen een gedragsverandering zien: de naamwaarde kan niet langer worden bewerkt 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 voor handtekeningen).
| Eerst gerapporteerd: augustus 2021 | Verwijderd uit huidige lijst: november 2021 |
Om te voldoen aan de wettelijke vereisten van Adobe werkt Adobe Sign het acceptatiegedrag van de gebruiksvoorwaarden (TOU) op de e-Sign-pagina bij. Bij de nieuwe ervaring moeten alle "onbekende" ontvangers de Adobe Sign TOU accepteren (door te klikken op de knop Doorgaan) alvorens in te gaan op de overeenkomst. Deze acceptatie staat los van eventuele aangepaste gebruiksvoorwaarden die het klantaccount mogelijk heeft geconfigureerd. Deze blijven gelden volgens de configuratie voor acceptatie van gebruiksvoorwaarden/algemene voorwaarden van het account.
- 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.
- Aanvaard de Klantgegevens en aangepaste ToU door de knop Klikken om te ondertekenen te selecteren.
Updates van API en de pagina Verzenden voor de integratiefunctie Notarize (verwacht in oktober)
| Eerst gerapporteerd: september 2021 | Verwijderd uit huidige lijst: november 2021 |
In de versie van oktober wordt een nieuwe functie van Adobe Sign geïntroduceerd ter ondersteuning van de integratie met het RON-platform (Remote Online Notarization) van Notarize, Inc.De Adobe Sign-integratie met Notarize, Inc. is beschikbaar voor gebruik in de Verenigde Staten.alleen.
Hieronder volgt een samenvatting van de wijzigingen:
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. Beschikbaar voor activering voor klanten in zakelijke en bedrijfsniveaus die rechtstreeks door Adobe worden verkocht via het ETLA-programma. De transacties in Notarize kunnen alleen door deze klanten als een add-on tegen een meerprijs worden gekocht.
Er zijn twee elementen die moeten worden beoordeeld door klanten die hun eigen apps bouwen of integraties gebruiken:
De pagina Verzenden heeft een nieuw element dat een ondertekenaar kan identificeren die een notariële akte moet ondertekenen, en bijkomende configuratiestappen om het ondertekeningsproces te begeleiden.
De REST-API is bijgewerkt om te voldoen aan de vereisten om deze functionaliteit te benutten. Klanten die de REST-API gebruiken, moeten het onderstaande bekijken om te bepalen of dit invloed heeft op hun huidige gebruik.
- Pagina-updates verzenden
Klanten bij wie Notarize Transactions is ingeschakeld, kunnen de optie Notariële akte vereist selecteren in de ontvangersrecord, rechts van de verificatiemethode:
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 |
ISO_DATE_TIME opgemaakte tekenreeks. 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.
| Eerst gerapporteerd: juli 2021 | Verwijderd uit huidige lijst: oktober 2021 |
Adobe Sign heeft op 16 september 2021 een functierelease voltooid. Er was geen onderbreking tijdens deze release
De release van september bevat functieverbeteringen voor gebruikers en beheerders, en biedt oplossingen voor problemen die door meerdere klanten zijn gemeld.
| Eerst gerapporteerd: juni 2021 | Verwijderd uit huidige lijst: oktober 2021 |
De beveiliging met een sms-bericht (met betrekking tot de verzendID die overeenkomt met de vermeende bedrijfsnaam in het bericht) is zodanig verbeterd dat Adobe Sign bij het verzenden van sms-berichten met een andere bedrijfsnaam de aflevering van het bericht kan doen mislukken.
Als gevolg hiervan wordt de optie om het bericht voor telefoonauthenticatie aan te passen met de bedrijfsnaam uit de service verwijderd in de release van september 2021.
Bekend probleem: Nieuwe start- of beheerpagina is leeg
|
Eerst gerapporteerd: februari 2020 |
Verwijderd uit huidige lijst: |
|---|
Probleem: Als ik overschakel naar de nieuwe pagina Start of Beheren, is deze pagina helemaal leeg.
Test: probeer deze pagina te laden: https://documentcloud.adobe.com/
- Als het niet mogelijk is om https://documentcloud.adobe.com/ te laden, moet u uw interne netwerkbeheerder verzoeken om het domein documentcloud.adobe.com te ontgrendelen.
- Als u wel toegang hebt tot de bovenstaande koppeling, neemt u contact op met ondersteuning
| Eerst gerapporteerd: juni 2021 | Verwijderd uit huidige lijst: oktober 2021 |
De API-call van v6 REST POST /workflows/ID/agreements is buiten gebruik gesteld in de release van juni 2021, een jaar na het verwijderen van de call uit de documentatie en het informeren van de gebruikers dat het eindpunt verwijderd zou worden.
Klanten die deze API-call blijven gebruiken, krijgen nu een 404-foutmelding.
Het voorgestelde alternatief voor het vervangen van deze functionaliteit is het gebruik van een call POST/agreement met een workflowID in het JSON-verzoek.
Voorbeeld van een verzoek:
| Eerst gerapporteerd: juni 2021 | Verwijderd uit huidige lijst: oktober 2021 |
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 code 404: AGREEMENT_NOT_EXPOSED geretourneerd totdat de volledige lijst van ondertekenings-URL's is voltooid. Op dat moment wordt een code 200 geleverd.
Klanten die de API-oproep niet willen blijven proberen totdat het 200-antwoord is geretourneerd, worden aangemoedigd om webhooks te gebruiken en te reageren op de AGREEMENT_CREATED-gebeurtenis.
Geplande onderbreking voor de integraties van Adobe Sign met Word/PowerPoint, Outlook en Teams
|
Eerst gerapporteerd: maart 2021 - Bijgewerkt: juni 2021 |
Verwijderd uit huidige lijst: |
|---|
Op zaterdag 17 juli 2021 heeft Adobe Sign het onderhoud aan de volgende integraties voltooid:
- Adobe Sign voor Microsoft Teams
- Adobe Sign voor Microsoft Word/PowerPoint
- Adobe Sign voor Microsoft Outlook
De integraties zijn nu operationeel en werken normaal.
| Eerste melding: juni 2021 - Bijgewerkt augustus 2021 | Verwijderd uit de huidige lijst: september 2021 |
Adobe Sign heeft de patch-update per 11 augustus 2021 voltooid. De patch is voltooid zonder downtime.
De patch-release van augustus bevat kleine ervaringswijzigingen en oplossingen voor problemen die door meerdere klanten zijn gerapporteerd.
Gepland einde van service voor de SOAP-API in mei 2021
|
Eerst gerapporteerd: juni 2018 - Bijgewerkt: februari 2021 |
Verwijderd uit de huidige lijst: september 2021 |
|---|
De release van versie 6 van de REST-API biedt de beste programmeerervaring voor Adobe Sign-ontwikkelaars. De SOAP-API is verouderd en wordt na mei 2021 niet meer ondersteund. De REST API-interface geniet nu de voorkeur bij integratoren en ontwikkelaars van toepassingen, en alle toekomstige ontwikkelingen dienen gebruik te maken van deze API.
Het onderstaande referentiemateriaal kan u helpen bij het doorvoeren van deze overgang:
- Migreren van SOAP
- Methoden voor Adobe Sign REST-API versie 6
VEREISTE ACTIE
Als u een integratie of een applicatie op basis van de SOAP-API hebt ontwikkeld voor de Adobe Sign-service, moet u deze vóór mei 2021 herschrijven met gebruik van de REST-API versie 6 of hoger. Om een vloeiende overgang naar de nieuwste API te waarborgen zullen we in de volgende kwartalen direct communiceren met ontwikkelaars van toepassingen en integraties.
Gepland einde van de service voor IE 11-browsers in Microsoft-integraties
|
Eerst gerapporteerd: januari 2021 |
Verwijderd uit de huidige lijst: september 2021 |
|---|
Microsoft beëindigt de ondersteuning voor Internet Explorer 11 op 17 augustus 2021.
Als gevolg hiervan beëindigen de Adobe Sign voor Microsoft-integraties ook de ondersteuning voor IE11, met gebruik van dezelfde tijdlijn.
De betrokken services zijn:
- Dynamics 365 (Online en On-Premise)
- Microsoft 365
- Outlook 365
- Power Automate/Power Apps
- SharePoint (Online en On-Premise)
- Teams
Gepland einde van de service voor de integratie van Adobe Sign met Dropbox
|
Eerst gerapporteerd: maart 2021 |
Verwijderd uit huidige lijst: augustus 2021 |
|---|
De integratie van Adobe Sign met Dropbox eindigt op 31 juli 2021.
Vanaf dat moment is Adobe Sign niet meer beschikbaar via je Dropbox-account. Al je Adobe Sign-overeenkomsten blijven echter beschikbaar en zijn toegankelijk door in te loggen op je Adobe Sign-account.
Nieuwe release: Adobe Sign van juni 2021
Adobe Sign heeft de release van juni 2021 voltooid zonder onderbreking.
De release van juni bevat functieverbeteringen voor gebruikers en beheerders, en biedt oplossingen voor problemen die door meerdere klanten zijn gemeld.
|
Eerst gerapporteerd: april 2021 |
Verwijderd uit huidige lijst: augustus 2021 |
|---|
Adobe Sign brengt op 1 juni 2021 nieuwe SSL-certificaten uit
Er zijn geen wijzigingen in de openbare sleutel, de onderliggende cryptografische protocollen of het schema.
De nieuwe certificeringen zijn beschikbaar voor downloaden vanaf de pagina met systeemvereisten van Adobe Sign.
VEREISTE ACTIE
Gebruik van openbare sleutel
Als u aangepaste integraties hebt met Adobe Sign en daarvoor SOAP of REST-API's gebruikt, hoeft u niets te doen, op voorwaarde dat de bestaande openbare sleutel is 'vastgezet' door een van deze integraties.
Als je SSL-certificeringen van Adobe Sign gebruikt voor SSO, of als je het certificaat zelf vastmaakt (of andere methoden gebruikt), vind je de nieuwe Adobe Sign-certificeringen in de systeemvereisten van Adobe Sign.
De nieuwe SSL-certificaten worden van kracht op 1 juni 2021
|
Eerst gerapporteerd: januari 2021 |
Verwijderd uit huidige lijst: juli 2021 |
|---|
Het nieuwe IRS-formulier W-4 (2021), getiteld W-4 2021 (Employee's Withholding Certificate) wordt naar verwachting tijdens de release van februari 2021 toegevoegd aan de Adobe Sign-bibliotheek.
VEREISTE ACTIE
De nieuwe W-4-formuliersjabloon heeft een nieuwe libraryDocumentId. Als u de libraryDocumentId van de bestaande sjabloon gebruikt in uw toepassingen, dient u deze bij te werken.
De versie van 2020 wordt in mei 2021 uit het systeem verwijderd.
Eventuele toepassingen/API's die het verouderde formulier (versie 2020) gebruiken, moeten vóór 1 mei worden bijgewerkt om onderbrekingen in de dienstverlening te voorkomen.
De libraryDocumentId zoeken in een API-account:
- Meld u aan als accountbeheerder
- Klik op het tabblad Account > Adobe Sign-API > API-informatie > op de koppeling Documentatie REST-API-methoden
- Klik in de sectie GET /libraryDocuments op de knop OAUTH ACCESS-TOKEN
- Schakel het bereik library_read:self in
- Klik op Probeer het uit!
- Zoek in de hoofdtekst van de reactie naar de nieuwe formuliersjabloon W-4 2021 (Employee's Withholding Certificate) (niet ver. 2020) om de waarde van de libraryDocumentId weer te geven.
Nieuwe release: Adobe Sign van mei 2021
|
Eerst gerapporteerd: maart 2021 |
Verwijderd uit huidige lijst: juli 2021 |
|---|
Adobe Sign heeft de release van mei 2021 voltooid zonder onderbreking.
De release van mei bevat functieverbeteringen voor gebruikers en beheerders, en biedt oplossingen voor problemen die door meerdere klanten zijn gemeld.
Update voor Adobe Sign-cookiebeheer
|
Eerst gerapporteerd: augustus 2020 |
Verwijderd uit huidige lijst: juli 2021 |
|---|
Adobe Sign neemt een nieuwe banner voor cookietoestemming van OneTrust over die blijft bestaan totdat de gebruiker expliciet een keuze maakt.
Gebruikers die tijdens de authenticatie worden omgeleid naar een nieuw domein, moeten een tweede keer toestemming geven voor het tweede domein (dit komt algemeen voor bij het omleiden van echosign.com naar adobesign.com vanwege de domeinschakelaar).
Gebruikers wordt geadviseerd om hun bladwijzers bij te werken en zo de omleiding te elimineren.
Invullen en ondertekenen heeft een pad voor sjablonen en geverifieerde ondertekening
|
Eerst gerapporteerd: maart 2020 |
Verwijderd uit huidige lijst: juli 2021 |
|---|
De Alleen ik onderteken-samenstellingspagina wordt vervangen door een nieuwe samenstellingspagina (gebaseerd op de nieuwste Verzend-paginaontwerpen) die het gebruik van sjablonen en de plaatsing van velden via authoring mogelijk maakt.
De beheerinstellingen bepalen de standaardervaring voor gebruikers. Met een optionele schakeloptie kunt u gebruikers de optie geven om te schakelen tussen de vrije interface Invullen en ondertekenen en de nieuwe ervaring voor zelfondertekening met ontwerpfunctionaliteit.
Nieuw voor deze ervaring is de mogelijkheid om de ondertekenaar te verifiëren.
De besturingselementen zijn gebaseerd op de Identiteitsauthenticatie afdwingen-instellingen. Indien ingeschakeld, wordt de gebruiker gevraagd om zijn Adobe Sign-inloggegevens in te voeren bij het openen van de overeenkomst en (optioneel) opnieuw wanneer hij een handtekening plaatst of de overeenkomst afrondt.
De besturingselementen voor de nieuwe ervaring voor zelfondertekening en voor Verificatie verplichten kunnen worden ingesteld op account- en/of groepsniveau (instellingen op groepsniveau overschrijven de instellingen op accountniveau)
Implementatieplan
De nieuwe ervaring voor zelfondertekening zal in de volgende twee grote releases de verouderde pagina Alleen ik onderteken vervangen.
Klanten die de verouderde functie Alleen ik onderteken gebruiken, dienen plannen te maken om tegen het najaar van 2020 te migreren naar de nieuwe ervaring, aangezien deze dan de standaard wordt en de oude pagina buiten werking wordt gesteld.
- In de release van juli worden de bestaande instellingen niet gewijzigd.
- In de volgende release wordt de nieuwe ervaring ingesteld als de standaard, met de optie om de oude pagina te gebruiken.
- In de release van het najaar van 2020 wordt de mogelijkheid om terug te gaan naar de oude interface verwijderd.
De Adobe Sign-update voor Word/PowerPoint, Outlook en Teams is vanaf 19 april beschikbaar
|
Eerst gerapporteerd: december 2020 - Bijgewerkt: maart 2021 |
Verwijderd uit huidige lijst: mei 2021 |
|---|
De update wordt van kracht om 8:00 uur PDT / 11:00 uur EST / 15:00 UTC
Deze update wordt uitgevoerd om de algehele beveiliging van deze drie integraties te verbeteren.
Nadat de update is voltooid, worden beheerders / gebruikers gevraagd om een machtigingsverzoek voor de toepassing opnieuw te accepteren voordat toegang wordt toegestaan.
Nieuwe release: Adobe Sign maart 2021
|
Eerst gerapporteerd: februari 2021 |
Verwijderd uit huidige lijst: mei 2021 |
|---|
Adobe Sign heeft de release voor maart 2021 voltooid zonder downtime.
Deze productrelease bevat nieuwe functies/verbeteringen voor beheerders en eindgebruikers, evenals meerdere opgeloste problemen.
Geplande "Einde van service" voor Edge Legacy-browsers in Microsoft-integraties
|
Eerst gerapporteerd: januari 2021 |
Verwijderd uit huidige lijst: mei 2021 |
|---|
Microsoft beëindigt de ondersteuning voor de Edge Legacy-browser op 9 maart 2021
Als gevolg hiervan beëindigen de Adobe Sign voor Microsoft-integraties ook de ondersteuning voor Edge Legacy, met gebruik van dezelfde tijdlijn.
De betrokken services zijn:
- Dynamics 365 (Online en On-Premise)
- Microsoft 365
- Outlook 365
- Power Automate/Power Apps
- SharePoint (Online en On-Premise)
- Teams
Einde van ondersteuning: Adobe Sign voor Microsoft Power Automate v1-acties - gepland voor januari 2021
|
Eerst gerapporteerd: juli 2020 |
Verwijderd uit huidige lijst: mei 2021 |
|---|
De Adobe Sign voor Power Automate 3.0-update introduceert nieuwe REST v6-handelingen die bedoeld zijn als robuustere versies van bestaande handelingen met dezelfde naam.
Workflows met verouderde handelingen blijven actief als er geen actie wordt ondernomen. De verouderde handelingen zijn gemarkeerd met (Oud) in hun naam. Deze verouderde handelingen worden in januari 2021 buiten gebruik gesteld.
De lijst met af te schaffen handelingen is:
- Maak een bibliotheeksjabloon van een document-URL (Oud)
- Een bibliotheeksjabloon maken vanaf een geüpload document (Oud)
- Een overeenkomst maken vanaf een document-URL en deze verzenden voor ondertekening (Oud)
- Een overeenkomst maken vanaf een bibliotheeksjabloon en deze verzenden voor ondertekening (Oud)
- Een overeenkomst maken vanaf een geüpload document en deze verzenden voor ondertekening (Oud)
- Een lijst met alle overeenkomsten ophalen (Oud)
- Een lijst met alle bibliotheeksjablonen ophalen (Oud)
- Formulierveldgegevens van een overeenkomst ophalen (Oud)
- Een document uploaden en een document-id ophalen (Oud)
De nieuwe handelingen worden in de lijst met handelingen weergegeven met dezelfde naam als de oude handelingen.
Klanten die deze handelingen gebruiken, moeten hun flows bijwerken om de nieuwe connector Handelingen te kunnen gebruiken. Dit kan gedaan worden door de verouderde handeling te vervangen door de nieuwe handelingen in uw bestaande automatiseringsflow.
Einde van de service voor sociale authenticatie
|
Eerst gerapporteerd: november 2020 |
Verwijderd uit huidige lijst: mei 2021 |
|---|
Vanaf maart 2021 kunnen ondertekenaars niet meer worden verplicht om hun sociale identiteit op te geven voordat ze toegang krijgen om het document te bekijken en te ondertekenen. Met deze functie konden afzenders zich aanmelden via Facebook, LinkedIn, Google, Yahoo!, Microsoft Live of Twitter.
Gepland 'einde van de service' voor persoonlijke Twitter-integratie
|
Eerst gerapporteerd: december 2020 - Bijgewerkt: januari 2021 |
Verwijderd uit huidige lijst: mei 2021 |
|---|
De optie om te integreren met Twitter op gebruikersniveau (via persoonlijke voorkeuren) wordt in maart 2021 uit de gebruikersinterface verwijderd. Vanaf dat moment:
- Kunnen nieuwe gebruikersaccounts Twitter niet inschakelen op gebruikersniveau
- Zien gebruikers die Twitter hebben ingeschakeld geen Twitter-berichten meer voor nieuwe overeenkomsten
- Wordt voor gebruikers met een gratis account waarvoor Twitter is ingeschakeld de maandelijkse transactielimiet verlaagd van tien naar:
- 5 transacties per maand voor Adobe Sign Web-klanten
- 2 transacties per maand voor Acrobat-klanten
- 5 transacties per maand voor Adobe Sign Web-klanten
- Voor ingeschakelde accounts worden de Twitter-inloggegevens verwijderd uit de Adobe Sign-systemen
- De Twitter-app van Adobe Sign wordt verwijderd en alle Twitter-tokens vervallen
Nieuwe release: Adobe Sign-versie van februari 2021
|
Eerst gerapporteerd: januari 2021 - Bijgewerkt: februari 2021 |
Verwijderd uit de actuele lijst: maart 2021 |
|---|
De release van februari is voltooid zonder downtime voor de service.
Deze productrelease bevat nieuwe functies/verbeteringen voor beheerders en eindgebruikers, evenals meerdere opgeloste problemen.
Foutberichten van Workflow Designer
|
Eerst gerapporteerd: september 2020 |
Verwijderd uit de actuele lijst: maart 2021 |
|---|
Vanwege de verbeterde beveiliging voor het delen van bibliotheekelementen, treedt bij sommige workflows een serverfout op bij het bewerken van de workflow na de update van september:
Als afzenders een workflow gebruiken waarop dit probleem van toepassing is, krijgen ze het foutbericht dat de workflow documenten bevat die buiten het bereik liggen:
Deze fout houdt in dat de workflow niet meer gemachtigd is om een of meer van de gekoppelde bibliotheeksjablonen te gebruiken. Dit gebeurt meestal wanneer de toegangsrechten van de sjabloon worden gewijzigd van het toestaan van account-/groeptoegang naar het beperken van toegang tot de eigenaar.
Beheerders dienen dit foutbericht te annuleren, en niet de pagina opnieuw te laden.
Foutcorrectie:
- De eigenaar van de sjabloon moet de sjabloonmachtigingen bewerken, zodat de sjabloon beschikbaar is voor het account of de groep waaraan de workflow is gebonden
- De eigenaar van de workflow kan de sjabloon vervangen door een sjabloon met de juiste machtigingen. Annuleer hiertoe de bovenstaande foutconditie en ga door met het bewerken van de workflow en het vervangen van het document
Einde van de service voor Adobe Sign voor Workplace van Facebook
|
Eerst gerapporteerd: november 2020 |
Verwijderd uit de huidige lijst: januari 2021 |
|---|
De Adobe Sign voor Workplace van Facebook-integratie is per 29 november 2020 volledig buiten gebruik gesteld.