Sidst opdateret den
2. mar. 2026
Nyheder
Kom godt i gang
- Vejledning til hurtig start for administratorer
- Vejledning til hurtig start for brugere
- For udviklere
- Bibliotek med videoselvstudier
- Ofte stillede spørgsmål
Administrer
- Oversigt over Admin Console
- Brugeradministration
- Tilføj, rediger og gennemgå aktive brugere
- Opret funktionsfokuserede brugere
- Gennemgå brugere, der ikke har fuldført bekræftelse
- Søg efter brugere med klargøringsfejl
- Skift navn/e-mailadresse
- Rediger en brugers gruppemedlemskab
- Rediger en brugers gruppemedlemskab via gruppegrænsefladen
- Forfrem en bruger til en administratorrolle
- Brugeridentitetstyper og enkeltlogin
- Skift brugeridentitet
- Godkend brugere med MS Azure
- Godkend brugere med Google-føderation
- Produktprofiler
- Login-oplevelse
- Konto-/gruppeindstillinger
- Oversigt over indstillinger
- Globale indstillinger
- Kontoniveau og ID
- Ny modtageroplevelse
- Selvunderskrivelsesarbejdsforløb
- Send i massevis
- Webformularer
- Arbejdsforløb for brugerdefineret afsendelse
- Power Automate-arbejdsforløb
- Biblioteksdokumenter
- Indsaml formulardata med aftaler
- Begrænset dokumentsynlighed
- Vedhæft en PDF-kopi af den underskrevne aftale
- Inkluder et link i mailen
- Medtag et billede i e-mailen
- Filer, der vedhæftes i mail, navngives som
- Vedhæft redigeringsrapport til dokumenter
- Flet flere dokumenter sammen til ét
- Download individuelle dokumenter
- Upload et underskrevet dokument
- Delegering til brugere af min konto
- Tillad eksterne modtagere at delegere
- Tilladelse til at underskrive
- Tilladelse til at sende
- Autoritet til at tilføje elektroniske segl
- Indstil en standardtidszone
- Indstil et standarddatoformat
- Brugere i flere grupper (UMG)
- Tilladelser for gruppeadministratorer
- Udskift modtager
- Revisionsrapport
- Fodnote om transaktion
- Beskeder og vejledning i produktet
- Tilgængelige PDF'er
- Sundhedsplejekunde
- Kontoopsætning / Brandingindstillinger
- Signaturindstillinger
- Velformaterede signaturer
- Tillad modtagere at underskrive ved
- Underskrivere kan ændre deres navn
- Tillad modtagere at bruge deres gemte signatur
- Brugerdefinerede vilkår for anvendelse og videregivelse af oplysninger
- Naviger modtagere gennem formularfelter
- Genstart aftalearbejdsforløb
- Afvis at underskrive
- Tillad arbejdsforløb for stempler
- Kræv, at underskrivere angiver deres titel eller virksomhed
- Tillad underskrivere at udskrive og placere en håndskreven signatur
- Vis meddelelser ved e-signering
- Kræve, at underskrivere bruger en mobilenhed til at oprette deres underskrift
- Anmod om IP-adresse fra underskrivere
- Udelad firmanavn og titel fra deltagelsesstempler
- Anvend adaptiv skalering af signaturtegning
- Digitale signaturer
- Elektroniske segl
- Digital identitet
- Rapportindstillinger
- Ny rapportoplevelse
- Klassiske rapportindstillinger
- Sikkerhedsindstillinger
- Indstillinger for Single Sign-on
- Husk mig-indstillinger
- Politik for adgangskode til login
- Styrke af login-adgangskode
- Varighed af websession
- PDF-krypteringstype
- API
- Adgang for bruger- og gruppeoplysninger
- Tilladte IP-områder
- Kontodeling
- Tilladelser til kontodeling
- Kontroller til aftaledeling
- Bekræftelse af underskrivers identitet
- Adgangskode til underskrivelse af aftaler
- Dokumentadgangskodens styrke
- Bloker underskrivere efter geolokalitet
- Telefongodkendelse
- Videnbaseret godkendelse (KBA)
- Tillad sideudtrækning
- Udløb af dokumentlink
- Upload et klientcertifikat til webhooks/tilbagekald
- Tidsstempel
- Afsendelsesindstillinger
- Vis siden Send efter login
- Oplevelser ved aftaleoprettelse
- Kræv modtagernavn ved afsendelse
- Lås navneværdier for kendte brugere
- Tilladte modtagerroller
- Tillad e-vidner
- Modtagergrupper
- CC'er
- Obligatoriske felter
- Vedhæftning af dokumenter
- Samkopiering af felter
- Rediger aftaler
- Fjern modtagere fra aftaler under behandling
- Aftalenavn
- Sprog
- Private beskeder
- Tilladte signaturtyper
- Påmindelser
- Beskyttelse af underskrevne dokumenter med adgangskode
- Send aftalenotifikation via
- Muligheder for underskriveridentifikation
- Udfyld formularfelter med identitetsbekræftede data
- Indholdsbeskyttelse
- Aktivér Notarize-transaktioner
- Dokumentudløb
- Forhåndsvisning, placer signaturer, og tilføj felter
- Rækkefølge for underskrivelse
- Tilføj mig selv
- Link til download af aftalen
- Grænser for formularfelt
- Liquid-tilstand
- Brugerdefinerede arbejdsforløbskontrolelementer
- Uploadindstillinger for e-underskrivelsessiden
- Omdirigering af bekræftelses-URL efter underskrivelse
- Begræns adgang til delte aftaler
- Vis siden Send efter login
- Beskedskabeloner
- Indstillinger for biomedicin
- Arbejdsforløbintegration
- Notariseringsindstillinger
- Integration af betalinger
- Underskrivermeddelelser
- SAML-indstillinger
- SAML-konfiguration
- Installer Microsoft Active Directory Federation Service
- Installer Okta
- Installer OneLogin
- Installer Oracle Identity Federation
- SAML-konfiguration
- Dataforvaltning
- Tidsstempelindstillinger
- Eksternt arkiv
- Kontosprog
- E-mailindstillinger
- Migrering fra echosign.com til adobesign.com
- Konfigurer indstillinger for modtagere
- Vejledning om forskriftsmæssige krav
- Hjælp til handicappede
- HIPAA
- Persondataforordning
- 21 CFR del 11 og EudraLex bilag 11
- Kunder i sundhedssektoren
- IVES-understøttelse
- "Lagring" af aftaler
- EU/UK-overvejelser
- Download aftaler i massevis
- Gør krav på dit domæne
- Rapportér misbrug-links
- Systemkrav og -begrænsninger
Send, underskriv og administrer aftaler
- Modtagerindstillinger
- Annuller en mailpåmindelse
- Indstillinger på e-underskrivelsessiden
- Oversigt over e-underskrivelsessiden
- Åbn for at læse aftalen uden felter
- Afvis at underskrive en aftale
- Deleger underskrivelsesautoritet
- Genstart aftalen
- Download en PDF af aftalen
- Se aftalens historik
- Vis aftalemeddelelserne
- Konvertér fra elektronisk til håndskreven signatur
- Konvertér fra håndskreven til elektronisk signatur
- Naviger formularfelterne
- Ryd dataene fra formularfelterne
- Forstørrelse og navigation på e-underskrivelsesside
- Skift det sprog, der bruges i aftaleværktøjerne og -oplysningerne
- Gennemse de juridiske meddelelser
- Juster Acrobat Sign-cookieindstillinger
- Send aftaler
- Send (opret)-side
- Oversigt over milepæle og funktioner
- Gruppevælger
- Tilføjelse af filer og skabeloner
- Aftalenavn
- Global meddelelse
- Deadline for udfyldelse
- Påmindelser
- Adgangskodebeskyt PDF'en
- Signaturtype
- Landestandard for modtageren
- Rækkefølge/forløb for modtagersignatur
- Modtagerroller
- Modtagergodkendelse
- Privat besked til modtageren
- Adgang til modtageraftale
- Cc-parter
- Identitetstjek
- Send en aftale kun til dig selv
- Send en aftale til andre
- Håndskrevne underskrifter
- Modtageres underskrivelsesrækkefølge
- Send i massevis
- Send (opret)-side
- Oprettelse af felter i dokumenter
- Oprettelsesmiljø i appen
- Automatisk feltregistrering
- Træk og slip felter ved hjælp af oprettelsesmiljøet
- Tildel formularfelter til modtagere
- Rollen Forudfyld
- Anvend felter med en genanvendelig feltskabelon
- Overfør felter til en ny biblioteksskabelon
- Opdateret oprettelsesmiljø ved afsendelse af aftaler
- Opret formularer med teksttags
- Opret formularer med Acrobat (AcroForms)
- Felter
- Felttyper
- Almindelige felttyper
- E-signaturfelter
- Initialfelt
- Feltet Modtagernavn
- Feltet Modtagermail
- Feltet Dato for underskrivelse
- Tekstfelt
- Datofelt
- Talfelt
- Afkrydsningsfelt
- Gruppe med afkrydsningsfelter
- Alternativknap
- Rullemenu
- Linkoverlejring
- Betalingsfelt
- Vedhæftede filer
- Deltagelsesstempel
- Transaktionsnummer
- Billede
- Firma
- Titel
- Stempel
- Udseende af feltindhold
- Feltvalideringer
- Værdier for maskerede felter
- Indstilling af vis/skjul betingelser
- Beregnede felter
- Verificerede formularer
- Felttyper
- Ofte stillede spørgsmål om oprettelse
- Oprettelsesmiljø i appen
- Underskriv aftaler
- Administrer aftaler
- Administrer sideoversigt
- Kopiér en aftale
- Deleger aftaler
- Udskift modtagere
- Begræns dokumentsynlighed
- Annuller en aftale
- Opret nye påmindelser
- Gennemgå påmindelser
- Annuller en påmindelse
- Få adgang til Power Automate-forløb
- Flere handlinger ...
- Sådan fungerer søgning
- Se en aftale
- Opret en skabelon fra en aftale
- Skjul/vis aftaler fra visning
- Upload en underskrevet aftale
- Rediger en sendt aftales filer og felter
- Rediger en modtagers godkendelsesmetode
- Tilføj eller rediger en udløbsdato
- Føj en note til aftalen
- Del en individuel aftale
- Annuller deling af en aftale
- Download en individuel aftale
- Download de enkelte filer i en aftale
- Download revisionsrapporten for en aftale
- Download feltindholdet af en aftale
- Revisionsrapport
- Rapportering og dataeksport
- Oversigt
- Giv brugere adgang til rapportering
- Rapportdiagrammer
- Dataeksporter
- Omdøb en rapport/eksport
- Dubler en rapport/eksport
- Planlæg en rapport/eksport
- Slet en rapport/eksport
- Brug af kontroltransaktion
Avancerede aftalefunktioner og arbejdsforløb
- Webformularer
- Genanvendelige skabeloner (Biblioteksskabeloner)
- Amerikanske regeringsformularer i Acrobat Sign-biblioteket
- Opret en biblioteksskabelon
- Skift en biblioteksskabelons navn
- Skift en biblioteksskabelons type
- Skift en biblioteksskabelons tilladelsesniveau
- Kopiér, rediger og gem en delt skabelon
- Download de aggregerede feltdata for en biblioteksskabelon
- Overfør ejerskab af webformularer og biblioteksskabeloner
- Power Automate-arbejdsforløb
- Oversigt over Power Automate-integrationen og inkluderede rettigheder
- Aktivér Power Automate-integrationen
- Kontekstintegrerede handlinger på siden Administrer
- Spor Power Automate-brug
- Opret et nyt forløb (eksempler)
- Udløsere, der bruges til forløb
- Import af forløb uden for Acrobat Sign
- Administrer forløb
- Rediger forløb
- Del forløb
- Deaktivere eller aktivere forløb
- Slet forløb
- Nyttige skabeloner
- Kun administrator
- Aftalearkivering
- Arkivering af webformularaftaler
- Gem udfyldte webformulardokumenter i SharePoint-bibliotek
- Gem udfyldte webformulardokumenter i OneDrive for Business
- Gem alle fuldførte dokumenter i Google Drive
- Arkiver udfyldte webformulardokumenter i Box
- Udtrækning af aftaledata
- Aftalenotifikationer
- Send brugerdefinerede mailnotifikationer med dit aftaleindhold og din underskrevne aftale
- Få dine Adobe Acrobat Sign-notifikationer i en Teams-kanal
- Få dine Adobe Acrobat Sign-notifikationer i Slack
- Få dine Adobe Acrobat Sign-notifikationer på Webex
- Aftalegenerering
- Generer dokument fra Power App-formular og Word-skabelon, send til underskrivelse
- Generér aftale fra Word-skabelon i OneDrive, og få signatur
- Generér aftale for markeret Excel-række, send til gennemgang og underskrivelse
- Arbejdsforløb for brugerdefineret afsendelse
- Del brugere og aftaler
Integrer med andre produkter
- Oversigt over Acrobat Sign-integrationer
- Acrobat Sign til Salesforce
- Acrobat Sign til Microsoft
- Andre integrationer
- Partneradministrerede integrationer
- Sådan oprettes en integrationsnøgle
Acrobat Sign-udvikler
- REST API'er
- Webhooks
- Sandkasse
Support og fejlfinding
Plan for udgivelse af Adobe Acrobat Sign og foreløbig dokumentation
Adobe Acrobat Sign udsender mindst tre opdateringer om året, kategoriseret som større eller mindre udgivelser. Yderligere mindre opdateringer kan introduceres efter behov med henblik på at løse system- eller kundeproblemer.
- Overordnede versioner indeholder vigtige opdateringer, nye funktioner og flere forbedringer.
- Mindre udgivelser fokuserer på mindre forbedringer og justeringer af brugeroplevelsen. Disse opstår mellem større opdateringer, typisk en til to gange pr. cyklus.
For at forhindre afbrydelser er nye funktioner som standard deaktiveret og skal være aktiveret manuelt af en konto- eller gruppeadministrator.
For sundheds- og biovidenskabskunder, der kræver overensstemmelsesvalidering, skal Acrobat Sign samarbejde med en tredjepartsleverandør om at levere en valideringspakke for hver større version, der indeholder funktioner, for at minimere din risikofaktor.
Bemærk:
Denne Side med forhåndsbemærkninger opdateres jævnligt, når der kommer nye oplysninger, så indholdet er relativt dynamisk.
Selvom siden er lokaliseret, tager processen tid, hvilket kan resultere i oversatte versioner, der afviger en smule fra den autoritative version på amerikansk engelsk.
Vi anbefaler, at du læser siden på amerikansk engelsk for at få de mest nøjagtige og opdaterede oplysninger.
Adobe Acrobat Sign følger en struktureret tidsplan for udgivelse af produktbemærkninger og dokumentationsopdateringer:
8 uger før produktionsudgivelse
- Den foreløbige side udgiver en opsummering af forventede funktioner og opdatering – typisk 4 uger før Sandbox-lanceringen.
- Funktioner, der tilføjes eller fjernes efter dette punkt, kan ses i sektionen Errata.
- Løste problemer er ikke medtaget i denne fase.
4 uger før produktionsudgivelse (Sandbox-lancering)
- Førudgivelsessiden opdateres med detaljeret dokumentation om nye og opdaterede funktioner.
- Links til foreløbig udgivelses-supportdokumentation, der kun er tilgængelig på amerikansk engelsk, tilføjes efter behov.
- Afsnittet Løste problemer udgives med løbende opdateringer i løbet af de næste fire uger.
Startdag
- De officielle produktbemærkninger er opdateret med de endelige funktionsdetaljer og links til produktionssupportens dokumentation.
- Førudgivelsessiden opdateres for at fremhæve den næste udgivelsescyklus.
- Dokumentationen udgives efter verificering af udgivelsen i live-systemet, typisk efter kl. 19 PT, selvom komplekse opdateringer kan tage længere tid.
- Den endelige liste over Løste problemer føjes til de amerikansk engelske produktbemærkninger med oversatte versioner, der opdateres senere.
Offentlig cloud-udgivelse
- Government Cloud-miljøet opdateres typisk mellem to dage og flere uger efter produktionsudgivelsen, da nogle funktioner kan kræve yderligere evaluering før udrulning.
Bemærk:
Sandbox-dokumentationen er designet til produktionsmiljøet. Links i forhåndsudgivelses-indholdet retter sig mod produktions-URL'erne, hvilket betyder, at linksene kan linke til ældre eksisterende dokumentation eller give 404-resultater, hvis målsiden er ny og endnu ikke udgivet (f.eks. når linket peger mod en ny funktion i samme udgave).
De nye sider udgives når versionen udgives, og links vil være korrekt forbundet med deres produktions-URL'er.
Sandkassetilgængelighed
Kunder, der har adgang til Acrobat Sign Sandbox-miljøet, kan få adgang til den nye versions funktionalitet fire uger før lanceringen.
- Sandbox-miljøet skal bestå alle kvalitetssikringsprocedurer i produktionen på samme kvalitetsniveau som det almindelige produktionsmiljø.
- Adobe bestræber sig på at have 99,9 % tilgængelighed i sandkassemiljøet, men kunder bør bemærke, at Adobe Unified SLA ikke formelt dækker sandkassen.
- Sandkassemiljøet bruger den samme statusside og afbrydelsesprocedurer som det almindelige produktionsmiljø.
Advarsel:
Denne artikel indeholder oplysninger om foreløbige bemærkninger. Udgivelsesdatoer, funktioner og andre oplysninger kan ændres uden varsel.
Adobe Acrobat Sign-udgivelse v17.0.1
Sandbox-installation: 17. februar 2026
Produktionsudrulning: 17. marts 2026
GovCloud-udrulning: 19. marts 2026
Forbedret funktionalitet
- Opret en kopi – Udvidede adgangspunkter, hurtigere genbrug af aftaler.
Opret en kopi er nu tilgængelig direkte fra filtrene Igangværende og Venter på dig på siden Administrer. Disse yderligere indgangspunkter gør det nemmere at genbruge aftaler på flere punkter i afsendelseslivscyklussen, hvilket reducerer behovet for at starte forfra.
Denne funktion vil være tilgængelig i Sandbox-miljøet den 20. februar 2026.
Bemærk: Med denne udgivelse fjernes de administrative kontrolelementer til at deaktivere denne funktion fra administratormenuen, hvilket etablerer Opret en kopi som en standardfunktion, der er tilgængelig for alle berettigede brugere.
- Tilgængelige miljøer: Sandkasse, Kommerciel, Offentlig | Tilgængelige tjenesteniveauer: Acrobat Sign Solutions | Konfigurationsomfang: Konto og Gruppe, Aktiveret som standard.
REST API-/Webhook-opdateringer
Nedenstående opdateringer vises i de foreløbige produktbemærkninger med henblik på offentliggørelse. Fuld dokumentation for API- og Webhook-opdateringer kan findes i Acrobat Sign-udviklerdokumentation, når versionsopdateringen leveres til produktionsserverne.
- OEM 2.0 personaliseret e-mail-visning – Mere tydelig identitet på afsender og modtager på tværs af integrerede oplevelser og korrekt e-mail-levering.
For OEM 2.0-partnere, der bruger integrerede arbejdsforløb, viser Acrobat Sign nu en brugers personlige mailadresse i stedet for den partnerregistrerede mail på tværs af vigtige brugergrænseflader og notifikationer. Aftaler, køer som "Venter på dig" og "Gennemse og underskriv" e-mails afspejler konsekvent den personaliserede identitet, mens den registrerede e-mail bevares internt til godkendelse og rettigheder. Dette forbedrer klarheden for afsendere og underskrivere og forhindrer, at mails sendes til registrerede adresser, der ikke kan leveres til.
Tilgængelige miljøer: Sandkasse, Kommerciel | Tilgængelige tjenesteniveauer: Acrobat Sign Solutions | Konfigurationsomfang: Kun API - OEM 2.0-partnere
- Webhook-notifikation for SMS-leveringsfejl – Synlighed i realtid af mislykkede afsendelser af SMS, automatiseret fejlretning og paritet med e-mail-bounces.
Acrobat Sign udsender nu en ny webhook-begivenhed, AGREEMENT_PHONE_BOUNCED, når en aftale sendt via SMS ikke kan leveres på grund af problemer som ugyldige telefonnumre, operatørafvisning eller blokerede linjer. Det gør det muligt for kunder at opdage SMS-leveringsfejl næsten i realtid og automatisk udløse opfølgende handlinger som at rette telefonnumre, igen prøve levering eller åbne supportsager, hvilket eliminerer blinde pletter og sænker forsinkelser i mobil-først underskriftsarbejdsgange.
Tilgængelige miljøer: Sandkasse, kommercielt, offentligt Tilgængelige serviceniveauer: Acrobat Sign Solutions Konfigurationsomfang: API
- Webhook-payloads – Tilføjet betinget deltagerfelt extendedStatus til dynamiske deltagelsesopdateringer, hvilket forbedrer synligheden af deltagerstatus.
Webhook-notifikationer inkluderer nu feltet extendedStatus i hver deltagers (memberInfos[])-objekt, når afsenderen ændrer en igangværende aftale med dynamisk deltagelse. Feltet giver yderligere oplysninger om deltagerens livscyklus og efterlader samtidigt det allerede eksisterende felt uændret, hvilket sikrer bagudkompatibilitet.
{
"participantSets": [
{
"id": "",
"memberInfos": [
{
"company": "TestCo",
"email": "signer2@someDomain.dom",
"id": "CBJCHBCAABAAJiZV9cH",
"name": "Signer Two",
"status": "ACTIVE",
"extendedStatus": "REMOVED"
}
],
"order": ,
"role": "",
"status": ""
}
]
}
- status-værdier (uændret): ACTIVE, REPLACED.
- extendedStatus-værdier: ACTIVE, REPLACED, REMOVED, COMPLETED.
Tilgængelige miljøer: Sandkasse, kommercielt, offentligt | Tilgængelige tjenesteniveauer: Acrobat Sign Solutions | Konfigurationsomfang: API
Udgivelseserrata
Der er ingen elementer, der er blevet fjernet fra denne udgivelse på nuværende tidspunkt.
Løste problemer
| Problem | Beskrivelse |
|---|---|
| 4543515 | Resumé: En webhook-e-mail-bounce-hændelse kan blive genereret forkert for en gyldig underskriver, efter at underskriveren har underskrevet, og aftalen går videre til næste trin. Dette kan forekomme, når en delegeret i samme underskrivergruppe har en ugyldig e-mailadresse, og afsenderen erstatter den oprindelige delegator. I disse tilfælde kan systemet forkert tilskrive "underskrevet på vegne af..."-bounce-hændelsen til den gyldige underskriver i stedet for den deltager, hvis e-mail faktisk bouncer. |
| Løsning: Hændelsestilskrivningslogikken blev rettet, så e-mail-bounce-hændelser kun associeres med den deltager, hvis e-mail faktisk bouncer. En bounce-hændelse genereres ikke længere for en gyldig underskriver, der allerede har fuldført underskrivningen, og webhook-notifikationer afspejler nu den korrekte deltager og e-mailadresse. | |
| 4544548 | Resumé: Integrationsnøgler oprettet gennem web-brugergrænsefladen kan udløbe efter 10 år, selvom oprettelsessiden angiver, at nøglen giver "permanent adgang." Når en nøgle når sin 10-årige levetid, begynder API-kald at returnere en udløbet token-fejl, hvilket kan bryde eksisterende integrationer uventet. |
| Løsning: Brugergrænseflademeddelelsen blev opdateret for at fjerne "permanent adgang"-ordlyden og tydeligt vise udløbsdatoen for integrationsnøgler. Den opdaterede tekst angiver nu, at nøglen bevarer adgang indtil udløbsdatoen eller indtil den manuelt tilbagekaldes, hvilket giver gennemsigtighed om den 10-årige standardlevetid. | |
| 4546301 | Resumé: Webhook-hændelseslevering kan blive forsinket med op til flere timer for aftaler med meget store dokumenter, selv når aftaleoprettelse fuldføres, og tidlige behandlingstrin ser ud til at afsluttes inden for minutter. Under forsinkelsesvinduet kan webhook-leveringstjenesten gentagne gange modtage DOCUMENT_NOT_AVAILABLE-svar, når den forsøger at hente aftaledokumenter, og webhook-hændelsen leveres muligvis ikke, før tjenesten stopper med at prøve igen, eller dokumenterne bliver tilgængelige. |
| Løsning: Dokumenttilgængelighedshåndtering blev rettet, så store aftaler pålideligt overgår til en tilstand, hvor dokumenter kan hentes uden udvidede DOCUMENT_NOT_AVAILABLE-svar. Som resultat leveres webhook-hændelser uden flertimers forsinkelser forårsaget af dokumenthentningsforsøg mod utilgængelige dokumenter. | |
| 4547823 | Resumé: En modtagers private besked vises muligvis ikke for nogle underskrivere, når en aftale oprettes i Authoring-tilstanden gennem API'en og derefter redigeres fra Manage-oplevelsen. I dette scenarie kan brugergrænsefladen vise Private Message-værdien som "Ingen" eller tom, selvom aftaledata inkluderer den korrekte private beskedværdi. Denne adfærd vises i delte kontoscenarier, hvor en bruger skifter til en anden brugers konto for at redigere udkastet, og det kan kun påvirke specifikke modtagere, mens andre vises korrekt. |
| Løsning: Et tjek blev tilføjet for at hente den primære delingskontekst og returnere den private besked for autoriserede delte brugere. Som resultat vises Private Message-værdien nu korrekt, når man ser eller sender et API-oprettet udkast fra Authoring-flowet. | |
| 4548274 | Resumé: Den ændrede dato for biblioteksskabeloner opdateres muligvis ikke, efter at en skabelon er redigeret og gemt i den nye skabelonoplevelse. Brugere kan se nyligt tilføjede eller opdaterede felter på skabelonen, men den ændrede dato forbliver uændret i Manage-brugergrænsefladen og i administrative visninger, hvilket får det til at se ud som om skabelonen ikke blev ændret for nylig. Dette sker, fordi den nye oplevelse opdaterer formularfelter gennem en sti, der ikke også opdaterer skabelonens ændrede tidsstempel. |
| Løsning: Den ændrede datoopdateringsadfærd blev tilpasset på tværs af den nye skabelonoplevelse og de relaterede API-operationer. Kodestien, der gemmer skabelonfeltændringer, opdaterer nu også skabelonens ændrede dato, så den afspejler det faktiske tidspunkt for den seneste ændring. | |
| 4548564 | Resumé: Underskrifter og formularfelter kan virke usynlige i den underskrevne pdf, når de placeres over allerede eksisterende stempelannotationer i kildedokumentet. I berørte skabeloner overlapper stempelannotationerne eller skjuler de interaktive felter under behandling, hvilket medfører, at udfyldte signaturer og andre felter skjules i det endelige signerede dokument. |
| Løsning: Håndtering af stempelannotationer blev opdateret til sikkert at behandle og flade eksisterende stempelannotationer, så de ikke længere skjuler formularfelter eller signaturer.Felter placeret over stemplede områder forbliver nu synlige gennem hele signeringsprocessen og i den fuldt udførte pdf. | |
| 4549103 | Resumé: En e-mail-bounce-hændelse kan blive logget igen for en tidligere forkert modtager, efter at afsenderen erstatter denne modtager med en gyldig e-mailadresse.I nogle tilfælde kan revisionssporet vise en anden bounce-hændelse for den gamle e-mail, og aftalestatus kan afspejle "e-mail bounced", selvom den nye modtager med succes modtager, ser eller signerer aftalen.Denne adfærd kan få det til at se ud som om, aftalen stadig er rettet mod både den gamle og den nye e-mailadresse. |
| Løsning: Arbejdsforløbet til erstatning af underskriver blev opdateret for at forhindre afsendelse af yderligere notifikations-e-mails til en erstattet modtager, hvis e-mail allerede er bounced.Systemet kontrollerer nu for tidligere bounce-historik, før der sendes erstatningsrelaterede notifikationer, hvilket sikrer, at der ikke genereres nye bounce-hændelser for den gamle e-mailadresse efter erstatning. | |
| 4549306 | Resumé: Brugere, hvis e-mailadresser indeholder visse specialtegn (for eksempel en apostrof), kan muligvis ikke logge ind fra de generiske adobesign.com eller echosign.com offentlige login-sider.Efter indtastning af e-mailadressen og klik i adgangskodefeltet kan siden genindlæse og rydde e-mailfeltet i stedet for at omdirigere brugeren til den korrekte shard eller SSO-loginside.Dette forhindrer berørte brugere i at fuldføre godkendelse og blokerer integrationer, der er afhængige af det offentlige login-endpoint. |
| Løsning: Login shard-opløsningslogikken blev rettet til korrekt at håndtere og dekode e-mailadresser, der indeholder specialtegn, før inter-shard-omdirigerings-URL'en konstrueres.Brugere med berørte e-mailformater omdirigeres nu korrekt til deres udpegede shard og SSO-loginside uden at e-mailfeltet ryddes. | |
| 4549331 | Resumé: Signaturer og andre formularfelter kan virke manglende eller usynlige i den signerede pdf, når visse dokumentbehandlingsfunktioner er aktiveret, og kilde-pdf'en indeholder ugyldige sidebokskoordinater (for eksempel forkerte CropBox- eller MediaBox-værdier).I dette scenarie kan felter, der er afhængige af sidekoordinater, gengives uden for det synlige sideområde, hvilket får udfyldte signaturer til at virke manglende, selvom signering fuldføres med succes. |
| Løsning: pdf-sidebokshåndtering blev rettet til sikkert at normalisere ugyldige CropBox- og MediaBox-værdier under dokumentbehandling.Som resultat tilpasser signatur- og formularfeltplacering sig nu til det synlige sideområde, og signerede pdf'er viser signaturer som forventet. | |
| 4550367 | Resumé: Oprettelse af en webformular kan mislykkes med en generisk "Serverfejl" efter valg af Forhåndsvisning og Tilføj felter, når standard signeringsgodkendelse for afsenderens gruppe er indstillet til Telefon, og kontoen ikke har tilgængelig telefongodkendelseskvote, selvom webformularens signeringsgodkendelse er indstillet til en ikke-telefonmetode (for eksempel Adobe Sign). Som resultat kan alle brugere i den berørte konto blive blokeret fra at oprette web-formularer på tværs af alle dokumenter. |
| Løsning: Oprettelse af webformular evaluerer nu kun kvote for den godkendelsesmetode, der faktisk er konfigureret for webformularens underskriver, og den anvender ikke længere kontrol af telefongodkendelseskvote udelukkende baseret på gruppens standard godkendelsesindstilling. Dette forhindrer falske kvoteudtømningsfejl og tillader, at web-formularer oprettes normalt. | |
| 4551011 | Resumé: Når en afsender uploader nogle scannede PDF'er, tilføjer signaturfelter og sender aftalen, viser den signerede PDF muligvis ingen synlige signaturer, når signeringen er fuldført.Denne adfærd kan forekomme, når den uploadede pdf indeholder ugyldige sidegrænse-metadata (MediaBox- og CropBox-koordinater virker omvendte), hvilket kan få signatur- og andre feltudseendelag til at gengives uden for det synlige sideområde. |
| Løsning: Håndtering af PDF-sidegrænser er opdateret, så den korrekt behandler PDF'er med ugyldige eller omvendte MediaBox- og CropBox-koordinatværdier, så indholdet for signatur- og formularfelters udseende gengives inden for det synlige sideområde og forbliver synligt i den endelige signerede PDF. | |
| 4551427 | Resumé: Nogle modtagere, der allerede har primære, korrekt provisionerede konti, modtager aftaler som "pseudo-bruger"-modtagere i stedet, så aftalen ikke vises i deres normale Administrer-visning.Dette sker, når modtagerens e-mailadresser indeholder foranstillede eller efterstillede mellemrum, hvilket forhindrer systemet i at matche e-mailen med den eksisterende bruger og forårsager, at der oprettes en pseudo-brugerpost. |
| Løsning: E-mailparsing og brugeropslag blev opdateret til at normalisere modtager-e-mailadresser (fjerne foranstillede og efterstillede mellemrum), før de matches med eksisterende brugere.Som resultat løses aftaler adresseret til eksisterende brugere til den registrerede konto i stedet for at oprette en pseudo-brugermodtager, selvom e-mailen blev indtastet med mellemrum (i API-payloads og arbejdsforløb-modtagerlister). | |
| 4553198 | Resumé: Når en aftale inkluderer mindst én modtager konfigureret til SMS-levering og mindst én modtager konfigureret til kun e-mail-levering, sender annullering af aftalen gennem API'en ikke en SMS-annulleringsnotifikation til SMS-modtageren.Aftalen annulleres med succes, og e-mailnotifikationer leveres, men SMS-modtagere modtager ikke en annulleringsbesked. |
| Løsning: Annulleringsarbejdsforløbet blev rettet for at sikre, at SMS-annulleringsnotifikationer sendes til alle modtagere konfigureret til SMS-levering, når en aftale annulleres, uanset andre modtageres leveringsmetoder. | |
| 4554463 | Resumé: Når aftaler inkluderer klonede radioknapper, der deler det samme feltnavn på tværs af kombinerede dokumenter, forbliver kun én instans af den valgte mulighed valgt i den endelige underskrevne pdf.Selvom felterne visuelt fremstår som afkrydsningsfelter, er de implementeret som radioknapper.Efter underskrivning propagerer den valgte værdi ikke konsekvent på tværs af alle klonede instanser, hvilket forårsager forkert eller ufuldstændig mapping af det forventede valg. |
| Løsning: Formularfeltets håndteringslogik blev rettet, så klonede radioknapper gemmer og propagerer den valgte eksportværdi i stedet for en intern indeksværdi.Dette sikrer, at alle klonede instanser af det samme radioknapfelt afspejler det korrekte valg i den underskrevne pdf. | |
| 4554593 | Resumé: Nogle partnerintegrationer, der bruger de ældre OAuth-endepunkter til at opdatere adgangstokens, begyndte at fejle med HTTP 401-fejl.Tjenesten afviste tokenopdateringsanmodninger med en fejl, der indikerede, at appen ikke har tilladelse til at bruge de ældre OAuth-endepunkter og i stedet skal bruge OAuth v2-endepunkterne.Dette blokerede kunder fra at autentificere Acrobat Sign gennem partner-apps, selv for integrationer, der tidligere fungerede. |
| Løsning: Autentificeringstjenesten blev rettet, så partner-apps, der er konfigureret til at bruge det ældre OAuth-flow, kan opdatere tokens med succes igen i stedet for at blive forkert tvunget over på OAuth v2-endepunkterne. | |
| 4554614 | Resumé: Når en underskriver bruger den moderne eSign-oplevelse på en aftale, der kræver underskriverautentificering og er konfigureret til at kræve accept af brugsvilkår før underskrivning, udløser klik på Klik for at underskrive en 5-sekunders omdirigering til den klassiske underskrivningsoplevelse.Omdirigeringsmeddelelsen advarer om, at underskrifter og initialer indtastet i moderne underskrivning vil blive ryddet, hvilket tvinger underskriveren til at indtaste dem igen og effektivt underskrive to gange. |
| Løsning: Underskrivningstokenopdateringsflowet blev rettet, så når underskriveren accepterer brugsvilkårene før underskrivning, bevarer det genudstedte underskrivningstoken underskriverautentificeringsdetaljerne.Dette forhindrer det endelige underskrivningstrin i at fejle autentificering og eliminerer den tvungne tilbagegang fra moderne underskrivning til den klassiske oplevelse. | |
| 4555656 | Resumé: Under specifikke timingbetingelser kan en aftalestatusovergang synes at lykkes, men ændrer faktisk ikke aftalestatus.Når en webhook-notifikation modtages, før backend-behandling er fuldført, kan efterfølgende API-kald bruge forældede aftalestatusdata.I dette vindue returnerer visse statusovergangsmetoder HTTP 200 OK, selvom aftalen ikke er i en gyldig tilstand for den anmodede overgang.Som resultat kan automatiseringsarbejdsforløb antage, at overgangen lykkedes, mens aftalen forbliver i den oprindelige tilstand. |
| Løsning: Aftalestatusovergangslogikken blev opdateret til at håndhæve streng validering, før en overgang anvendes.Hvis aftalen ikke er i en gyldig tilstand, returnerer API'en nu et klart fejlsvar i stedet for stiltiende at returnere succes.Dette sikrer, at ugyldige overgange eksplicit afvises, gør det muligt for kaldende systemer at prøve igen på passende vis og forhindrer aftaler i at forblive i en utilsigtet tilstand uden synlighed. |
