Ikke alle funksjoner/endringer er garantert aktivert på utgivelsesdatoen. Referer alltid til den amerikanske engelske versjonen av siden som den mest oppdaterte og nøyaktige versjonen.

Adobe Acrobat Sign utgivelse v17.0.1

Produksjonsdistribusjon: 17. mars 2026

GovCloud-distribusjon: 19. mars 2026

Forbedret funksjonalitet

Opprett en kopi – Utvidede tilgangspunkter, raskere gjenbruk av avtaler.
Opprett en kopi er nå tilgjengelig direkte fra filtrene Pågår og Venter på deg på Administrer-siden, samt fra bekreftelsessiden etter sending. Disse ekstra inngangspunktene gjør det enklere å gjenbruke avtaler på flere punkter i sendingslivssyklusen, noe som reduserer behovet for å starte på nytt fra bunnen av.
Merk: Med denne utgivelsen vil de administrative kontrollene for å deaktivere denne funksjonen bli fjernet fra administratormenyen, noe som etablerer Opprett en kopi som en standardfunksjon tilgjengelig for alle kvalifiserte brukere.

Tilgjengelige miljøer: Sandbox, Commercial, Government | Tilgjengelige tjenestenivåer: acrobat sign Solutions | Konfigurasjonssområde: Konto og gruppe; Aktivert som standard.

Se gjennom den oppdaterte dokumentasjonen for brukerhandlinger >

REST API/Webhook-oppdateringer

API- og webhook-oppdateringer for denne utgivelsen finnes i API-dokumentasjon for Acrobat Sign.

OEM 2.0 personlig e-postvisning – Klarere avsender- og mottakeridentitet på tvers av innebygde opplevelser, og korrekt e-postlevering.
For OEM 2.0 innebygde arbeidsflyter viser Acrobat Sign nå en brukers personlige e-postadresse i stedet for partnerregistrert e-post på tvers av viktige brukergrensesnittflater og varsler. Avtaler, køer som "Venter på deg" og "Gjennomgå og signer"-e-poster gjenspeiler konsekvent den personlige identiteten samtidig som den registrerte e-posten bevares internt for autentisering og rettigheter. Dette forbedrer klarheten for avsendere og underskrivere og forhindrer at e-poster sendes til ikke-leverbare registrerte adresser.

Tilgjengelige miljøer: Sandbox, Commercial | Tilgjengelige tjenestenivåer: Acrobat Sign Solutions | Konfigurasjonssområde: API

Webhook-varsel for SMS-leveringsfeil – Sanntidssynlighet inn i mislykkede SMS-sendinger, automatisert utbedring og paritet med e-postreturer.
Acrobat Sign sender nå ut en ny webhook-hendelse, AGREEMENT_PHONE_BOUNCED, når en avtale sendt via SMS ikke kan leveres på grunn av problemer som ugyldige telefonnumre, operatøravvisning eller blokkerte linjer. Dette gjør det mulig for kunder å oppdage SMS-leveringsfeil i nesten sanntid og automatisk utløse oppfølgingshandlinger som å korrigere telefonnumre, prøve levering på nytt eller åpne støttesaker, noe som eliminerer blinde flekker og reduserer forsinkelser i mobilfokuserte signeringsarbeidsflyter.

Tilgjengelige miljøer: Sandbox, Commercial, Government | Tilgjengelige tjenestenivåer: acrobat sign Solutions | Konfigurasjonens omfang: API

