Senast uppdaterad den
17 mars 2026
Användarhandbok för Adobe Acrobat Sign
Nyheter
Kom igång
- Snabbstartsguide för administratörer
- Snabbstartsguide för användare
- För utvecklare
- Videosjälvstudiebibliotek
- Vanliga frågor och svar
Administrera
- Översikt av Admin Console
- Användarhantering
- Lägg till, redigera och granska aktiva användare
- Skapa funktionsfokuserade användare
- Granska användare som inte har slutfört verifieringen
- Sök efter användare med etableringsfel
- Ändra namn/e-postadress
- Redigera en användares gruppmedlemskap
- Redigera en användares gruppmedlemskap via gruppgränssnittet
- Uppgradera en användare till en administratörsroll
- Användaridentitetstyper och SSO
- Byt användaridentitet
- Autentisera användare med MS Azure
- Autentisera användare med Google-federation
- Produktprofiler
- Inloggningsupplevelse
- Konto-/gruppinställningar
- Inställningsöversikt
- Globala inställningar
- Kontonivå och ID
- Ny mottagarupplevelse
- Arbetsflöden för självsignering
- Massutskick
- Webbformulär
- Anpassat arbetsflöde för sändning
- Power Automate-arbetsflöden
- Biblioteksdokument
- Samla formulärdata med avtal
- Begränsad dokumentsynlighet
- Bifoga en PDF-kopia av det signerade avtalet
- Inkludera en länk i e-postmeddelandet
- Inkludera en bild i e-postmeddelandet
- Filer som bifogas i e-post namnges som
- Bifoga granskningsrapporter till dokument
- Sammanfoga flera dokument till ett
- Hämta enskilda dokument
- Ladda upp ett signerat dokument
- Delegering för användare i mitt konto
- Tillåt att externa mottagare delegerar
- Behörighet att signera
- Behörighet att skicka
- Behörighet att lägga till elektroniska stämplar
- Ange standardtidszon
- Ange standarddatumformat
- Användare i flera grupper (UMG)
- Behörigheter för gruppadministratörer
- Ersätt mottagare
- Granskningsrapport
- Transaktions-sidfot
- I produktmeddelanden och -vägledning
- Åtkomliga PDF-filer
- pdf/A-arbetsflöden
- Hälsovårdskund
- Ny upplevelse för att begära signaturer
- Ny anpassad arbetsflödesupplevelse
- Den nya upplevelsen Skapa mall
- Kontoikonfiguration/Varumärkesinställningar
- Signaturinställningar
- Väl formaterade signaturer
- Tillåt mottagare att signera efter
- Signerare får inte ändra sitt namn
- Tillåt att mottagare kan använda sin sparade signatur
- Anpassade användningsvillkor och konsumentsekretess
- Navigera mottagare genom formulärfält
- Starta om arbetsflöde för avtal
- Avböj att signera
- Tillåt stämpelarbetsflöden
- Kräv att signerare tillhandahåller sin titel eller sitt företag
- Tillåt att signerare skriver ut och gör en skriftlig signatur
- Visa meddelanden vid e-signering
- Kräv att signerare gör signaturer och initialer med en mobil enhet
- Begär IP-adress av undertecknare
- Exkludera företagsnamn och titel från deltagandestämplar
- Använd adaptiv skalning av signatur
- Digitala signaturer
- Elektroniska sigill
- Digital identitet
- Rapportinställningar
- Aktivera klassisk rapportering
- Ny rapporteringsupplevelse
- Klassiska rapporteringsinställningar
- Säkerhetsinställningar
- Inställningar för enkel inloggning
- Inställningar för Kom ihåg mig
- Policy för inloggningslösenord
- Styrka för inloggningslösenord
- Webbsessionens varaktighet
- Typ av PDF-kryptering
- API
- Informationsåtkomst för användare och grupper
- Tillåtna IP-intervall
- Kontodelning
- Behörigheter för kontodelning
- Delningskontroller för avtal
- Verifiering av signeraridentitet
- Signeringslösenord för avtal
- Dokumentlösenordets styrka
- Blockera signerare efter geolokalisering
- Telefonautentisering
- Kunskapsbaserad autentisering (KBA)
- Tillåt sidextrahering
- Dokumentlänkens förfallotid
- Överför ett klientcertifikat för webhookar/återanrop
- Tidsstämpel
- Sändningsinställningar
- Expandera Skicka-sidan efter inloggning
- Erfarenheter med avtalskapande
- Kräv mottagarnamn för att skicka
- Lås namnvärden för kända användare
- Tillåtna mottagarroller
- Tillåt e-vittnen
- Mottagargrupper
- CC-mottagare
- Obligatoriska fält
- Bifoga dokument
- Förenkla fält
- Ändra avtal
- Ta bort mottagare från pågående avtal
- Avtalsnamn
- Språk
- Privata meddelanden
- Tillåtna signaturtyper
- Påminnelser
- Lösenordsskydd för signerade dokument
- Skicka avtalsmeddelande via
- Alternativ för identifiering av signerare
- Fyll i formulärfält med identitetsverifierad data
- Innehållsskydd
- Aktivera Notarize-transaktioner
- Förfallotid för dokument
- Förhandsgranska, placera signaturer och lägg till fält
- Signeringsordning
- Lägg till mig själv
- Hämta avtalets länk
- Formulärfältskanter
- Liquid Mode
- Anpassade arbetsflödeskontroller
- Uppladdningsalternativ för e-signeringssidan
- Bekräftelseadress för omdirigering efter signering
- Begränsa åtkomsten till delade avtal
- Expandera Skicka-sidan efter inloggning
- Meddelandemallar
- Bioläkemedelsinställningar
- Arbetsflödesintegrering
- Attesteringsinställningar
- Betalningsintegrering
- Signerarmeddelanden
- SAML-inställningar
- SAML-konfiguration
- Installera Microsoft Active Directory Federation Service
- Installera Okta
- Installera OneLogin
- Installera Oracle Identity Federation
- SAML-konfiguration
- Datastyrning
- Inställningar för tidsstämpling
- Externt arkiv
- Kontospråk
- E-postinställningar
- Migrera från echosign.com till adobesign.com
- Konfigurera alternativ för mottagare
- Riktlinjer för lagstadgade krav
- Tillgänglighet
- HIPAA
- GDPR
- 21 CFR del 11 och EudraLex bilaga 11
- Hälsovårdskunder
- Stöd för IVES
- Säkrade avtal
- Överväganden mellan EU och Storbritannien
- Hämta flera avtal samtidigt
- Gör anspråk på din domän
- Länkar för att rapportera missbruk
- Systemkrav och begränsningar
Skicka, signera och hantera avtal
- Mottagaralternativ
- Avbryta en e-postpåminnelse
- Alternativ på e-signeringssidan
- Översikt över e-signeringssidan
- Öppna för att läsa avtalet utan fält
- Avböj att signera ett avtal
- Delegera signeringsbehörighet
- Starta om avtalet
- Hämta en PDF-fil av avtalet
- Visa avtalshistoriken
- Visa avtalsmeddeladen
- Konvertera från en elektronisk till en skriftlig signatur
- Konvertera från en skriftlig till en elektronisk signatur
- Navigera formulärfälten
- Rensa data från formulärfälten
- Förstoring och navigering av e-signeringssidan
- Ändra språket som används i avtalsverktygen och informationen
- Granska juridiska meddelanden
- Justera cookiepreferenser för Acrobat Sign
- Skicka avtal
- Sidan Skicka (slå samman)
- Översikt över landmärken och funktioner
- Gruppväljare
- Lägger till filer och mallar
- Avtalsnamn
- Globalt meddelande
- Tidsgräns för slutförande
- Påminnelser
- Lösenordsskydda PDF-filen
- Signaturtyp
- Mottagarens plats
- Mottagarens signaturordning/-flöde
- Mottagarroller
- Mottagarautentisering
- Privat meddelande till mottagaren
- Mottagarens avtalsåtkomst
- Parterna som får en kopia
- Identitetskontroll
- Skicka ett avtal bara till dig själv
- Skicka ett avtal till andra
- Skriftliga signaturer
- Mottagarnas signeringsordning
- Massutskick
- Sidan Skicka (slå samman)
- Redigera in fält i dokument
- Redigeringsmiljö i appen
- Skapa formulär och texttaggar
- Skapa formulär med Acrobat (AcroForms)
- Fält
- Fälttyper
- Vanliga fälttyper
- Fält för e-signatur
- Fält för initialer
- Fält för mottagarens namn
- Fält för mottagarens e-postadress
- Fält för signeringsdatum
- Textfält
- Datumfält
- Sifferfält
- Kryssruta
- Kryssrutegrupp
- Alternativknapp
- Rullgardinsmeny
- Länköverlagring
- Betalningsfält
- Bilagor
- Deltagandestämpel
- Transaktionsnummer
- Bild
- Företag
- Titel
- Stämpel
- Utseende på fältinnehåll
- Fältvalideringar
- Maskerade fältvärden
- Välj visa/dölj villkor
- Beräkningsfält
- Verifierade formulär
- Fälttyper
- Vanliga frågor om redigering
- Signera avtal
- Hantera avtal
- Översikt över sidan Hantera
- Kopiera ett avtal
- Delegera avtal
- Ersätt mottagare
- Begränsa dokumentsynlighet
- Avbryta ett avtal
- Skapa nya påminnelser
- Granska påminnelser
- Avbryta en påminnelse
- Åtkomst till Power Automate-flöden
- Fler åtgärder...
- Så här fungerar sökning
- Visa ett avtal
- Skapa en mall från ett avtal
- Dölja/visa avtal från vyn
- Överför signerat avtal
- Ändra filer och fält i ett skickat avtal
- Redigera en mottagares autentiseringsmetod
- Lägg till eller ändra ett förfallodatum
- Lägga till en anteckning i avtalet
- Dela ett enskilt avtal
- Sluta dela ett avtal
- Ladda ner ett enskilt avtal
- Hämta de enskilda filerna i ett avtal
- Hämta granskningsrapporten för ett avtal
- Hämta fältinnehållet i ett avtal
- Granskningsrapport
- Rapportering och dataexporter
- Översikt
- Bevilja användare åtkomst till rapportering
- Rapportdiagram
- Dataexport
- Byt namn på en rapport/export
- Duplicera en rapport/export
- Schemalägg en rapport/export
- Ta bort en rapport/export
- Kontrollera transaktionsanvändning
Avancerade avtalsfunktioner och arbetsflöden
- Webbformulär
- Återanvändbara mallar (Biblioteksmallar)
- Överför ägarskap av webbformulär och biblioteksmallar
- Power Automate-arbetsflöden
- Översikt över Power Automate-integreringen och inkluderade rättigheter
- Aktivera Power Automate-integreringen
- Åtgärder i kontexten på sidan Hantera
- Spåra Power Automate-användningen
- Skapa ett nytt flöde (Exempel)
- Utlösare som används för flöden
- Importera flöden från utanför Acrobat Sign
- Hantera flöden
- Redigera flöden
- Dela flöden
- Inaktivera eller aktivera flöden
- Ta bort flöden
- Användbara mallar
- Endast administratör
- Avtalsarkivering
- Spara dina slutförda dokument i SharePoint
- Spara dina färdiga dokument på OneDrive för företag
- Spara alla slutförda dokument på Google Drive
- Spara alla slutförda dokument i DropBox
- Spara slutförda dokument i Box
- Arkivering av webbformuläravtal
- Spara slutförda webbformulärdokument i SharePoint-biblioteket
- Spara slutförda webbformulärdokument i OneDrive för företag
- Spara dina slutförda dokument i Google Drive
- Spara slutförda webbformulärdokument i Box
- Dataextrahering av avtal
- Avtalsmeddelanden
- Skicka anpassade e-postmeddelanden med avtalsinnehållet och det signerade avtalet
- Få dina Adobe Acrobat Sign-aviseringar i en Teams-kanal
- Få dina Adobe Acrobat Sign-aviseringar i Slack
- Få Adobe Acrobat Sign-aviseringar i Webex
- Avtalsgenerering
- Generera dokument från Power App-formulär och Word-mall, skicka för signering
- Generera avtal från en Word-mall i OneDrive och hämta signaturen
- Generera avtal för vald Excel-rad, skicka för granskning och signering
- Anpassat arbetsflöde för sändning
- Dela användare och avtal
Integrera med andra produkter
- Översikt över Acrobat Sign-integreringar
- Acrobat Sign för Salesforce
- Acrobat Sign för Microsoft
- Övriga integreringar
- Partnerhanterade integreringar
- Så skapar du en integreringsnyckel
Acrobat Sign-utvecklare
- REST-API:er
- Webhookar
- Sandlåda
Support och felsökning
Obs!
I det här dokumentet beskrivs de nya funktionerna, upplevelseändringarna och de lösta problemen i det kundinriktade programmet för den senaste versionen.
Utvecklarcentrerade uppdateringar av API:et och webbhookarna dokumenteras i Användarhandboken för utvecklare för Acrobat Sign.
Det är inte säkert att alla funktioner/ändringar är aktiverade på releasedatumet. Hänvisa alltid till sidversionen på amerikansk engelska som den mest aktuella och korrekta versionen.
Adobe Acrobat Sign version v17.0.1
Produktionsdriftsättning: 17 mars 2026
GovCloud-driftsättning: 19 mars 2026
Förbättrade funktioner
- Skapa en kopia – Utökade åtkomstpunkter, snabbare återanvändning av avtal.
Skapa en kopia är nu tillgängligt direkt från filtren Pågående och Väntar på dig på sidan Hantera samt från bekräftelsesidan efter sändning. Dessa ytterligare startpunkter gör det enklare att återanvända avtal vid fler tillfällen i sändningslivscykeln, vilket minskar behovet av att börja om från början.
Obs! I och med den här versionen tas de administrativa kontrollerna, som används för att inaktivera den här funktionen, bort från administratörsmenyn. Detta etablerar Skapa en kopia som en standardfunktion tillgänglig för alla berättigade användare.
Tillgängliga miljöer: Sandlåda, Kommersiell, Myndighet | Tillgängliga tjänstenivåer: Acrobat Sign Solutions | Konfigurationsomfång: Konto och Grupp, aktiverad som standard.
Granska den uppdaterade dokumentationen för användaråtgärder >
Ändrad upplevelse
- Se förfallotiden för integrationsnycklar – förfallodatumet visas nu på fliken Åtkomsttoken
Fliken Åtkomsttoken, i menyn Personliga inställningar, visar förfallodatumet för varje integrationsnyckel. Detta ger användare och administratörer tydligare överikt över nyckelålder och ersättningstidpunkt, vilket gör det enklare att övervaka befintliga nycklar och undvika oväntade avbrott när en nyckel når slutet av sin 10-åriga giltighetsperiod.
Tillgängliga miljöer: Sandlåda, Kommersiell, Myndighet Tillgängliga tjänstenivåer:Acrobat Sign Solutions Konfigurationsomfång: API
Uppdateringar för REST API/webhook
API- och webhookuppdateringar för den här versionen finns i Acrobat Sign API-dokumentation.
- OEM 2.0 personaliserad e-postvisning – Tydligare avsändar- och mottagaridentitet över inbäddade upplevelser och korrekt e-postleverans.
För OEM 2.0-partner som använder inbäddade arbetsflöden kan Acrobat Sign nu visa en användares personaliserade e-postadress istället för den partnerregistrerade e-postadressen på användargränssnittet på viktiga ytor och meddelanden. Avtal, köer såsom ”Väntar på dig” och e-postmeddelanden för ”Granska och signera” återspeglar konsekvent den personaliserade identiteten samtidigt som den registrerade e-postadressen bevaras internt för autentisering och berättiganden. Detta förbättrar tydligheten för avsändare och signatärer och förhindrar att e-postmeddelanden skickas till ej levererbara registrerade adresser.
Tillgängliga miljöer: Sandlåda, Kommersiell | Tillgängliga tjänstenivåer: Acrobat Sign Solutions | Konfigurationsomfång: API – OEM 2.0-partner, endast på begäran
- Webhook-meddelande för fel vid SMS-leverans – insyn i realtid över misslyckade SMS-sändningar, automatiserad korrigering och paritet med studsade e-postmeddelanden.
Acrobat Sign sänder nu ut en ny webhook-händelse, AGREEMENT_PHONE_BOUNCED, när ett avtal som skickas via SMS inte kan levereras på grund av problem som ogiltiga telefonnummer, operatörsavvisning eller blockerade linjer. Detta gör det möjligt för kunder att upptäcka fel vid SMS-leveran i nästan realtid och automatiskt utlösa uppföljningsåtgärder såsom att korrigera telefonnummer, försöka leverera igen eller öppna supportärenden, vilket eliminerar blinda fläckar och minskar förseningar i mobilcentrerade signeringsarbetsflöden.
Tillgängliga miljöer: Sandlåda, Kommersiell, Myndighet Tillgängliga tjänstenivåer: Acrobat Sign Solutions Konfigurationsomfång: API
- Webhook-nyttolaster – fältet extendedStatus för villkorligt deltagande har lagts till för dynamiska deltagaruppdateringar, vilket förbättrar insynen i deltagarstatusen.
Webhook-meddelanden inkluderar nu ett extendedStatus-fält i varje deltagarobjekt (memberInfos[]) när avsändaren ändrar ett pågående avtal med dynamiskt deltagande. Detta fält ger ytterligare detaljer om deltagarlivscykeln samtidigt som det befintliga statusfältet lämnas oförändrat för bakåtkompatibilitet.
{
"participantSets": [
{
"id": "",
"memberInfos": [
{
"company": "TestCo",
"email": "signer2@someDomain.dom",
"id": "CBJCHBCAABAAJiZV9cH",
"name": "Signer Two",
"status": "ACTIVE",
"extendedStatus": "REMOVED"
}
],
"order": ,
"role": "",
"status": ""
}
]
}
status-värden (oförändrade): ACTIVE, REPLACED.
extendedStatus-värden: ACTIVE, REPLACED, REMOVED, COMPLETED.
Tillgängliga miljöer: Sandlåda, Kommersiell, Myndighet Tillgängliga servicenivåer: Acrobat Sign Solutions Konfigurationsomfång: API
Korrigerade problem
| Problem | Beskrivning |
|---|---|
| 4543515 | Sammanfattning: En webhook för studsat e-postmeddelande kan felaktigt genereras för en giltig signatär efter att denne har signerat och avtalet går vidare till nästa steg. Detta kan inträffa när en delegat i samma signeringsgrupp har en ogiltig e-postadress och avsändaren ersätter den ursprungliga delegatorn. I dessa fall kan systemet felaktigt tillskriva studshändelsen ”signerat på uppdrag av ...” till den giltiga signatären istället för deltagaren vars e-postadress faktiskt studsar. |
| Åtgärd: Logiken för händelsetillskrivning korrigerades så att e-poststudshändelser endast associeras med deltagaren vars e-postadress faktiskt studsar. En studshändelse genereras inte längre för en giltig undertecknare som redan slutfört signeringen, och webhook-meddelanden återspeglar nu rätt deltagare och e-postadress. | |
| 4544548 | Sammanfattning: Integrationsnycklar skapade genom webbanvändargränssnittet kan förfalla efter 10 år, även om skapandesidan anger att nyckeln ger ”permanent åtkomst”. När en nyckel når sin 10-åriga livslängd börjar API-anrop returnera felet Utgången token, vilket oväntat kan bryta befintliga integrationer. |
| Åtgärd: Meddelanden i användargränssnittet uppdaterades för att ta bort formuleringen ”permanent åtkomst” och tydligt visa förfallodatumet för integrationsnycklar. Den uppdaterade texten anger nu att nyckeln behåller åtkomst till förfallodatumet eller tills den återkallas manuellt, vilket påvisar den 10-åriga standardiserade livslängden. | |
| 4546301 | Sammanfattning: Leverans av webhook-händelser kan försenas med upp till flera timmar för avtal med mycket stora dokument, även när skapandet av avtalet slutförs och tidiga bearbetningssteg verkar avslutas inom några minuter. Medan fördröjningsfönstret visas kan webhook-leveranstjänsten upprepade gånger få svaret DOCUMENT_NOT_AVAILABLE när den försöker hämta avtalsdokument. Webhook-händelsen kanske därför inte levereras tills tjänsten slutar försöka igen eller dokumenten blir tillgängliga. |
| Åtgärd: Hantering av dokumenttillgänglighet korrigerades så att stora avtal på ett tillförlitligt sätt övergår till ett tillstånd där dokument kan hämtas utan utökade DOCUMENT_NOT_AVAILABLE-svar. Som resultat levereras webhook-händelser utan flera timmars förseningar orsakade av dokumenthämtningsförsök mot otillgängliga dokument. | |
| 4547823 | Sammanfattning: En mottagares privata meddelande kanske inte visas för vissa signatärer när ett avtal skapas i framtagningstillståndet via API:et och sedan redigeras från Hantera-upplevelsen. I detta scenario kan användargränssnittet visa värdet för privat meddelande som ”Inget” eller vara tomt även om avtalsdata inkluderar rätt värde för privat meddelande. Detta beteende visas i scenarier med delade konton där en användare växlar till en annan användares konto för att redigera utkastet, och det kan påverka endast specifika mottagare medan andra visas korrekt. |
| Åtgärd: En kontroll lades till för att hämta det primära delade sammanhanget och returnera det privata meddelandet för auktoriserade delade användare. Som resultat visas nu värdet för privat meddelande korrekt när man visar eller skickar ett API-skapat utkast från framtagningsflödet. | |
| 4548274 | Sammanfattning: Det ändrade datumet för biblioteksmallar kanske inte uppdateras efter att en mall har redigerats och sparats i den nya mallupplevelsen. Användare kan se nyligen tillagda eller uppdaterade fält på mallen men det ändrade datumet förblir oförändrat i Hantera-användargränssnittet och i administrativa vyer. Detta gör att det verkar som om mallen inte nyligen har ändrats. Detta inträffar eftersom den nya upplevelsen uppdaterar formulärfält genom en väg som inte också uppdaterar mallens ändrade tidsstämpel. |
| Åtgärd: Beteendet för uppdateringen av ändrat datum anpassades för den nya mallupplevelsen och relaterade API-åtgärder. Kodsökvägen som sparar mallfältändringar uppdaterar nu också mallens ändrade datum så att det återspeglar den faktiska tiden för den senaste ändringen. | |
| 4548564 | Sammanfattning: Signaturer och formulärfält kan verka osynliga i den signerade PDF:en när de placeras över redan befintliga stämpelkommentarer i källdokumentet. I påverkade mallar överlappar eller döljer stämpelkommentarerna de interaktiva fälten under bearbetning, vilket gör att slutförda signaturer och andra fält döljs i det slutliga signerade dokumentet. |
| Åtgärd: Hantering av stämpelkommentarer uppdaterades för att säkert bearbeta och platta ut redan befintliga stämpelkommentarer så att de inte längre döljer formulärfält eller signaturer. Fält som placeras över stämplade områden förblir nu synliga under signering och i den helt genomförda PDF:en. | |
| 4549103 | Sammanfattning: En e-poststudshändelse kan loggas igen för en tidigare felaktig mottagare efter att avsändaren ersätter den mottagaren med en giltig e-postadress. I vissa fall kan granskningsspåret visa en andra studshändelse för den gamla e-postadressen och avtalsstatusen kan visa ”studsat e-postmeddelande” även om den nya mottagaren tar emot, läser eller signerar avtalet. Detta beteende kan få det att verka som om avtalet fortfarande riktar sig till både den gamla och den nya e-postadressen. |
| Åtgärd: Arbetsflödet för att ersätta signerare uppdaterades för att förhindra att ytterligare aviseringsmeddelanden skickas till en ersatt mottagare vars e-post redan har studsats. Systemet kontrollerar nu tidigare studshistorik innan det skickar ersättningsrelaterade aviseringar, vilket säkerställer att inga nya studshändelser genereras för den gamla e-postadressen efter ersättning. | |
| 4549306 | Sammanfattning: Användare vars e-postadresser innehåller vissa specialtecken (till exempel apostrof) kanske inte kan logga in från de generiska adobesign.com eller echosign.com offentliga inloggningssidorna. Efter att ha angett e-postadressen och klickat i lösenordsfältet kan sidan laddas om och rensa e-postfältet istället för att omdirigera användaren till rätt shard eller SSO-inloggningssida. Detta hindrar berörda användare från att slutföra autentisering och blockerar integrationer som förlitar sig på den offentliga inloggningsslutpunkten. |
| Åtgärd: Logiken för resolutionen av login shard korrigerades för att korrekt hantera och avkoda e-postadresser som innehåller specialtecken innan omdirigerings-URL:en för inter-shard konstrueras. Användare med berörda e-postformat omdirigeras nu korrekt till sin utsedda shard och SSO-inloggningssida utan att e-postfältet rensas. | |
| 4549331 | Sammanfattning: Signaturer och andra formulärfält kan verka saknas eller vara osynliga i den signerade PDF:en när vissa dokumentbearbetningsfunktioner är aktiverade och käll-PDF:en innehåller ogiltiga sidboxkoordinater (till exempel felaktiga CropBox- eller MediaBox-värden). I detta scenario kan fält som förlitar sig på sidkoordinater renderas utanför det synliga sidområdet, vilket gör att slutförda signaturer verkar saknas även om signeringen slutförs framgångsrikt. |
| Åtgärd: PDF-sidboxhanteringen korrigerades för att säkert normalisera ogiltiga CropBox- och MediaBox-värden under dokumentbearbetning. Resultatet blir att signatur- och formulärfältens placering nu anpassas till det synliga sidområdet och signerade PDF-filer visar signaturer som förväntat. | |
| 4550367 | Sammanfattning: Att skapa ett webbformulär kan misslyckas med ett generiskt ”Serverfel” efter att Förhandsgranskning och Lägg till fält har valts när standardautentiseringen för signering för avsändarens grupp är inställd till Telefon och kontot inte har tillgänglig telefonautentiseringskvot, även om webbformulärets signeringsautentisering är inställd till en icke-telefonmetod (såsom Adobe Sign). Som resultat kan alla användare i det berörda kontot blockeras från att skapa webbformulär över alla dokument. |
| Åtgärd: Skapandet av webbformulär utvärderar nu kvoter endast för autentiseringsmetoden som faktiskt är konfigurerad för webbformulärets signatär och tillämpar inte längre kontroller av telefonautentiseringskvoter baserat enbart på inställningarna för gruppens standardautentisering. Detta förhindrar falska fel med uttömd kvot och tillåter att webbformulär skapas normalt. | |
| 4551011 | Sammanfattning: När en avsändare laddar upp vissa skannade PDF-filer, lägger till signaturfält och skickar avtalet kanske den signerade PDF-filen inte visar några synliga signaturer efter att signeringen har slutförts. Detta beteende kan inträffa när den uppladdade PDF:en innehåller ogiltig sidgränsmetadata (MediaBox- och CropBox-koordinater verkar omvända), vilket kan orsaka att signatur- och andra fältutseendelager renderas utanför det synliga sidområdet. |
| Åtgärd: Hanteringen av PDF-sidgränser har uppdaterats för att korrekt bearbeta PDF-filer med ogiltiga eller omvända MediaBox- och CropBox-koordinatvärden så att utseendet på, och innehållet i, signatur- och formulärfält renderas inom det synliga sidområdet och förblir synligt i den slutliga signerade PDF-filen. | |
| 4551427 | Sammanfattning: Vissa mottagare som redan har primära och korrekt etablerade konton får avtal som ”pseudo-användare”-mottagare istället. Avtalet visas därför inte i deras normala Hantera-vy. Detta händer när mottagarens e-postadresser inkluderar inledande eller avslutande mellanslag vilket hindrar systemet från att matcha e-postadressen till den befintliga användaren. Detta gör så att ett pseudo-användarregister skapas. |
| Åtgärd: E-postparsning och användaruppslagning uppdaterades för att normalisera mottagarens e-postadresser (trimma inledande och avslutande blanksteg) innan de matchas till befintliga användare. Resultatet blir att avtal adresserade till befintliga användare hanteras för det registrerade kontot istället för att skapa en pseudo-användarmottagare, även om e-postadressen angavs med mellanslag (i API-nyttolaster och mottagarlistor i arbetsflöden). | |
| 4553198 | Sammanfattning: När ett avtal inkluderar minst en mottagare konfigurerad för SMS-leverans och minst en mottagare konfigurerad för endast e-postleverans, skickar inte avbrytande av avtalet genom API:et en SMS-avbrytningsnotifiering till SMS-mottagaren. Avtalet avbryts framgångsrikt och e-postnotifieringar levereras, men SMS-mottagare får inte ett avbrytningsmeddelande. |
| Åtgärd: Avbrytningsarbetsflödet korrigerades för att säkerställa att SMS-avbrytningsnotifieringar skickas till alla mottagare konfigurerade för SMS-leverans när ett avtal avbryts, oavsett andra mottagares leveransmetoder. | |
| 4554463 | Sammanfattning: När avtal inkluderar klonade radioknappar som delar samma fältnamn över kombinerade dokument förblir endast en instans av det valda alternativet valt i den slutliga signerade PDF:en. Även om fälten visuellt verkar som kryssrutor implementeras de som radioknappar. Efter signering sprids inte det valda värdet konsekvent över alla klonade instanser, vilket orsakar felaktig eller ofullständig mappning av det förväntade valet. |
| Åtgärd: Logiken för hantering av formulärfält korrigerades så att klonade radioknappar lagrar och sprider det valda exporteringsvärdet istället för ett internt indexvärde. Detta säkerställer att alla klonade instanser av samma radioknappsfält återspeglar det korrekta valet i den signerade PDF-filen. | |
| 4554593 | Sammanfattning: Vissa partnerintegrationer som använder de äldre OAuth-slutpunkterna för att uppdatera åtkomsttoken började misslyckas med HTTP 401-fel. Tjänsten avvisade begäran om tokenuppdatering med ett fel som indikerade att appen inte får använda de äldre OAuth-slutpunkterna och måste använda OAuth v2-slutpunkterna istället. Detta blockerade kunder från att autentisera Acrobat Sign genom partnerprogram, även för integrationer som tidigare fungerade. |
| Åtgärd: Autentiseringstjänsten korrigerades så att partnerprogram som är konfigurerade att använda det äldre OAuth-flödet kan uppdatera sina token igen, istället för att felaktigt tvingas till OAuth v2-slutpunkterna. | |
| 4554614 | Sammanfattning: När en signatär använder den moderna eSign-upplevelsen på ett avtal som kräver signatärautentisering och är konfigurerat att kräva godkännande av användningsvillkor före signering, utlöses en 5 sekunders omdirigering till den klassiska signeringsupplevelsen när användaren klickar på Klicka för att signera. Omdirigeringsmeddelandet varnar att signaturer och initialer som anges i modern signering kommer att rensas, vilket tvingar signeraren att ange dem igen och i praktiken signera två gånger. |
| Åtgärd: Flödet för uppdatering av signeringstoken korrigerades så att när signatären godkänner användningsvillkoren före signering behåller den nyutfärdade signeringstoken informationen om signatärautentiseringen. Detta förhindrar att det slutliga signeringssteget inte kan autentiseras och eliminerar den tvingade återgången från modern signering till den klassiska upplevelsen. | |
| 4555656 | Sammanfattning: Under specifika tidsbetingelser kan en avtalsstatusövergång verka lyckas men ändrar faktiskt inte avtalsstatus. När en webhook-avisering tas emot innan backend-bearbetning slutförs kan efterföljande API-anrop använda föråldrade avtalsstatusdata. I detta fönster returnerar vissa statusövergångsmetoder HTTP 200 OK även om avtalet inte är i ett giltigt tillstånd för den begärda övergången. Som resultat kan automatiseringsarbetsflöden anta att övergången lyckades medan avtalet förblir i det ursprungliga tillståndet. |
| Åtgärd: Logiken för avtalsstatusens övergång uppdaterades för att genomdriva strikt validering innan en övergång tillämpas. Om avtalet inte är i ett giltigt tillstånd returnerar API:et nu ett tydligt felsvar istället för att returnera framgång i bakgrunden. Detta säkerställer att ogiltiga övergångar uttryckligen avvisas, gör det möjligt för anropande system att försöka igen på lämpligt sätt och förhindrar att avtal förblir i ett oavsiktligt tillstånd utan synlighet. |
