Gjennomgå de tekniske merknadene som er oppført, og bokmerk de som er viktige for deg.
Siden for tekniske varsler oppdateres jevnlig med ny informasjon, noe som gjør innholdet svært dynamisk. Selv om lokaliserte versjoner er tilgjengelige, kan oversettelsesprosessen forårsake små forskjeller fra den autoritative amerikanske engelske versjonen. Se alltid først den amerikanske engelske siden for den for den mest nøyaktige og oppdaterte informasjonen.
[Neste utgivelse] Den neste Adobe Acrobat Sign–utgivelsen er planlagt til 8. september 2026, v17.2
Denne mindre oppdateringen løser kunderapporterte feil og bruker nødvendige optimaliserings- og sikkerhetsoppdateringer.
Sandbox-miljøet mottar disse oppdateringene fire uker før den planlagte utgivelsen. En oversikt over de løste problemer publiseres på det tidspunktet og oppdateres 14 dager før utgivelsen.
Funksjonsutgivelse: Adobe Acrobat Sign – 21. juli-utgivelse fullført
Utgivelsen ble fullført til alle fragmenter uten nedetid for noen av tjenestene.
Gjeldende merknader:
|
Status |
Problem eller hendelse |
Utføringsdato |
|
Ny Neste utgivelse |
Fra og med 8. september 2026 |
|
|
Ny Neste utgivelse Gradvis |
Starter 16. juni |
|
|
Oppdatert Viktig Gjeldende |
5. mai 2026 |
|
|
Oppdatert |
september 2026 |
|
|
Oppdatert Gradvis |
september 2026 |
|
|
Gradvis Neste større utgivelse |
september 2026 |
|
|
Viktig |
Fra mars 2026 |
|
|
Oppdatert |
2027 |
|
|
Gjeldende |
september 2026 |
|
|
Vedvarende informasjonsmeldinger |
||
|
Gjeldende Informasjonsmessig |
Gjeldende |
|
|
Gjeldende Informasjonsmessig |
Gjeldende |
|
Først rapportert: Mars 2026 |
Gjeldende |
|---|
|
Først rapportert: Mars 2026 |
Gjeldende |
|---|
Innebygd dokumentredigering under forfatterskap rulles ut gjennom en trinnvis utrulling som en del av 17.1.2-utgivelsen for VIP-kontoer.
Utrullingsplan:
VIP- og VIPMP-kundekontoer mottar en gradvis produksjonsutrulling etter 17.1.2-utgivelsen.
Redigering av dokumenter direkte i teksten blir inkludert i 17.2.1 Sandbox–distribusjonen. Utrulling til ETLA-kunder forventes etter 17.2.1-utgivelsen.
Funksjonen er aktivert som standard på kontonivå for både nye og eksisterende støttede kontoer. Konto- og gruppeadministratorer kan aktivere eller deaktivere funksjonen etter behov.
Funksjonen støttes ikke for:
- Acrobat Sign for Government-kontoer.
- Organisasjoner som bruker det eldre Acrobat Sign-brukeradministrasjonssystemet.
For konfigureringsinstruksjoner kan du se Aktiver eller deaktiver innebygd dokumentredigering
For instruksjoner om avsenderarbeidsflyt kan du se Slik redigerer du tekst under feltredigering
Utrullingsplanene kan endres, avhengig av uforutsette hendelser.
|
Først rapportert: August 2025 – Oppdatert august 2026 |
Gjeldende |
|---|
For å bidra til å opprettholde systemstabilitet og forbedre ytelsen, introduserer Adobe Acrobat Sign en spørreterskel for GET API-endepunkter. Denne policyen begrenser hvor ofte klientprogrammer kan gjøre identiske API-kall til Adobe Acrobat Sign-tjenesten.
Høyfrekvent spørring skaper unødvendig belastning på backend-systemer, noe som resulterer i redusert ytelse og tregere responstider. API-utviklere oppfordres til å bruke webhooks for nær sanntidsoppdateringer i stedet for gjentatt spørring.
Hva som endres
Spørringspolicyen gjelder for alle GET API-endepunkter for identiske kall.
Det er en grense for hvor ofte den samme effektive brukeren kan foreta det samme API-kallet til Acrobat Sign. Det returneres en feil når samme effektive bruker gjør identiske kall oftere enn den gjeldende spørreterskelen tillater.
For eksempel behandles en gjentatt forespørsel til samme endepunkt for samme avtale eller bibliotekdokument som et identisk kall. Forespørsler om forskjellige avtaler eller bibliotekdokumenter behandles som separate kall, fordi hvert objekt representerer et annet forespørselsmål.
Eksempler på berørte endepunkter
Henting av status
- GET /agreements/{agreementId} – henter gjeldende status for en avtale.
- GET /agreements/{agreementId}/documents/{documentId} – henter filstrømmen til et dokument i en avtale.
Lister, hendelser og bibliotekdokumenter
- GET /agreements – henter avtaler for brukeren.
- GET /agreements/{agreementId}/events – henter hendelsesinformasjon for en avtale.
- GET /libraryDocuments — Henter bibliotekdokumenter for brukeren.
- GET /libraryDocuments/{libraryDocumentId} — Henter informasjon for et spesifikt bibliotekdokument.
Detaljer om spørringspolicy
Minimum Object Polling Interval (MOPI) definerer hvor ofte samme effektive bruker kan gjøre samme GET API-forespørsel til Acrobat Sign-tjenesten.
Standard MOPI varierer etter tjenestenivå:
- GLOBAL-, ENTERPRISE- og DEVELOPER-nivåer: Tre identiske kall per ett minutts intervall.
- Alle andre nivåer: Tre identiske kall per tre minutters intervall.
Hvis samme effektive bruker gjør identiske GET-forespørsler oftere enn nivået tillater, returnerer Acrobat Sign et 429 Too Many Requests-svar med en Prøv igjen etter-overskrift.
En forespørsel regnes som identisk når samme effektive bruker gjør samme GET-forespørsel med samme forespørselssti og overskrifter innenfor gjeldende spørringsintervall.
ETag-håndtering
Applikasjoner kan fortsette å bruke ETags og If-None-Match-overskriften for endepunkter som støtter betingede GET-forespørsler.
For betingede GET-forespørsler som er tillatt under avspørringsterskelen, kan Adobe Acrobat Sign returnere 304 Not Modified når ressursen ikke har endret seg.
Når avspørringsterskelen overskrides, returnerer Acrobat Sign 429 Too Many Requests med en Retry-After-header, selv når forespørselen inkluderer en If-None-Match-header.
Handling kreves
Webhooker: Hvis appen din krever oppdateringer i nær sanntid, bruker du webhook i stedet for polling. Webhooks gir en mer effektiv og skalerbar måte å motta rettidige oppdateringer på.
Hvis webhooker ikke kan implementeres, bør applikasjoner implementere klientsidehurtigbufring for å lagre og gjenbruke API-svar.
- Når en 304 Not Modified-respons mottas, bør hurtigbufrede data brukes i stedet for å gjøre et nytt API-kall.
- Når et 429 Too Many Requests-svar mottas, prøver du API-anropet på nytt etter antall sekunder oppgitt i Prøv igjen-overskriften.
Ressurser
- Håndtering av 429-svar: https://developer.adobe.com/acrobat-sign/docs/overview/developer_guide/apiusage#handling-rate-limiting-http-429
- Terskel for API-spørring: https://developer.adobe.com/acrobat-sign/docs/overview/developer_guide/apiusage#get-endpoints
Tidslinje
De oppdaterte MOPI-tersklene er allerede i produksjon.
- Den oppdaterte ETag-begrensningsfunksjonaliteten er inkludert i 17.1.1-utgivelsen. Etter denne endringen returnerer Acrobat Sign 429 Too Many Requests for begrensede forespørsler, inkludert betingede GET-forespørsler som inkluderer en Hvis-ikke-samsvar-overskrift.
- Retningslinjene for avspørring er satt til ENFORCED for nye kontoer i Sandbox-miljøet 11. februar 2026.
- Avspørringspolicyen er satt til ENFORCED for nye kontoer i produksjonsmiljøet 5. april 2026.
Ta kontakt med CSM-en din hvis du trenger hjelp eller har spørsmål.
|
Først rapportert: Mars 2026 |
Gjeldende |
|---|
Oppdateringer for SSL/TLS-sertifikatrotasjon – overgang til kortere gyldighetsperioder
SSL/TLS-bransjen går over til betydelig kortere gyldighetsperioder for sertifikater. Denne endringen er drevet av oppdateringer fra CA/Browser Forum (det styrende organet for offentlig klarerte sertifikater) og blir tatt i bruk av store sertifikatmyndigheter (CA-er), inkludert DigiCert.
Som et resultat vil sertifikatenes levetid gradvis reduseres fra dagens ~398 dager til så kort som 47 dager i løpet av de neste årene.
Hva endres?
Den maksimale gyldighetsperioden for offentlig klarerte TLS-sertifikater vil bli redusert til 47 dager. Dette kravet er definert av CA/Browser Forum og gjelder for hele bransjen.
Hvorfor kreves denne endringen?
Kortere levetid for sertifikater forbedrer sikkerheten ved å:
- Redusere eksponeringsvinduet hvis et sertifikat eller en privat nøkkel blir kompromittert
- Begrense avhengigheten av mekanismer for tilbakekalling av sertifikater
- Oppmuntre til automatisert livssyklusstyring av sertifikater
- Forbedre det generelle sikkerhetsnivået på Internett
Store nettleserleverandører (Google, Apple, Mozilla, Microsoft) støtter denne overgangen.
For ytterligere bransjekontekst, se DigiCerts kunngjøring:
TLS Certificate Lifetimes Will Officially Reduce to 47 Days
Hvordan dette påvirker deg
- Sertifikater må oftere fornyes
- Sertifikater må oftere fornyes ettersom maksimale gyldighetsperioder reduseres.
- Automatisering er påkrevd
- På grunn av de kortere gyldighetsperiodene forventes sertifikatfornyelser å være fullstendig automatiserte. Manuelle fornyelsesprosesser er ikke lenger opprettholdbare med denne frekvensen.
Hvis miljøet ditt er avhengig av sertifikatfesting, manuelle tillitslagre eller statiske sertifikatreferanser, gjennomgå konfigurasjonen din for å sikre kompatibilitet med hyppige fornyelser.
Kundevarsler
Tidligere ble varsler sendt når sertifikater ble fornyet på årlig basis.
Fra slutten av juni 2026 vil rutinemessige meldinger for standard sertifikatrotasjoner bli avviklet.
Med kortere gyldighetsperioder og automatiske fornyelser:
- Rutinemessige sertifikatrotasjoner vil ikke generere kundemeldinger.
- Meldinger vil kun sendes ved:
- Fornyelsesfeil
- Tjenestepåvirkning
- Handling av kunden kreves
Denne tilnærmingen er i tråd med bransjens beste praksis for automatisert administrasjon av livssyklus for sertifikater.
Ingen handling kreves (hvis automatisering er aktivert)
Hvis integrasjonen din baserer seg på standard TLS-tillitsvalidering og ikke er avhengig av sertifikatfesting, kreves ingen handling.
Sertifikater vil fortsette å fornyes automatisk før utløp.
Når handling kan kreves
Du må kanskje handle hvis:
- Du bruker sertifikatfesting (SPKI eller full sertifikatfesting)
- Du vedlikeholder manuelle sertifikatlagre
- Du har brannmurregler knyttet til spesifikke sertifikatfingeravtrykk
- Du driver systemer som ikke støtter automatiske sertifikatoppdateringer
Hvis du er usikker, rådfør deg med sikkerhets- eller infrastrukturteamet ditt.
Vanlige spørsmål
- Er dette en Adobe-spesifikk endring?
- Nei. Dette er en bransjeomfattende endring pålagt av CA/Browser Forum og implementert av alle store sertifikatmyndigheter.
- Vil tjenestetilgjengeligheten bli påvirket?
- Nei. Sertifikater vil fornyes automatisk før de utløper. Det forventes ingen nedetid som del av normal rotasjon.
- Når vil meldinger om sertifikatrotasjon stoppe?
- Rutinemeldinger om sertifikatrotasjon vil stoppe ved slutten av juni 2026. Kunder vil fortsatt bli varslet kun hvis handling kreves eller hvis et problem påvirker tjenesten.
- Hvor kan jeg lære mer?
- For mer informasjon for industrien, se DigiCerts annonsering:
https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days
- For mer informasjon for industrien, se DigiCerts annonsering:
Trenger du hjelp?
Hvis du har spørsmål om sertifikatrotasjon eller trenger hjelp med å validere integrasjonen din, kontakt Adobe Support eller din Adobe-kontorepresentant.
|
Først rapportert: februar 2025 – oppdatert: juni 2026 |
Gjeldende |
|---|
I 17.2–utgivelsen (september 2026) blir alle kommersielle og offentlige kontoer oppdatert til å bruke det moderne Be om signatur–miljøet.
- Byttelenkene blir deaktivert
- Administratorkontroller i Admin-menyen vil forbli for kunder som trenger å falle tilbake til det klassiske brukergrensesnittet.
Dette endres
I utgivelsen i september 2026 (17.2):
- Alle kommersielle– og Govcloud–kontoer byttes automatisk til den moderne Be om signatur–opplevelsen.
- Byttelenkene deaktiveres for både kommersielle kontoer og Govcloud–kontoer
- Kontrollene for å tilbakestille opplevelsen til det klassiske miljøet forblir tilgjengelige.
I utgivelsen fra januar 2027 (18.0):
- Alle kontoer vil automatisk bli byttet til den moderne Be om signatur–opplevelsen.
- Byttelenkene vil bli fjernet.
- Kontrollene for å tilbakestille opplevelsen til det klassiske miljøet fjernes fra grensesnittet.
Vi anbefaler at du gjør brukerne dine kjent med den nye opplevelsen før utgivelsen for å sikre en problemfri overgang.
|
Først rapportert: februar 2025 – oppdatert: juni 2026 |
Gjeldende |
|---|
I 17.2–utgivelsen (september 2026) blir alle kommersielle og offentlige kontoer oppdatert til å bruke den moderne Opprett mal–opplevelsen.
- Byttelenkene blir deaktivert
- Administratorkontroller i Admin-menyen vil forbli for kunder som trenger å falle tilbake til det klassiske brukergrensesnittet.
Dette endres
I utgivelsen i september 2026 (17.2):
- Alle kommersielle– og Govcloud–kontoer byttes automatisk til den moderne Opprett mal–opplevelsen.
- Byttelenkene deaktiveres for både kommersielle kontoer og Govcloud–kontoer
- Kontrollene for å tilbakestille opplevelsen til det klassiske miljøet forblir tilgjengelige.
I utgivelsen fra januar 2027 (18.0):
- Alle kontoer blir automatisk byttet til den moderne Opprett mal–opplevelsen.
- Byttelenkene vil bli fjernet.
- Kontrollene for å tilbakestille opplevelsen til det klassiske miljøet fjernes fra grensesnittet.
Vi anbefaler at du gjør brukerne dine kjent med den nye opplevelsen før utgivelsen for å sikre en problemfri overgang.
|
Først rapportert: april 2025 – oppdatert juni 2026 |
Gjeldende |
|---|
Den nye arbeidsflytutformeren-opplevelsen blir aktivert for alle eksisterende kontoer og erstatter den klassiske versjonen over tid. Under overgangen har administratorer og brukere en viss fleksibilitet til å gå tilbake til det forrige grensesnittet til det blir fullstendig avviklet.
Tidslinje for utrulling
September 2026 (v17.2)
- Alle kontoer oppgraderes til den nye opplevelsen etter utgivelsen (hvis ikke allerede gjort).
- Administratorer beholder muligheten til å gå tilbake til den klassiske opplevelsen.
- Brukere ser ikke lenger byttelenker; administratorer kan aktivere dem ved behov.
Januar 2027 (v18.0)
- Alle kontoer flyttes permanent til den nye opplevelsen.
- Administratorkontroller for å gå tilbake til den klassiske versjonen fjernes.
- Den klassiske tilpassede arbeidsflytutformeren er fullstendig avviklet og ikke lenger tilgjengelig.
Vi anbefaler at du forbereder brukerne dine så snart som mulig for å sikre en smidig overgang.
Nye kontoer som opprettes etter Acrobat Sign-utgivelsen i juli 2025 får den nye opplevelsen aktivert som standard. Det finnes ikke kontrollere for å gå tilbake til den eldre versjonen.
|
Først rapportert: August 2025 – Oppdatert: Oktober 2025 |
Gjeldende |
|---|
Alle eksisterende kontoer er byttet til det moderne miljøet
I 17.0-utgivelsen (jan. 2026) vil alle kontoer bli oppdatert til å bruke det moderne e-signering smiljøet.
Kontroller for det klassiske miljøet vil forbli tilgjengelige som en reserveløsning for alle brukstilfeller der det moderne miljøet ikke kan brukes.
|
Først rapportert: september 2022 – oppdatert juni 2026 |
Gjeldende |
|---|
Klassisk rapportering fjernes fullstendig fra Acrobat Sign-grensesnittet i 2027. Dette inkluderer en vekslekobling som gjør det mulig å bytte mellom miljøer. Straks den er fjernet, får ikke kunder gå tilbake til klassisk miljø for å gjennomgå klassiske rapporter, og planlagte rapporter slutter å kjøre.
Det moderne rapporteringsmiljøet vil forbli den eneste rapporteringsløsningen.
Alle kunder oppfordres på det sterkeste til å gjenskape alle sine eksisterende rapporter i det nye miljøet så snart som mulig.
|
Først rapportert: Februar 2026 |
Gjeldende |
|---|
Sammendrag
På grunn av oppdaterte regulatoriske krav i Thailand støttes ikke avtaleleveranse via SMS for mottakere med thailandske telefonnumre.
Hva som endres
Thailand har innført oppdaterte reguleringer som begrenser SMS-meldinger som inneholder nettadresser fra å dirigere mottakere til flyter som krever brukerinteraksjon. Fordi signering av en avtale krever mottakerinteraksjon, er SMS-levering for dette brukstilfellet begrenset.
Hvem som påvirkes
- Avtaler sendt ved hjelp av Avtaleleveranse via SMS.
- Mottakere med thailandske (+66) telefonnumre.
Påvirkning
Mottakere med thailandske telefonnumre mottar kanskje ikke SMS-meldinger som inneholder avtalelenker. Som et resultat kan mottakere være ute av stand til å få tilgang til og fullføre signeringsprosessen når SMS-levering brukes.
Denne begrensningen er av regulatorisk karakter og er ikke forårsaket av et tjenesteavbrudd eller produktfeil.
Tidspunkt
Det er for øyeblikket ingen bekreftet tidslinje for når denne begrensningen kan oppheves eller en teknisk løsning vil bli anvendt. Denne meldingen vil bli oppdatert når forholdene endres.
Nødvendige handlinger
- Ikke bruk Avtaleleveranse via SMS for mottakere med thailandske telefonnumre.
- Inkluder e-post som en alternativ leveringsmetode for å sikre avtaleleveranse.
Ytterligere detaljer
Denne begrensningen gjelder kun SMS-basert levering. Andre leveringsmetoder og autentiseringsmetoder for avtaler påvirkes ikke.
|
Først rapportert: Mai 2024 |
Gjeldende |
|---|
Alternativet for å bruke en ekstern stasjon for å laste opp filer vil være begrenset til OneDrive bare i den nye Be om signatur-opplevelsen.
Det anbefales at kunder som bruker andre alternativer for filopplasting, bruker den leverandørspesifikke applikasjonen for å tilby en nettverksstasjon som kan nås gjennom den opprinnelige filvelgeren på brukerens lokale system.
- Dropbox: https://www.dropbox.com/desktop
- Google Disk: https://support.google.com/drive/answer/10838124
- Box: https://support.box.com/hc/en-us/articles/360043697194-Installing-Box-Sync
- Acrobat/Document Cloud: https://www.adobe.com/no/acrobat/how-to/share-pdf-online.html
Flere ressurser
- Fellesskapsfora
- Ukentlig opplæring – Ukentlig webinar som dekker kursemner for nye brukere og administratorer
Arkiverte varsler
Oppført etter datoen da varslet ble fjernet fra den gjeldende varsellisten, sortert fra nyeste til eldste.
Effektiviser arbeidet ditt med Acrobat Sign
Behandle og signer dokumenter på nettet raskt og enkelt.
