Adobe Acrobat Sign planlegger å rulle ut minst tre utgivelser hvert år, kategorisert som større or mindre utgivelser. Andre små oppdateringer kan introduseres etter behov for å løse system- eller kundeproblemer.

Større utgivelser inneholder betydelige oppdateringer, nye funksjoner og flere forbedringer.
Mindre lanseringer fokuserer på små forbedringer og justeringer av brukeropplevelsen. Disse finner sted mellom de større utgivelsene, typisk en til to ganger pr. syklus.

For å forhindre avbrudd, deaktiveres nye funksjoner som standard og må aktiveres manuelt av en konto- eller gruppeadministrator.

For Helse- og livsvitenskap-kunder som krever samsvarsvalidering, samarbeider Acrobat Sign med en tredjepartsleverandør om å levere en valideringspakke for alle store utgivelser som inneholder funksjoner for å minimere risikofaktoren.

Merk:

Denne siden med forhåndsutgivelsesnotater oppdateres jevnlig etter hvert som ny informasjon blir tilgjengelig, innholdet er derfor relativt dynamisk.

Selv om siden er lokalisert tar prosessen tid. Det kan føre til at lokaliserte versjoner avviker litt fra den autoritative amerikanske engelske versjonen.

For den mest nøyaktige og oppdaterte informasjonen, anbefaler vi å referere til den amerikanske siden på engelsk.

Forhåndsutgivelsesplanen og notatene vises nedenfor.

Adobe Acrobat Sign følger en strukturert tidsplan for publisering av utgivelsesmerknader og dokumentasjonsoppdateringer:

8 uker før produksjonsutgivelse

Forhåndsutgivelsessiden publiserer et sammendrag av forventede funksjoner og oppdateringer, vanligvis fire uker før Sandbox-lanseringen.
Alle funksjonsendringer som er lagt til eller fjernet etter dette punktet, er angitt i Errata-delen.
Løste problemer inkluderes ikke på dette stadiet.

4 uker før produksjonsutgivelse (Sandbox-lansering)

Forhåndsutgivelsessiden oppdateres med detaljert dokumentasjon om nye og oppdaterte funksjoner.
Lenker til støttedokumentasjon for forhåndsutgivelser (kun tilgjengelig på engelsk) legges til etter behov.
Den første Løste problemer-delen publiseres, med pågående oppdateringer de neste fire ukene.

Lanseringsdag

De offisielle utgivelsesnotatene er oppdatert med endelige funksjonsdetaljer og lenker til dokumentasjon om produksjonsstøtte.
Forhåndsutgivelsessiden oppdateres for å markere neste utgivelsessyklus.
Dokumentasjon publiseres etter utgivelsesverifisering i det publiserte systemet, vanligvis etter kl. 17 (PT), selv om komplekse oppdateringer kan ta lengre tid.
Den endelige listen over løste problemer legges til de amerikansk engelske versjonsnotatene, med lokaliserte versjoner oppdatert senere.

Utgivelse av Government Cloud

Government Cloud-miljøet oppdateres normalt mellom to dager og flere uker etter produksjonsutgivelsen, siden noen funksjoner kan kreve ytterligere evaluering før utrullering.

Merk:

Sandbox-dokumentasjonen er utformet for produksjonsmiljøet. Lenker som finnes i nettadressene for produksjon av forhåndsutgivelsesinnhold. Det betyr at disse lenkene kan føre til eldre eksisterende dokumentasjon eller 404-resultater hvis målsiden er ny og ikke er publisert ennå (for eksempel når lenken peker til en ny funksjon i samme utgivelse).

De nye sidene publiseres når utgivelsen publiseres, og lenkene føres korrekt til produksjonsnettadressene.

Sandbox-tilgjengelighet

Kunder som har tilgang til Acrobat Sign Sandbox-miljøet får normalt tilgang til den nye utgivelsesfunksjonaliteten fire uker før lansering.

Sandbox-miljøet består av alle produksjonskvalitetssikringsprosedyrer på samme kvalitetsnivå som det vanlige produksjonsmiljøet.
Adobe arbeider for å ha 99,9 % tilgjengelighet i Sandbox-miljøet, men kunder bør være oppmerksom på at Adobes enhetlige SLA ikke formelt dekker Sandbox.
Sandbox-miljøet bruker samme statusside og avbruddsprosedyrer som det vanlige produksjonsmiljøet.

Utgivelser

Varsel:

Denne artikkelen inneholder forhåndsutgivelsesinformasjon. Utgivelsesdatoer, funksjoner og annen informasjon kan endres uten varsel.

17. mars 2026 (mindre utgivelse) v17.0.1

Adobe Acrobat Sign utgivelse v17.0.1

