Adobe Acrobat Sign produktmerknader - 2021

Sist oppdatert 2. apr. 2026

Produktmerknader for Adobe Sign: 2021  

Adobe Sign: mars 2021

Forbedret funksjonalitet

Flersignatør-nettskjemaer

Kontoer som bruker Web Forms kan nå tillate flere eksterne mottakere i signaturprosessen.

Ytterligere mottakere defineres av den første underskriveren:

Flermottaker-nettskjema

Bruk Library Templates til å opprette Web Forms

Forfattere kan nå bruke eksisterende Library Templates til å opprette nye Web Forms.Filen importeres med alle felt intakte:

Nettskjema fra mal

"Liquid Mode" i Adobe Sign for mobilvisning

Liquid Mode er en valgfri funksjon for å generere en responsiv visning, slik at du kan forbedre visningen av dokumentene dine basert på underskriverens enhetstype.

Det signerte dokumentet lagres i standard "PDF"-versjon mens mottakerne kan se Liquid Mode på mobiltelefoner og kan bytte for å vise det opprinnelige dokumentet.

Du kan nå laste opp HTML-dokumentet ditt og generere en Liquid Mode-visning for mobiltelefoner.

Mer informasjon om Liquid Mode-alternativet finner du her >

Eksempel på Liquid Mode

Lås Name-verdien for kjente brukere ved signering via Bilde- eller Tegnet signaturmetoder

Det er situasjoner der muligheten til å endre navnet på mottakeren under signeringen er uønsket. Adobe Sign har gitt fleksibilitet i denne forbindelse når det gjelder hensyn til navnepreferanse fra underskriveren.  I mer samsvarende miljøer er denne fleksibiliteten uakseptabel, så det er en ny kontroll for å låse navnene til mottakerne til avtalen.

Administratorer kan nå hindre mottakere med kjente Name -verdier fra å endre disse verdiene når de bruker en Drawn - eller Image -signatur.

Situasjoner der navneverdien er kjent:

  • Når du sender til en mottaker med en Adobe Sign-ID
  • Når du sender navnet via API
  • Når Signer Info-feltene fylles ut under skjemautfylling
  • Når navnet låses under fullføring av en KBA - eller Government ID-autentisering

Mer informasjon om denne funksjonen finner du her >

La mottakere redigere navnet sitt

 

Forbedringer av kunnskapsbasert autentisering

Kontroller er lagt til KBA-metoden for identitetsautentisering som kan kreve at avsenderen oppgir et Name for mottakeren og at Name -verdien låses på plass gjennom signaturprosessen.

KBA lock name value.png

Alternativer for forbedret e-postsikkerhet

To nye alternativer er tilgjengelige for å forbedre e-postsikkerheten. Begge innstillingene er aktivert som standard:

Alternativer for e-postsikkerhet

Email options - pair.png

v6 REST API-oppdateringer

STANDARDOVERSKRIFTER I HVER V6 REST API-FORESPØRSEL

Som standard har hver v6 REST API-forespørsel nå standardhoder:

Standard Headers.png

/AGREEMENTS

Alle /agreements-endepunkter som har en agreement id -sti returnerer nå en 404 AGREEMENT_DESTROYED-feilkode hvis avtalen har blitt slettet via GDPR-verktøy.  


BIBLIOTEKSMALER

PUT /libraryDocuments/{libraryDocumentId} - Utvidet til å inkludere det nye feltet ownerId

Notat

Bare v6 REST API påvirkes.

Alle v6 REST API-kall som ikke inkluderer disse overskriftene vil eksplisitt dokumentere dette fraværet.

libraryDocumentId

libraryDocumentId

Hent biblioteksdokumenter

Nye felter i LibraryDocumentInfo-objektet:

12.1

Felter med oppdatert oppførsel:

12.1

web-SKJEMAER (/WIDGETS)

  • POST /widgets - Bruk av en libraryDocumentId til å opprette et web-skjema støttes nå med en gyldig id

Statuskode lagt til:

Post Widgets

  • PUT /widgets - Bruk av en libraryDocumentId til å opprette et web-skjema støttes nå med en gyldig id

Statuskode lagt til:

Put Widgets

Put widgetID-enhet

Statuskode lagt til:

Put widgetID-enhet

Endringer i brukeropplevelsen

  • GET /widgets/{widgetId} - Utvidet til å inkludere de nye feltene: ownerId, ownerEmail, ownerName, og creatorName

Nye felter i WidgetInfo-objektet:

Hent WidgetID

Felter med oppdatert oppførsel:

Hent WidgetID

/MEGA SIGN

NYTT:

Hent megasignID-skjemafelt

Parametere:

Hent megasignID-skjemafelt-parametere

Svarobjekt:

Hent megasignID-skjemafelt-svar

PUT megasignID-skjemafelt

Parametere:

PUT megasignID-skjemafelt

Svarobjekt:

Put megasignID-skjemafelt

OPPDATERT:

  • POST /megaSigns - AUTHORING har blitt lagt til som en tilstandsVerdi for å støtte redigering av en Mega Sign-mal

Endret parameter:

Post Megasigns.png

  • PUT /megaSigns/{megaSignId}/state - AUTHORING har blitt lagt til som en tilstandsVerdi for å støtte redigering av en Mega Sign-mal. Som et resultat er megaSignCancellationInfo ikke lenger et obligatorisk felt
PUT MegasignID State.png

De moderne Hjem- og Behandle-sidene er aktivert for alle gjenværende kontoer

Alle kontoer har fått kontrollsettet sitt oppdatert for å aktivere de moderne Hjem- og Administrer-sidene for brukerne sine.

Kontrollene i administratormenyen forblir tilgjengelige for kontoer som må gå tilbake til den klassiske opplevelsen:

v4-sidekontroller

Adobe Sign-tjenestenivå og konto-ID eksponert i administratormeny

Administratorer kan nå finne sin konto-ID på siden Globale innstillinger:

AccountID.png

Gruppe-ID kan finnes på siden Gruppeinnstillinger:

GroupID.png

Eksplisitt HIPAA-konfigurasjon

