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å siden Administrer, samt fra bekreftelsessiden etter sending. Disse ekstra inngangspunktene gjør det enklere å gjenbruke avtaler på flere punkter i sendingslivssyklusen, og 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, og Opprett en kopi etableres som en standardfunksjon tilgjengelig for alle kvalifiserte brukere.

Tilgjengelige miljøer: Sandbox, Commercial, Government | Tilgjengelige tjenestenivåer: Acrobat Sign Solutions | Konfigurasjonens omfang: Konto og gruppe; aktivert som standard.

Gjennomgå den oppdaterte brukerdokumentasjonen >

Endringer i brukeropplevelsen

Visning av integrasjonsnøkkelens utløp – Utløpsdatoer vises nå i fanen Tilgangstokener
Under fanen Tilgangstokener, i menyen Personlige preferanser, kan du se utløpsdatoen for hver integrasjonsnøkkel. Dette gir brukere og administratorer bedre oversikt over nøklenes alder og tidspunkt for utskifting, slik at det blir enklere å overvåke eksisterende nøkler og unngå uventede avbrudd når en nøkkel når slutten av sin 10-årige gyldighetsperiode.

Tilgjengelige miljøer: Sandbox, kommersiell, statlig | Tilgjengelige tjenestenivåer:Acrobat Sign Solutions | Konfigurasjonsomfang: API

REST API/Webhook-oppdateringer

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

OEM 2.0 personlig tilpasset e-postvisning – Klarere avsender- og mottakeridentitet på tvers av innebygde opplevelser, og korrekt e-postlevering.
For OEM 2.0-partnere som bruker innebygde arbeidsflyter, kan Acrobat Sign nå vise en brukers personlig tilpassede e-postadresse i stedet for den partnerregistrerte e-postadressen for sentrale brukergrensesnittflater og varsler. Avtaler, køer som for eksempel «Venter på deg» og e-poster om «gjennomgang og signering» reflekterer konsekvent den personlig tilpassede identiteten, samtidig som den registrerte e-postadressen 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 | Konfigurasjonens omfang: API - OEM 2.0-partnere; kun på forespørsel

Webhook-varsel for SMS-leveringsfeil – Sanntidsvisning av 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 nesten i sanntid og automatisk utløse oppfølgingshandlinger som korrigering av telefonnumre, nytt forsøk på levering eller åpning av supportsaker, noe som eliminerer blindsoner og reduserer forsinkelser i mobilbaserte signeringsarbeidsflyter.

Tilgjengelige miljøer: Sandbox, Commercial, Government | Tilgjengelige tjenestenivåer: Acrobat Sign Solutions | Konfigurasjonsomfang: API

Webhook-payloads – Lagt til betinget deltaker extendedStatus-felt for dynamiske deltakelsesoppdateringer, noe som forbedrer visningen 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 samtidig som 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 | Konfigurasjonsomfang: API

Løste problemer

