Issue key
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:
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:
"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.
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
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.
Alternativer for forbedret e-postsikkerhet
To nye alternativer er tilgjengelige for å forbedre e-postsikkerheten. Begge innstillingene er aktivert som standard:
- Inkluder en kobling i e-postmeldinger for visning av den signerte avtalen
- Inkluder et bilde av den første avtalesiden i e-postmeldinger
- Aktivert som standard
- Når denne funksjonen er aktivert, vises et bilde av den første siden av avtalen i enkelte e-postutsendelser
v6 REST API-oppdateringer
STANDARDOVERSKRIFTER I HVER V6 REST API-FORESPØRSEL
Som standard har hver v6 REST API-forespørsel nå standardhoder:
/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
Bare v6 REST API påvirkes.
Alle v6 REST API-kall som ikke inkluderer disse overskriftene vil eksplisitt dokumentere dette fraværet.
- GET /libraryDocuments - Utvidet til å inkludere det nye feltet ownerEmail
- GET /libraryDocuments/{libraryDocumentId} - Utvidet til å inkludere de nye feltene: ownerId, ownerEmail og ownerName
Nye felter i LibraryDocumentInfo-objektet:
Felter med oppdatert oppførsel:
web-SKJEMAER (/WIDGETS)
- POST /widgets - Bruk av en libraryDocumentId til å opprette et web-skjema støttes nå med en gyldig id
Statuskode lagt til:
- PUT /widgets - Bruk av en libraryDocumentId til å opprette et web-skjema støttes nå med en gyldig id
Statuskode lagt til:
- PUT /widgets/{widgetId} - Utvidet til å inkludere det nye feltet ownerId
Statuskode lagt til:
Endringer i brukeropplevelsen
- GET /widgets/{widgetId} - Utvidet til å inkludere de nye feltene: ownerId, ownerEmail, ownerName, og creatorName
Nye felter i WidgetInfo-objektet:
Felter med oppdatert oppførsel:
/MEGA SIGN
NYTT:
- GET /megaSigns/{megaSignId}/formFields - Henter skjemafeltdetaljene til en Mega Sign mal-avtale
Parametere:
Svarobjekt:
- PUT /megaSigns/{megaSignId}/formFields - Oppdaterer skjemafeltene til en Mega Sign-avtale
Parametere:
Svarobjekt:
OPPDATERT:
- POST /megaSigns - AUTHORING har blitt lagt til som en tilstandsVerdi for å støtte redigering av en Mega Sign-mal
Endret parameter:
- 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
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:
Adobe Sign-tjenestenivå og konto-ID eksponert i administratormeny
Administratorer kan nå finne sin konto-ID på siden Globale innstillinger:
Gruppe-ID kan finnes på siden Gruppeinnstillinger:
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
"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:
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.
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:
Påminnelse: Sosial autentisering er fjernet
Som annonsert i november, er autentiseringsmetoden som bruker sosial identitet fjernet fra listen over autentiseringsmetoder i Admin-menyen.
Påminnelse: Personlig Twitter-integrasjon er fjernet
Som kunngjort i desember er brukernes mulighet til å lage personlige godkjente tilkoblinger til Twitter fjernet.
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
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
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:
Ytterligere feilstatuskoder:
Ytterligere feilstatuskoder:
Nye felt i LibraryDocument objekt:
Nye felt i LibraryDocumentInfo-objektet:
Felt med oppdatert oppførsel:
Nye felt i WidgetInfo-objektet:
Felt med oppdatert oppførsel:
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
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.
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 er for øyeblikket bare tilgjengelig i NA1-, NA2- og NA4-miljøene.
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)
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 >
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:
Endringer i brukeropplevelsen
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.
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.
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
|
|
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.
- 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 oppdatert – Liquid 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.
- 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.
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:
- Godta Adobe Sign-vilkårene for bruk ved å velge Fortsette-knappen (etter at avtalen er åpnet).
- Fyll ut avtalefeltene etter behov.
- Aksepter kundeerklæringen og tilpasset ToU ved å velge Klikk for å signere-knappen.
- 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).
- 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.
- Kontoer med flere lisenser kan dele en avtale opptil ti ganger.
- Egendefinert firmanavn i telefongodkjenning er fjernet fra tjenesten – Den tilpassbare firmanavnverdien som kunne settes inn i telefongodkjenningsmetoden, er fjernet fra tjenesten som kunngjort i de tekniske spesifikasjonene fra juni.
- HIPAA-aktiverte kontoer kan nå få tilgang til kontrollene for bilder og koblinger i e-postadresser for mottakere på siden Globale/gruppeinnstillinger.
- 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 >
- 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 skjemafeltdata på Behandle-siden.
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.
- 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:
- Send-sideoppdateringer – Kunder med notar aktivert kan velge alternativet Krever notarialbekreftelse på mottakerposten, rett til høyre for godkjenningsmetoden:
Kunder som bruker den innebygde Send-side i sine programmer eller integreringer, vil også ha tilgang til notarfunksjonaliteten.
Når avtalen er konfigurert og avsenderen klikker på Neste, får avsenderen ytterligere konfigureringsalternativer for notarprosessen:
- 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 |
|
Rolle for alle deltakere i settet (underskriver, godkjenner og så videre) |
FileInfo-utvidelse
FileInfo-definisjonen må utvides for å indikere hvilke dokumenter som skal notarialbekreftes.
|
Parameternavn |
Type |
Standard |
Obligatorisk |
Beskrivelse |
|---|---|---|---|---|
|
dokument |
Document |
|
valgfritt |
Et dokument som er tilknyttet avtalen. |
|
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.
|
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 |
NotaryInfo
Et nytt valgritt notaryInfo-felt er lagt til i AgreementInfo-definisjonen for å inneholde NotaryInfo-objektet som angir flere alternativer knyttet til notarialbekreftelse.
|
Parameternavn |
Type |
Standard |
Obligatorisk |
Beskrivelse |
|---|---|---|---|---|
|
notaryType |
Enum |
Hvis bare notartjeneste på forespørsel fra Notarize er aktivert på kontoen, |
obligatorisk |
NOTARIZE_NOTARY – Notartjenesten besørger notar |
|
betaling |
Enum |
BY_SENDER |
valgfritt |
Gjelder bare hvis typen == NOTARIZE_NOTARY |
|
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>
|
|
||||||||||||||
Notarunderskriveren kan følge sekvensen nedenfor med API-kall for å fullføre e-signeringsfasen:
- GET /agreements/{agreementId}/members – for å hente notarunderskriverens deltaker-ID og deltakersett-ID
- POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens – for å be om signeringstoken for notarunderskriver med ACCEPT_BEFORE_NOTARIZATION-funksjonalitet
- POST /transientDocuments – for å laste opp dokument som ble gjennomgått
- 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. |