Det er en ny side tilgjengelig som tydelig viser når kontoen er aktivert for å administrere avtaler som er underlagt HIPAA-krav.  

  • Denne kontrollen er bare eksponert på kontonivå. Administratorer på gruppenivå har ikke tilgang
  • Denne kontrollen er bare for visning, for å tydelig indikere når kontoen er konfigurert
  • Kontakt kundeansvarlig eller støtte for å aktivere HIPAA-konfigurasjon

Finn mer informasjon om HIPAA-innstillinger her >

HIPAA-innstilling

"Handlingsoppfordring"-knappen har endret seg for kunder som bruker Outlook-skrivebordsprogrammet på Windows-systemer

Mottakere som bruker en Outlook Desktop-e-postklient, vil se en endring i «handlingsoppfordring»-knappen i e-post fra Adobe Sign.

Den nye opplevelsen fjerner den blå HTML-knappen og gir i stedet en klikkbar tekstkobling:

Ny CTA

Notat

Denne endringen påvirker bare Outlook-skrivebordsprogrammer på Windows-systemer. Andre e-postklienter og operativsystemer fortsetter å motta malen med den blå knappen.

Delegering av avtaler med digitale signaturer

Muligheten til å delegere en avtale med påsatte digitale signaturer er forbedret til å tillate delegering fra den opprinnelige e-postvarslingen til mottakeren, gjennom automatisk delegering når konfigurert av en bruker, og gjennom Erstatt nåværende signerer-handlingen på Administrer -siden.


Oppdatert grensesnitt for Payments-integrasjonen

Payments grensesnittet er oppdatert slik at autentiseringskontrollene er bedre synlige, noe som gjør konfigurasjonsprosessen enklere.

Betalingsintegrasjon

Maksimalverdien for datastyring er økt til 5475 dager (15 år)

Kunder som bruker datastyringsregler for å automatisk slette avtaler fra Adobe Sign-systemet kan nå sette den slettingsdatoen til maksimalt 15 år (opp fra ti).


Feltnivå-tekstetiketten for validering av amerikanskesocialsikkerhetsnummer er oppdatert:

Feltnivå-tekstetiketten for validering av amerikansk personnummer er oppdatert for å klargjøre at SSN er amerikansk-basert:

Amerikansk SSN-validering

Påminnelse: Sosial autentisering er fjernet

Som annonsert i november, er autentiseringsmetoden som bruker sosial identitet fjernet fra listen over autentiseringsmetoder i Admin-menyen.

End of Service for SocialID.png

Påminnelse: Personlig Twitter-integrasjon er fjernet

Som kunngjort i desember er brukernes mulighet til å lage personlige godkjente tilkoblinger til Twitter fjernet.

End of Service for Personal Twitter

Inaktive brukere vil motta et e-postvarsel når de inkluderes i en avtale

Brukere som er satt til Inaktiv status mottar nå en e-postvarsel som instruerer mottakeren om å delegere avtalen til en annen bruker.

Løste problemer

Løste problemer.png

Adobe Sign: Mai 2021

Forbedret funksjonalitet

Overfør eierskap til bibliotekmaler og webskjemaer til en annen bruker

Endring av eieren til ressurs kan nå gjøres av enhver administrator for kontoen som har tilgang til ressursen.

Administratoren kan tildele eierskapet til ressursen til hvilken som helst bruker under deres myndighet.

  • Kontoadministratorer har tilgang til alle delte ressurser og alle brukere. Derfor kan administratorer på kontonivå overføre eierskapet til en hvilken som helst bibliotekmal eller et hvilket som helst webskjema til en hvilken som helst annen brukere på kontoen deres.
  • Hvis ressursen er konfigurert til å bare være tilgjengelig for én bruker (eieren), deles den ikke og kan derfor ikke tilordnes til en ny eier.
  • Gruppeadministratorer har bare tilgang til bibliotekmaler og webskjemaer i gruppene hvor de har administratormyndighet
  • Gruppeadministratorer kan bare tildele en ressurs på nytt til en bruker hvis hoved gruppe faller under deres administrative myndighet
12.1.1

OPPDATERTE API-ENDEPUNKTER SOM STØTTER RESSURSOVERFØRING

Endepunktene beskrevet nedenfor er bare tilgjengelige i v6 REST API.

 

Utvidet for å støtte oppdatering av bibliotekdokumentets eier.

LibraryDocumentInfo:

 

Put LibDocID

Ytterligere feilstatuskoder:

Put LibDocID

Utvidet for å støtte oppdatering av kontrollprogrameieren.

WidgetInfo:

Put widgetID

Ytterligere feilstatuskoder:

Put widgetID

Nye felt i LibraryDocument objekt:

12.1.1

Nye felt i LibraryDocumentInfo-objektet:

Get LibDocID1211

Felt med oppdatert oppførsel:

Get LibDocID1211

Nye felt i WidgetInfo-objektet:

GEt WidgetID 1211

Felt med oppdatert oppførsel:

GEt WidgetID 1211

Endringer i brukeropplevelsen

Standardreturverdien for v6 REST GET /workflows{workflowId} har blitt endret

v6 REST GET /workflows{workflowId} API-kallet har blitt oppdatert til å returnere gjeldende versjon av WorkflowID (vs. original versjon-ID, som var returverdien før mai-utgivelsen)

Denne oppdateringen tilpasser standard API-opplevelse med Webhook-opplevelsen, og gir samme WorkflowID, som bør forbedre utviklingen og administreringen av applikasjoner.

Hvis kontoen din av en eller annen grunn krever at API-et returnerer original-ID (som det gjorde før mai-utgivelsen), kontakt support for å be om at kontoen din returnerer grunnversjon-IDene for arbeidsflyter

Løste problemer

12-1-1 Løste problemer.png

Adobe Sign: Juni 2021

Brukere i flere grupper

Administratorer i kontoer med flere grupper kan nå gi brukere i kontoen tilgang til flere grupper. Dette gjør det mulig å bruke grupper som en form for arbeidsflytmal og håndheve spesifikke kontroller for sending og signering for bibliotekmalene som er tilgjengelige for gruppen.

Gå til brukergrensesnittalternativer for administratorer

Eksisterende virksomhets- og forretningskontoer som ønsker å oppgradere, kan gå gjennom oppgraderingsprosessen her >

Et sammendrag av de viktigste forskjellene finner du her >

Vi introduserer Liquid Mode i Sign