Problem	Beskrivelse
4543515	Sammendrag: En webhook e-postretur-hendelse 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 returhendelsen «signert på vegne av ...» til den gyldige underskriveren i stedet for deltakeren som e-posten faktisk returneres for.
4543515	Løsning: Logikken for hendelsestilskrivning ble korrigert slik at e-postreturer kun knyttes til deltakeren som e-posten faktisk returneres for. En returhendelse genereres ikke lenger for en gyldig underskriver som allerede har fullført signeringen, og webhook-varsler reflekterer nå riktig deltaker og e-postadresse.
4544548	Sammendrag: Integrasjonsnøkler opprettet gjennom webgrensesnittet kan utløpe etter 10 år, selv om opprettelsessiden sier at nøkkelen gir «permanent tilgang». Når en nøkkel når sin levetid på 10 år, begynner API-kall å returnere en utløpt-token-feil, noe som kan ødelegge eksisterende integrasjoner uventet.
4544548	Løsning: Teksten i brukergrensesnittet 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 frem til utløpsdatoen eller til den blir manuelt tilbakekalt, noe som gir tydeligere oversikt over standardlevetiden på 10 år.
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 å fullføres i løpet av minutter. I løpet av forsinkelsesvinduet kan webhook-leveringstjenesten gjentatte ganger motta DOCUMENT_NOT_AVAILABLE-svar når den prøver å hente avtaledokumenter, og webhook-hendelsen leveres da ikke før tjenesten slutter å prøve på nytt eller dokumentene blir tilgjengelige.
4546301	Løsning: Håndteringen av dokumenttilgjengelighet ble korrigert slik at store avtaler pålitelig går over til en status der dokumenter kan hentes uten flere 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 redigeringstilstanden gjennom API-et og deretter redigeres fra Administrer-opplevelsen. I dette scenarioet kan brukergrensesnittet vise privatmeldingsverdien som «Ingen» eller tom selv om avtaledataene inkluderer riktig privatmeldingsverdi. Denne oppførselen vises i delte kontoscenarier der en bruker bytter til en annen brukers konto for å redigere utkastet, og det kan påvirke bare spesifikke mottakere mens andre vises riktig.
4547823	Løsning: En sjekk ble lagt til for å hente den aktive delingskonteksten og returnere den private meldingen for autoriserte delte brukere. Som et resultat vises verdien for privat melding nå riktig når du viser eller sender et API-opprettet utkast fra redigeringsflyten.
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 Administrer-brukergrensesnittet og i administrative visninger, noe som får det til å se 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: Oppførselen for oppdatering av endringsdato ble tilpasset på tvers av den nye malopplevelsen og de relaterte API-operasjonene. Kodebanen som lagrer endringer av malfelt, oppdaterer nå også malens endringsdato slik at den gjenspeiler den faktiske tiden for den siste endringen.
4548564	Sammendrag: Signaturer og skjemafelt kan virke usynlige i den signerte PDF-en når de plasseres over eksisterende stempelannotasjoner i kildedokumentet. I berørte maler overlapper stempelannotasjonene eller skjuler de interaktive feltene under behandling, noe som fører til at fullførte signaturer og andre felt skjules i det endelige signerte dokumentet.
4548564	Løsning: Stempelannotasjonshåndtering ble oppdatert for å trygt behandle og flate ut eksisterende stempelannotasjoner slik at de ikke lenger skjuler skjemafelt eller signaturer. Felt plassert over stemplede områder forblir nå synlige gjennom signering og i den fullstendig utførte PDF-en.
4549103	Sammendrag: En e-postavvisningshendelse kan logges igjen for en tidligere feil mottaker etter at avsenderen erstatter den mottakeren med en gyldig e-postadresse. I noen tilfeller kan revisjonssporet vise en andre returhendelse for den gamle e-posten og avtalestatusen indikere «e-post returnert», selv om den nye mottakeren mottar, viser eller signerer avtalen. Denne oppførselen 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 underskriveren er oppdatert for å forhindre sending av ytterligere e-postvarsler til en erstattet mottaker hvis e-post allerede har blitt returnert. Systemet sjekker nå for tidligere avvisningshistorikk før det sender erstatningsrelaterte varsler, og sikrer at ingen nye avvisningshendelser genereres for den gamle e-postadressen etter erstatning.
4549306	Sammendrag: Brukere med e-postadresser som inneholder visse spesialtegn (for eksempel apostrof), kan være ute av stand til å logge inn fra de generiske offentlige påloggingssidene adobesign.com eller echosign.com. 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 hindrer berørte brukere i å fullføre autentisering og blokkerer integrasjoner som er avhengige av det offentlige påloggingsendepunktet.
4549306	Løsning: Logikken for løsning av pålogging-shard ble korrigert for å håndtere og dekode e-postadresser med spesialtegn på riktig måte før URL-en for inter-shard-omdirigering konstrueres. Brukere med berørte e-postformater blir nå korrekt omdirigert til sin 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-en når visse dokumentbehandlingsfunksjoner er aktivert og kilde-PDF-en inneholder ugyldige sidebokskoordinater (for eksempel feil CropBox- eller MediaBox-verdier). I dette scenarioet kan felt som avhenger av sidekoordinater, gjengis utenfor det synlige sideområdet, slik at fullførte signaturer ser ut som de mangler, selv om signeringen er fullført på riktig måte.
4549331	Løsning: Håndteringen av PDF-sideboks ble korrigert for trygt å normalisere ugyldige CropBox- og MediaBox-verdier under dokumentbehandlingen. Som et resultat justeres signatur- og skjemafeltplassering nå til det synlige sideområdet, og signerte PDF-er viser signaturer som forventet.
4550367	Sammendrag: Opprettelse av et webskjema kan mislykkes med en generisk «serverfeil» etter valg av Forhåndsvisning og Legg til felt når avsendergruppens standard signeringsautentisering er satt til Telefon og kontoen ikke har tilgjengelig telefonautentiseringskvote, selv om webskjemaets signeringsautentisering 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 webskjemaer for alle dokumenter.
4550367	Løsning: Webskjemaopprettelse vurderer nå kvote kun for autentiseringsmetoden som faktisk er konfigurert for webskjemaets underskriver, og bruker ikke lenger sjekk av telefonautentiseringskvote basert utelukkende på gruppens standard autentiseringsinnstilling. Dette forhindrer falske feil for oppbrukt kvote og gjør det mulig å opprette webskjemaer som normalt.
4551011	Sammendrag: Når en avsender laster opp visse skannede PDF-er, legger til signaturfelt og sender avtalen, kan det hende at den signerte PDF-en ikke viser synlige signaturer etter at signeringen er fullført. Dette kan forekomme når den opplastede PDF-en inneholder ugyldige sidegrense-metadata (MediaBox- og CropBox-koordinater fremstår reversert), noe som kan føre til at signatur- og andre feltvisningslag gjengis utenfor det synlige sideområdet.
4551011	Løsning: Håndteringen av PDF-sidegrenser er oppdatert for korrekt behandling av PDF-er med ugyldige eller reverserte MediaBox- og CropBox-koordinatverdier, slik at signatur- og skjemafeltinnhold gjengis innenfor det synlige sideområdet og forblir synlig i den endelige signerte PDF-en.
4551427	Sammendrag: Noen mottakere som allerede har aktive, korrekt klargjorte kontoer, mottar avtaler som «pseudobruker»-mottakere i stedet, slik at avtalen ikke vises i deres normale Administrer-visning. Dette skjer når mottakernes e-postadresser inkluderer ledende eller etterfølgende mellomrom, noe som hindrer systemet fra å matche e-posten med den eksisterende brukeren og gjør at en pseudobruker-oppføring opprettes.
4551427	Løsning: E-postparsing og brukeroppslag er oppdatert for å normalisere mottakernes e-postadresser (trimme ledende og etterfølgende mellomrom) før de matches med eksisterende brukere. Som et resultat rettes avtaler adressert til eksisterende brukere til den registrerte kontoen i stedet for å opprette en pseudobruker-mottaker, selv om e-posten ble skrevet inn med mellomrom (i API-payloads og arbeidsflyt-mottakerlister).
4553198	Sammendrag: Når en avtale inkluderer minst én mottaker konfigurert for SMS-levering og minst én mottaker konfigurert for kun e-postlevering, medfører ikke kansellering av avtalen gjennom API-et sending av et SMS-kanselleringsvarsel til SMS-mottakeren. Avtalen blir vellykket kansellert, og e-postvarsler blir levert, 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-en. Selv om feltene visuelt fremstår som avkrysningsbokser, 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 tilordning av det forventede valget.
4554463	Løsning: Logikken for håndtering av skjemafelt ble korrigert slik at klonede alternativknapper lagrer og forplanter den valgte eksportverdien i stedet for en intern indeksverdi. Dette sikrer at alle klonede forekomster av det samme alternativknappfeltet gjenspeiler det riktige valget i den signerte PDF-en.
4554593	Sammendrag: Noen partnerintegrasjoner som bruker de eldre OAuth-endepunktene til å 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 via partnerapplikasjoner, selv for integrasjoner som fungerte tidligere.
4554593	Løsning: Autentiseringstjenesten ble korrigert slik at partnerapper som er konfigurert til å bruke den eldre OAuth-flyten kan oppdatere tokener igjen, i stedet for å bli feilaktig tvunget over på OAuth v2-endepunktene.
4554614	Sammendrag: Når en underskriver 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 Klikk for å signere en fem sekunders omdirigering til den klassiske signeringsopplevelsen. Omdirigeringsmeldingen advarer om at signaturer og initialer som er lagt inn i moderne signering vil bli slettet, noe som tvinger signereren til å legge dem inn på nytt og faktisk signere to ganger.
4554614	Løsning: Flyten for oppdatering av signeringstokenet ble korrigert, slik at det nyutstedte signeringstokenet beholder detaljene for signeringsautentisering når underskriveren aksepterer bruksvilkårene før signering. Dette forhindrer at autentiseringen feiler i det siste signeringstrinnet og fjerner den tvungne overføringen fra moderne til klassisk signering.
4555656	Sammendrag: Under spesifikke tidsforhold kan en avtalestatusovergang se ut til å lykkes, men endrer faktisk ikke avtalestatusen. Når en webhook-varsling mottas før backend-behandlingen er fullført, kan påfølgende API-kall bruke utdaterte avtalestatusdata. I dette tidsvinduet returnerer visse statusovergangsmetoder HTTP 200 OK selv om avtalen ikke er i en gyldig status for den forespurte overgangen. Som et resultat kan automatiseringsarbeidsflyter anta at overgangen lyktes mens avtalen forblir i den opprinnelige statusen.
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 status, returnerer API-et nå et tydelig feilsvar i stedet for suksess uten svar. 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 status uten synlighet.