Webhook-nyttelaster – Lagt til betinget deltaker extendedStatus-felt for dynamiske deltakelsesopdateringer, som forbedrer synligheten av deltakerstatus.
Webhook-varsler inkluderer nå et extendedStatus-felt i hvert deltakerobjekt (memberInfos[]) når avsenderen endrer en pågående avtale ved hjelp av dynamisk deltakelse. Dette feltet gir ytterligere detaljer om deltakerens livssyklus mens det eksisterende statusfeltet forblir uendret for bakoverkompatibilitet.

        {
          &quot;participantSets&quot;: [
            {
              &quot;id&quot;: &quot;&quot;,
              &quot;memberInfos&quot;: [
                {
                  &quot;company&quot;: &quot;TestCo&quot;,
                  &quot;email&quot;: &quot;signer2@someDomain.dom&quot;,
                  &quot;id&quot;: &quot;CBJCHBCAABAAJiZV9cH&quot;,
                  &quot;name&quot;: &quot;Signer Two&quot;,
                  &quot;status&quot;: &quot;ACTIVE&quot;,
                  &quot;extendedStatus&quot;: &quot;REMOVED&quot;
                }
              ],
              &quot;order&quot;: ,
              &quot;role&quot;: &quot;&quot;,
              &quot;status&quot;: &quot;&quot;
            }
          ]
        }

status verdier (uendret): ACTIVE, REPLACED.
extendedStatus verdier: ACTIVE, REPLACED, REMOVED, COMPLETED.

Tilgjengelige miljøer: Sandbox, Commercial, Government | Tilgjengelige tjenestenivåer: acrobat sign Solutions | Konfigurasjonssområde: API

Løste problemer