Aktiver Liquid Mode-visning for mobiltelefoner for HTML sendt via Send side eller sendAgreement-API-en. Alternativet for å aktivere Liquid Mode i Sign for HTML er nå tilgjengelig i administratormenylisten både på konto- og gruppenivå.

Fullstendige detaljer om Liquid Mode-dokumenter finner du her >

Liquid Mode i brukergrensesnittet for administratorer

Notat

Liquid Mode er for øyeblikket bare tilgjengelig i NA1-, NA2- og NA4-miljøene.

Identifiser miljøet ditt her >

Sømløse oppdateringer av webskjemaer

Webskjemaer i Utkast -status kan redigeres for å endre følgende:

  • webskjemanavnet
  • redigere e-postadressene til medunderskrivere
  • e-postadressen til partene som er satt på kopi
  • vedlagte filer som skal redigeres
  • feltene i webskjemaet (tidligere tilgjengelig)

Oppdatering av et aktivt webskjema gjør det mulig å redigere skjemaelementene uten å endre den opprinnelige URL-adressen, noe som gir en friksjonsfri prosess hvis du trenger å oppdatere innholdet i et webskjema som allerede er innebygd eller sendt til publikum. Disse elementene kan redigeres:

  • filene (dokumentene) og anvendte felt for mottakerne
  • medunderskrivere (fra Behandle-siden)
  • parter som skal ha en kopi (fra Behandle-siden)
Redigere et eksisterende webskjema

Notat

For å aktivere sømløs webskjemafunksjonalitet må du aktivere alternativet Tillat flere deltakere i menyen Globale innstillinger:

Stempel for deltakelse: Kontrolltittel og bedriftsvisning

Kontroller er lagt til for å tillate eller skjule mottakerens stilling og firma (avledet av brukerprofilen) på stempelet for deltakelse.

Ytterligere informasjon kan du finne på Felttyper-siden >

Stempel for deltakelse

Forbedrede søkealternativer: Prefiks- og setningssamsvar

Avanserte søkealternativer har blitt introdusert for å tillate mer spesifikke søkemønstre som vil bidra til å redusere den returnerte avtalelisten.

Mer informasjon om hvordan søk virker i Adobe Sign, finner du her >

OAuth 2.0 er den nye standarden

En ny (forbedret) versjon av OAuth-endepunktet er lagt til for å unngå bruksfeil. I denne versjonen:

  • api_access_point / web_access_point returnerer bare i Access Token Request (i brødteksten)
  • Adobe Sign godtar ikke hemmeligheten som spørringsparameter
  • Rotasjon av klienthemmelighet støttes

OAuth v1-endepunktet vil fortsatt fungere for eksisterende koblinger i de kommende månedene for å sikre tilgang.

Avskrivingen av OAuth v1 vil bli kunngjort på siden for tekniske varsler når det er planlagt.

 

Rotering av klienthemmeligheter

Klienthemmeligheter i programmet kan roteres av enhver administrator med tilgang til program-ID-en i brukergrensesnittet til Adobe Sign:

Rotering av klienthemmeligheter

Endringer i brukeropplevelsen

Mega Sign er nå Send samlet

Navnet på funksjonen Mega Sign endres til Send gruppevis. Dette er bare en navneendring og inkluderer ikke endringer i funksjonens virkemåte.

12.2

Gruppeadministratorer kan bare se API-programmene som faller inn under deres administratormyndighet

Synligheten til programmer som er knyttet til kontoen, er nå begrenset til bare å vise programmene som faller inn under brukerens administrative omfang. Bare gruppeadministratorer kan se virkemåteendringen:

  • Brukerne ser programmene de eier
  • Gruppeadministratorer ser programmene under gruppen(e) de har administratormyndighet over
  • Kontoadministratorer ser alle programmene i kontoen

E-post til avsenderen når en avtale som er fullført, har blitt oppdatert

Det endelige e-postvarselet for en avtale som er sendt til avsenderen, har blitt oppdatert for å gi en omfattende liste over alle parter som er varslet om den fullførte avtalen.

Bare den opprinnelige avsenderen får denne e-postmalen.

Utvidet e-postmal for opphavspersonen til avtalen

Nye tjenester fra sikkerhetstjenesteleverandører

Nye sikkerhetstjenesteleverandører fra Cloud Signature Consortium er integrert for å støtte digitale signaturer: DigiCert (Sveits), Entrust (global), VIDA (Indonesia) og Worldline (Frankrike).

 Oppdatert v6 REST API-resultat for GET /agreements/{agreementId}/signingUrls

Når du kalte opp GET /agreements/{agreementId}/signingUrls før juniutgivelsen, returnerte API-en en 404-feil umiddelbart etter at avtalen var blitt opprettet.

Kort tid etter at 404-feilen var blitt fjernet, ville svaret returnere et ikke-404-svar, men inkluderte bare avsenderens URL-adresser for signatur. (Mens underskriverens deltakelse fortsatt ble definert.)

Etter lanseringen i juni 2021 returneres en 404: AGREEMENT_NOT_EXPOSED-kode til hele listen over URL-adresser for signatur er fullført, og da leveres en 200-kode.

Kunder som ikke ønsker å fortsette å prøve API-kallet før 200-svaret returneres, oppfordres til å bruke Webhooks og svare på AGREEMENT_CREATED-hendelsen.

API  

Sign Search V6-API for Adobe Sign 

Nye søkerelaterte API-er blir eksponert for kundebruk. Search-API-en støtter oppføring, søk, filtrering og sortering av en brukers liste over avtaler vedkommende har deltatt i.

Se gjennom Search API-en her >

Løste problemer

Adobe Sign: August 2021  

Endringer i brukeropplevelsen

  • Internasjonal støtte for Aadhaar - Kunder fra alle Adobe Sign-forekomster kan nå bruke den valgfrie Aadhaar-tjenesten som digital signaturleverandør. Den var tidligere bare tilgjengelig for kontoer i IN1-forekomsten. Aadhaar-tillegget kan kjøpes for en ekstrakostnad per signaturtransaksjon.
  • REST v6-oppdatering: POST /users - REST v6-API-kallet POST /users er oppdatert til å opprette brukeren i kontoens Standard-gruppe hvis den valgfrie parameteren primaryGroupId ikke er definert.  Bare v6 av REST API er berørt av denne endringen.

