Ärende-ID
Senast uppdaterad den
2 apr. 2026
Versionsinformation för Adobe Sign: 2021
Adobe Sign: mars 2021
Förbättrade funktioner
Webbformulär för flera undertecknare
Konton som använder webbformulär kan nu tillåta flera externa mottagare i signeringsprocessen.
Extra mottagare definieras av den första signeraren:
Använd biblioteksmallar för att skapa webbformulär
Författare kan nu använda befintliga biblioteksmallar för att skapa nya webbformulär.Filen importeras med alla fält intakta:
"Flytande läge" i Adobe Sign för mobilvisning
Liquid Mode är en valfri funktion som skapar en responsiv vy som förbättrar visningen av dokument baserat på signerarens enhetstyp.
Det signerade dokumentet lagras i standard-PDF-versionen medan mottagarna kan se Liquid Mode på mobiltelefoner och kan växla för att visa originaldokumentet.
Du kan nu ladda upp ditt HTML-dokument och generera en Liquid Mode-vy för mobiltelefoner.
Lås namn-värdet för kända användare vid signering via bild- eller ritade signaturmetoder
Det finns situationer där möjligheten att ändra namnet på mottagaren under signeringsprocessen inte är önskvärd. Adobe Sign tillhandahåller flexibilitet vad gäller signerarens namnpreferens. I striktare miljöer är denna flexibilitet inte acceptabel, så det finns en ny kontroll för att låsa namnen på avtalets mottagare.
Administratörer kan nu förhindra mottagare med kända namn-värden från att ändra dessa värden när de använder en ritad eller bild-signatur.
Situationer där namnvärdet är känt:
- När du skickar till en mottagare med ett Adobe Sign ID
- När namnet skickas via API:t
- När undertecknarinformation-fälten fylls i under formulärfyllning
- När namnet låses under slutförandet av en KBA eller myndighetsutfärdat ID-autentisering
Förbättringar av kunskapsbaserad autentisering
Kontroller har lagts till i KBA-metoden för identitetsautentisering som kan kräva att avsändaren anger ett namn för mottagaren och att namn-värdet låses fast genom signeringsprocessen.
Alternativ för förbättrad e-postsäkerhet
Det finns två nya alternativ för att förbättra e-postsäkerheten. Båda inställningarna är aktiverade som standard:
- Lägg till en länk för att visa det signerade avtalet i e-postmeddelandet
- Lägg till en bild på den första sidan av avtalet i e-postmeddelanden
- Aktiverat som standard
- När det är aktiverat visas en bild av den första sidan av avtalet i viss e-postdistribution
v6 REST API-uppdateringar
STANDARDHUVUDEN I ALLA V6 REST API-BEGÄRAN
Som standard har varje v6 REST API-begäran nu följande standardsidhuvuden:
/AGREEMENTS
Alla /agreements-slutpunkter som har en agreement id -sökväg returnerar nu en 404 AGREEMENT_DESTROYED-felkod om avtalet har tagits bort via GDPR-verktyg.
BIBLIOTEKSMALLAR
PUT /libraryDocuments/{libraryDocumentId} - Expanderad för att inkludera det nya fältet ownerId
Obs!
Endast v6 REST API påverkas.
Alla v6 REST API-anrop som inte inkluderar dessa huvud kommer att explicit dokumentera den frånvaron.
- GET /libraryDocuments – Utökad för att inkludera det nya fältet ownerEmail
- GET /libraryDocuments/{libraryDocumentId} – Utökad för att inkludera de nya fälten: ownerId, ownerEmail och ownerName
Nya fält i LibraryDocumentInfo-objekt:
Fält med uppdaterat beteende:
WEBBFORMULÄR (/WIDGETS)
- POST /widgets - Att använda ett libraryDocumentId för att skapa ett webbformulär stöds nu med ett giltigt ID
Tillagd statuskod:
- PUT /widgets - Att använda en libraryDocumentId för att skapa ett webbformulär stöds nu med ett giltigt id
Tillagd statuskod:
- PUT /widgets/{widgetId} - Expanderad för att inkludera det nya fältet ownerId
Tillagd statuskod:
Ändrad upplevelse
- GET /widgets/{widgetId} - Utökad för att inkludera de nya fälten: ownerId, ownerEmail, ownerName och creatorName
Fält med uppdaterat beteende:
/MEGA SIGN
NYTT:
- GET /megaSigns/{megaSignId}/formFields - Hämtar formulärfältsdetaljerna för ett Mega Sign-mallkontrakt
Parametrar:
Svarsobjekt:
- PUT /megaSigns/{megaSignId}/formFields - Uppdaterar formulärfälten för ett Mega Sign-kontrakt
Parametrar:
Svarsobjekt:
UPPDATERAT:
- POST /megaSigns - AUTHORING har lagts till som ett tillståndsvärde för att stödja framtagning av en Mega Sign-mall
Ändrad parameter:
- PUT /megaSigns/{megaSignId}/state - AUTHORING har lagts till som ett tillståndsvärde för att stödja framtagning av en Mega Sign-mall. Som ett resultat är megaSignCancellationInfo inte längre ett obligatoriskt fält
Den moderna startsidan och hanteringssidan har aktiverats för alla återstående konton
Alla konton har fått sina kontrollinställningar uppdaterade för att aktivera de moderna startsidorna och hanteringssidorna för sina användare.
Kontrollerna i administratörsmenyn förblir tillgängliga för konton som måste återgå till den klassiska upplevelsen:
Adobe Sign-servicenivå och konto-ID visas i administratörsmenyn
Administratörer kan nu hitta sitt konto-ID på sidan globala inställningar:
Grupp-ID:t finns på sidan Gruppinställningar:
Explicit HIPAA-konfiguration
Det finns en ny sida som tydligt visar när kontot kan hantera avtal som omfattas av HIPAA-krav.
- Den här kontrollen visas bara på kontonivån. Administratörer på gruppnivå har inte åtkomst
- Den här kontrollen är skrivskyddad, för att tydligt visa när kontot är konfigurerat
- Kontakta din Success Manager eller supporten om du vill aktivera HIPAA-konfigurationen
Knappen "Uppmaning till åtgärd" har ändrats för kunder som använder Outlook-datorprogrammet på Windows-system
CTA-knappen i Adobe Sign e-postmeddelanden har ändrats för mottagare som använder en Outlook e-postklient för datorer.
Den nya upplevelsen tar bort den blå HTML-knappen och tillhandahåller istället en klickbar textlänk:
Obs!
Den här ändringen påverkar endast Outlook Desktop-appar på Windows-system.Andra e-postklienter och operativsystem fortsätter att ta emot mallen med den blå knappen.
Delegering av avtal med digitala signaturer
Möjligheten att delegera ett avtal med digitala signaturer har förbättrats för att tillåta delegering från den ursprungliga e-postnotifieringen till mottagaren, genom automatisk delegering när det konfigureras av en användare, och genom åtgärden Ersätt nuvarande undertecknare på sidan Hantera.
Uppdaterat gränssnitt för Payments-integrationen
Gränssnittet för Payments har uppdaterats så att autentiseringskontrollerna exponeras på ett bättre sätt, vilket skapar en enklare konfigurationsprocess.
Maxvärdet för datastyrning har ökats till 5475 dagar (15 år)
Kunder som använder datastyrningsregler för att automatiskt ta bort avtal från Adobe Sign-systemet kan nu ställa in det borttagningsdatumet till maximalt 15 år (upp från tio).
Textrubriken på fältnivå för validering av amerikanskt personnummer har uppdaterats:
Textetiketten på fältnivå för validering av amerikanskt personnummer har uppdaterats för att förtydliga att personnumret gäller USA:
Påminnelse: Social autentisering har tagits bort
Som meddelades i november har autentiseringsmetoden som använder social identitet tagits bort från listan över autentiseringsmetoder i Admin-menyn.
Påminnelse: Personlig Twitter-integration har tagits bort
Som vi meddelade i december har möjligheten att skapa personliga autentiserade anslutningar till Twitter tagits bort.
Inaktiva användare får ett e-postmeddelande när de ingår i ett avtal
Användare som har inaktiv status får nu ett e-postmeddelande som instruerar mottagaren att delegera avtalet till en annan användare.
Korrigerade problem
Adobe Sign: Maj 2021
Förbättrade funktioner
Överför ägarskap av biblioteksmallar och webbformulär till en annan användare
Alla administratörer på kontot som har åtkomst till resursen kan nu ändra ägaren av den.
Administratören kan tilldela resursägarskapet till valfri användare under deras behörighet.
- Kontoadministratörer har åtkomst till alla delade resurser och alla användare. Därför kan administratörer på kontonivå tilldela ägarskapet av alla biblioteksmallar eller webbformulär till en annan användare av deras konto
- Om resursen är konfigurerad att endast vara tillgänglig för en användare delas den inte och är därför inte tillgänglig att tilldelas en ny ägare
- Gruppadministratörer kan bara komma åt biblioteksmallar och webbformulär inom grupperna där de har administratörsbehörighet
- Gruppadministratörer kan endast omtilldela en resurs till en användare vars primära grupp faller under deras administrativa behörighet
UPPDATERADE API-SLUTPUNKTER SOM STÖDER RESURSÖVERFÖRING
Slutpunkterna som beskrivs nedan är bara tillgängliga i v6 REST API.
Utökad för at stödja uppdatering av ägare av biblioteksdokument.
LibraryDocumentInfo:
Ytterligare felstatuskoder:
Ytterligare felstatuskoder:
Nya fält i LibraryDocument-objektet:
Nya fält i LibraryDocumentInfo-objektet:
Fält med uppdaterat beteende:
Nya fält i WidgetInfo-objektet:
Fält med uppdaterat beteende:
Ändrad upplevelse
Standardreturvärdet för v6 REST GET /workflows{workflowId} har ändrats
V6 REST GET /workflows{workflowId} API-anropet har uppdaterats för att returnera den aktuella versionen av WorkflowID (jämfört med den ursprungliga versions-ID:t, som var returvärdet före majversionen)
Denna uppdatering anpassar standard-API-upplevelsen med Webhook-upplevelsen genom att tillhandahålla samma WorkflowID, vilket bör förbättra utvecklingen och hanteringen av applikationer.
Om ditt konto av någon anledning kräver att API:et returnerar det ursprungliga ID:t (som det gjorde före majversionen), kontakta support för att begära att ditt konto returnerar basversions-ID:n för arbetsflöden
Korrigerade problem
Adobe Sign: Juni 2021
Användare i flera grupper (UMG)
Administratörer med flera gruppkonton kan nu ge användare inom sina konton åtkomst till flera grupper genom att öppna alternativet använda grupper som en form av arbetsflödesmall och använda särskilda kontroller för att skicka och signera för de biblioteksmallar som är tillgängliga för gruppen.
Befintliga enterprise- och företagskonton som vill uppgradera kan granska uppgraderingsprocessen här >
En sammanfattning av de påverkande skillnaderna finns här >
Introduktion till Liquid Mode i signatur
Aktivera vyn Liquid Mode för mobiltelefoner för HTML som skickas via sidan Skicka eller API:et sendAgreement. Alternativet att aktivera Liquid Mode i signatur för HTML är nu tillgängligt på Admin-menylistan på både konto- och gruppnivå.
Fullständig information om dokument i Liquid Mode finns här >
Obs!
Liquid Mode finns för närvarande endast tillgängligt i NA1-, NA2- och NA4-miljöerna.
Smidiga uppdateringar av webbformulär
Webbformulär med utkaststatus kan redigeras för att ändra:
- webbformulärnamn
- e-postadressen till motsigneraren/motsignerarna
- e-postadressen till de som är kopierade
- de bifogade filer som ska redigeras
- fälten i webbformuläret (tidigare tillgängligt)
Om du uppdaterar ett aktivt webbformulär kan du redigera formulärelementen utan att ändra den ursprungliga URL-adressen. Det ger en smidig process om du behöver uppdatera innehållet i ett webbformulär som redan har bäddats in eller skickats till din målgrupp. Element som kan redigeras är:
- filerna (dokumenten) och tillämpade fält för mottagarna
- motsignerare (från sidan Hantera)
- Kopiemottagarna (från sidan Hantera)
Obs!
För att aktivera funktionen för sömlösa webbformulär måste du aktivera alternativet Tillåt fler deltagare på menyn Globala inställningar:
Deltagandestämpel: Kontrollera titel- och företagsskärm
Kontroller har lagts till för att tillåta eller inaktivera mottagarens Titel och Företag (härledd från användarprofilen) i fältet deltagarstämpel.
Ytterligare information finns på sidan Fälttyper >
Förbättrade sökalternativ: prefix- och frasmatchningar
Avancerade sökalternativ har lagts till för att tillåta mer specifika sökmönster som hjälper till att reducera den returnerade avtalslistan.
Mer information om hur Sökning fungerar i Adobe Sign finns här >
OAuth 2.0 är den nya standarden
En ny (förbättrad) version av OAuth-slutpunkten har lagts till för att undvika användarmisstag. Med den här versionen:
- api_access_point/web_access_point returnerar bara i begäran om åtkomsttoken (i brödtexten)
- Adobe Sign accepterar inte hemligheten som en frågeparameter
- Rotation av klienthemlighet stöds
OAuth v1-slutpunkten fortsätter att fungera för befintliga anslutningar under de kommande månaderna för att säkerställa fortsatt åtkomst.
Utfasningen av OAuth v1 kommer att meddelas på sidan för tekniska meddelanden när den är schemalagd.
Rotation av klienthemliget
Applikationens klienthemligheter kan roteras av alla administratörer som har åtkomst till applikations-ID i Adobe Sign-gränssnittet:
Ändrad upplevelse
Gruppadministratörer kan bara se de API-program som faller under deras administratörsbehörighet
Synligheten för program som är kopplade till kontot är nu begränsad till att endast visa de program som omfattas av användarens administrativa omfång. Det är bara gruppadministratörer som kan se beteendeändringen:
- Användarna ser de program de äger
- Gruppadministratörer kan se programmen under de grupper som de har administratörsbehörighet för
- Kontoadministratörer ser alla program på kontot
E-post till avsändaren när ett avtal är komplett har uppdaterats
Det slutgiltiga e-postmeddelandet för ett avtal som skickas till avsändaren har uppdaterats för att ge en fullständig lista över alla parter som har underrättats om det slutförda avtalet.
Det är bara den ursprungliga avsändaren som får den här e-postmallen.
Uppdaterat REST API v6-resultat för GET /agreements/{agreementId}/signingUrls
Före juniversionen returnerade API:et 404 omedelbart efter att avtalet skapades när GET /agreements/{agreementId}/signingUrls anropades.
För en kort tid efter att 404-felet had åtgärdats returnerade svaret ett svar som inte är 404, men det inkluderade endast avsändarens signingURL:er. (Medan undertecknarens deltagande fortfarande definierades.)
Efter juni 2021-lanseringen returneras en 404: AGREEMENT_NOT_EXPOSED-kod tills den fullständiga listan över signerings-URL:er har slutförts och då levereras en 200-kod.
Kunder som inte vill fortsätta att prova API-anropet tills 200-svaret har returnerats uppmanas att använda Webhooks och svara på AGREEMENT_CREATED-händelsen.
Korrigerade problem
Adobe Sign: Augusti 2021
Upplevelseändring
- Aadhaar International Support - Kunder från alla Adobe Sign-instanser kan nu använda den valfria Aadhaar-tjänsten som leverantör av digitala signaturer. Tidigare var den bara tillgänglig för konton på IN1-instansen. Aadhaar-tillägget kan köpas till en extra kostnad per signaturtransaktion.
- REST v6-uppdatering: POST /users - REST v6- POST /users API-anropet har uppdaterats för att skapa användaren i kontots standardgrupp om den valfria primärGroupId- parametern inte har definierats. Det är bara v6 i REST API som påverkas av den här ändringen.
Lösta problem
|
|
Beskrivning |
|---|---|
|
4299495 |
Löste ett problem i Workflow Designer som kunde förhindra att en kunddefinierad URL i instruktionerna inte fungerade. |
|
4308294 |
Korrigerade ett problem i rapport-CSV-filen där fälten Till och Mottagarnamn kunde lämnas tomma när samma mottagares e-postadress användes mer än en gång i avtalet. |
|
4310569 |
Adobe Sign-mallarna har filtrerats bort från sandlådealternativen. |
|
4311098 |
Korrigerade ett problem där gruppadministratörer inte kunde uppdatera användare i en grupp via CSV-uppladdning. |
|
4311723 |
Löste ett problem där GET /groups/ID/users API-anropet skulle misslyckas om användaren var på en annan Adobe Sign-instans. |
|
4312103 |
Korrigerade ett problem där SAML-användare skapade via massuppladdning skulle vara i ett skapat tillstånd (i stället för primärt). |
|
4312309 |
Korrigerade ett problem där gruppadministratörer inte kunde omfördela ägarskap av webbformulär om andra användare i deras grupp skapade dem. |
|
4312840 |
Åtgärdade ett problem med att aktivera nya användare när ett andra aktiverings-e-postmeddelande skickades till den nya användaren och länken i det andra e-postmeddelandet användes. |
|
4314751 |
Korrigerade ett problem där alternativet att avböja avtalet inte var synligt vid signering för en annan användares räkning. |
|
4315033 |
Åtgärdade ett problem där kontoadministratörer inte kunde återställa lösenord när SAML-läge var inställt på Obligatorisk. |
|
4315605 |
Korrigerade ett problem där bilder på myndighetsutfärdat ID inte kunde bearbetas framgångsrikt. |
|
4316057 |
Korrigerade ett problem där myndighetsutfärdat ID skulle generera ett fel som angav att de fyra hörnen av dokumentet inte kunde hittas. |
|
4316474 |
Åtgärdade ett problem där Signera för någon annans räkning var synligt i konton där alternativet inte var aktiverat. |
|
4316659 |
Ett problem har korrigerats där e-postadressen för ”actingUserEmail” i ett GET/agreements/id-anrop returnerade ett systemgenererat e-postmeddelande efter att avtalet hade signerats helt. |
|
4317095 |
Korrigerade ett problem där ett mottagarnamn skulle importeras till etiketten för Deltagare 1 när kunskapsbaserad autentisering användes för den första signeraren. |
|
4317221 |
Korrigerade ett problem där automatiska notis-e-postmeddelanden för misslyckade webhooks skulle skickas till webhook-skaparen trots att det var konfigurerat att inte meddela skaparen. |
|
4317347 |
Korrigerade ett problem där autentisering av OAuth i Power Automate skulle omdirigera användaren till startsidan. |
|
4317429 |
Löste ett problem där administratörer inte kunde uppdatera egenskapen Kan skicka för användare vid uppdatering via CSV-uppladdning. |
|
4317548 |
Löste ett problem där vissa kunder som använder iPad skulle se webbsidan i stället för sidan optimerad för mobila enheter. |
|
4317629 |
Löste ett visningsproblem med namn som innehåller en apostrof som visar HTML-koden för apostrofen. |
|
4318175 |
Ett problem har korrigerats där användare fick ett fel när de arkiverade ett konto via e-postlänken. |
|
4319012 |
Ett problem har korrigerats där användare skapade via REST v5- och v6-POST/användare inte skapades i standardgruppen. |
|
4320197 |
Åtgärdade ett problem där rapporten för signerarens identitet inte kunde hämtas från sidan Hantera på grund av att knappen var inaktiv. |
Adobe Sign: september 2021
Förbättrade funktioner
- Sandlåda – Företagskunder kan köpa tillgång till en sandlådemiljö för att testa mallar, kundarbetsflöden, API-program och annat. Dessa objekt kan flyttas från produktion till sandlåda för uppdatering i en säker miljö och sedan flyttas tillbaka till produktion när uppdateringarna har verifierats och är klara för distribution.
- Stöd för digitala ECDSA-signaturer – Adobe Sign stöder nu säkrare och effektivare digitala signaturer baserade på ECDSA-formatet, som använder elliptisk kurvkryptografi enligt definitionen i standarden ANS X9.62-2005.
NIST-kurvor med SHA-2-hash-funktioner, som definieras av FIPS-standarderna, stöds nu vilket ger våra TSP-partners (Trust Service Providers) från Cloud Signature Consortium möjligheten att ge signerare snabbare och säkrare autentiseringsuppgifter med elliptiska kurvor, inklusive de som uppfyller de rekommenderade kraven för myndighetsbruk i USA och Singapore.
- Liquid Mode har uppdaterats – Liquid Mode-underskriftsupplevelsen har utökats utöver avtal och inkluderar nu webbformulär. Formulär med Liquid Mode kan dramatiskt förbättra undertecknarens upplevelse genom att minska behovet av att nypa och zooma för att visa formulärets innehåll och samtidigt förbättra fokus på fält som behöver fyllas i.
Dessutom är Liquid Mode inte längre begränsat till nordamerikanska servrar. Alla storföretag- och Företag-konton har nu åtkomst oavsett plats.
- Nya TSP:er – Cleverbase (Nederländerna), PrimeSign (Österrike), Sectigo (Global) och TrustPro (Irland) är nya leverantörer av betrodda tjänster från Cloud Signature Consortium som tillhandahåller certifikat för att använda säkra digitala signaturer som uppfyller de högsta standarderna och efterlevnadskraven.
- Anpassa Till- och Kopia-fälten i e-posthuvuden till mottagare – Kunder som är oroliga för att läcka e-postadresser via e-posthuvuden till mottagare kan välja att dölja e-postadressvärdena i Till- och Kopia-fälten.
- Det här alternativet är tillgängligt för konton på Enterprise- och Business-nivå och kan konfigureras på konto- och gruppnivå.
- Funktionskontrollerna kan nås genom att navigera till Kontoinställningar > E-postinställningar > Anpassa Till- och Kopia-fält.
Ändrad upplevelse
- Adobe användningsvillkor godkännande på e-signeringssidor – För att följa Adobes juridiska krav uppdaterar Adobe Sign beteendet för godkännande av användningsvillkor på e-signeringssidan. Under den nya upplevelsen måste alla "okända" mottagare acceptera Adobe Sign användningsvillkor och integritetspolicy (genom att klicka på knappen Fortsätt ) innan de interagerar med avtalet. Detta godkännande är skilt från eventuella anpassade användningsvillkor som kundkontot kan ha konfigurerat, vilket kommer att fortsätta att lösas enligt kontots konfiguration för godkännande av användarvillkor/kundinformation.
- En "okänd" mottagare är vilken e-postadress som helst som inte är en registrerad, aktiv användarens e-postadress i ett betrott konto.
- ”Kända” användare har accepterat Adobe Sign TOU som en del av registreringsprocessen när de verifierade sitt användarkonto, så de uppmanas inte att acceptera det igen.
Nedan visas ett exempel på flödet för underförstått samtycke för ett avtal med anpassade användarvillkor som konfigurerats av kunden:
- Acceptera Användarvillkoren för Adobe Sign genom att välja Fortsätt-knappen (efter att ha öppnat avtalet).
- Fyll i avtalsfälten efter behov.
- Acceptera kundinformationen och anpassade användningsvillkor genom att välja knappen Klicka för att signera .
- Låsning av namnvärden utökad till skrivna signaturer – Versionen från mars innehöll en inställning för att aktivera/inaktivera en mottagares möjlighet att redigera namnvärdet vid signering, förutsatt att namnet angavs eller var känt (via API eller användarprofil). Skrivna signaturer exkluderades från denna funktion, vilket innebar att vissa signerare kunde ändra sitt namnvärde under signeringsprocessen. Versionen från september uppdaterar denna funktion för att efterleva namnlåsinställningen för alla signaturtyper, inklusive skrivna signaturer.
- Kunder som har aktiverat Skriva sitt namn och initialer och inaktiverat Signerare kan ändra sitt namn eller initialer kommer att se en beteendeförändring – namnvärdet kan inte längre redigeras under signeringsprocessen för skrivna signaturer.
- Kunder som vill tillåta redigering av namnvärdet under signeringsprocessen bör aktivera inställningen Signerare kan ändra sitt namn eller sina initialer (i menyn Signaturinställningar).
- Inaktiva användare kan signera avtal – Adobe Sign behandlar nu inaktiva användare som om de är okända i systemet (för signering av inkommande avtal). När en inaktiv användare ombeds att signera ett avtal skapas ett nytt användar-ID för engångsbruk för att signera det avtalet. Användar-ID:et för engångsbruk är oberoende av det inaktiva användar-ID:et och kontot som styr det. Detta har flera konsekvenser:
- Avtal som skickas till en inaktiv användare kan signeras, eftersom statusen Inaktiv inte gäller det användar-ID för engångsbruk som genereras för avtalet.
- Avtal som signeras av användar-ID:et för engångsbruk är inte resurser som tillhör det inaktiva användar-ID:et och finns inte i kontot för det inaktiva användar-ID:et.
- Delningar från det inaktiva användar-ID:t återspeglar inte avtal som har signerats av användar-ID:t för engångsbruk.
- Rapportering mot det inaktiva användar-ID:t återspeglar inte avtal som har signerats av användar-ID:t för engångsbruk.
- Om det inaktiva användar-ID:t återaktiveras ser de inte posterna för avtalen som har signerats av användar-ID:t för engångsbruk på sin hanteringssida.
Det finns två undantag till ovanstående beteende:
- Avtal som skickas till användaren innan de markerades som inaktiva kanske inte signeras (avtalet var redan bundet till det inaktiva användar-ID:t).
- Användare som uttryckligen konfigurerats att inte få signera avtal kommer att fortsätta att inte tillåtas utföra några signeringsåtgärder.
Inaktiva användare hindras fortfarande från att logga in på Adobe Sign-systemet och skicka avtal under sin behörighet (på något sätt).
- Förbättrad säkerhet för åtkomst till webbformulär via lösenord - Webbformulär har en fördröjning efter ett antal misslyckade försök att komma åt en lösenordsskyddad URL.
- Internationell support för Aadhaar – Kunder från alla Adobe Sign-instanser kan nu använda den valfria Aadhaar-tjänsten som leverantör av digitala signaturer. Tidigare var den bara tillgänglig för konton på IN1-instansen. Aadhaar-tillägget kan köpas till en extra kostnad per signaturtransaktion.
- Begränsad delning av avtal – Avtalsdelning har begränsats när avtalet delas till en extern e-postadress.
- Flerlicenskonton kan dela ett avtal upp till tio gånger.
- Enskilda användarkonton kan dela ett avtal upp till 5 gånger.
- Det är obegränsat att dela ett avtal med interna användare.
- Flerlicenskonton kan dela ett avtal upp till tio gånger.
- Anpassat företagsnamn vid telefonautentisering har tagits bort från tjänsten – Det anpassningsbara företagsnamnsvärdet som kunde infogas i telefonautentiseringsmetoden har tagits bort från tjänsten i enlighet med tillkännagivandet i det tekniska meddelandet från juni.
- HIPAA-aktiverade konton kan nu komma åt kontrollerna för bilder och länkar i mottagarnas e-postmeddelanden på sidan Globala och gruppinställningar.
- Ordningen som Filbilagor inkluderas i den slutliga PDF-filen har uppdaterats för att först sortera efter sidnummer och sedan efter fältposition (när man läser från vänster till höger; uppifrån och ned)
- Med funktionen Ersätt mottagare på den nya sidan Hantera kan avsändaren nu inkludera ett valfritt meddelande för den nya mottagaren.
- Externa signerare som har åtkomst till slutförda avtal måste nu genomgå en autentiseringsprocess när multifaktorautentisering har konfigurerats för avtalet (istället för att uppmanas att logga in på Adobe Sign).
- Webbformulär rapporterar nu fältvärden för overifierade webbformulär när de hämtar fältdata med funktionen Hämta formulärfältdata på sidan Hantera.
API-uppdateringar
- Alternativet Läs avtal för webbformulär – Det finns två nya REST v6 API-anrop som ger åtkomst till visning av webbformulär:
- GET /widgets/<resourceId>
- GET /widgets/<resourceId>/combinedDocument/url
- GET/workflows/{workflowId} returnerar nu deltagarrollen i svaret.
Korrigerade problem
| 4292343 | Förbättrad tydlighet i signaturer när alternativet TYPE-signatur på mobila enheter används. |
| 4295123 | Ett problem har korrigerats som kunde förhindra att digitala signaturer var synliga när de öppnades i en webbläsare. |
| 4299289 | Förbättrade upplevelsen av Ersätt mottagare genom att låta avsändaren inkludera ett meddelande till den nya mottagaren. |
| 4299857 | Ett problem har korrigerats som kunde göra att ett signerat avtal inte tillämpade certifikatets försegling. |
| 4304261 | Ett problem har korrigerats som kunde göra att alternativet Läs avtal inte fylldes i på menyn Alternativ |
| 4308516 | Ett problem har korrigerats där användare hela tiden uppmanades att få administratörsgodkännande när de använde OneDrive |
| 4310225 | Ett problem har korrigerats där avtal som innehåller flera signaturer utlöste ett serverfel: Felmeddelande: Signaturen som har tillämpas på det här dokumentet är ogiltig. Rensa den och signera igen. |
| 4310416 | v5 REST API har uppdaterats för att skapa användare i ett aktivt tillstånd när de skapades med POST /users |
| 4311287 | Ett problem har korrigerats där gruppnavigeringsknappen försvann på UMG-aktiverade konton efter att en användare hade tagits bort från en grupp. |
| 4311956 | Ett problem har korrigerats där den angivna typsnittsstorleken för ett fält inte återspeglades i signerarupplevelsen. |
| 4312302 | Ett problem har korrigerats som tog bort alternativet Återställ lösenord om SAML-läget var inställt på Obligatoriskt. |
| 4312735 | Ett problem har korrigerats som orsakade att delade händelsemeddelanden levererades när delade meddelanden inaktiverades. |
| 4313025 | Ett problem har korrigerats där en formulärifyllningsroll inte kunde fylla i ej tilldelade roller när Hybrid-routning aktiverades. |
| 4313030 | Ett problem har korrigerats där UMG-aktiverade konton utlöste ett fel med ett anpassat arbetsflöde om avsändarens primära grupp inte får skicka. |
| 4313264 | Inställningen för HIPAA-aktivering har uppdaterats för att ge åtkomst till inställningarna för e-postlänkar och bilder på sidan Globala inställningar. |
| 4315839 | Ett problem har korrigerats för anpassade arbetsflöden som inte tillät förifyllda fält när avsändaren också var den andra mottagaren. |
| 4316058 | Uppdaterat beteende för rapportfält som tillåter inledande nollor i textfält. |
| 4317382 | Ett problem har korrigerats med alternativknappar som visar HTML-koden för apostrofer i verktygstipset |
| 4317978 | Sättet som bifogade filer ordnas i den slutliga PDF-filen har uppdaterats för att gruppera bifogade filer baserat på fältets sidnummer först och sedan fältets relativa position (vid läsning från vänster till höger, uppifrån och ned). |
| 4318598 | GET/workflows/{workflowId} REST v6 API-anropet returnerar nu deltagarrollen i svaret. |
| 4318606 | Funktionen Hämta formulärfältdata på sidan Hantera returnerar nu fältvärden för webbformulär som ännu inte har verifierats. |
| 4318617 | Ett problem har korrigerats där UMG-aktiverade konton inte tillåter att en gruppadministratör skickar en inbjudan igen. |
| 4318679 | Ett intermittent problem har korrigerats som kunde göra att dokument med skriven signatur inte kunde överföras. |
| 4318926 | Ett problem har korrigerats som kunde utlösa ett fel (Cookie-funktionen är inaktiverad i webbläsaren) när ett avtal skapas från en mobil enhet. |
| 4318991 | Ett problem har korrigerats som kunde göra att inställningen för maximalt antal fel vid inloggning ignorerades om SAML hade angetts till Tillåten. |
| 4319068 | Externa mottagare måste nu genomgå en process med andrafaktorautentisering (i stället för att logga in på Adobe Sign) för att få åtkomst till slutförda avtal när multifaktorautentisering har konfigurerats. |
| 4319422 | Ett problem har korrigerats där en mottagare kunde ersättas utan att bekräfta lösenordet (för lösenordsautentiserade avtal) |
| 4319455 | Ett problem har korrigerats för avancerad delning där inställningar kanske inte är beständiga efter att de har sparats. |
| 4320123 | Ett problem har korrigerats som kunde utlösa ett fel vid försök att visa och godkänna ett avtal på sidan Hantera. |
| 4320205 | Ett problem har korrigerats som kunde förhindra att information sparades när ett avtal fylldes i förskott i med avancerad delning. |
| 4320542 | Ett problem har korrigerats för UMG-aktiverade konton där en användares alla grupper kunde tas bort om en grupp togs bort med hjälp av Sök. |
| 4321357 | Ett problem har korrigerats som kunde utlösa ett fel på sändningssidan när KBA valdes som autentisering och ”Kräv namn vid sändning” är aktiverat. |
| 4322445 | Förbättrad redigering för att säkerställa enhetliga bakgrundsfärger. |
| 4322956 | Ett problem har korrigerats för anpassade e-postmallar där mottagarna inte kunde se den faktiska e-postadressen till signeraren. |
| 4323609 | Under utveckling – ett problem har korrigerats där avtal som slutfördes genom att ladda upp ett signerat dokument inte utlöste webbhookmeddelandet AGREEMENT_WORKFLOW_COMPLETED. |
| 4323968 | Funktionen för låsning av signaturer har förbättrats så att den inkluderar inskrivna signaturer när namnvärdet levereras via profil eller API. |
Adobe Sign: oktober 2021
Förbättrade funktioner
- Rapportera missbruk-länkar – små företag och konton på enskild nivå har nu en länk som låter mottagare rapportera potentiellt missbruk i inkommande avtalsbegäranden.
- Notarize-integrering – genom att integrera Adobe Sign med plattformen Remote Online Notarization (RON) från Notarize Inc. kan kunderna lägga till en notariefjärrtjänst online som en del av Adobe Sign-transaktionerna. Tillgängligt för att lägga till amerikanska kunder på enterprise- och business-nivåer som säljs direkt av Adobe via ETLA-programmet. Notarize-transaktioner kan endast köpas som ett tillägg till en extra kostnad för dessa kunder.
- Skicka sidouppdateringar – kunder med notariefunktionen aktiverad kan välja alternativet Kräver notarisering på mottagarposten, precis till höger om autentiseringsmetoden:
- Skicka sidouppdateringar – kunder med notariefunktionen aktiverad kan välja alternativet Kräver notarisering på mottagarposten, precis till höger om autentiseringsmetoden:
Obs!
Kunder som använder den inbäddade sidan Skicka i sina program eller integreringar får också tillgång till notariefunktionerna.
När avtalet har konfigurerats och avsändaren klickar på Nästa visas ytterligare konfigurationsalternativ för notariseringsprocessen:
- API-uppdateringar – viktiga uppdateringar av API:erna som stöder Notarize-integrering har utförts:
POST/avtal
POST-/avtals-API:t har uppdaterats med stöd för att skicka ett avtal för notarisering.
- En ny roll, NOTARY_SIGNER, ska användas för att ange en deltagare i en notariesession.
- Ett nytt NotaryInfo-attribut har lagts till i AgreementInfo-definitionen och innehåller alla alternativ associerade till att skapa ett nytt avtal som kräver notarisering.
|
Parameternamn |
REST-objekt |
Beskrivning |
||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
memberInfos |
ParticipantInfo[] |
Matris med ParticipantInfo-objekt som innehåller deltagarspecifika data (e-post, t.ex.). Alla deltagare i arrayen tillhör samma uppsättning. |
||||||||||||||||
|
roll |
|
Roll som antas av alla deltagare i uppsättningen (signerare, godkännare osv.) |
FileInfo-tillägg
FileInfo-definitionen måste expanderas för att ange vilka dokument som ska notatiseras.
|
Parameternamn |
Typ |
Standard |
Obligatoriskt |
Beskrivning |
|---|---|---|---|---|
|
dokument |
Document |
|
valfritt |
Ett dokument som är kopplat till avtalet. |
|
label |
Sträng |
|
valfritt |
Det unika etikettvärdet för ett filinformationselement. Om arbetsflödet är anpassat mappas en fil till motsvarande filelement i arbetsflödesdefinitionen. |
|
libraryDocumentId |
Sträng |
|
valfritt |
ID för ett befintligt biblioteksdokument som ska läggas till i avtalet |
|
transientDocumentId |
Sträng |
|
valfritt |
ID för ett tillfälligt dokument som ska läggas till i avtalet |
|
notarisera |
true |
falskt |
valfritt |
Anger att dokumentet måste notariseras. |
ParticipantInfo-tillägg
ParticipantInfo-definitionen har utökats till att tillåta metoden för notarieautenticering att specificeras.
|
Parameternamn |
Typ |
Standard |
Obligatoriskt |
Beskrivning |
|---|---|---|---|---|
|
|
Sträng |
Ej tillämpligt |
obligatoriskt |
Mottagarens e-postadress. |
|
notaryAuthentication |
Enum |
MULTI_FACTOR_AUTHENTICATION |
valfritt |
MULTI_FACTOR_AUTHENTICATION – notarieautenticering utförs med en tvåfaktorautenticeringsmetod |
NotaryInfo
Ett nytt valfritt notaryInfo-fält har lagts till i AgreementInfo-definitionen för att innehålla NotaryInfo-objekt som specificerar ytterligare alternativ kopplade till notarisering.
|
Parameternamn |
Typ |
Standard |
Obligatoriskt |
Beskrivning |
|---|---|---|---|---|
|
notaryType |
Enum |
Om bara Notarize-tjänsten Notarie vid behov är aktiverad för kontot |
obligatoriskt |
NOTARIZE_NOTARY – Notariseringstjänsten tillhandahåller notarien |
|
payment |
Enum |
BY_SENDER |
valfritt |
Gäller endast om typ == NOTARIZE_NOTARY |
|
appointmentStart |
Sträng |
"" |
valfritt |
ISO_DATE_TIME-formaterad sträng Se ISO_ZONED_DATE_TIME |
|
note |
Sträng |
inget |
valfritt |
Anteckningar för notariesession. |
|
notaryEmail |
Sträng |
"" |
valfritt |
e-postmeddelande för att ta med egen notarie |
Exempel/avtal
PUT|GET /agreements/{aid}
PUT agreements/{aid} API har stöd för att uppdatera ett avtal med notariseringsalternativ. GET /agreements/{aid} API returnerar alla alternativ som angetts för avtalsnotarius publicus. Se avsnittet POST/avtal för att visa uppdaterade attribut.
Felkoder
Befintliga felkoder för POST/avtal ändras inte. Vi har definierat en ny felkod enligt nedan:
|
REST-felkod |
HTTP-statuskod |
Meddelande |
Scenario |
|---|---|---|---|
|
PERMISSION_DENIED |
403 |
Användarinställning eller OAuth-scopetoken tillåter inte att avtal skickas för notarisering. |
Det här felet uppstår när rollen är inställd på NOTARY_SIGNER och API-anroparen (d.v.s. potentiell avsändare) inte har notariefunktionen aktiverad och/eller om notarietjänstleverantören inte är inställd. |
Dokumentationspåverkan
I förfrågans AgreementInfo-objekt inkluderas "status"-element i den nya avtalsstatusen"WAITING_FOR_NOTARIZATION".
POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens
API kan användas av kunder (notariesignerare) för att erhålla en signeringstoken som gör att de kan slutföra flödets e-signeringsfas.
- Ny signeringsfunktion har lagts till för att fånga den nya rollen – ACCEPT_BEFORE_NOTARIZATION.
- Signeringstoken ska inte hämtas för att slutföra notariseringsfasen.
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status
API:t kan användas av kunder (notariesignerare) för att slutföra flödets e-signeringsfas. För att passa den nya rollen har ett nytt uppräkningsstatusvärde introducerats – ACCEPTED_BEFORE_NOTARIZATION.
|
Attribut |
Typ |
Beskrivning |
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Status |
Enum<string>
|
|
||||||||||||||
Notarie-signeraren kan följa nedanstående sekvens av API-anrop för att slutföra e-signeringsfasen:
- GET/avtal/{agreementId}/medlemmar – för att hämta notariens deltagar-ID och deltagaruppsättnings-ID
- POST /agreements/{agreementId}/Members/participantSets/{participantSetId}/Deltagare/{participantId}/signingTokens – för att begära signeringstoken för notariesignerare med ACCEPT_BEFORE_NOTARIZATION-kapacitet
- POST /transientDocuments – för att ladda upp dokument som granskats
- PUT /agreements/{agreementId}/Members/participantSets/{participantSetId}/Deltagare/{participantId}/status – att skicka in granskat dokument och slutföra e-signeringsfasen.
Ny webhook-händelse
Kunderna kan prenumerera på ny webhook-händelse, AGREEMENT_READY_FOR_NOTARIZATION, som ska meddelas när avtalet är klart för notarisering. Händelsen visas inte på webbhooks-gränssnittet och kan prenumereras på via API-anrop för POST/webhooks.
Dokumentationspåverkan
Följande API:er ändras inte, men deras dokumentation har uppdaterats så att den inkluderar den nya avtalsstatusen ”WAITING_FOR_NOTARIZATION” eller den nya rollen ”NOTARY_SIGNER”.
GET /agreements
I sitt svar på UserAgreements/UserAgreement-objekt innehåller nu elementet "status" motsvarande status "WAITING_FOR_NOTARIZATION".
GET /agreements/{agreementId}
I AgreementInfo-objektet innehåller "status"-elementet nu motsvarande status "WAITING_FOR_NOTARIZATION".
GET /agreements/{agreementId}/events
API:t har uppdaterats för att stödja nya READY_TO_NOTARIZE- och NOTARIZED-händelser.
I svars-Event-objekt
- Elementet ”participantRole” innehåller nu den nya rollen NOTARY_SIGNER.
- ”type”-elementet innehåller de nya händelserna READY_TO_NOTARIZE och NOTARIZED. ”description”-elementet kommer att vara ”Dokument skickat för notarisering” och ”Notariserat dokument mottaget”
GET /agreements/{agreementId}/members/participantSets/{participantSetId}
I DetailedParticipantSetInfo-objektet innehåller "status"-elementet nu motsvarande status ”WAITING_FOR_NOTARIZATION”.
PUT /agreements/{agreementId}
Begäran-AgreementInfo-objektet innehåller nu statusen ”WAITING_FOR_NOTARIZATION”.
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}
WAITING_FOR_NOTARIZATION-status är ett av värdena för ”status”-elementet i DetailedParticipantSetInfo-objektet.
POST /agreements/{agreementId}/view
WAITING_FOR_NOTARIZATION-status har lagts till som en av de tillåtna vyerna.
GET /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingInfo
Om deltagaren som anges i sökvägen till begäran har en notariesignerarroll returnerar API ACCEPT_BEFORE_NOTARIZATION-signeringskonfigurationen, i linje med alla andra signeringskonfigurationer för avtalet/deltagaren.
Korrigerade problem
| Problem | Beskrivning |
| 4308901 | Ett problem har åtgärdats där delegering av ett avtal med telefonautentisering utlöste ett fel om det delegerade telefonnumret hade samma landskod. |
| 4314113 | Ett problem har åtgärdats där standardförfallodatum inte kunde redigeras av användare när ett nytt avtal skickades |
| 4318558 | Ett problem har åtgärdats där felet ”Det angivna ID-numret för deltagaruppsättningen är ogiltigt” visades om en mottagare med telefonautentisering ersattes |
| 4319038 | Ett problem har åtgärdats där avsändaren inte fick möjligheten att verifiera externa mottagares identitet när denne skickade med arbetsflödet Massutskick. |
| 4319798 | Ett problem har åtgärdats som kunde göra att markören hoppade till ett annat fält när en radioknapp skulle markeras. |
| 4320154 | Ett problem har åtgärdats som kunde förhindra att biblioteksmallar sparades i en ny grupprelation. |
| 4323013 | Ett problem har åtgärdats där ett fel uppstod om ett webbformulär öppnades på hanteringssidan: ”Dokumentet är inte tillgängligt än eller har inga sidor att visa.” |
| 4323554 | Ett problem har åtgärdats där tids- eller datumstämplar för uppdatering av administratörsrättigheter kunde skapa två poster med samma tidsvärden. |
| 4323609 | Ett problem har åtgärdats där överföringen av ett signerat avtal på hanteringssidan inte utlöste webbhooken AGREEMENT_WORKFLOW_COMPLETED. |
| 4325142 | Ett problem har åtgärdats där anpassade e-postmallar inte använde rätt namnvärde för en deltagare om de annullerade avtalet. |
| 4326747 | Ett problem har åtgärdats som kunde leda till att sidan Massutskick inte laddades och åtgärderna Överför och Skicka utelämnades. |
| 4326855 | Ett problem har åtgärdats som förhindrade att mottagare kunde avböja att godkänna ett avtal. |
| 4327000 | Ett problem har åtgärdats som kunde få autentiseringsuppgifterna för Smart-Id att misslyckas. Felet indikerade att inga algoritmer hittades. |