Problem	Beskrivelse
4543515	Sammendrag: En webhook-e-postsprettshendelse kan bli feilaktig generert for en gyldig underskriver etter at underskriveren har signert og avtalen går videre til neste trinn. Dette kan skje når en delegat i samme signeringsgruppe har en ugyldig e-postadresse og avsenderen erstatter den opprinnelige delegatoren. I disse tilfellene kan systemet feilaktig tilskrive «signert på vegne av...»-sprettshendelsen til den gyldige underskriveren i stedet for deltakeren hvis e-post faktisk spretter.
4543515	Løsning: Logikken for hendelsetilskriving ble korrigert slik at e-postsprettshendelser kun knyttes til deltakeren hvis e-post faktisk spretter. En sprettshendelse genereres ikke lenger for en gyldig underskriver som allerede har fullført signeringen, og webhook-varsler gjenspeiler nå riktig deltaker og e-postadresse.
4544548	Sammendrag: Integrasjonsnøkler opprettet gjennom web-grensesnittet kan utløpe etter 10 år, selv om opprettelsessiden sier at nøkkelen gir «permanent tilgang.» Når en nøkkel når sin 10-års levetid, begynner API-kall å returnere en utløpt token-feil, noe som kan ødelegge eksisterende integrasjoner uventet.
4544548	Løsning: Brukergrensesnittmeldingen ble oppdatert for å fjerne ordlyden «permanent tilgang» og tydelig vise utløpsdatoen for integrasjonsnøkler. Den oppdaterte teksten sier nå at nøkkelen beholder tilgang til utløpsdatoen eller til den manuelt tilbakekalles, noe som gir gjennomsiktighet om standard 10-års levetid.
4546301	Sammendrag: Levering av webhook-hendelser kan bli forsinket med opptil flere timer for avtaler med svært store dokumenter, selv når avtaleoppretting fullføres og tidlige behandlingstrinn ser ut til å avsluttes innen minutter. I løpet av forsinkelsesvinduet kan webhook-leveringstjenesten gjentatte ganger motta DOCUMENT_NOT_AVAILABLE-svar når den forsøker å hente avtaledokumenter, og webhook-hendelsen kan ikke leveres før tjenesten slutter å prøve på nytt eller dokumentene blir tilgjengelige.
4546301	Løsning: Håndtering av dokumenttilgjengelighet ble korrigert slik at store avtaler pålitelig går over til en tilstand der dokumenter kan hentes uten utvidede DOCUMENT_NOT_AVAILABLE-svar. Som et resultat leveres webhook-hendelser uten flertimers forsinkelser forårsaket av dokumenthentingsforsøk mot utilgjengelige dokumenter.
4547823	Sammendrag: En mottakers private melding vises kanskje ikke for noen underskrivere når en avtale opprettes i Authoring-tilstanden gjennom API-et og deretter redigeres fra Manage-opplevelsen. I dette scenariet kan brukergrensesnittet vise Private Message-verdien som «None» eller tom selv om avtaledataene inkluderer riktig privat meldingsverdi. Denne oppførselen vises i delte kontoscenarier der en bruker bytter til en annen brukers konto for å redigere utkastet, og det kan påvirke kun spesifikke mottakere mens andre vises korrekt.
4547823	Løsning: En sjekk ble lagt til for å hente den hoved delingskonteksten og returnere den private meldingen for autoriserte delte brukere. Som et resultat vises Private Message-verdien nå korrekt når du viser eller sender et API-opprettet utkast fra Authoring-flyten.
4548274	Sammendrag: Endringsdatoen for biblioteksmaler oppdateres kanskje ikke etter at en mal er redigert og lagret i den nye malopplevelsen. Brukere kan se nylig tillagte eller oppdaterte felt på malen, men endringsdatoen forblir uendret i administrasjonsgrensesnittet og i administrative visninger, noe som gjør at det ser ut som om malen ikke ble endret nylig. Dette skjer fordi den nye opplevelsen oppdaterer skjemafelt gjennom en bane som ikke også oppdaterer malens endrede tidsstempel.
4548274	Løsning: Oppdateringsatferden for endringsdato ble tilpasset på tvers av den nye malopplevelsen og de relaterte API-operasjonene. Kodebanen som lagrer malendringer oppdaterer nå også malens endringsdato slik at den gjenspeiler det faktiske tidspunktet for den siste endringen.
4548564	Sammendrag: Signaturer og skjemafelt kan virke usynlige i den signerte pdf-filen når de plasseres over eksisterende Stempel-merknader i kildedokumentet. I berørte maler overlapper Stempel-merknadene eller skjuler de interaktive feltene under behandling, noe som fører til at fullførte signaturer og andre felt blir skjult i det endelige signerte dokumentet.
4548564	Løsning: Håndteringen av Stempel-merknader ble oppdatert for å trygt behandle og flate ut eksisterende Stempel-merknader slik at de ikke lenger skjuler skjemafelt eller signaturer. Felt som er plassert over stemplede områder forblir nå synlige gjennom signeringen og i den fullstendig utførte pdf-filen.
4549103	Sammendrag: En e-post-returhendelse kan logges på nytt for en tidligere feil mottaker etter at avsenderen erstatter denne mottakeren med en gyldig e-postadresse. I noen tilfeller kan revisjonsloggen vise en andre returhendelse for den gamle e-posten, og avtalestatus kan gjenspeile "e-post returnert" selv om den nye mottakeren vellykket mottar, viser eller signerer avtalen. Denne atferden kan få det til å se ut som om avtalen fortsatt retter seg mot både den gamle og den nye e-postadressen.
4549103	Løsning: Arbeidsflyten for å erstatte signerer ble oppdatert for å forhindre sending av ytterligere varslings-e-poster til en erstattet mottaker hvis e-post allerede har returnert. Systemet sjekker nå for tidligere returhistorikk før det sender erstatningsrelaterte varsler, og sikrer at ingen nye returhendelser genereres for den gamle e-postadressen etter erstatning.
4549306	Sammendrag: Brukere hvis e-postadresser inneholder visse spesialtegn (for eksempel apostrof) kan være ute av stand til å logge inn fra de generiske adobesign.com eller echosign.com offentlige påloggingssidene. Etter å ha skrevet inn e-postadressen og klikket i passordfeltet, kan siden laste på nytt og tømme e-postfeltet i stedet for å omdirigere brukeren til riktig shard eller SSO-påloggingsside. Dette forhindrer berørte brukere fra å fullføre autentisering og blokkerer integrasjoner som er avhengige av det offentlige påloggingsendepunktet.
4549306	Løsning: Påloggings-shard-oppløsningslogikken ble korrigert for å riktig håndtere og dekode e-postadresser som inneholder spesialtegn før konstruksjon av inter-shard-omdirigeringsadressen. Brukere med berørte e-postformater blir nå riktig omdirigert til deres utpekte shard og SSO-påloggingsside uten at e-postfeltet blir tømt.
4549331	Sammendrag: Signaturer og andre skjemafelt kan virke manglende eller usynlige i den signerte pdf-filen når visse dokumentbehandlingsfunksjoner er aktivert og kilde-pdf-filen inneholder ugyldige sidebokskoordinater (for eksempel feil CropBox- eller MediaBox-verdier). I dette scenariet kan felt som er avhengige av sidekoordinater gjengi utenfor det synlige sideområdet, noe som gjør at fullførte signaturer virker manglende selv om signeringen fullføres vellykket.
4549331	Løsning: Håndteringen av pdf-sidebokser ble korrigert for å trygt normalisere ugyldige CropBox- og MediaBox-verdier under dokumentbehandling. Som et resultat tilpasses signatur- og skjemafeltplassering nå til det synlige sideområdet, og signerte pdf-filer viser signaturer som forventet.
4550367	Sammendrag: Opprettelse av et web-skjema kan mislykkes med en generisk "Serverfeil" etter å ha valgt forhåndsvisning og Legg til felt når avsenderens gruppestandardsignererautentisering er satt til telefon og kontoen ikke har tilgjengelig telefonautentiseringskvote, selv om web-skjemasignererautentiseringen er satt til en ikke-telefonmetode (for eksempel Adobe Sign). Som et resultat kan alle brukere i den berørte kontoen bli blokkert fra å opprette web-skjemaer på tvers av alle dokumenter.
4550367	Løsning: Opprettelse av web-skjema evaluerer nå kvote kun for autentiseringsmetoden som faktisk er konfigurert for web-skjemasignereren, og den anvender ikke lenger telefonautentiseringskvotesjekker basert utelukkende på gruppens standardautentiseringsinnstilling. Dette forhindrer falske kvoteuttømmingsfeil og gjør at nettskjemaer kan opprettes normalt.
4551011	Sammendrag: Når en avsender laster opp visse skannede pdf-filer, legger til signaturfelt og sender avtalen, kan den signerte pdf-filen vise ingen synlige signaturer etter at signeringen er fullført. Denne oppførselen kan oppstå når den opplastede pdf-filen inneholder ugyldige sidegrensemetadata (MediaBox- og CropBox-koordinater ser ut til å være reversert), noe som kan føre til at signatur- og andre feltutseendelag gjengis utenfor det synlige sideområdet.
4551011	Løsning: Håndtering av pdf-sidegrenser er oppdatert for å behandle pdf-filer med ugyldige eller reverserte MediaBox- og CropBox-koordinatverdier på riktig måte, slik at signatur- og skjemafeltutseendeinnhold gjengis innenfor det synlige sideområdet og forblir synlig i den endelige signerte pdf-filen.
4551427	Sammendrag: Noen mottakere som allerede har hoved, korrekt klargjorte kontoer mottar avtaler som «pseudo-bruker»-mottakere i stedet, slik at avtalen ikke vises i den normale Administrer-visningen. Dette skjer når mottakernes e-postadresser inkluderer innledende eller etterfølgende mellomrom, noe som hindrer systemet i å matche e-posten til den eksisterende brukeren og forårsaker at en pseudo-brukerpost opprettes.
4551427	Løsning: E-postparsing og brukeroppslag ble oppdatert for å normalisere mottakernes e-postadresser (fjerne innledende og etterfølgende mellomrom) før de matches mot eksisterende brukere. Som et resultat løses avtaler adressert til eksisterende brukere til den registrerte kontoen i stedet for å opprette en pseudo-brukermottaker, selv om e-posten ble skrevet inn med mellomrom (i API-nyttelaster og arbeidsflytmottakerlister).
4553198	Sammendrag: Når en avtale inkluderer minst én mottaker konfigurert for SMS-levering og minst én mottaker konfigurert for kun e-postlevering, sender ikke kansellering av avtalen gjennom API-et en SMS-kanselleringsvarsel til SMS-mottakeren. Avtalen kanselleres vellykket, og e-postvarsler leveres, men SMS-mottakere mottar ikke en kanselleringsmelding.
4553198	Løsning: Kanselleringsarbeidsflyten ble korrigert for å sikre at SMS-kanselleringsvarsler sendes til alle mottakere konfigurert for SMS-levering når en avtale kanselleres, uavhengig av andre mottakeres leveringsmetoder.
4554463	Sammendrag: Når avtaler inkluderer klonede radioknapper som deler samme feltnavn på tvers av kombinerte dokumenter, forblir bare én forekomst av det valgte alternativet valgt i den endelige signerte pdf-filen. Selv om feltene ser ut som avkrysningsbokser visuelt, er de implementert som radioknapper. Etter signering forplanter ikke den valgte verdien seg konsekvent på tvers av alle klonede forekomster, noe som forårsaker feil eller ufullstendig kartlegging av det forventede valget.
4554463	Løsning: Skjemafeltbehandlingslogikken ble korrigert slik at klonede radioknapper lagrer og forplanter den valgte eksportverdien i stedet for en intern indeksverdi. Dette sikrer at alle klonede forekomster av samme radioknappefeltet reflekterer det riktige valget i den signerte pdf-filen.
4554593	Sammendrag: Noen partnerintegrasjoner som bruker de eldre OAuth-endepunktene for å oppdatere tilgangstokener begynte å feile med HTTP 401-feil. Tjenesten avviste tokenoppdateringsforespørsler med en feil som indikerte at appen ikke har tillatelse til å bruke de eldre OAuth-endepunktene og må bruke OAuth v2-endepunktene i stedet. Dette blokkerte kunder fra å autentisere acrobat sign gjennom partnerapplikasjoner, selv for integrasjoner som tidligere fungerte.
4554593	Løsning: Autentiseringstjenesten ble korrigert slik at partnerapplikasjoner som er konfigurert til å bruke den eldre OAuth-flyten kan oppdatere tokener vellykket igjen, i stedet for å bli feilaktig tvunget over på OAuth v2-endepunktene.
4554614	Sammendrag: Når en signerer bruker den moderne eSign-opplevelsen på en avtale som krever signeringsautentisering og er konfigurert til å kreve aksept av bruksvilkår før signering, utløser klikking på Klikk for å signere en 5-sekunders omdirigering til den klassiske signeringsopplevelsen. Omdirigeringsmeldingen advarer om at signaturer og initialer som er skrevet inn i moderne signering vil bli slettet, noe som tvinger signereren til å skrive dem inn på nytt og effektivt signere to ganger.
4554614	Løsning: Signeringstokenoppdateringsflyten ble korrigert slik at når signereren aksepterer bruksvilkårene før signering, beholder det nyutstedte signeringstokenet signeringsautentiseringsdetaljene. Dette forhindrer at det endelige signeringstrinnet feiler autentisering og eliminerer den tvungne tilbakefallet fra moderne signering til den klassiske opplevelsen.
4555656	Sammendrag: Under spesifikke tidsforhold kan en avtalestatusovergang se ut til å lykkes, men endrer faktisk ikke avtalestatus. Når en webhook-varsling mottas før backend-behandling er fullført, kan påfølgende API-kall bruke foreldede avtalestatusdata. I dette vinduet returnerer visse tilstandsovergangsmetoder HTTP 200 OK selv om avtalen ikke er i en gyldig tilstand for den forespurte overgangen. Som et resultat kan automatiseringsarbeidsflyter anta at overgangen lyktes mens avtalen forblir i den opprinnelige tilstanden.
4555656	Løsning: Logikken for avtalestatusovergang ble oppdatert for å håndheve streng validering før en overgang anvendes. Hvis avtalen ikke er i en gyldig tilstand, returnerer API-et nå et tydelig feilsvar i stedet for å returnere suksess uten varsel. Dette sikrer at ugyldige overganger eksplisitt avvises, gjør det mulig for kallende systemer å prøve på nytt på riktig måte, og forhindrer at avtaler forblir i en utilsiktet tilstand uten synlighet.