Løste problemer

Issue key

Beskrivelse

4299495

Løste et problem i Workflow Designer som ville hindre en kundedefinert nettadresse i instruksjonene fra å fungere.

4308294

Rettet et problem i rapport-CSV-filen der feltene Til og Mottakernavn kunne stå tomme når samme mottaker-e-post brukes mer enn én gang i avtalen.

4310569

Adobe Sign-malene har blitt filtrert bort fra sandkassealternativene.

4311098

Korrigerte et problem der gruppeadministratorer ikke kunne oppdatere brukere i en gruppe ved CSV-opplasting.

4311723

Løste et problem der GET /groups/ID/users API-kallet ville mislykkes hvis brukeren var på en annen Adobe Sign-instans.

4312103

Korrigerte et problem der SAML-brukere opprettet via masseopplasting ville være i tilstanden Opprettet (i stedet for Aktiv).

4312309

Korrigerte et problem der gruppeadministratorer ikke kunne tildele eierskapet til web-skjemaer på nytt hvis andre brukere i gruppen opprettet dem.

4312840

La til en løsning på et problem med aktivering av nye brukere når en andre aktiverings-e-post ble sent til den nye brukeren og lenken i den andre e-posten ble brukt.

4314751

Har korrigert et problem der alternativet for å avslå avtalen ikke var synlig ved signering på vegne av en annen bruker.

4315033

Rettet et problem der kontoadministratorer ikke kunne tilbakestille passord når SAML-modus var satt til Mandatory.

4315605

Rettet et problem der bilder av myndighetsutstedt ID ikke ble behandlet på riktig måte.

4316057

Rettet et problem der myndighetsutstedt ID ville gi en feilmelding som indikerte at de fire hjørnene av dokumentet ikke kunne finnes.

4316474

Korrigerte et problem der Signer på vegne av var synlig i kontoer der alternativet ikke var aktivert.

4316659

Løste et problem der e-postadressen for actingUserEmail i et GET /agreements/id-kall returnerte en systemgenerert e-postmelding etter at avtalen var fullt signert.
 

4317095

Rettet et problem der et mottakernavn ville bli importert til Deltaker 1-etiketten når kunnskapsbasert autentisering ble brukt for den første underskriveren.

4317221

Korrigerte et problem der automatiske varsel-e-poster for mislykkede webhooks ville bli sendt til webhook-oppretteren til tross for at det var konfigurert til ikke å varsle oppretteren.

4317347

Rettet opp et problem der autentisering av OAuth i Power Automate ville omdirigere brukeren til hjemmesiden.

4317429

Løste et problem der administratorer ikke kunne oppdatere egenskapen Kan sende for brukere ved oppdatering via CSV-opplasting.

4317548

Løste et problem der noen kunder som bruker iPad ville se nettsiden i stedet for siden optimalisert for mobilenheter.

4317629

Rettet et visningsproblem med navn som inneholder apostrof og som viste HTML-koden for apostrofen.

4318175

Løste et problem der brukere fikk feilmelding ved arkivering av en konto via e-postlenken.

4319012

Løste et problem der brukere opprettet via REST v5 og v6 POST /users ikke ble opprettet i standardgruppen.

4320197

La til en løsning på et problem der signerarens identitetsrapport ikke kunne lastes ned fra Administrer -siden på grunn av at knappen var inaktiv.

Adobe Sign: september 2021

Forbedret funksjonalitet

  • Sandbox – Kunder på bedriftsnivå kan kjøpe tilgang til et Sandbox-miljø for å teste maler, arbeidsflyter for kunder, API-programmer og mye mer. Disse objektene kan flyttes fra produksjon til sandbox for oppdateringer i et sikkert miljø, og deretter flyttes til bake til produksjon når oppdateringene er verifiserte og klare for distribusjon.
Sandbox – malvisning

  • ECDSA Digital signaturstøtte - Adobe Sign støtter nå sikrere og mer effektive digitale signaturer basert på ECDSA-formatet, som bruker elliptisk kurve-kryptografi som definert i ANS X9.62-2005-standarden.
    Nå støttes NIST-kurver med SHA-2-hashfunksjoner, som definert av FIPS-standarder, og dette gir våre TSP-partnere (Trust Service Providers) fra Cloud Signature Consortium muligheten til å gi underskrivere raskere og sikrere legitimasjon med elliptisk kurve, inkludert de som oppfyller anbefalte krav for føderal bruk i USA og offentlig bruk i Singapore.
  • Liquid Mode oppdatertLiquid Mode-signeringsopplevelsen er blitt utvidet utover avtaler til å inkludere webskjemaer. Liquid Mode-skjemaer kan forbedre underskriverens opplevelse dramatisk ved å redusere behovet for å klype og zoome for å se skjemainnholdet, samtidig som fokuseringen på felt som må fylles ut, forbedres.
I tillegg er Liquid Mode ikke lenger begrenset til nordamerikanske områder. Alle bedrifts- og forretningskontoer har nå tilgang uavhengig av plassering.

Detaljer om Liquid Mode finner du her >

  • Nye TSP-er Cleverbase (Nederland), PrimeSign (Østerrike), Sectigo (global) og TrustPro (Irland) er den nye TSP-ene fra Cloud Signature Consortium som leverer sertifikater for å bruke sikre digitale signaturer som oppfyller de høyeste standarder og samsvarkrav.
  • Tilpass Til- og Kopi-feltene i e-posthoder til mottakere - Kunder som er bekymret for å lekke e-postadresser via e-posthodene til mottakere kan velge å skjule e-postadresseverdiene i Til- og Kopi-feltene.
    • Dette alternativet er tilgjengelig for Enterprise- og Business-kontoer og kan konfigurere på konto- og gruppenivå.
    • Funksjonskontrollene kan åpnes ved å navigere til Kontoinnstillinger > E-postinnstillinger > Tilpass Til- og Kopi-felter.
Tilpasse Til- og Kopi til-feltene i e-posthoder til mottakere