Sandbox-distribusjon: 17. februar 2026

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.
Denne funksjonen vil være tilgjengelig i Sandbox-miljøet 20. februar 2026.

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 | Konfigurasjonens omfang: Konto og gruppe; aktivert som standard.

Se gjennom den oppdaterte dokumentasjonen for brukerhandlinger >

REST API/Webhook-oppdateringer

Oppdateringene nedenfor er presentert i forhåndsutgivelsesnotatene for utleveringsformål. Full dokumentasjon for API- og Webhook-oppdateringer finnes i Utviklerdokumentasjon for Acrobat Sign når versjonsoppdateringen leveres til produksjonsserverne.

OEM 2.0 personlig e-postvisning – Klarere avsender- og mottakeridentitet på tvers av innebygde opplevelser, og korrekt e-postlevering.
For OEM 2.0-partnere som bruker innebygde arbeidsflyter, viser acrobat sign nå en brukers personlige e-postadresse i stedet for den partnerregistrerte e-postadressen 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 | Konfigurasjonens omfang: API - kun OEM 2.0-partnere

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 | Konfigurasjonens omfang: API

Uregelmessigheter ved utgivelse

Det er ingen elementer som har gått ut fra denne utgivelsen på dette tidspunktet.

Løste problemer

Problem	Beskrivelse
4543515	Sammendrag: En webhook-hendelse for e-post som spretter tilbake 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..."-hendelsen som spretter tilbake til den gyldige underskriveren i stedet for deltakeren hvis e-post faktisk spretter tilbake.
4543515	Løsning: Logikken for hendelses-tilskrivning ble korrigert slik at hendelser for e-post som spretter tilbake kun knyttes til deltakeren hvis e-post faktisk spretter tilbake. En hendelse som spretter tilbake 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 web-brukergrensesnittet 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: Meldingen 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 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 å fullføres 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 dokumenthenting som prøver på nytt 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 verdien for privat melding som "Ingen" eller tom selv om avtaledataene inkluderer riktig verdi for privat melding. Denne oppførselen vises i delte konto-scenarioer 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 delekonteksten og returnere den private meldingen for autoriserte delte brukere. Som et resultat vises verdien for privat melding nå korrekt når du viser eller sender et API-opprettet utkast fra Authoring-flyten.
4548274	Sammendrag: Endringsdatoen for bibliotek-maler 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 Manage-brukergrensesnittet og i administrative visninger, noe som får det til å se ut som om malen ikke ble nylig endret. 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 endret dato ble tilpasset på tvers av den nye malopplevelsen og de relaterte API-operasjonene. Kodebanen som lagrer endringer i malfelt 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 behandler, noe som fører til at fullførte signaturer og andre felt blir skjult i det endelige signerte dokumentet.
4548564	Løsning: Håndtering av Stempel-merknader ble oppdatert for å trygt behandler 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-retursending kan logges på nytt for en tidligere feil mottaker etter at avsenderen erstatter den mottakeren med en gyldig e-postadresse. I noen tilfeller kan revisjonssporet vise en andre retursending for den gamle e-posten, og avtalestatusen kan gjenspeile "e-post returnert" selv om den nye mottakeren vellykket 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: Arbeidsflyt for å erstatte signerer ble oppdatert for å forhindre sending av ytterligere varslings-e-poster til en erstattet mottaker hvis e-post allerede har blitt 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 en 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 inn 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 den konstruerer 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 får fullførte signaturer til å virke manglende selv om signeringen fullføres vellykket.
4549331	Løsning: pdf-sidebokshåndtering ble korrigert for å trygt normalisere ugyldige CropBox- og MediaBox-verdier under dokumentbehandling. Som et resultat tilpasser signatur- og skjemafeltplassering seg nå til det synlige sideområdet, og signerte pdf-filer viser signaturer som forventet.
4550367	Sammendrag: Oppretting 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: web-skjemaoppretting evaluerer nå kvote kun for autentiseringsmetoden som faktisk er konfigurert for web-skjemasignereren, og den bruker ikke lenger telefonautentiseringskvotesjekker basert utelukkende på gruppestandardautentiseringsinnstillingen. Dette forhindrer falske kvoteutmattingsfeil og lar web-skjemaer 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 deres normale Administrer-visning. 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-postanalyse 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 visuelt ut 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 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 tilgangstokens 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 tokens 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 signerautentisering 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 signerautentiseringsdetaljene. 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 avtaletilstandsovergang se ut til å lykkes, men endrer faktisk ikke avtaletilstanden. Når et webhook-varsel mottas før backend-behandling fullføres, kan påfølgende API-kall bruke utdaterte 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 brukes. 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.