Senast uppdaterad den
24 feb. 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
- Hälsovårdskund
- 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
- 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
Versionsschema och förhandsversionsdokumentation för Adobe Acrobat Sign
Varje år lanseras minst tre versioner av Adobe Acrobat Sign, som kategoriseras som antingen större eller mindre. Ytterligare mindre uppdateringar kan införas vid behov för att lösa system- eller kundproblem.
- Större versioner innehåller betydande uppdateringar, nya funktioner och flera förbättringar.
- Mindre versioner fokuserar på mindre förbättringar och justeringar av användarupplevelsen. Dessa inträffar mellan större uppdateringar, vanligtvis en till två gånger per cykel.
För att förhindra störningar är nya funktioner inaktiverade som standard och måste aktiveras manuellt av en konto- eller gruppadministratör.
För kunder inom området Hälsa och livsvetenskap som kräver efterlevnadsvalidering, samarbetar Acrobat Sign med en tredjepartsleverantör för att tillhandahålla ett valideringspaket för varje större version som innehåller funktioner för att minimera era riskfaktorer.
Obs!
Den här sidan med Förhandsversionsinformation uppdateras regelbundet när ny information blir tillgänglig, så innehållet är relativt dynamiskt.
Även om den här sidan är lokaliserad tar processen tid, vilket kan leda till att lokaliserade versioner skiljer sig något från den auktoritativa amerikanska engelska versionen.
För den mest korrekta och uppdaterade informationen rekommenderar vi att du läser sidan på amerikansk engelska.
Adobe Acrobat Sign följer ett strukturerat schema för publicering av versionsinformation och dokumentationsuppdateringar:
8 veckor före en ny version
- Sidan för förhandsutgivna versioner publicerar en sammanfattning av förväntade funktioner och uppdateringar. Detta sker vanligtvis fyra veckor innan sandlådeversionen.
- De funktioner som läggs till eller tas bort efter denna tidpunkt noteras i avsnittet Fel.
- Lösta problem publiceras inte för närvarande.
4 veckor före produktionsversionen (Sandlådestart)
- Förhandsversionssidan är uppdaterad med detaljerad dokumentation om nya och uppdaterade funktioner.
- Länkar till förhandsutgiven supportdokumentation (endast tillgänglig på amerikansk engelska), läggs till vid behov.
- Det första avsnittet med Lösta problem publiceras, med aktuella uppdateringar under de kommande fyra veckorna.
Lanseringsdatum
- Den officiella versionsinformationen uppdateras med slutgiltiga detaljer och länkar till färdig supportdokumentation.
- Förhandsutgivningssidan uppdateras för att markera nästa versionscykel.
- Dokumentation publiceras efter versionsverifieringen i livesystemet, vanligtvis efter kl. 19.00 Pacific Time, även om komplexa uppdateringar kan ta längre tid.
- Den slutliga listan över Lösta problem läggs till i versionsinformationen (på amerikansk engelska), med lokaliserade versioner som uppdateras vid ett senare tillfälle.
Government Cloud-version
- Miljön Government Cloud uppdateras vanligtvis mellan två dagar och flera veckor efter produktionsversionen eftersom vissa funktioner kan kräva ytterligare utvärdering innan driftsättning.
Obs!
Dokumentationen för sandlåda är utformad för produktionsmiljön. Länkar som finns i förhandsinnehållet riktar sig till produktionswebbadresser, vilket innebär att dessa länkar kan leda till äldre befintlig dokumentation eller 404-resultat om målsidan är ny och inte har publicerats ännu (t.ex. när länken går till en ny funktion i samma version).
De nya sidorna publiceras när versionen publiceras, och länkarna kommer att korrekt tolkas till sina produktions-URL:er.
Sandlådetillgänglighet
Kunder som har tillgång till sandlådemiljön i Acrobat Sign får normalt tillgång till funktionaliteten i den nya versionen fyra veckor före lanseringen.
- Sandlådemiljön måste klara alla produktionsprocedurer för kvalitetskontroll på samma kvalitetsnivå som den vanliga produktionsmiljön.
- Adobe strävar efter att ha 99,9 % tillgänglighet i sandlådemiljön, men kunder bör tänka på att Adobes enhetliga SLA täcker inte formellt sandlådan.
- Sandlådemiljön använder samma statussida och driftstoppsprocedurer som den vanliga produktionsmiljön.
Varning:
Den här artikeln innehåller information om förhandsversion. Lanseringsdatum, funktioner och annan information kan ändras utan föregående meddelande.
Adobe Acrobat Sign frigöra v17.0.1
Sandbox-distribution: 17 februari 2026
Produktionsdistribution: 17 mars 2026
GovCloud-distribution: 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år 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 starta om från början.
Den här funktionen kommer att vara tillgänglig i Sandbox-miljön den 20 februari 2026.
Obs: Med den här versionen kommer de administrativa kontrollerna för att inaktivera den här funktionen att tas bort från administratörsmenyn, vilket etablerar Skapa en kopia som en standard-funktion tillgänglig för alla berättigade användare.
- Tillgängliga miljöer: Sandbox, Commercial, Government | Tillgängliga tjänstenivåer: acrobat sign Solutions | Konfigurationsomfång: Konto och grupp; Aktiverat som standard.
Granska den uppdaterade dokumentationen för användaråtgärder >
Uppdateringar för REST API/webhook
Nedanstående uppdateringar presenteras i förhandsversionsinformationen i informationssyfte. Fullständig dokumentation för API- och webhookuppdateringar finns i Acrobat Sign-utvecklardokumentation när versionsuppdateringen levereras till produktionsservrarna.
- OEM 2.0 personlig e-postadress-visning – Tydligare avsändar- och mottagaridentitet i inbäddade upplevelser och korrekt e-postadress-leverans.
För OEM 2.0-partners som använder inbäddade flöden visar acrobat sign nu en användares personliga e-postadress istället för den partnerregistrerade e-postadressen över viktiga användargränssnittsytor och notifieringar. Avtal, köer som "Väntar på dig" och "Granska och signera" e-postadresser återspeglar konsekvent den personliga identiteten samtidigt som den registrerade e-postadressen bevaras internt för autentisering och rättigheter. Detta förbättrar tydligheten för avsändare och undertecknare och förhindrar att e-postmeddelanden skickas till icke-levererbara registrerade adresser.
Tillgängliga miljöer: Sandbox, Commercial | Tillgängliga tjänstenivåer: acrobat sign Solutions | Konfigurationsomfång: API - Endast OEM 2.0-partners
- Webhook-notifiering för SMS-leveransfel – Realtids-synlighet av misslyckade SMS-sändningar, automatiserad reparation och paritet med e-postadress-studsar.
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 SMS-leveransfel i nästan realtid och automatiskt utlösa uppföljningsåtgärder som att korrigera telefonnummer, försöka leverera igen eller öppna supportärenden, vilket eliminerar blinda fläckar och minskar förseningar i mobilfokuserade signeringsarbetsflöden.
Tillgängliga miljöer: Sandbox, Commercial, Government | Tillgängliga tjänstenivåer: acrobat sign Solutions | Konfigurationsomfång: API
- Webhook-nyttolaster – Lagt till villkorligt extendedStatus-fält för deltagare för dynamiska deltagaruppdateringar, vilket förbättrar synligheten för deltagarstatus.
Webhook-aviseringar inkluderar nu ett extendedStatus-fält i varje deltagare (memberInfos[])-objekt när avsändaren ändrar ett pågående avtal med dynamiskt deltagande. Detta fält ger ytterligare detaljer om deltagarens livscykel samtidigt som det befintliga status-fä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": "primär",
"extendedStatus": "REMOVED"
}
],
"order": ,
"role": "",
"status": ""
}
]
}
- status-värden (oförändrade): primär, REPLACED.
- extendedStatus-värden: primär, REPLACED, REMOVED, COMPLETED.
Tillgängliga miljöer: Sandbox, Commercial, Government | Tillgängliga tjänstenivåer: acrobat sign Solutions | Konfigurationsomfång: API
Versionsfel
Det finns för närvarande inga objekt som har flyttats från den här versionen.
Korrigerade problem
| Problem | Beskrivning |
|---|---|
| 4543515 | Sammanfattning: En webhook-händelse för e-poststuds kan felaktigt genereras för en giltig undertecknare efter att undertecknaren framgångsrikt undertecknat och avtalet går vidare till nästa steg. Detta kan inträffa när en delegat i samma undertecknargrupp har en ogiltig e-postadress och avsändaren ersätter den ursprungliga delegatorn. I dessa fall kan systemet felaktigt tillskriva "undertecknad på uppdrag av..."-studshändelsen till den giltiga undertecknaren 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 undertecknandet, och webhook-notifieringar återspeglar nu rätt deltagare och e-postadress. | |
| 4544548 | Sammanfattning: Integrationsnycklar skapade genom webbanvändargränssnittet kan löpa ut efter 10 år, även om skapandesidan anger att nyckeln ger "permanent åtkomst." När en nyckel når sin 10-åriga livstid börjar API-anrop returnera ett utgånget token-fel, vilket kan bryta befintliga integrationer oväntat. |
| Åtgärd: Användargränssnittsmeddelandet uppdaterades för att ta bort formuleringen "permanent åtkomst" och tydligt visa utgångsdatumet för integrationsnycklar. Den uppdaterade texten anger nu att nyckeln behåller åtkomst till utgångsdatumet eller tills den manuellt återkallas, vilket ger genomskinlighet om den 10-åriga standardlivstiden. | |
| 4546301 | Sammanfattning: Webhook-händelseleverans kan försenas med upp till flera timmar för avtal med mycket stora dokument, även när avtalskapandet slutförs och tidiga bearbetningssteg verkar slutföras inom minuter. Under fördröjningsfönstret kan webhook-leveranstjänsten upprepade gånger få DOCUMENT_NOT_AVAILABLE-svar när den försöker hämta avtalsdokument, och webhook-händelsen kanske inte levereras förrän tjänsten slutar försöka igen eller dokumenten blir tillgängliga. |
| Åtgärd: Dokumenttillgänglighetshanteringen 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 flertimmarsförseningar orsakade av dokumenthämtningsförsök mot otillgängliga dokument. | |
| 4547823 | Sammanfattning: En mottagares privata meddelande kanske inte visas för vissa undertecknare när ett avtal skapas i framtagningstillståndet genom API:et och sedan redigeras från hanteringsupplevelsen. I det här scenariot kan användargränssnittet visa värdet för privat meddelande som "Inget" eller tomt även om avtalsdata inkluderar rätt privata meddelandevärde. Detta beteende visas i scenarier med delat konto 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 delningskontextet 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 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 hanteringsanvändargränssnittet och i administrativa vyer, vilket gör att det verkar som om mallen inte nyligen ä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 uppdatering av ändringsdatum anpassades mellan den nya mallupplevelsen och relaterade API-operationer. Kodvägen som sparar mallfältändringar uppdaterar nu också mallens ändringsdatum så att det återspeglar den faktiska tiden för den senaste ändringen. | |
| 4548564 | Sammanfattning: Signaturer och formulärfält kan verka osynliga i det signerade pdf:et när de placeras över befintliga Stämpel-kommentarer i källdokumentet. I berörda mallar överlappar eller döljer Stämpel-kommentarerna de interaktiva fälten under bearbetar, vilket gör att slutförda signaturer och andra fält döljs i det slutgiltiga signerade dokumentet. |
| Åtgärd: Hanteringen av Stämpel-kommentarer uppdaterades för att säkert bearbetar och platta ut befintliga Stämpel-kommentarer 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 det fullständigt genomförda pdf:et. | |
| 4549103 | Sammanfattning: En e-poststuds-hä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 studs-händelse för den gamla e-postadressen, och avtalets status kan återspegla "e-post studsade" även om den nya mottagaren framgångsrikt tar emot, visar eller signerar avtalet. Detta beteende kan få det att verka som om avtalet fortfarande riktar sig till både den gamla och nya e-postadressen. |
| Åtgärd: Arbetsflödet för att ersätta signerare uppdaterades för att förhindra att ytterligare notifieringsmeddelanden skickas till en ersatt mottagare vars e-post redan har studsats. Systemet kontrollerar nu tidigare studshistorik innan ersättningsrelaterade notifieringar skickas, vilket säkerställer att inga nya studs-händelser genereras för den gamla e-postadressen efter ersättning. | |
| 4549306 | Sammanfattning: Användare vars e-postadresser innehåller vissa specialtecken (till exempel en 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 förhindrar 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 inloggnings-shard-upplösning korrigerades för att korrekt hantera och avkoda e-postadresser som innehåller specialtecken innan inter-shard-omdirigerings-URL:en 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 det signerade pdf:et när vissa dokumentbearbetningsfunktioner är aktiverade och käll-pdf:et innehåller ogiltiga sidboxkoordinater (till exempel felaktiga CropBox- eller MediaBox-värden). I detta scenario kan fält som förlitar sig på sidkoordinater rendera utanför det synliga sidområdet, vilket gör att slutförda signaturer verkar saknas även om signeringen slutförs framgångsrikt. |
| Åtgärd: Hanteringen av pdf-sidboxar korrigerades för att säkert normalisera ogiltiga CropBox- och MediaBox-värden under dokumentbearbetning. Som resultat anpassas nu signatur- och formulärfältplacering till det synliga sidområdet, och signerade pdf:er visar signaturer som förväntat. | |
| 4550367 | Sammanfattning: Att skapa ett webbformulär kan misslyckas med ett generiskt "server-fel" efter att ha valt förhandsgranskning och Lägg till fält när avsändarens grupps standardsignerarautentisering är inställd på Telefon och kontot inte har tillgänglig telefonautentiseringskvot, även om webbformulärets signerarautentisering är inställd på en icke-telefonmetod (till exempel 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 kvot endast för den autentiseringsmetod som faktiskt är konfigurerad för webbformulärets signerare, och den tillämpar inte längre telefonautentiseringskvotskontroller baserat enbart på gruppens standardautentiseringsinställning. Detta förhindrar falska kvotutmattningsfel 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 kan den signerade PDF-filen inte visa några synliga signaturer efter att signeringen är klar. Detta beteende kan inträffa när den uppladdade PDF-filen innehåller ogiltig metadata för sidgränser (MediaBox- och CropBox-koordinater verkar omvända), vilket kan göra att signatur- och andra fältutseendelager renderas utanför det synliga sidområdet. |
| Åtgärd: Hanteringen av PDF-sidgränser är uppdaterad för att korrekt bearbeta PDF-filer med ogiltiga eller omvända MediaBox- och CropBox-koordinatvärden, så att signatur- och formulärfältutseendeinnehåll 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, korrekt konfigurerade konton får avtal som "pseudo-användare"-mottagare istället, så avtalet visas inte i deras normala Hantera-vy. Detta händer när mottagarens e-postadresser innehåller inledande eller avslutande mellanslag, vilket förhindrar systemet från att matcha e-postadressen med den befintliga användaren och orsakar att en pseudo-användarpost skapas. |
| Åtgärd: E-postanalys och användarsökning uppdaterades för att normalisera mottagarens e-postadresser (trimma inledande och avslutande blanksteg) innan de matchas med befintliga användare. Som resultat löses avtal adresserade till befintliga användare till det registrerade kontot istället för att skapa en pseudo-användarmottagare, även om e-postadressen angavs med mellanslag (i API-nyttolaster och arbetsflödemottagarlistor). | |
| 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 annullering av avtalet genom API:et en SMS-annulleringsnotifiering till SMS-mottagaren. Avtalet annulleras framgångsrikt och e-postnotifieringar levereras, men SMS-mottagare får inte ett annulleringsmeddelande. |
| Åtgärd: Annulleringsarbetsflödet korrigerades för att säkerställa att SMS-annulleringsnotifieringar skickas till alla mottagare konfigurerade för SMS-leverans när ett avtal annulleras, 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-filen. Ä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: Formulärfälthanteringslogiken korrigerades så att klonade radioknappar lagrar och sprider det valda export-värdet snarare än ett internt indexvärde. Detta säkerställer att alla klonade instanser av samma radioknappfä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 åtkomst-token började misslyckas med HTTP 401-fel. Tjänsten avvisade token-uppdateringsbegäranden 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 framgångsrikt kan uppdatera token igen, istället för att felaktigt tvingas till OAuth v2-slutpunkterna. | |
| 4554614 | Sammanfattning: När en signerare använder den moderna eSign-upplevelsen på ett avtal som kräver signerarautentisering och är konfigurerat att kräva acceptans av användningsvillkor före signering, utlöser klickning på Klicka för att signera en 5-sekunders omdirigering till den klassiska signeringsupplevelsen. Omdirigeringsmeddelandet varnar att signaturer och initialer som angivits i modern signering kommer att rensas, vilket tvingar signeraren att ange dem igen och effektivt signera två gånger. |
| Åtgärd: Signeringstoken-uppdateringsflödet korrigerades så att när signeraren accepterar användningsvillkoren före signering, behåller det återutfärdade signeringstoken signerarautentiseringsdetaljerna. Detta förhindrar att det slutliga signeringssteget misslyckas med autentisering 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-notifiering tas emot innan backend-bearbetning slutförs, kan efterföljande API-anrop använda föråldrad avtalsstatus-data. I det här fönstret returnerar vissa metoder för tillståndsövergångar HTTP 200 OK även om avtalet inte är i ett giltigt tillstånd för den begärda övergången. Som ett resultat kan automatiseringsarbetsflöden anta att övergången lyckades medan avtalet förblir i det ursprungliga tillståndet. |
| Åtgärd: Logiken för avtalsövergångar 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 tyst returnera framgång. 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. |