Endringer i brukeropplevelsen

  • Adobe vilkår for bruk-aksept på eSign-sider - For å overholde Adobe juridiske krav oppdaterer Adobe Sign akseptfunksjonaliteten for vilkår for bruk (ToU) på eSign-siden. Under den nye opplevelsen må alle «ukjente» mottakere akseptere Adobe Sign ToU og personvernerklæring (ved å klikke på Fortsett-knappen) før de samhandler med avtalen.Denne aksepten er forskjellig fra enhver tilpasset ToU som kundekontoen kan ha konfigurert, som vil fortsette å styres av kontokonfigurasjonen for TOU/CD-aksept.
  • En «ukjent» mottaker er enhver e-postadresse som ikke er en registrert, aktiv brukers e-postadresse i en klarert konto.
  • "Kjente" brukere har godtatt Adobe Sign-vilkårene for bruk som del av registreringsprosessen da de verifiserte brukerkontoen, så de blir ikke bedt om å godta på nytt.

Nedenfor er et eksempel på flyten Implisitt samtykke for en avtale med egendefinerte bruksvilkår konfigurert av kunden:

  1. Godta Adobe Sign-vilkårene for bruk ved å velge Fortsette-knappen (etter at avtalen er åpnet).
  2. Fyll ut avtalefeltene etter behov.
  3. Aksepter kundeerklæringen og tilpasset ToU ved å velge Klikk for å signere-knappen.
Kontrollert tilgang til signering

  • Låsing av navneverdier utvidet til skrevne signaturer – Marsutgivelsen innførte en innstilling for å aktivere/deaktivere et mottakers mulighet til å redigere navneverdien sin ved signering, forutsatt at navnet var oppgitt eller kjent (via API eller brukerprofil).  Skrevne signaturer ble utelatt fra denne funksjonen som ga mulighet til at noen underskrivere kunne endre navneverdien sin under signaturprosessen.  Septemberutgivelsen oppdaterer denne funksjonen til å omfatte innstilling for låsing av navn for alle signaturtyper, inkludert skrevne signaturer. 
  • Kunder som har aktivert Skriv navnet og initialene sine og deaktivert Signører kan endre navnet eller initialene sine vil se en funksjonsendring – navneverdien kan ikke lenger redigeres under signaturprosessen for skrevne signaturer.
  • Kunder som ønsker å tillate redigering av navneverdien under signaturprosessen, skal aktivere innstillingen Underskrivere kan endre navn eller initialer (i menyen Signaturinnstillinger).
La mottakere redigere navnet sitt

  • Inaktive brukere kan signere avtaler – Adobe Sign behandler nå inaktive brukere som om de er ukjente i systemet (for signering av innkommende avtaler). Når en inaktiv bruker blir bedt om å signere en avtale, opprettes en ny bruker-ID til engangsbruk eksplisitt for signering av den ene avtalen. Bruker-IDen til engangsbruk er uavhengig av den inaktive bruker-IDen og kontoen som styrer den. Dette har flere implikasjoner:
  • Avtaler sendt til en inaktiv bruker, kan signeres, fordi inaktiv-statusen ikke gjelder bruker-IDen til engangsbruk generert for avtalen.
  •  Avtaler signert av bruker-IDene til engangsbruk er ikke aktiva for den inaktive bruker-IDen og ligger ikke i kontoen til den inaktive bruker-IDen.
  • Delinger fra den inaktive bruker-IDen vil ikke gjenspeile avtaler signert av bruker-IDer til engangsbruk.
  • Rapporteringer mot den inaktive bruker-IDen vil ikke gjenspeile avtaler signert av bruker-IDen til engangsbruk.
  • Hvis den inaktive bruker-IDen aktiveres igjen, vil de ikke se oppføringer med avtalene signert av bruker-IDene til engangsbruk på Behandle-siden.

Det er to unntak fra den ovennevnte virkemåten:

  • Avtaler sendt til brukeren før de ble merket som inaktive, kan ikke signeres (avtalen var allerede bundet til den inaktive bruker-ID-en).
  • Brukere som er eksplisitt konfigurert til ikke å få lov til å signere avtaler vil fortsette å bli nektet alle signeringshandlinger.

Inaktive brukere er fremdeles forhindret fra å logge på Adobe Sign-systemet og sende avtaler under sin myndighet (på noen måte).

  • Forbedret sikkerhet for webskjematilgang via passord – Webskjemaer har inkludert en forsinkelse etter et antall mislykkede forsøk på tilgang til en passordbeskyttet nettadresse.
  • Internasjonal støtte for Aadhaar – Kunder fra alle Adobe Sign-forekomster kan nå bruke den valgfrie Aadhaar-tjenesten som digital signaturleverandør. Den var tidligere bare tilgjengelig for kontoer i IN1-forekomsten. Aadhaar-tillegget kan kjøpes for en ekstrakostnad per signaturtransaksjon.
  • Begrenset deling av avtaler - Avtaledeling har blitt begrenset når avtalen deles til en ekstern e-postadresse.
    • Kontoer med flere lisenser kan dele en avtale opptil ti ganger. 
    • Individuelle kontoer kan dele en avtale opptil 5 ganger.
    • Avtaledeling med interne brukere er ubegrenset.
  • HIPAA-aktiverte kontoer kan nå få tilgang til kontrollene for bilder og koblinger i e-postadresser for mottakere på siden Globale/gruppeinnstillinger.

Se gjennom HIPAA-relaterte konfigurasjoner her >

Bilde og koblinger til avtalen i e-post

  • Rekkefølgen som Filvedlegg inkluderes i den endelige PDF-filen har blitt oppdatert til å sortere etter sidenummer først, og deretter feltposisjon andre (når man leser fra venstre til høyre; fra topp til bunn)
  • Funksjonen Erstatt mottaker på den nye Behandle -siden lar nå avsenderen inkludere en valgfri melding til den nye mottakeren.

Gå gjennom funksjonen Erstatt mottaker for mer informasjon >

Erstatt mottaker

  • Eksterne underskrivere som skal åpne fullførte avtaler må nå gå gjennom en godkjenningsprosess når godkjenning med flere faktorer er konfigurert for avtalen (i stedet for å bli bedt om å logge på Adobe Sign).
  • Webskjemaer rapporterer nå feltverdiene til ubekreftede webskjemaer ved tilgang til feltdata ved hjelp av funksjonen Last ned skjemafeltdataBehandle-siden.

For mer informasjon om webskjemaer >  

Last ned skjemafeltdata

API-oppdateringer

  • Les avtale-alternativ for webskjemaer – To nye REST v6-API-kall er tilgjengelige for å gi tilgang til visning av webskjemaer:
    • GET /widgets/<resourceId>
    • GET /widgets/<resourceId>/combinedDocument/url
  • GET/workflows/{workflowId} returnerer nå deltakerrollen i svaret.

Løste problemer

4292343 Forbedret signaturklarhet ved bruk av TYPE-signaturalternativet på mobile enheter.
4295123 Løste et problem som kunne hindre visning av digitale signaturer når de ble åpnet i en nettleser.
4299289 Forbedret opplevelsen Erstatt mottaker ved å la avsenderen inkludere en melding til den nye mottakeren.
4299857 Løste et problem som kan føre til at en signert avtale ikke bruker sertifikatseglet.
4304261 Løste et problem som kan føre til at alternativet Les avtale ikke fylles ut i Alternativer-menyen
4308516 Løste et problem der brukere kontinuerlig ble bedt om å få administrators samtykke når de brukte OneDrive
4310225 Løste et problem med at avtaler som inneholder flere signaturer, utløste en serverfeil: Feilmelding: Signaturen som er brukt på dette dokumentet, er ugyldig. Fjern den og signer på nytt.
4310416 Oppdaterte v5 REST API for å opprette brukere i en aktiv tilstand når de blir opprettet med POST /brukere
4311287 Løste et problem der gruppenavigasjonsknappen forsvant i UMG-aktiverte kontoer etter at en bruker ble fjernet fra en gruppe.
4311956 Løste et problem der den angitte skriftstørrelsen for et felt ikke ble gjenspeilet i signaturopplevelsen.
4312302 Løste et problem som ville fjerne alternativet Tilbakestill passord hvis SAML-modusen var satt til Obligatorisk.
4312735 Løste et problem som ville føre til at delte hendelsesvarsler ble levert når delte varsler ble deaktivert.
4313025 Løste et problem der en skjemautfyllerrolle ikke kunne fylle ikke-tildelte roller når Hybrid-ruting var aktivert.
4313030 Løste et problem der UMG-aktiverte kontoer ville utløse en feil ved bruk av en tilpasset arbeidsflyt hvis primærgruppen til avsenderen ikke har lov til å sende.
4313264 Oppdaterte HIPAA-aktivert innstilling for å gi tilgang til innstillingene for e-postkobling/bilde på siden Global setting.
4315839 Løste et problem med tilpassede arbeidsflyter som ikke tillot forhåndsfylling av felter når avsenderen også var den andre mottakeren.
4316058 Oppdaterte virkemåte for rapportfelt for å tillate innledende nuller i tekstfelt.
4317382 Løste et problem med valgknapper som viser HTML-koden for apostrofer i verktøytipset
4317978 Oppdaterte måten filvedlegg blir ordnet på i den endelige PDF-filen, til å gruppere vedlegg basert på sidenummeret i feltet først, og deretter den relative posisjonen til feltet (ved lesing fra venstre til høyre og topp til bunn).
4318598 GET/workflows/{workflowId} REST v6 API-kallet returnerer nå deltakerrollen i svaret.
4318606 Funksjonen Last ned skjemafeltdata på Behandle-siden returnerer nå feltverdier for webskjemaer som ennå ikke er bekreftet.
4318617 Løste et problem der UMG-aktiverte kontoer ikke tillot en gruppeadministrator å sende en invitasjon på nytt.
4318679 Løste et periodisk problem som kan føre til at dokumenter med skriftlig signatur ikke kan lastes opp.
4318926 Løste et problem som kan utløse en feil (informasjonskapselfunksjonaliteten er deaktivert i nettleseren din) ved oppretting av en avtale fra en mobilenhet.
4318991 Løste et problem som kunne føre til at innstillingen for maksimalt antall mislykkede pålogginger ignoreres hvis SAML var satt til Tillatt.
4319068 Eksterne mottakere må nå gå gjennom en andre godkjenningsprosess (i stedet for å logge på Adobe Sign) for å få tilgang til fullførte avtaler når godkjenning med flere faktorer er konfigurert.
4319422 Løste et problem der en mottaker kunne byttes ut uten å bekrefte passordet (for avtale med passordgodkjenning)
4319455 Løste et problem i avansert deling der innstillinger kanskje ikke ble beholdt etter lagring.
4320123 Løste et problem som kan utløse en feil ved forsøk på å vise og godkjenne en avtale på Behandle-siden.
4320205 Løste et problem som kunne forhindre lagring av fremgang ved forhåndsutfylling av en avtale med avansert deling.
4320542 Løste et problem for UMG-aktiverte kontoer der alle brukerens gruppetilknytninger kunne bli fjernet hvis én gruppe ble fjernet ved hjelp av Søk.
4321357 Løste et problem som kan utløse en feil på sendesiden når KBA er valgt for godkjenning, og Krev navn ved sending er aktivert.
4322445 Forbedret redigering for å sikre konsekvente bakgrunnsfarger.
4322956 Løste et problem med tilpassede e-postmaler der mottakerne ikke ville se underskriverens faktiske e-postadresse.
4323609 Under utvikling – Løste et problem der avtaler fullført ved opplasting av et signert dokument ikke ville utløse webhookvarselet AGREEMENT_WORKFLOW_COMPLETED.
4323968 Forbedret signaturlåsefunksjonen til å inkludere skrevne signaturer når navneverdien leveres via profil eller API.

Adobe Sign: Oktober 2021  

Forbedret funksjonalitet

  • Lenker for rapportering av misbruk – Kontoer for små virksomheter og enkeltkontoer inkluderer nå en lenke som gir tilgang til en metode for å rapportere potensielt misbruk i forbindelse med innkommende avtaleforespørsler.
Rapporter misbruk-lenke i e-post

  • Notarize-integrering – Adobe Sign-integrering med Notarize, Inc.s plattform for ekstern nettbasert notarialbekreftelse (RON, Remote Online Notarization) lar kunder legge til ekstern nettbasert notartjeneste som en del av sine Adobe Sign-transaksjoner. Tilgjengelig for aktivering for amerikanske Enterprise- og Business-kunder som selges direkte av Adobe via ETLA-programmet. Bare disse kundene kan kjøpe notartransaksjoner som et tillegg for en ekstra kostnad.
    • Send-sideoppdateringer – Kunder med notar aktivert kan velge alternativet Krever notarialbekreftelse på mottakerposten, rett til høyre for godkjenningsmetoden:
Notat

Kunder som bruker den innebygde Send-side i sine programmer eller integreringer, vil også ha tilgang til notarfunksjonaliteten.

Notarize-grensesnitt på Send-siden

Når avtalen er konfigurert og avsenderen klikker på Neste, får avsenderen ytterligere konfigureringsalternativer for notarprosessen:

Konfigurere Notarize-alternativer

  • API-oppdateringer – Det er betydelige oppdateringer til API-ene for å støtte Notarize-integreringen:

POST /agreements

API-et POST /agreements er oppdatert for å støtte sending av en avtale til notarialbekreftelse.

  • Den nye rollen NOTARY_SIGNER brukes til å indikere en notarøktdeltaker.
  • Et nytt NotaryInfo-attributt er lagt til i definisjonen AgreementInfo for å inneholde alle alternativene knyttet til oppretting av en ny avtale som krever notartjenester.

Parameternavn

REST-objekt

Beskrivelse

memberInfos

ParticipantInfo[]

En rekke ParticipantInfo-objekter som inneholder deltakerspesifikke data (f.eks. e-post). Alle deltakere i matrisen tilhører samme sett.

rolle

Verdi

Beskrivelse

UNDERSKRIVER

Signerer avtalen

GODKJENNER

Godkjenner avtalen

DELEGATE_TO_SIGNER

En som selv ikke kan signere, men delegerer avtalen til en annen underskriver

DELEGATE_TO_APPROVER

En som selv ikke kan godkjenne, men delegerer avtalen til en annen godkjenner

SHARE

Deltaker som denne avtalen er delt med

DELEGATE

Deltaker som avtalen ble delegert til. Denne rollen kan ikke brukes under oppretting eller oppdatering av avtale gjennom POST/PUT-kallet på avtaleressurs. Delegasjonen skjer separat av deltakerne.

NOTARY_SIGNER

Notarøktdeltaker

Rolle for alle deltakere i settet (underskriver, godkjenner og så videre)

 

FileInfo-utvidelse

FileInfo-definisjonen må utvides for å indikere hvilke dokumenter som skal notarialbekreftes.

FileInfo

Parameternavn

Type

Standard

Obligatorisk

Beskrivelse

dokument

Document

valgfritt

Et dokument som er tilknyttet avtalen.
Dette feltet kan ikke angis i POST-kall.
Ved GET-kall er dette det eneste feltet som returneres i responsen

label  

Streng

valgfritt

Den unike etikettverdien til et filinfoelement. I en egendefinert arbeidsflyt vil dette tilordne en fil til det tilsvarende filelementet i arbeidsflytdefinisjonen.

libraryDocumentId

Streng

valgfritt

ID for et eksisterende bibliotekdokument som blir lagt til avtalen

transientDocumentId

Streng

valgfritt

ID for et midlertidig dokument som skal legges til avtalen

notarize

true

false

valgfritt

Indikerer at dette dokumentet må notarialbekreftes.

 

ParticipantInfo-utvidelse

ParticipantInfo-definisjonen er utvidet slik at notargodkjenningsmetoden kan angis.

ParticipantInfo

Parameternavn

Type

Standard

Obligatorisk

Beskrivelse

e-post

Streng

I/T

obligatorisk

E-post til deltakeren.

notaryAuthentication

Enum

MULTI_FACTOR_AUTHENTICATION

valgfritt

MULTI_FACTOR_AUTHENTICATION – Notargodkjenning utføres ved hjelp av en godkjenningsmetode med flere faktorer
NONE – Ingen godkjenning kreves.

 

NotaryInfo

Et nytt valgritt notaryInfo-felt er lagt til i AgreementInfo-definisjonen for å inneholde NotaryInfo-objektet som angir flere alternativer knyttet til notarialbekreftelse.

NotaryInfo

Parameternavn

Type

Standard

Obligatorisk

Beskrivelse

notaryType

Enum

Hvis bare notartjeneste på forespørsel fra Notarize er aktivert på kontoen,
så vil notaryType som standard være NOTARIZE_NOTARY, ellers vil den som standard være BYON_NOTARY

obligatorisk

NOTARIZE_NOTARY – Notartjenesten besørger notar
BYON_NOTARY – Konto besørger notar

betaling

Enum

BY_SENDER

valgfritt

Gjelder bare hvis typen == NOTARIZE_NOTARY
BY_SENDER – Avsender betaler for notarialbekreftelsen
BY_SIGNER – Underskriveren betaler for notarialbekreftelse

appointmentStart

Streng

""

valgfritt  

ISO_DATE_TIME-formatert streng Se ISO_ZONED_DATE_TIME

note

Streng

ingen

valgfritt  

Merknader for notarøkt.

notaryEmail

Streng

""

valgfritt  

e-post for ta med deg din egen notar

 

Eksempel på /agreement

 

PUT|GET /agreements/{aid}

API-et PUT /agreements/{aid} støtter oppdatering av en avtale med alternativer for notarialbekreftelse. API-et GET /agreement /{aid} returnerer alle alternativer som er angitt for notarisering av avtalen. Se avsnittet POST /agreements for å se oppdaterte attributter.

 

Feilkoder

Eksisterende feilkoder for POST /agreements forblir uendret. Vi har definert en ny feilkode som angitt nedenfor:

REST-feilkode

HTTP-statuskode

Melding

Scenario

PERMISSION_DENIED

403

Brukerinnstilling eller OAuth-omfangstoken tillater ikke sending av avtale til notarialbekreftelse.

Denne feilen oppstår når rollen er satt til NOTARY_SIGNER og API-kalleren (det vil si potensiell avsender) ikke har notarfunksjon aktivert og/eller hvis notartjenesteleverandør ikke er angitt.

 

Dokumentasjonseffekt

I forespørselens AgreementInfo-objekt vil "status"-elementet inkludere den nye avtalestatusen WAITING_FOR_NOTARIZATION.

 

POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens

API-et kan brukes av kunder (notarunderskrivere) for å skaffe et signeringstoken som lar dem fullføre e-signeringsfasen av flyten. 

  • Ny signeringsfunksjon er lagt til for å registrere den nye rollen – ACCEPT_BEFORE_NOTARIZATION. 
  • Signeringstokener bør ikke anskaffes for å fullføre notarialbekreftelsesfasen.

 

PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status

API-et kan brukes av kunder (notarunderskrivere) for å fullføre e-signeringsfasen i flyten. For å tilrettelegge for den nye rollen har ny enumstatusverdi blitt introdusert – ACCEPTED_BEFORE_NOTARIZATION.

Attributt

Type

Beskrivelse

Status

Enum<String>

Verdi

SIGNED

GODKJENT

ACCEPTED

DELIVERED

FORM_FILLED

ACCEPTED_BEFORE_NOTARIZATION

                                         

Denne statusen indikerer at mottakeren med rollen SIGNER fullførte avtalen.

Denne statusen indikerer at mottakeren med rollen APPROVER fullførte avtalen.

Denne statusen indikerer at mottakeren med rollen ACCEPTOR fullførte avtalen.

Denne statusen indikerer at mottakeren med rollen CERTIFIED_RECIPIENT fullførte avtalen.

Denne statusen indikerer at mottakeren med rollen FORM_FILLER fullførte avtalen.

Denne statusen indikerer at mottakeren med rollen NOTARY_SIGNER fullførte avtalen uten å notarialbekrefte den

Notarunderskriveren kan følge sekvensen nedenfor med API-kall for å fullføre e-signeringsfasen:

  1. GET /agreements/{agreementId}/members – for å hente notarunderskriverens deltaker-ID og deltakersett-ID
  2. POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens – for å be om signeringstoken for notarunderskriver med ACCEPT_BEFORE_NOTARIZATION-funksjonalitet
  3. POST /transientDocuments – for å laste opp dokument som ble gjennomgått
  4. PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status – for å sende gjennomgått dokument og fullføre e-signeringsfase.

Ny webhook-hendelse

Kunder kan abonnere på ny webhook-hendelse, AGREEMENT_READY_FOR_NOTARIZATION, for å bli varslet når avtalen er klar for notarialbekreftelse. Hendelsen er ikke synlig i webhooks-brukergrensesnittet og kan abonneres på via API-kallet POST /webhooks.

Dokumentasjonseffekt

Følgende API-er endres ikke, men dokumentasjonen er oppdatert for å inkludere den nye avtalestatusen WAITING_FOR_NOTARIZATION eller den nye rollen NOTARY_SIGNER.

GET /agreements

I svarobjektet UserAgreements/UserAgreement, inkluderer "status"-elementet nå tilsvarende status "WAITING_FOR_NOTARIZATION".

GET /agreements/{agreementId}

I svarobjektet AgreementInfo, inkluderer "status"-elementet nå tilsvarende status "WAITING_FOR_NOTARIZATION".

GET /agreements/{agreementId}/events

API-et er oppdatert for å støtte de nye hendelsene READY_TO_NOTARIZE og NOTARIZED.

Som svar Hendelse-objekt

  • "participantRole"-elementet inkluderer nå den nye rollen NOTARY_SIGNER.
  • "type"-elementet inkluderer de nye hendelsene READY_TO_NOTARIZE og NOTARIZED. "description"-elementet vil være henholdsvis "Dokument sendt til notarialbekreftelse" og "Notarialbekreftet dokument mottatt"

GET /agreements/{agreementId}/members/participantSets/{participantSetId}

I svarobjektet DetailedParticipantSetInfo inkluderer "status"-elementet nå den tilsvarende statusen WAITING_FOR_NOTARIZATION.

PUT /agreements/{agreementId}

Be om AgreementInfo-objektet inkluderer nå statusen "WAITING_FOR_NOTARIZATION".

PUT /agreements/{agreementId}/members/participantSets/{participantSetId}

WAITING_FOR_NOTARIZATION-status er én av "status"-elementverdiene i DetailedParticipantSetInfo-objektet.

POST /agreements/{agreementId}/view

WAITING_FOR_NOTARIZATION-status er lagt til som en av de tillatte visningene.

GET /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingInfo

Hvis deltakeren som er angitt i forespørselsbanen, har en notarunderskriverrolle, returnerer API-et signeringskonfigurasjonen ACCEPT_BEFORE_NOTARIZATION, sammen med alle de andre signeringskonfigurasjonene for denne avtalen/deltakeren.

Løste problemer

Problem Beskrivelse
4308901 Rettet et problem der delegering av en avtale med telefongodkjenning ville føre til en feil hvis det delegerte telefonnummeret hadde samme landskode.
4314113 Løste et problem der standard utløpsdatoer ikke kunne redigeres av brukere når de sendte en ny avtale
4318558 Rettet et problem der erstatning av en mottaker med telefongodkjenning ville føre til feilmeldingen "Den angitte deltakersett-IDen er ugyldig"
4319038 Løste et problem der avsenderen ikke fikk alternativet for "Identitetsbekreftelse for ekstern mottaker" ved sending ved hjelp av arbeidsflyten Send samlet.
4319798 Løste et problem som kunne føre til at valg av en valgknapp førte til at markøren hoppet til et annet felt.
4320154 Løste et problem som kunne hindre at en bibliotekmal ble lagret i en ny grupperelasjon.
4323013 Løste et problem der åpning av et webskjema på Behandle-siden ville utløse en feil: "Dokumentet er ikke tilgjengelig ennå eller vil ikke ha noen sider å vise".
4323554 Løste et problem der tidsdatostemplene for oppdatering av administratorrettigheter kunne gi to poster med samme tidsverdier.
4323609 Løste et problem der opplasting av en signert avtale på Behandle-siden ikke ville utløse AGREEMENT_WORKFLOW_COMPLETED-webhooken.
4325142 Løste et problem der tilpassede e-postmaler ikke ville gjenspeile riktig navnverdi for en deltaker hvis de kansellerte avtalen.
4326747 Løste et problem som kunne føre til at Send samlet-siden ikke fullførte lasteprosessen, og utelot opplastings- og sendingshandlingene.
4326855 Løste et problem som kunne forhindre mottakere i å nekte godkjenning av en avtale.
4327000 Rettet et problem som kunne føre til at Smart-Id-legitimasjon mislyktes, der feilen indikerte at ingen algoritmer ble funnet.