Zuletzt aktualisiert am
17. Juni 2026
Adobe Acrobat Sign Versionshinweise: 2026
Adobe Acrobat Sign Version v17.0
Produktionsbereitstellung: 3. Februar 2026
GovCloud-Bereitstellung: 10. Februar 2026
Verbesserte Funktionalität
- Gruppierte Kontrollkästchen in Authoring und in Vorlagen – Sendende Parteien können über moderne Authoring-Umgebungen jetzt für Signaturanfragen und Bibliotheksvorlagen Kontrollkästchengruppen mit Validierungsregeln erstellen. Darunter beispielsweise die folgenden Optionen: exakt auswählen, mindestens, höchstens oder ein Bereich von X aus Y. Massenversand, Webformulare und Benutzerdefinierte Workflows werden durch die Verwendung von Bibliotheksvorlagen unterstützt. Diese Verbesserung gewährleistet konsistente Formularlogik und verbessert die Datengenauigkeit bei Signatur-Workflows.
- Zulässige IP-Bereiche – Erweiterte Steuerung über API- und Mobile-Zugriff - Administratoren können jetzt explizit steuern, ob IP-Beschränkungen für API-basierte Clients gelten, einschließlich Acrobat Sign Mobile-Anwendungen und zertifizierte Integrationen.
- Authentifizierungsunterstützung für modernes E-Signieren – Modernes E-Signieren unterstützt jetzt drei Authentifizierungsmethoden: Acrobat Sign-Authentifizierung, Passwort und telefonbasierte 2FA.
- Hinzufügen von Empfangsgruppen im Hybrid-Routing für modernes Signatur anfordern – Empfangsgruppen können jetzt im Hybrid-Routing eingebunden werden, sodass mehrere Empfangende oder Gruppen parallel innerhalb desselben Routing-Schritts agieren können. Gruppenmodi unterstützen entweder ein oder alle Mitglieder beim Abschließen der Aktion und bieten so mehr Flexibilität für komplexe Genehmigungs- und Signatur-Workflows.
- Vereinbarungen im Endstatus kopieren, die gesendet wurden von Signaturanfrage – Sendende Parteien können jetzt einen neuen Vereinbarungsentwurf erstellen, indem sie eine zuvor abgeschlossene, stornierte oder abgelaufene Vereinbarung kopieren. Alle Empfangenden, Einstellungen, Dateien und Formularfelder werden automatisch vorausgefüllt. Die kopierte Vereinbarung wird auf der Seite Erstellen geöffnet, um schnelle Bearbeitungen vor dem Versenden vorzunehmen. Außerdem spart dies Zeit bei der Einrichtung, minimiert Fehler und verbessert die Produktivität bei sich wiederholenden Workflows wie Verlängerungen oder Korrekturen.
- Deaktiviere den Vereinbarung herunterladen -Link für laufende Vereinbarungen – Administratoren können jetzt den „Kopie herunterladen"-Link von Bestätigungsseiten nach der Signatur auf Account- oder Gruppenebene entfernen und verhindern, dass Empfänger Vereinbarungen von der Post-Sign-Seite herunterladen.
- Registerkarte Ressourcen in der oberen Navigation – Eine neue Seite Ressourcen ist in der oberen Navigation für Admins und Benutzende verfügbar und bietet direkten Zugriff auf Schulungsinhalte, Webinare, Blogs und Produktaktualisierungsvideos zu Acrobat Sign. Die Seite organisiert Anleitungen nach Benutzerebene – Anfänger, erfahren und Administrator – und verknüpft direkt mit zusätzlicher Dokumentation.
- Dynamische Teilnahme für laufende Vereinbarungen – Empfangende entfernen – Sendende Parteien können jetzt Empfangende aus bereits laufenden Vereinbarungen entfernen, ohne die Transaktion abzubrechen oder neu zu starten. Wenn eine empfangende Partei entfernt wird, widerruft Acrobat Sign automatisch deren Zugriff, aktualisiert Erinnerungen und Prüfprotokolle, entfernt die zugewiesenen Felder und setzt die Vereinbarung nahtlos in ihren aktiven Signatur-Zustand zurück. Diese Flexibilität hilft Organisationen dabei, die Genauigkeit in Live-Routing-Workflows zu erhalten – etwa wenn eine signierende Person nicht verfügbar ist – während die rechtliche Integrität, Compliance und ein vollständiges Audit-Protokoll bewahrt werden.
- Digitale Signaturen für einzelne Empfangende während der Vereinbarungskonfiguration erforderlich: Sendende können jetzt digitale Signaturen für ausgewählte Empfangende verlangen und so strengere Signaturanforderungen sicherstellen, wo sie benötigt werden, ohne andere Empfangende zu beeinträchtigen. Das Signaturerlebnis passt sich automatisch an, erzwingt erforderliche Felder für digitale Signaturen und stellt Identitätsprüfungen bereit, sofern unterstützt, wodurch Fehler reduziert und die Compliance für regulierte Workflows verbessert wird.
- Anbietende von digitalen Identitäten als Standard-Authentifizierungsmethoden –Admins können jetzt in den Sendeeinstellungen einen „Digital Identity Gateway“-Anbietenden als Standard-Authentifizierungsmethode für Unterzeichnende für interne und externe Empfangende auswählen. Die Konfiguration wird automatisch auf Vereinbarungen, Webformulare, Massenversand und Workflows angewendet und gewährleistet eine einheitliche und konforme Empfängerverifizierung. Diese Verbesserung vereinfacht das Authentifizierungs-Setup, setzt organisatorische Identitätsrichtlinien durch und verbessert die Unterstützung für Regierungsorganisationen und Unternehmenskunden, die auf Digital Identity-basierte Authentifizierung angewiesen sind.
- Verifizierte Formularfelder mit identitätsgeprüften Daten – Die Autorin oder der Autor des Formulars kann jetzt verifizierte Formularfelder erstellen, die automatisch mit Daten ausgefüllt werden, die während der Unterzeichnerauthentifizierung von einem Identitätsanbieter (wie OneID) zurückgegeben werden. Diese Felder können als schreibgeschützt oder bearbeitbar festgelegt werden, wodurch sichergestellt wird, dass verifizierte Identitätsdaten genau erfasst und optional gegen Bearbeitungen gesperrt werden (z. B. Name, Adresse oder Kontonummer). Dies stärkt die Identitätssicherheit, reduziert manuelle Eingabefehler und optimiert die Compliance für Workflows, die validierte Unterzeichner-Daten erfordern.
- Empfangsgruppen in CSV-Datei für Massenversand – Sendende Parteien können jetzt Empfangsgruppen direkt in der Massenversand-CSV-Datei definieren, wodurch mehrere Empfangende im selben Routing-Schritt agieren können. Jede Gruppe kann im Modus EINZELN oder ALLE konfiguriert werden – wobei entweder ein Mitglied oder alle Mitglieder ihre Aktion abschließen müssen, bevor das Routing fortschreitet. Gruppendefinitionen, Gültigkeitsprüfung und Prüf-Tracking werden pro CSV-Zeile verarbeitet, wobei Fehler über herunterladbare Validierungsdateien gemeldet werden.
- Bibliotheksvorlage – Freigabe für mehrere Gruppen – Das moderne Erlebnis Bibliotheksvorlage erstellen unterstützt jetzt die Freigabe von Vorlagen für mehrere Gruppen innerhalb eines Kontos und entspricht damit der Funktionalität, die zuvor im klassischen Workflow verfügbar war. Benutzende können beim Erstellen oder Bearbeiten einer Vorlage eine oder mehrere Gruppen auswählen, um ein einheitliches Verhalten über alle Gruppen hinweg sicherzustellen. Diese Verbesserung eliminiert den Rückfall auf das klassische Erlebnis, verbessert die Zusammenarbeit und vereinfacht die Vorlagenverwaltung für Organisationen mit mehreren Gruppen.
- Dateianhänge für alle Empfangenden mit digitalen Signaturen – Alle Empfangenden in einem digital signierten Workflow können jetzt Dateien anhängen (nicht nur der bzw. die erste Unterzeichner*in). Eine neue Anhängemethode mit Büroklammer-Anmerkungen zeigt ein sichtbares Büroklammer-Symbol im Dokument an und bleibt weiterhin mit mehreren digitalen Signaturen kompatibel. Jeder Anhang wird hinzugefügt, bevor die digitale Signatur des Unterzeichners bzw. der Unterzeichnerin angewendet wird, wodurch die Signatur-Gültigkeit erhalten bleibt und eine klare visuelle Anzeige der angehängten Dateien angegeben wird. Diese Verbesserung erhöht die rechtliche Integrität, Transparenz und Konsistenz bei E-Signatur- und digitalen Signatur-Workflows.
Änderungen der Experience
- Workflow-Vereinbarungs-Stornierungsbenachrichtigungen – Stornierungsbenachrichtigung wurde aktualisiert, um das Workflow-Verhalten widerzuspiegeln.
Beim Abbrechen einer Workflow-erstellten Vereinbarung wird das Kontrollkästchen „Empfänger benachrichtigen" nicht mehr angezeigt. Benachrichtigungen werden immer basierend auf den Einstellungen des Workflows gesendet. Diese Änderung passt die Nachricht an, um dieses Verhalten in der Stornierungsherausforderung widerzuspiegeln.
- Verbesserungen der Anmeldeseite – Die Anmeldeseite von Acrobat Sign ist jetzt übersichtlicher und einheitlicher. Sobald du deine E-Mail-Adresse eingibst, erkennt die Seite automatisch deinen Kontotyp und leitet dich zur richtigen Anmeldemethode weiter – unnötige Schritte und veraltete Bildschirme entfallen. Das macht die Anmeldung für alle schneller, einfacher und intuitiver.
- Neues E-Mail-Format für Anwendende von Acrobat Sign Enterprise, die sich direkt in die Web-Oberfläche einloggen – Acrobat Sign setzt jetzt ein Limit von 64 Zeichen für den lokalen Teil einer E-Mail-Adresse (der Teil vor dem „@“-Symbol) durch, wenn eine bestehende E-Mail-Adresse bearbeitet wird oder sich jemand neu registriert.
Alle Benutzenden mit einem lokalen Teil über 64 Zeichen wurden bewertet und als inaktiv oder Test-Benutzer-IDs eingestuft.
- Neues E-Mail-Format für Anwendende von Acrobat Sign Enterprise, die sich direkt in die Web-Oberfläche einloggen – Acrobat Sign setzt jetzt ein Limit von 64 Zeichen für den lokalen Teil einer E-Mail-Adresse (der Teil vor dem „@“-Symbol) durch, wenn eine bestehende E-Mail-Adresse bearbeitet wird oder sich jemand neu registriert.
Beachte, dass dieses Erlebnis durch ein Rolling Release basierend auf der Acrobat Sign Server-Umgebung bereitgestellt wird.Der Rollout-Zeitplan wird in der technischen Benachrichtigung Aktualisiertes Anmeldeerlebnis veröffentlicht.
- Aktivierung der Verwaltung von Benutzerdetails für inaktive Benutzende –Admins können jetzt Benutzerdetails für inaktive Benutzende direkt in der Admin-Benutzeroberfläche und über CSV-Uploads bearbeiten, ohne die Konten zu reaktivieren. Dies umfasst die Aktualisierung von Gruppenzuweisungen (für Konfigurationen mit einer einzelnen Gruppe oder mit mehreren Gruppen), die Verwaltung des Attributs „Benutzende können Dokumente signieren“ und die Durchführung von Massenbearbeitungen zwecks Konformität und Führen von Aufzeichnungen. Die Änderung optimiert das Enterprise-User-Lifecycle-Management, reduziert den administrativen Aufwand und unterstützt eine sauberere Gruppenorganisation und DSGVO-konforme Datensatzbehandlung.
Behobene Probleme
| Problem | Beschreibung |
|---|---|
| 4528600 | Zusammenfassung: Einstellungen für die Feldgültigkeitsprüfung funktionieren nicht, wenn eine Formularfeldebene an einen benutzerdefinierten Workflow angehängt ist. Validierungsregeln wie Regex oder numerische Bereichsbegrenzungen werden entfernt, wenn der Workflow gestartet wird, wodurch Felder ungültige Eingaben akzeptieren. |
| Fehlerbehebung: Gültigkeitsprüfungsregeln werden jetzt korrekt angewendet, wenn Formularfeldebenen in benutzerdefinierten Workflows enthalten sind. Felder behalten ihr Validierungsverhalten sowohl in der klassischen als auch in der neuen Authoring-Umgebung bei. Es sind keine Maßnahmen von Benutzenden erforderlich. | |
| 4528748 | Zusammenfassung: Admins sehen gelegentlich einen „Unbehandelten Fehler“, wenn sie neu synchronisierten Benutzenden (Azure-Synchronisation) eine Gruppenmitgliedschaft hinzufügen. Bei einigen neuen Benutzenden in der Gruppe ist die Gruppen-ID festgelegt auf Null |
| Lösung: Wenn die Gruppe eines Benutzenden nach der Erstellung null ist, wird diese Person in die Standardgruppe des Kontos zugeordnet. | |
| 4529934 | Zusammenfassung: In Verwalten > Webformulare, „Formularfelddaten herunterladen“ lädt dauerhaft und wird nie fertig – besonders bei Webformularen mit vielen Einreichungen. Teams-Kunden ohne API-Zugriff können keine Daten (z. B. 1.–31. Mai) für das Reporting exportieren |
| Fehlerbehebung: Paginierter, schnellerer CSV-Export in der Benutzeroberfläche hinzugefügt. Formulardaten-Downloads werden für ausgewählte Datumsbereiche zuverlässig und ohne Hängenbleiben abgeschlossen. | |
| 4532186 | Zusammenfassung: In der neuen Authoring-Umgebung entspricht die Farbhervorhebung von Feldern nicht dem Verhalten des klassischen Authorings. Wenn mehrere Empfangende beteiligt sind, bleiben alle Felder vollständig eingefärbt, anstatt die Felder nicht ausgewählter Empfangenden abzudunkeln. Das macht es schwierig, Feldzuweisungen zu überprüfen. |
| Fehlerbehebung: Die visuelle Klarheit wurde wiederhergestellt, indem Felder, die zu nicht ausgewählten Empfangenden gehören, abgedunkelt wurden (20 % Deckkraft). Dies repliziert die Klarheit des klassischen Authorings und bewahrt gleichzeitig das moderne Designsystem. Die Hervorhebung hilft Benutzenden jetzt dabei, die Felder des aktuell ausgewählten Empfangenden einfach zu identifizieren und reduziert das Risiko einer falschen Zuordnung. | |
| 4534061 | Zusammenfassung: Der Link „Kopie herunterladen“ wird auf der Bestätigungsseite nach der Unterzeichnung angezeigt, auch wenn die Konto- oder Gruppeneinstellung so konfiguriert ist, dass er deaktiviert wird. |
| Fehlerbehebung: Eine neue Einstellung wurde hinzugefügt, um die Option zum Herunterladen auf allen Seiten nach dem Posten explizit zu unterdrücken. Die Seite nach dem Posten respektiert jetzt korrekt die Herunterladen-Steuerungseinstellung und blendet den Link „Kopie herunterladen“ aus, wenn die Einstellung deaktiviert ist. | |
| 4536347 | Zusammenfassung: In der klassischen Erfahrung konnten Sendende keine zweite Datei hinzufügen (oder das Hinzufügen einer Datei wiederholen), wenn sie bestimmte Workflows starteten, was das Senden von Multi-Dokument-Workflows blockierte, aufgrund eines Fehlers in der Art, wie die Dateiauswahl mit Vorlagen umging, die über mehrere Gruppen hinweg geteilt wurden. |
| Fehlerbehebung: Die Behandlung von Vorlagen, die über mehrere Gruppen hinweg geteilt werden, durch die Dateiauswahl wurde korrigiert, sodass Benutzende zusätzliche Dateien hinzufügen oder die Dateiauswahl in der klassischen Benutzeroberfläche ohne Fehler wiederholen können. | |
| 4537504 | Zusammenfassung: Ein bedingter Dropdown-Wert fehlte im signierten Dokument, obwohl er während der Signatur korrekt ausgewählt wurde. Dies lag daran, dass die Sichtbarkeitslogik gegen ein ausgeblendetes abhängiges Feld evaluierte und den gerenderten Wert nicht in der finalen signierten PDF beibehielt. |
| Fehlerbehebung: Das bedingte Feld-Rendern wurde aktualisiert, um Sichtbarkeitsabhängigkeiten zum Zeitpunkt der Signatur korrekt aufzulösen und den ausgewählten Dropdown-Wert im signierten Dokument beizubehalten, wenn die Bedingungen erfüllt sind. | |
| 4537995 | Zusammenfassung: In Empfangsgruppen wurde die Authentifizierungsmethode für externe Benutzende nach dem Speichern auf Telefon zurückgesetzt, wodurch E-Mail-OTP nicht angewendet werden konnte. Dies lag an einem Frontend-Statusbehandlungsfehler, der die Benutzerauswahl überschrieb. |
| Fehlerbehebung: Die Benutzeroberflächen-Logik der Empfängergruppe wurde korrigiert, um die ausgewählte Authentifizierungsmethode bei Speichervorgängen ordnungsgemäß beizubehalten und erneut anzuwenden. Dadurch wird der gewählte Wert beibehalten, anstatt auf die Standardeinstellung zurückgesetzt zu werden. | |
| 4539214 | Zusammenfassung: In benutzerdefinierten Workflows führt eine lange Nachrichtenbeschriftung dazu, dass der Nachrichtentext den Hyperlink der Nachrichtenvorlage auf der Senden-Seite überlappt und verdeckt. Dies liegt an der unsachgemäßen Layout-Behandlung übermäßiger Beschriftungsinhalte. |
| Fehlerbehebung: Die Layout-Logik der Senden-Seite wurde aktualisiert, um lange Nachrichtenbeschriftungen korrekt zu begrenzen und umzubrechen, sodass der Hyperlink der Nachrichtenvorlage sichtbar und zugänglich bleibt. | |
| 4539854 | Zusammenfassung: Einige Unterzeichnende werden vom Signaturerlebnis weggeleitet, wenn sie bestimmte Vereinbarungen öffnen. Dies liegt an einem fehlerhaften Verknüpfungsfeld im zugrunde liegenden Dokument, dem ein erforderliches Namensattribut fehlt. |
| Fehlerbehebung: Der Signaturfluss behandelt jetzt unbenannte Verknüpfungsfelder korrekt, indem er zur Verarbeitung einen gültigen Namen zuweist. Dies verhindert Fehler und ermöglicht es Unterzeichnenden, Vereinbarungen ohne Umleitung abzuschließen. | |
| 4539858 | Zusammenfassung: Auf iOS-Geräten können Genehmigende, die die chinesische Handschrift-Tastatur verwenden, die Genehmigung nicht abschließen, da die Genehmigen-Schaltfläche nach der Eingabe ihres Namens deaktiviert bleibt. Dies liegt daran, dass die Signaturseite Handschrift-Eingabeereignisse nicht als gültige Texteingabe erkennt. |
| Fehlerbehebung: Die Eingabeverarbeitungslogik wurde aktualisiert, um handschriftbasierte Texteingaben auf iOS zu erkennen und sicherzustellen, dass die Genehmigen-Schaltfläche korrekt aktiviert wird, sobald gültige Zeichen eingegeben werden. | |
| 4540392 | Zusammenfassung: Admins sehen zeitweise HTTP 400-Fehler und Empfangsgruppen erscheinen in Workflows als fehlend, obwohl die Gruppen existieren und der Zugriff korrekt konfiguriert ist. Dies liegt daran, dass Request-Header die Header-Größenbegrenzung der Plattform überschreiten, wenn Benutzende zu einer großen Anzahl von Gruppen gehören. |
| Fehlerbehebung: Das serverseitige Anfrage-Header-Größenlimit wurde erhöht, sodass Empfangsgruppen-Lookups nicht mehr fehlschlagen, wenn Benutzende viele Gruppenmitgliedschaften haben. | |
| 4541258 | Zusammenfassung: Admins konnten nur die ersten 100 Vorlagen in der Produktions- oder Sandbox-Sync-Benutzeroberfläche sehen, wobei zusätzliche Vorlagen in den lokalen und Remote-Listen fehlten, da die Sync-Seite einen begrenzten Datensatz lud und die Suchfunktion nur bereits im Browser geladene Vorlagen filterte. |
| Fehlerbehebung: Die Synchronisierungsoberfläche wurde aktualisiert, sodass die Texteingabe im Suchfeld alle Vorlagen für die ausgewählte Umgebung lädt (bis zu 5.000) und sicherstellt, dass Vorlagen über die ersten 100 hinaus für die Suche und Auswahl verfügbar sind | |
| 4541739 | Zusammenfassung: Ersetzte Empfangende wurden für die digitale Signatur gesperrt und erhielten die Meldung „Die Vereinbarung kann nicht digital signiert werden, da sie sich nicht in der Phase der digitalen Signatur befindet“, da der Workflow zukünftige ersetzte Unterzeichnende nicht in die Phase der digitalen Signatur überführte, wenn Felder für digitale Signaturen vorhanden waren. |
| Fehlerbehebung: Der Signatur-Workflow wurde aktualisiert, um ersetzte oder delegierte Empfangende korrekt in die digitale Signaturphase zu überführen, wenn Felder für digitale Signatur vorhanden sind. So können sie signieren und die Vereinbarung abschließen. | |
| 4541849 | Zusammenfassung: Einzeilige Textfelder mit automatischer Schriftgröße, die mit Multibyte-Zeichen vorausgefüllt waren, wurden in signierten PDFs abgeschnitten. Ein Teil des Textes wurde aufgrund einer fehlerhaften Textgröße während der PDF-Darstellung abgeschnitten. |
| Fehlerbehebung: Korrektur der Textmessung und des automatischen Schriftgrößenverhaltens für Multibyte-Zeichen, sodass der gesamte Wert ohne Abschneiden in das Feld passt. | |
| 4542574 | Zusammenfassung: Die Bearbeitung einer Bibliotheksvorlage ermöglichte es, dass erforderliche Dropdown-Felder ungepaarte Werte enthalten konnten, wodurch die Schaltfläche „Zum Signieren klicken“ während der Signatur nicht verfügbar blieb, wenn diese Werte ausgewählt wurden. Dies lag an einer fehlenden Validierung, die sicherstellte, dass Dropdown-Anzeigewerte und Exportwerte korrekt gepaart blieben. |
| Fehlerbehebung: Die Vorlagen-Bearbeitung erzwingt jetzt eine Gültigkeitsprüfung bei Dropdown-Feldern, sodass nur ordnungsgemäß gepaarte Werte gespeichert werden können. Dies verhindert ungepaarte Einträge und stellt sicher, dass erforderliche Dropdown-Auswahlen das Signieren nicht blockieren. | |
| 4542942 | Zusammenfassung: In Webformularen zeigten erforderliche Felder, die durch bedingte Logik deaktiviert wurden, weiterhin das Pflichtfeld-Sternchen an. Dies führte Unterzeichnende in die Irre, da sie dachten, eine Eingabe sei noch erforderlich. Der Grund war, dass die Benutzeroberfläche die Pflichtfeld-Indikatoren nicht aktualisierte, wenn Felder deaktiviert wurden. Ein separates Problem mit der Ausrichtung mobiler Signaturen wurde identifiziert, jedoch in einem anderen Zusammenhang behandelt. |
| Fehlerbehebung: Die Benutzeroberfläche des Webformulars blendet nun das erforderliche Sternchen aus, wenn ein Feld durch bedingte Logik deaktiviert ist. Dadurch wird sichergestellt, dass die erforderlichen Indikatoren genau widerspiegeln, ob eine Eingabe durch den Unterzeichnenden erwartet wird. | |
| 4543157 | Zusammenfassung: In der Ansicht „In Bearbeitung“ der Seite „Verwalten“ wurde in der Spalte „Empfangende“ weiterhin der Name des Delegierenden angezeigt, nachdem eine Unterzeichnerrolle delegiert wurde, obwohl ein anderer Unterzeichnender aktiv unterzeichnete, da die Benutzeroberfläche den angezeigten Empfangenden nicht aktualisierte, um den aktuellen Delegierten widerzuspiegeln. |
| Fehlerbehebung: Die Logik der Verwalten-Seite wurde aktualisiert, sodass in der Spalte „Empfangender“ jetzt der Name des primären Delegierten angezeigt wird, wenn eine Signaturrolle delegiert wird. Dadurch zeigt die Ansicht „In Bearbeitung“ genau an, wer gerade signiert. | |
| 4543253 | Zusammenfassung: Im klassischen Workflow-Erlebnis verschwanden Felder, die beobachtenden Personen zugewiesen waren (Signatur, Name, Datum), nach dem Speichern einer Vereinbarung im Entwurfsstatus, obwohl die Felder im Backend vorhanden waren. Dies lag daran, dass die Entwurfs-Rendering-Logik die Felder für beobachtende Personen nicht wiederherstellte, wenn der Fortschritt gespeichert wurde. |
| Fehlerbehebung: Die Logik für die Entwurfsdarstellung wurde korrigiert, um alle Felder, die beobachtenden Personen zugewiesen waren, nach dem Speichern des Fortschritts zu erhalten und anzuzeigen. Dadurch wird sichergestellt, dass Vereinbarungen, die im Entwurfsstatus geöffnet werden, dieselbe Feldsichtbarkeit beibehalten wie während der Erstellung und Unterzeichnung. | |
| 4543513 | Zusammenfassung: Benutzende wurden daran gehindert, Vereinbarungen in der Sign-Web-Benutzeroberfläche zu senden, mit dem Fehler „Gebietsschema ist entweder ungültig oder fehlt“, da die Gültigkeitsprüfung des Gebietsschemas fälschlicherweise API-Gebietsschema-Regeln in der Web-Benutzeroberfläche durchsetzte, wenn sich das Gebietsschema der sendenden Gruppe vom geerbten Primär-Gruppen-Gebietsschema des Benutzenden unterschied. |
| Fehlerbehebung: Die Gültigkeitsprüfung für Gebietsschemata wurde korrigiert, sodass die Sign-Web-Benutzeroberfläche gültige Gruppen- und Benutzer-Gebietsschema-Kombinationen ordnungsgemäß auflöst und akzeptiert. Dadurch wird verhindert, dass API-spezifische Gebietsschema-Beschränkungen das Senden von Verträgen im Web-Erlebnis blockieren. | |
| 4543592 | Zusammenfassung: Einige Audit-Berichte zeigten „Empfangender mit Adobe Acrobat Sign authentifiziert“ nach „Dokument elektronisch signiert“ und „Vereinbarung abgeschlossen“, da Ereignisse mit Zeitstempeln auf Sekundenebene gespeichert wurden, wodurch Authentifizierungs- und Signaturaktionen, die in derselben Sekunde auftraten, in falscher Reihenfolge erschienen. |
| Fehlerbehebung: Die Audit-Ereignisprotokollierung wurde aktualisiert, um Zeitstempel mit Millisekundenpräzision zu speichern und anzuzeigen. Dadurch werden Authentifizierungs-, Signatur- und Abschlussereignisse im Audit-Bericht korrekt sequenziert. | |
| 4543617 | Zusammenfassung: Das Erstellen einer Vorlage aus einer Vereinbarung startet die Classic-Benutzeroberfläche anstelle der neuen Benutzeroberfläche, obwohl die neue Benutzeroberfläche als Standard eingestellt ist. Dies liegt daran, dass die Aktion noch über den Legacy-Erstellungsworkflow geleitet wird. |
| Fehlerbehebung: Die Aktion „Muster aus Vereinbarung anlegen“ wurde so aktualisiert, dass sie sich im neuen Erlebnis öffnet. Dadurch wird das CTA-Verhalten an die Standard-UX angepasst und unerwartete Kontextwechsel für Benutzende vermieden. | |
| 4544564 | Zusammenfassung: Über die API hinzugefügte oder aktualisierte versteckte Felder (visible:false) wurden in der modernen eSign-Benutzeroberfläche als sichtbar dargestellt. Die Signatur-Benutzeroberfläche ignorierte die Markierung für die Feldsichtbarkeit, sodass Empfangende Felder sehen konnten, die versteckt bleiben sollten. |
| Fehlerbehebung: Die moderne eSign-Benutzeroberfläche wurde aktualisiert, um Felder herauszufiltern, bei denen visible auf false gesetzt ist – sowohl bei der Darstellung als auch in der Navigationslogik. So werden ausgeblendete Felder nie angezeigt und beeinflussen das Seitenverhalten nicht. | |
| 4544571 | Zusammenfassung: Die WhatsApp-Zustellungsoption fehlte in den Sendeeinstellungen, obwohl WhatsApp für das Konto aktiviert und beim Senden von Vereinbarungen verfügbar war. Dies führte zu inkonsistentem Verhalten und Verwirrung bei Administrationsteams. |
| Fehlerbehebung: Die WhatsApp-Zustellungsoption wurde in den Sendeeinstellungen überall dort wiederhergestellt, wo die Funktion verfügbar ist. Das gewährleistet konsistente Sichtbarkeit und Konfiguration zwischen Admin-Einstellungen und dem Erlebnis beim Senden von Vereinbarungen. | |
| 4545381 | Zusammenfassung: Die Schriftart Roboto fehlte im neuen Signaturanfrage-Erlebnis, obwohl sie im klassischen Erlebnis verfügbar war. Das lag daran, dass das neue Authoring-Erlebnis nicht alle von der Legacy-Version unterstützten Schriftarten enthielt. |
| Fehlerbehebung: Roboto wurde zur Schriftliste in der neuen Signaturanfrage-Benutzeroberfläche hinzugefügt. Dadurch wird die Schriftarten-Parität mit der klassischen Benutzeroberfläche wiederhergestellt und eine konsistente Formatierung beim Erstellen von Vereinbarungen ermöglicht. | |
| 4545484 | Zusammenfassung: Einige Admins konnten aufgrund eines Backend-Anfragefehlers nicht auf Empfängergruppen zugreifen oder diese über Admin > Adressbuch erstellen. Das führte zu einem 400-Fehler beim Laden der Empfängergruppendaten. Das Problem blockierte die anfängliche Einrichtung von Empfangsgruppen für betroffene Admins. |
| Fehlerbehebung: Die Backend-Anfrageverarbeitung wurde korrigiert, sodass die Suche und Erstellung von Empfängergruppen nicht mehr mit einem 400-Fehler fehlschlägt. Admins können jetzt zuverlässig auf Empfangsgruppen zugreifen und diese verwalten, unabhängig von Netzwerk oder Standort. | |
| 4545547 | Zusammenfassung: Vereinbarungen, die aus AutoCAD-PDFs erstellt wurden, konnten nicht gesendet werden, wenn ein Feld für eine digitale Signatur hinzugefügt wurde. Es wurde ein allgemeiner Sendefehler angezeigt, da das System die Seitendrehung bei der Validierung der Platzierung des Felds für die digitale Signatur nicht korrekt verarbeitet hat. |
| Fehlerbehebung: Die Koordinaten des Felds für die digitale Signatur werden jetzt angepasst, um gedrehte Seiten zu berücksichtigen. Dadurch wird sichergestellt, dass Felder gegen die korrekten Seitengrenzen validiert werden, sodass von AutoCAD generierte PDFs erfolgreich mit digitalen Signaturen gesendet werden können. | |
| 4545894 | Zusammenfassung: Wenn eine Empfängergruppe verwendet wird und kein Signaturfeld manuell platziert wird, zeigt der automatisch generierte Signaturblock die E-Mail-Adresse in sehr kleiner Schriftgröße an. Der Text wird progressiv kleiner, je mehr Empfangende zur Gruppe hinzugefügt werden. |
| Fehlerbehebung: Der automatisch generierte Signaturblock rendert jetzt die E-Mail-Adresse korrekt in normaler, lesbarer Größe, unabhängig davon, wie viele Empfangende in der Empfangsgruppen enthalten sind. | |
| 4546085 | Zusammenfassung: Bei der Verwendung von „Mich hinzufügen“ im neuen Erlebnis für Signaturanfragen werden E-Mail-Adressen mit einem Apostroph falsch angezeigt. Die fehlerhafte Adresse verhindert das Senden der Vereinbarung, es sei denn, die E-Mail-Adresse wird manuell erneut eingegeben oder der klassische Sendevorgang wird verwendet. |
| Fehlerbehebung: E-Mail-Adressen mit Apostrophen werden jetzt korrekt dekodiert und angezeigt, wenn „Mich hinzufügen“ in der Neuen Signaturanfrage ausgewählt wird, sodass Vereinbarungen ohne manuelle Korrektur gesendet werden können. | |
| 4546110 | Zusammenfassung: In der neuen Vorlagen-Erstellungsumgebung führt das Hinzufügen eines Hyperlink-Felds, das einem bestimmten Teilnehmenden zugewiesen ist, dazu, dass das Speichern der Vorlage fehlschlägt. Dasselbe Feld funktioniert, wenn es allen Teilnehmenden zugewiesen wird oder wenn das klassische Erlebnis verwendet wird. |
| Fehlerbehebung: Hyperlink-Felder unterstützen jetzt Platzhalter-Teilnehmerzuweisungen in der neuen Vorlagenerfahrung, sodass Vorlagen korrekt gespeichert werden können, wenn das Feld einem bestimmten Teilnehmenden zugewiesen ist. | |
| 4546257 | Zusammenfassung: In der Sandbox-Umgebung zeigen Vereinbarungen, die über eine benutzerdefinierte Anwendungs-API gesendet werden, fälschlicherweise eine Zurück-Schaltfläche auf der Authoring-Seite an, da die Sandbox Einstellungen von einer Adobe-verwalteten Anwendung mit aktiviertem nahtlosem Authoring lädt, im Gegensatz zu Swagger oder der Produktionsumgebung. |
| Fehlerbehebung: Das Sandbox-Verhalten wurde an die Produktions- und Swagger-Umgebung angepasst, indem sichergestellt wurde, dass die Authoring-Seite die beabsichtigten Anwendungseinstellungen respektiert und verhindert, dass die Zurück-Schaltfläche für Vereinbarungen erscheint, die über benutzerdefinierte Anwendungs-APIs gesendet werden. | |
| 4546547 | Zusammenfassung: Webformulare konnten den Gegenzeichnenden nicht aktualisieren und gaben einen sonstigen Fehler zurück, da bei älteren Benutzerdatensätzen eine erforderliche interne Markierung fehlte, was dazu führte, dass ein Null-Wert während des Austauschs des Gegenzeichnenden verarbeitet wurde. |
| Fehlerbehebung: Die Logik für die Aktualisierung des Gegenzeichnenden wurde mit null-sicherer Behandlung verstärkt, sodass Webformulare Gegenzeichnende erfolgreich ersetzen können, auch wenn älteren Benutzerdatensätzen die erwartete interne Hervorhebung fehlt. | |
| 4546553 | Zusammenfassung: Benutzende, die mehreren Gruppen zugewiesen waren, konnten Vorlagen in einer Gruppe erstellen, in der die Vorlagenerstellung deaktiviert ist, wenn die neue Vorlagenerstellungserfahrung aktiviert ist. Dies ermöglichte die Umgehung von Beschränkungen auf Gruppenebene. |
| Fehlerbehebung: Die Vorlagenerstellung setzt jetzt Berechtigungen auf Gruppenebene konsistent in der neuen und klassischen Erfahrung durch. Benutzende können keine Vorlagen mehr in Gruppen erstellen, in denen die Vorlagenerstellung deaktiviert ist, auch wenn sie anderen Gruppen angehören, in denen diese Berechtigung aktiviert ist. | |
| 4547744 | Zusammenfassung: Gruppenadmins konnten Benutzenden über die neue Benutzerverwaltungsseite Kontoadministrator-Rechte zuweisen. Dies überschritt ihren Berechtigungsumfang und schuf ein Compliance-Risiko, indem es die Erhöhung von Berechtigungen über die Gruppenadministratorrolle hinaus ermöglichte. |
| Fehlerbehebung: Das Rollenauswahlsteuerelement ist für Gruppenadmins nicht mehr verfügbar. Nur bestehende Kontoadmins können Kontoadministratorrechte zuweisen oder entziehen, um sicherzustellen, dass Rollenänderungen mit den Berechtigungsgrenzen übereinstimmen. | |
| 4547796 | Zusammenfassung: Einige Sendende, die die polnische Benutzeroberfläche verwenden, erhalten gelegentlich eine Bestätigungs-E-Mail mit dem falschen Text „kann keine digitale Signatur bereitstellen“, obwohl die Vereinbarung normal gesendet und unterzeichnet wird. |
| Fehlerbehebung: Polnische Übersetzungen für Bestätigungs-E-Mails des Sendenden wurden korrigiert, sodass die Nachricht „zur Signatur gesendet“ anstelle des falschen Texts „kann keine digitale Signatur bereitstellen“ anzeigt. | |
| 4548315 | Zusammenfassung: Wenn der Sendende als CC-Empfangender im neuen Sende-Workflow enthalten ist, wird kein Validierungsfehler angezeigt und CC-E-Mail-Benachrichtigungen werden nicht an Empfangende gesendet, die nach dem Sendenden in der CC-Liste aufgeführt sind. Dies unterscheidet sich vom Verhalten des klassischen Workflows und kann dazu führen, dass CC-Empfangende Benachrichtigungen verpassen. |
| Fehlerbehebung: Die neue Sende-Workflow-Logik wurde aktualisiert, sodass alle CC-Empfangenden, außer dem Sendenden, CC-E-Mail-Benachrichtigungen erhalten, unabhängig von ihrer Position in der CC-Liste. Das Verhalten entspricht nun den erwarteten Ergebnissen. | |
| 4548583 | Zusammenfassung: PDF/A konnte für eine Gruppe nicht aktiviert werden, wenn für die Standardgruppe des Benutzenden handschriftliche Signaturen aktiviert waren, auch wenn handschriftliche Signaturen für die zu bearbeitende Gruppe deaktiviert waren. Dies blockierte gültige PDF/A-Konfigurationen für nicht standardmäßige Gruppen. |
| Fehlerbehebung: Die Validierung wurde aktualisiert, um die Einstellungen für geschriebene Signaturen in der zu ändernden Gruppe zu prüfen, nicht in der Standardgruppe des Benutzenden. Dadurch kann PDF/A korrekt aktiviert werden, wo es erlaubt ist. | |
| 4549337 | Zusammenfassung: SMS-Benachrichtigungen für stornierte Verträge wurden unterdrückt, wenn die Einstellung E-Mail bei Vertragsstornierung deaktiviert war. Dies hinderte Kundinnen und Kunden, die E-Mail-Benachrichtigungen deaktivieren, daran, erforderliche SMS-Stornierungsbenachrichtigungen zu senden. |
| Fehlerbehebung: SMS- und WhatsApp-Stornierungsbenachrichtigungen wurden von der E-Mail-Einstellung entkoppelt, indem eine dedizierte Benachrichtigungssteuerung eingeführt wurde. Dadurch ist die SMS-Bereitstellung für stornierte Vereinbarungen auch bei deaktivierten E-Mail-Benachrichtigungen möglich. | |
| 4549472 | Zusammenfassung: In Acrobat Sign für Behörden konnten Benutzende keine wiederverwendbaren Muster mit dem neuen Muster-anlegen-Erlebnis anlegen. Nach dem Hochladen eines Dokuments blieb der Workflow auf einem leeren Bildschirm hängen und blockierte die Vorlagenerstellung. |
| Fehlerbehebung: Die fehlende Authoring-Abhängigkeit, die für das neue Erlebnis „Vorlage erstellen“ in behördlichen Umgebungen erforderlich ist, wurde wiederhergestellt, sodass der Authoring-Bildschirm korrekt geladen und Vorlagen erfolgreich erstellt werden können. | |
| 4549862 | Zusammenfassung: Wenn die Zielseite auf das neue Signaturanfrageerlebnis eingestellt ist, wird die konfigurierte Anmeldewarnung nach dem Anmelden nicht angezeigt. Dies verhindert, dass Organisationen ausschlaggebende Wartungs- oder Störungshinweise anzeigen können, wenn Benutzende direkt auf der „Senden“-Seite landen. |
| Fehlerbehebung: Die Unterstützung für die Anzeige der Anmeldewarnung im neuen Signaturanfrageerlebnis wurde wiederhergestellt. Wenn Benutzende nach der Anmeldung auf der Senden-Seite landen, erscheint die konfigurierte Warnung jetzt als Benachrichtigung und entspricht damit dem vorherigen Verhalten und den Kundenerwartungen. | |
| 4550175 | Zusammenfassung: Das Drücken der Eingabetaste nach der Eingabe einer Telefonnummer für die Telefon-Authentifizierung in einem Workflow sendet das Formular vorzeitig ab und löst einen Systemfehler aus, wodurch der Workflow unterbrochen wird, da das Formular gesendet wird, anstatt auf eine explizite Bestätigung zu warten. |
| Fehlerbehebung: Der Empfängerdialog wurde aktualisiert, um die Formularübermittlung bei Drücken der Eingabetaste in Telefon-Authentifizierungsfeldern zu verhindern. Dadurch bleiben Benutzende im Dialog und müssen auf Weiter klicken, was die unbeabsichtigte Workflow-Unterbrechung eliminiert. | |
| 4550302 | Zusammenfassung: Deutsche E-Mails für Signaturanfragen und Erinnerungen verwendeten inkonsistente Anredeformen und wechselten zwischen dem informellen „Du“ und dem formellen „Sie“ innerhalb derselben Nachricht, was zu verwirrenden und unprofessionellen Formulierungen führte. |
| Fehlerbehebung: Die deutschen E-Mail-Übersetzungen wurden aktualisiert, um durchgehend eine einheitliche Anredeform in der gesamten Vorlage zu verwenden und so eine einheitliche und vorhersagbare Sprache in allen E-Mails für Signaturanfragen und Erinnerungen sicherzustellen. | |
| 4550556 | Zusammenfassung: Vereinbarungen mit großen Architekturplan-PDFs konnten nicht gesendet werden, wenn Felder für digitale Signaturen hinzugefügt wurden, und gaben während der Erstellung einen Fehler zurück, der auf die Seitenrotation und Größenbehandlung bei der Platzierung digitaler Signaturen zurückzuführen war. |
| Fehlerbehebung: Die Verarbeitung des Feldes für digitale Signaturen wurde aktualisiert, um gedrehte Seiten im Großformat korrekt zu verarbeiten, sodass Verträge mit Architekturplänen erfolgreich mit digitalen Signaturen versendet werden können. | |
| 4550579 | Zusammenfassung: Wenn eine Vereinbarung durch das Entfernen der letzten verbleibenden Empfangenden während eines Überarbeitungsstatus abgeschlossen wurde, generierte das System das Ereignis AGREEMENT_WORKFLOW_COMPLETED nicht, sodass keine Webhook-Benachrichtigung gesendet wurde, was Workflows unterbrach, die auf dieses Ereignis angewiesen sind, um den Abschluss zu erkennen. |
| Fehlerbehebung: Die Ereignisbehandlung wurde aktualisiert, sodass Vereinbarungen, die durch Empfängerentfernung in der Überarbeitung abgeschlossen werden, nun die entsprechenden Abschlussereignisse generieren. Dies gewährleistet, dass Webhooks für AGREEMENT_WORKFLOW_COMPLETED wie erwartet ausgelöst werden. | |
| 4550998 | Zusammenfassung: Vorab ausgefüllte Kontrollkästchen erschienen in der Erstellung als aktiviert, waren aber für Unterzeichnende deaktiviert, da Kontrollkästchen-Werte als nicht-leere Textstrings anstatt als explizite JA/NEIN-Zustände gespeichert wurden, wodurch die Unterzeichnungserfahrung sie als deaktiviert behandelte. |
| Fehlerbehebung: Die Behandlung von Kontrollkästchen-Werten wurde aktualisiert, sodass jeder nicht-leere vorab ausgefüllte Wert als aktiviert und leere oder fehlende Werte als deaktiviert interpretiert werden, um sicherzustellen, dass Kontrollkästchenstatus für Unterzeichnende konsistent bleiben. |
Adobe Acrobat Sign Version v17.0.1
Produktionsbereitstellung: 17. März 2026
GovCloud-Bereitstellung: 19. März 2026
Verbesserte Funktionalität
- Kopie erstellen – Erweiterte Zugriffspunkte, schnellere Wiederverwendung von Vereinbarungen.
Das Erstellen einer Kopie ist jetzt direkt über die Filter In Bearbeitung und Wartet auf dich auf der Seite Verwalten sowie auf der Bestätigungsseite nach dem Senden verfügbar. Diese zusätzlichen Einstiegspunkte erleichtern die Wiederverwendung von Vereinbarungen an mehr Punkten im Versendungszyklus und reduzieren die Notwendigkeit, von vorne zu beginnen.
Hinweis: Mit dieser Version werden die administrativen Steuerelemente zum Deaktivieren dieser Funktion aus dem Administrator-Menü entfernt, wodurch Kopie erstellen als standardmäßige Funktion für alle berechtigten Benutzenden etabliert wird.
Verfügbare Umgebungen: Sandbox, Kommerziell, Behörden | Verfügbare Dienstebenen: Acrobat Sign Solutions | Konfigurationsumfang: Konto und Gruppe; Standardmäßig aktiviert.
Änderungen der Experience
- Sichtbarkeit des Ablaufs von Integrationsschlüsseln – Ablaufdaten werden jetzt auf der Registerkarte Zugriffstoken angezeigt
Die Registerkarte Zugriffstoken im Menü Persönliche Einstellungen zeigt das Ablaufdatum für jeden Integrationsschlüssel an. Dies bietet Benutzenden und Administrierenden eine klarere Transparenz über das Alter und den Zeitpunkt des Austauschs von Schlüsseln. Dadurch wird es einfacher, bestehende Schlüssel zu überwachen und unerwartete Unterbrechungen zu vermeiden, wenn ein Schlüssel das Ende seiner 10-jährigen Gültigkeitsdauer erreicht.
Verfügbare Umgebungen: Sandbox, Kommerziell, Behörden | Verfügbare Dienstebenen: Acrobat Sign Solutions | Konfigurationsumfang: API
REST API-/Webhook-Updates
API- und Webhook-Updates für diese Version finden Sie in der Acrobat Sign API-Dokumentation.
- OEM 2.0 personalisierte E-Mail-Anzeige – Klarere Sende- und Empfangsidentität in eingebetteten Umgebungen und korrekter E-Mail-Zustellung.
Bei eingebetteten Workflows von OEM 2.0-Partnern wird in Acrobat Sign jetzt auf wichtigen Oberflächen und in Benachrichtigungen die personalisierte E-Mail-Adresse des Benutzenden anstelle der vom Partner registrierten E-Mail-Adresse angezeigt. Vereinbarungen, Warteschlangen wie „Wartet auf dich" und „Prüfen und unterschreiben"-E-Mails spiegeln konsistent die personalisierte Identität wider, während die registrierte E-Mail-Adresse intern für Authentifizierung und Berechtigungen erhalten bleibt. Dies verbessert die Klarheit für Sendende und Unterzeichnende und verhindert, dass E-Mails an nicht zustellbare registrierte Adressen gesendet werden.
Verfügbare Umgebungen: Sandbox, Commercial | Verfügbare Dienstebenen: Acrobat Sign Solutions | Konfigurationsumfang: API – OEM 2.0-Partner; nur auf Anfrage
- Webhook-Benachrichtigung für fehlgeschlagene SMS-Zustellungen – Echtzeit-Sichtbarkeit für fehlgeschlagene SMS-Sendungen, automatisierte Behebung und Parität mit E-Mail-Bounces.
Acrobat Sign sendet jetzt ein neues Webhook-Ereignis, AGREEMENT_PHONE_BOUNCED, wenn eine per SMS gesendete Vereinbarung aufgrund von Problemen wie ungültigen Telefonnummern, Anbieter-Ablehnungen oder blockierten Leitungen nicht zugestellt werden kann. Dies ermöglicht es Kundinnen und Kunden, Fehler bei der SMS-Zustellung nahezu in Echtzeit zu erkennen und automatisch Folgeaktionen wie die Korrektur von Telefonnummern, erneute Zustellung oder das Öffnen von Support-Fällen auszulösen. Das beseitigt blinde Flecken und reduziert Verzögerungen in mobilbasierten Signatur-Workflows.
Verfügbare Umgebungen: Sandbox, Commercial, Behörden | Verfügbare Dienstebenen: Acrobat Sign Solutions | Konfigurationsumfang: API
- Webhook Payloads – Feld „Bedingt teilnehmende Person extendedStatus“ für dynamische Teilnahmeaktualisierungen hinzugefügt, um die Sichtbarkeit des Teilnahmestatus zu verbessern.
Webhook-Benachrichtigungen enthalten nun ein extendedStatus-Feld in jedem Teilnehmerobjekt (memberInfos[]), wenn die absendende Person eine laufende Vereinbarung über dynamische Teilnahme ändert. Dieses Feld enthält zusätzliche Details zum Teilnehmenden-Lebenszyklus, während das vorhandene Statusfeld aus Gründen der Abwärtskompatibilität unverändert bleibt.
status Werte (unverändert): ACTIVE, REPLACED.
extendedStatus -Werte: ACTIVE, REPLACED, REMOVED, COMPLETED.
Verfügbare Umgebungen: Sandbox, Kommerziell, Behörden | Verfügbare Dienstebenen: Acrobat Sign Solutions | Konfigurationsumfang: API
Behobene Probleme
| Problem | Beschreibung |
|---|---|
| 4543515 | Zusammenfassung: Ein Webhook-E-Mail-Bounce-Ereignis kann fälschlicherweise für eine gültige unterzeichnende Person generiert werden, nachdem die unterzeichnende Person erfolgreich signiert hat und die Vereinbarung zum nächsten Schritt übergeht. Das kann auftreten, wenn ein*e Delegierte*r in derselben Unterzeichnergruppe eine ungültige E-Mail-Adresse hat und die absendende Person den ursprünglichen Delegator ersetzt. In diesen Fällen kann das System das Bounce-Ereignis „im Namen von … signiert“ fälschlicherweise der gültigen unterzeichnenden Person zuordnen, anstatt der teilnehmenden Person, dessen E-Mail-Adresse tatsächlich zurückgewiesen wird. |
| Fehlerbehebung: Die Logik für die Event-Attribution wurde korrigiert, sodass E-Mail-Bounce-Events nur mit der teilnehmenden Person verknüpft werden, dessen E-Mail-Adresse tatsächlich bounced. Ein Bounce-Ereignis wird nicht mehr für eine gültige unterzeichnende Person generiert, die bereits die Signatur abgeschlossen hat, und Webhook-Benachrichtigungen spiegeln jetzt die korrekte teilnehmende Person und die korrekte E-Mail-Adresse wider. | |
| 4544548 | Zusammenfassung: Über die Web-Benutzeroberfläche erstellte Integrationsschlüssel können nach 10 Jahren ablaufen, obwohl auf der Erstellungsseite angegeben wird, dass der Schlüssel „permanenten Zugriff“ bietet. Wenn ein Schlüssel seine 10-jährige Lebensdauer erreicht, geben API-Aufrufe einen abgelaufenen Token-Fehler zurück, was bestehende Integrationen unerwartet unterbrechen kann. |
| Fehlerbehebung: Das Messaging der Benutzeroberfläche wurde aktualisiert, um die Formulierung „permanenter Zugriff“ zu entfernen und das Ablaufdatum für Integrationsschlüssel klar anzuzeigen. Der aktualisierte Text besagt nun, dass der Schlüssel den Zugriff bis zum Ablaufdatum oder bis zur manuellen Sperrung behält und bietet Transparenz über die standardmäßige 10-jährige Lebensdauer. | |
| 4546301 | Zusammenfassung: Die Webhook-Ereignis-Bereitstellung kann bei Verträgen mit sehr großen Dokumenten um bis zu mehrere Stunden verzögert werden, auch wenn die Vereinbarungserstellung abgeschlossen ist und frühe Verarbeitungsschritte innerhalb von Minuten beendet zu sein scheinen. Während des Verzögerungsfensters kann der Webhook-Bereitstellungsservice wiederholt DOCUMENT_NOT_AVAILABLE-Antworten erhalten, wenn er versucht, Vereinbarungsdokumente abzurufen, und das Webhook-Ereignis wird möglicherweise erst übermittelt, wenn der Service aufhört, es erneut zu versuchen, oder die Dokumente verfügbar werden. |
| Fehlerbehebung: Die Behandlung der Dokumentverfügbarkeit wurde korrigiert, sodass große Vereinbarungen zuverlässig in einen Zustand übergehen, in dem Dokumente abrufbar sind, ohne dass es zu längeren DOCUMENT_NOT_AVAILABLE-Antworten kommt. Infolgedessen werden Webhook-Ereignisse ohne mehrstündige Verzögerungen zugestellt, die durch Wiederholungsversuche beim Dokumentabruf gegen nicht verfügbare Dokumente verursacht wurden. | |
| 4547823 | Zusammenfassung: Die private Nachricht einer empfangenden Person wird möglicherweise nicht für einige Unterzeichnenden angezeigt, wenn eine Vereinbarung im Authoring-Status über die API erstellt und dann über das Verwalten-Erlebnis bearbeitet wird. In diesem Szenario zeigt die Benutzeroberfläche möglicherweise den Wert für Private Nachricht als „Keine“ oder leer an, obwohl die Vereinbarungsdaten den korrekten Wert für die private Nachricht enthalten. Dieses Verhalten tritt in Szenarien mit freigegebenen Konten auf, bei denen ein Anwender in das Konto eines anderen Anwenders wechselt, um den Entwurf zu bearbeiten, und es kann nur bestimmte Empfänger betreffen, während andere korrekt angezeigt werden. |
| Fehlerbehebung: Eine Überprüfung wurde hinzugefügt, um den primären Freigabe-Kontext abzurufen und die private Nachricht für autorisierte freigegebene Benutzende zurückzugeben. Dadurch wird der Wert der privaten Nachricht jetzt korrekt angezeigt, wenn ein über die API erstellter Entwurf aus dem Authoring-Fluss angezeigt oder gesendet wird. | |
| 4548274 | Zusammenfassung: Das Änderungsdatum für Bibliotheksmuster wird möglicherweise nicht aktualisiert, nachdem ein Muster im neuen Mustererlebnis bearbeitet und gespeichert wurde. Benutzende sehen möglicherweise neu hinzugefügte oder aktualisierte Felder im Muster, aber das Änderungsdatum bleibt in der Benutzeroberfläche zum Managen und in administrativen Ansichten unverändert, wodurch es so aussieht, als wäre das Muster nicht kürzlich geändert worden. Dies geschieht, weil das neue Erlebnis Formular-Felder über einen Pfad aktualisiert, der nicht auch den Zeitstempel der Muster-Änderung aktualisiert. |
| Fehlerbehebung: Das Verhalten der Aktualisierung des Änderungsdatums wurde zwischen dem neuen Muster-Erlebnis und den zugehörigen API-Operationen abgestimmt. Der Code-Pfad, der Muster-Feldänderungen speichert, aktualisiert jetzt auch das Änderungsdatum des Musters, sodass es die tatsächliche Zeit der letzten Änderung widerspiegelt. | |
| 4548564 | Zusammenfassung: Signaturen und Formularfelder erscheinen möglicherweise unsichtbar im signierten PDF, wenn sie über bereits vorhandene Stempelanmerkungen im Quelldokument platziert werden. In betroffenen Vorlagen überlappen oder verdecken die Stempelanmerkungen die interaktiven Felder während der Verarbeitung, wodurch ausgefüllte Signaturen und andere Felder im endgültigen signierten Dokument ausgeblendet werden. |
| Fehlerbehebung: Die Behandlung von Stempelanmerkungen wurde aktualisiert, um bereits vorhandene Stempelanmerkungen sicher zu verarbeiten und zu reduzieren, damit sie Formularfelder oder Signaturen nicht mehr verdecken. Felder, die über gestempelte Bereiche platziert wurden, bleiben jetzt während des Signierens und in der vollständig ausgeführten PDF sichtbar. | |
| 4549103 | Zusammenfassung: Ein E-Mail-Bounce-Ereignis kann für eine zuvor fehlerhafte empfangende Person erneut protokolliert werden, nachdem die absendende Person diese empfangende Person durch eine gültige E-Mail-Adresse ersetzt hat. In einigen Fällen zeigt das Audit-Protokoll möglicherweise ein zweites Bounce-Ereignis für die alte E-Mail-Adresse an, und der Vereinbarungsstatus zeigt möglicherweise „E-Mail-Adresse bounced“ an, obwohl die neue empfangende Person die Vereinbarung erfolgreich erhält, anzeigt oder signiert. Dieses Verhalten kann den Anschein erwecken, dass die Vereinbarung noch immer sowohl die alte als auch die neue E-Mail-Adresse anspricht. |
| Fehlerbehebung: Der Workflow zum Ersetzen von Unterzeichnenden wurde aktualisiert, um zu verhindern, dass zusätzliche Benachrichtigungs-E-Mails an eine ersetzte empfangende Person gesendet werden, dessen E-Mail bereits zurückgewiesen wurde. Das System prüft jetzt das vorherige Zurückweisungsprotokoll, bevor es ersetzungsbezogene Benachrichtigungen sendet. So wird sichergestellt, dass nach dem Ersetzen keine neuen Zurückweisungsereignisse für die alte E-Mail-Adresse generiert werden. | |
| 4549306 | Zusammenfassung: Benutzende, deren E-Mail-Adressen bestimmte Sonderzeichen enthalten (z. B. einen Apostroph), können sich nicht über die generischen öffentlichen Anmeldeseiten adobesign.com oder echosign.com anmelden. Nach der Eingabe der E-Mail-Adresse und dem Klicken in das Kennwortfeld wird die Seite möglicherweise neu geladen und das E-Mail-Feld geleert, anstatt Benutzende zur korrekten Shard- oder SSO-Anmeldeseite weiterzuleiten. Dies verhindert, dass betroffene Benutzende die Authentifizierung abschließen können, und blockiert Integrationen, die auf den öffentlichen Anmelde-Endpunkt angewiesen sind. |
| Fehlerbehebung: Die Logik zur Anmelde-Shard-Auflösung wurde korrigiert, um E-Mail-Adressen mit Sonderzeichen ordnungsgemäß zu verarbeiten und zu dekodieren, bevor die Umleitungs-URL zwischen den Shards erstellt wird. Benutzende mit betroffenen E-Mail-Formaten werden jetzt korrekt zu ihrem zugewiesenen Shard und der SSO-Anmeldungsseite umgeleitet, ohne dass das E-Mail-Adresse-Feld geleert wird. | |
| 4549331 | Zusammenfassung: Signaturen und andere Formularfelder erscheinen möglicherweise fehlend oder unsichtbar im signierten PDF, wenn bestimmte Dokumentverarbeitungsfunktionen aktiviert sind und das Quell-PDF ungültige Seitenrahmenkoordinaten enthält (zum Beispiel falsche CropBox- oder MediaBox-Werte). In diesem Szenario können Felder, die auf Seitenkoordinaten angewiesen sind, außerhalb des sichtbaren Seitenbereichs rendern, wodurch abgeschlossene Signaturen fehlen, obwohl das Signieren erfolgreich abgeschlossen wurde. |
| Fehlerbehebung: Die Behandlung von PDF-Seitenrahmen wurde korrigiert, um ungültige CropBox- und MediaBox-Werte während der Dokumentverarbeitung sicher zu normalisieren. Dadurch richtet sich die Platzierung von Signaturen und Formularfeldern jetzt am sichtbaren Seitenbereich aus, und signierte PDFs zeigen Signaturen wie erwartet an. | |
| 4550367 | Zusammenfassung: Das Erstellen von Webformularen kann mit einem allgemeinen „Server-Fehler" fehlschlagen, nachdem du Echtzeitansicht auf iOS/Android und „Felder hinzufügen“ ausgewählt hast, wenn die Standard-Authentifizierung von Unterzeichnenden der Absendegruppe auf Telefon eingestellt ist und das Konto kein verfügbares Telefon-Authentifizierungs-Kontingent hat, auch wenn die Webformular-Authentifizierung von Unterzeichnenden auf eine Nicht-Telefon-Methode eingestellt ist (zum Beispiel Adobe Sign). Infolgedessen können alle Benutzer im betroffenen Konto daran gehindert werden, Webformulare in allen Dokumenten zu erstellen. |
| Lösung: Die Erstellung von Webformularen bewertet das Kontingent jetzt nur noch für die Authentifizierungsmethode, die tatsächlich für Unterzeichnende des Webformulars konfiguriert ist, und wendet keine Kontingentprüfungen für die Telefon-Authentifizierung mehr basierend nur auf der Standard-Authentifizierungseinstellung der Gruppe an. Dies verhindert falsche Kontingent-Erschöpfungsfehler und ermöglicht die normale Erstellung von Webformularen. | |
| 4551011 | Zusammenfassung: Wenn eine absendende Person bestimmte gescannte PDF-Dateien hochlädt, Signaturfelder hinzufügt und die Vereinbarung versendet, zeigt die signierte PDF-Datei möglicherweise nach Abschluss der Signatur keine sichtbaren Signaturen aufweist. Dieses Verhalten kann auftreten, wenn die hochgeladene PDF-Datei ungültige Seitenbegrenzungs-Metadaten enthält (MediaBox- und CropBox-Koordinaten erscheinen vertauscht), was dazu führen kann, dass Signatur- und andere Felddarstellungsebenen außerhalb des sichtbaren Seitenbereichs gerendert werden. |
| Fehlerbehebung: Die Behandlung von PDF-Seitengrenzen wurde aktualisiert, um PDFs mit ungültigen oder umgekehrten MediaBox- und CropBox-Koordinatenwerten korrekt zu verarbeiten, damit der Darstellungsinhalt von Signaturen und Formularfeldern innerhalb des sichtbaren Seitenbereichs gerendert wird und im endgültigen signierten PDF sichtbar bleibt. | |
| 4551427 | Zusammenfassung: Einige Empfangende, die bereits aktive, korrekt bereitgestellte Konten haben, erhalten Vereinbarungen als „Pseudo-Benutzende“, sodass die Vereinbarung nicht in ihrer normalen Ansicht „Verwalten" erscheint. Dies passiert, wenn E-Mail-Adressen der Empfangenden führende oder nachfolgende Leerzeichen enthalten, was verhindert, dass das System die E-Mail-Adresse mit der vorhandenen benutzenden Person abgleicht und zur Erstellung eines Pseudo-Benutzerdatensatzes führt. |
| Fehlerbehebung: E-Mail-Parsing und Benutzersuche wurden aktualisiert, um E-Mail-Adressen von Empfangenden zu normalisieren (führende und nachfolgende Leerzeichen trimmen), bevor sie mit vorhandenen Benutzenden abgeglichen werden. Dadurch werden Vereinbarungen, die an vorhandenen Benutzenden adressiert sind, dem registrierten Konto zugeordnet, anstatt eine Pseudo-Benutzerin bzw. einen Pseudo-Benutzer zu erstellen, auch wenn die E-Mail-Adresse mit Leerzeichen eingegeben wurde (in API-Payloads und Workflow-Empfangslisten). | |
| 4553198 | Zusammenfassung: Wenn eine Vereinbarung mindestens eine empfangende Person enthält, die für SMS-Versand konfiguriert ist, und mindestens eine Person, die nur für E-Mail-Versand konfiguriert ist, sendet die Stornierung der Vereinbarung über die API keine SMS-Stornierungsbenachrichtigung an die SMS-Empfängerin bzw. den SMS-Empfänger. Die Vereinbarung wird erfolgreich storniert und E-Mail-Benachrichtigungen werden zugestellt, aber SMS-Empfänger erhalten keine Stornierungsnachricht. |
| Fehlerbehebung: Der Stornierungsworkflow wurde korrigiert, um sicherzustellen, dass SMS-Stornierungsbenachrichtigungen an alle Empfangenden gesendet werden, die für die SMS-Bereitstellung konfiguriert sind, wenn eine Vereinbarung storniert wird, unabhängig von den Bereitstellungsmethoden anderer Empfangender. | |
| 4554463 | Zusammenfassung: Wenn Vereinbarungen geklonte Optionsfelder enthalten, die denselben Feldnamen in kombinierten Dokumenten teilen, bleibt nur eine Instanz der ausgewählten Option im finalen signierten PDF ausgewählt. Obwohl die Felder visuell als Kontrollkästchen erscheinen, sind sie als Optionsfelder implementiert. Nach dem Signieren wird der ausgewählte Wert nicht konsistent über alle geklonten Instanzen übertragen, was zu fehlerhaftem oder unvollständigem Mapping der erwarteten Auswahl führt. |
| Fehlerbehebung: Die Formular-Feldbehandlungslogik wurde korrigiert, sodass geklonte Optionsfelder den ausgewählten Export-Wert speichern und übertragen, anstatt eines internen Index-Werts. Dies stellt sicher, dass alle geklonten Instanzen desselben Optionsfelds die korrekte Auswahl in der signierten PDF widerspiegeln. | |
| 4554593 | Zusammenfassung: Einige Partner-Integrationen, die die Vorgängerversion-OAuth-Endpunkte zum Aktualisieren von Zugriffstoken verwenden, begannen mit HTTP 401-Fehlern zu scheitern. Der Service hat Token-Aktualisierungsanfragen mit einem Fehler abgelehnt, der anzeigt, dass die Anwendung nicht berechtigt ist, die OAuth-Endpunkte der Vorgängerversion zu verwenden und stattdessen die OAuth v2-Endpunkte verwenden muss. Dies hinderte Kunden daran, Acrobat Sign über Partner-Anwendungen zu authentifizieren, selbst für Integrationen, die zuvor funktionierten. |
| Fehlerbehebung: Der Authentifizierungsdienst wurde korrigiert, sodass Partner-Anwendungen, die für die Verwendung des Vorgängerversion-OAuth-Flusses konfiguriert sind, Token wieder erfolgreich aktualisieren können, anstatt fälschlicherweise zu den OAuth v2-Endpunkten weitergeleitet zu werden. | |
| 4554614 | Zusammenfassung: Wenn Unterzeichnende das moderne eSign-Erlebnis bei einer Vereinbarung verwenden, die eine Authentifizierung von Unterzeichnenden erfordert und so konfiguriert ist, dass vor der Signatur die Annahme der Nutzungsbedingungen erforderlich ist, löst das Klicken auf „Zum Signieren klicken“ eine 5-sekündige Umleitung zum klassischen Signaturerlebnis aus. Die Umleitungsnachricht warnt davor, dass Signaturen und Initialen, die bei der modernen Signierung eingegeben wurden, gelöscht werden, wodurch der Unterzeichner sie erneut eingeben und praktisch zweimal signieren muss. |
| Fehlerbehebung: Der Token-Aktualisierungsfluss für die Unterzeichnung wurde korrigiert, sodass das neu ausgestellte Unterzeichnungs-Token die Authentifizierungsdetails des Unterzeichners beibehält, wenn der Unterzeichner die Nutzungsbedingungen vor der Unterzeichnung akzeptiert. Dies verhindert, dass der finale Signierungsschritt aufgrund der Authentifizierung fehlschlägt und eliminiert den erzwungenen Fallback von der modernen Signierung zum klassischen Erlebnis. | |
| 4555656 | Zusammenfassung: Unter bestimmten zeitlichen Bedingungen kann ein Übergang des Vereinbarungsstatus erfolgreich erscheinen, ändert aber tatsächlich nicht den Vereinbarungsstatus. Wenn eine Webhook-Benachrichtigung empfangen wird, bevor die Backend-Verarbeitung abgeschlossen ist, können nachfolgende API-Aufrufe veraltete Vereinbarungsstatusdaten verwenden. In diesem Zeitfenster geben bestimmte Statusübergangsmethoden HTTP 200 OK zurück, obwohl sich die Vereinbarung nicht in einem gültigen Status für den angeforderten Übergang befindet. Infolgedessen können Automatisierungs-Workflows annehmen, dass der Übergang erfolgreich war, während die Vereinbarung im ursprünglichen Status verbleibt. |
| Fehlerbehebung: Die Logik für Vereinbarungsstatusübergänge wurde aktualisiert, um eine strenge Gültigkeitsprüfung vor der Anwendung eines Übergangs durchzusetzen. Wenn sich die Vereinbarung nicht in einem gültigen Status befindet, gibt die API jetzt eine klare Fehlerantwort zurück, anstatt stillschweigend Erfolg zu melden. Dies stellt sicher, dass ungültige Übergänge explizit abgelehnt werden, ermöglicht es aufrufenden Systemen, angemessen zu wiederholen, und verhindert, dass Vereinbarungen in einem unbeabsichtigten Zustand ohne Sichtbarkeit verbleiben. |
Adobe Acrobat Sign Version v17.1
Produktionsbereitstellung: 5. Mai 2026
GovCloud-Bereitstellung: 12. Mai 2026
Verbesserte Funktionalität
- Persönlich signieren – Aktiviere gehostete Signatursitzungen in der Web-Anwendung
Persönliches Signieren ermöglicht es einem Absender, einen internen Host zu bestimmen, der eine persönliche Signatursitzung mit einem Browser durchführt. Der Host startet eine gesteuerte Signatursitzung über die Seite „Verwalten“ oder eine E-Mail-Benachrichtigung, übergibt das Gerät vorübergehend an den Unterzeichner, damit dieser die erforderlichen Aktionen durchführen kann, und übernimmt nach Abschluss wieder die Kontrolle. Session-Erstellung und -Abschluss werden im Audit-Trail aufgezeichnet, und Signierer können optional eine E-Mail-Adresse angeben, um eine Kopie der Vereinbarung zu erhalten.
- Digitale Massensignatur auf der Seite „Verwalten“– Wende eine digitale Signatur auf mehrere Vereinbarungen mit einer einzigen Autorisierung an
Unterzeichner können mehrere Vereinbarungen in der Ansicht Wartet auf dich auswählen und digitale Signaturen als Massenaktion mit einer einzigen Signatur-Autorisierung anwenden. Dies reduziert wiederholte Signaturschritte für Workflows mit hohem Volumen und bewahrt gleichzeitig die bestehenden Cloud-Sicherheits-, Authentifizierungs- und Audit-Kontrollen für die Signatur. Beim Massen-Signieren müssen Unterzeichnende alle Verträge prüfen oder überspringen, bevor sie die Massen-Aktion abschließen.
- Nur an interne Empfänger senden – Beschränkt Vereinbarungen darauf, an Empfänger innerhalb desselben Acrobat Sign-Kontos gesendet zu werden.
Die Einstellung Nur an interne Empfänger senden verhindert, dass Benutzer Vereinbarungen an Empfänger außerhalb ihres Acrobat Sign-Accounts senden. Wenn aktiviert, können Vereinbarungen nur an Empfänger gesendet werden, deren Konto-IDs mit denen des Absenders übereinstimmen. Diese Kontrolle unterstützt interne Sicherheitsanforderungen und verhindert, dass Vereinbarungen extern geteilt werden.
- Telefontransaktions-Reporting – Erweiterte Berichte mit Sichtbarkeit auf Gruppenebene und Zugriff auf geplante Berichte
Das Telefontransaktions-Reporting bietet jetzt Einblick in gekaufte Mengen, Kontingent-Startdaten und detaillierte Nutzung bei SMS- und WhatsApp-Transaktionen. Die Kundschaft kann die Nutzung auf Gruppenebene verfolgen und über eine einheitliche Berichterstellungsoberfläche auf geplante CSV-Berichte zugreifen. Das ermöglicht eine genauere Budgetplanung, interne Zuordnung und proaktive Überwachung, um Serviceunterbrechungen zu vermeiden, wenn Transaktionslimits erreicht werden.
Reporting wird jetzt durch geplante Berichte in der Reporting-Oberfläche generiert, mit API-Zugriff verfügbar, um die neueste Berichtsausgabe abzurufen.
Neuer Endpunkt: POST /api/rest/v6/reportDownload
Dieser Endpunkt akzeptiert eine scheduleId und gibt die Download-URL für den zuletzt generierten CSV-Bericht zurück, der mit diesem Zeitplan verknüpft ist.
Änderungen der Experience
- Erfassung der Signaturmethode in Audit-Berichten – Protokolliert die von Unterzeichnenden verwendete Signaturmethode, wodurch die Transparenz in Bezug auf die Compliance erhöht und der manuelle Überprüfungsaufwand reduziert wird
Audit-Berichte erfassen nun die Methode der Signaturdarstellung, die Unterzeichnende beim Anwenden der Signatur verwenden. Für jedes ESIGNED-Ereignis gibt der Audit-Protokoll an, ob der Unterzeichner bzw. die Unterzeichnerin eine getippte Signatur, eine gezeichnete Signatur, ein hochgeladenes Bild oder eine mobile Zeichnung bzw. Bildaufnahme verwendet hat. Diese Verbesserung ermöglicht es Compliance- und Operations-Teams, Signaturmethoden direkt aus dem Audit-Bericht zu verifizieren, wodurch Mehrdeutigkeiten reduziert und unnötige Ablehnungen von Vereinbarungen verhindert werden.
\n Signaturdarstellungstypen:- Eingeben: Unterzeichnende Person gibt ihren Namen ein und wählt einen schriftbasierten Signaturstil aus.
- Zeichnen: Unterzeichnende Person zeichnet ihre Signatur mit einer Maus oder einem Trackpad auf dem Desktop.
- Bild: Unterzeichnende Person lädt eine Signatur-Grafikdatei vom Desktop hoch.
- Mobile Zeichnung: Unterzeichnende Person zeichnet ihre Signatur per Touch auf einem Mobilgerät.
- Mobile Bild: Unterzeichnende Person lädt eine Signatur-Grafikdatei auf einem Mobilgerät hoch oder nimmt sie auf.
- Gespeicherte Signaturen für API-Signatur-URLs – Ermöglicht die Verwendung gespeicherter Profilsignaturen beim API-basierten Signieren
Ermöglicht registrierten Benutzern, ihre gespeicherten Profilsignaturen anzuwenden, wenn sie Vereinbarungen über API-generierte Signatur-URLs (GET /agreements/{agreementId}/signingUrls) signieren. Gespeicherte Signaturen werden für interne Unterzeichner und für externe Unterzeichner angezeigt, die sich mit E-Mail-OTP oder Adobe ID authentifizieren. Diese Funktion optimiert Signatur-Workflows für Backend-Integrationen und behält gleichzeitig Sicherheitskontrollen auf Kontoebene bei.
Von Adobe pro Account nach einer Sicherheitsprüfung aktiviert.
- Persönliches Adressbuch-Management in der modernen Erfahrung – User können gespeicherte E-Mail-Adressen direkt aus ihrem persönlichen Adressbuch in der modernen Signatur anfordern -Erfahrung löschen, was es einfacher macht, persönliche Empfängerlisten genau und aktuell zu halten.
- Ablaufzeitfenster für Vereinbarungen – Standardablaufzeitraum auf 365 Tage erweitert
Die maximale Abschlussfrist für Vereinbarungen wurde von 180 Tagen auf 365 Tage erweitert. Wenn der Dokumentablauf aktiviert ist, wird den Vereinbarungen jetzt automatisch ein 365-Tage-Ablaufdatum zugewiesen, das nicht entfernt werden kann. Diese Änderung stellt sicher, dass alle Vereinbarungen einen definierten Lebenszyklus haben, verbessert langfristige Nachverfolgung und Compliance und reduziert das Risiko, dass Vereinbarungen unbegrenzt offen bleiben, während User weiterhin frühere Fristen setzen können, wenn erforderlich.
- Überarbeitete Startseite – Verbessert den Zugang zum Arbeitsablauf, hebt ausschlaggebende Aktionen hervor
Die Startseite wurde neu gestaltet, um das Starten von Vereinbarungen, die Überwachung von Aktivitäten und den Zugriff auf wichtige Funktionen zu erleichtern, einschließlich der Möglichkeit, kürzlich gesendete Vereinbarungen zu kopieren, Aktionskacheln in einer intuitiveren Reihenfolge anzuzeigen, schnell Elemente wie In Bearbeitung und Warten auf dich zu identifizieren und einen optimierten banner Was ist neu zu erleben, der visuelle Unordnung reduziert und Benutzern hilft, sich schneller zu bewegen, verpasste Vereinbarungen zu reduzieren und eine fokussiertere Startseite zu navigieren.
Die neue Startseite wird über 10 Tage nach der Veröffentlichung ausgerollt. Beziehe dich auf die Technische Mitteilung für den Zeitplan.
- Verbesserungen der Testversion – Das neueste Onboarding-Erlebnis wurde zu der Sign-Testversion hinzugefügt.
Sign-Testversion umfasst jetzt die verbesserte Onboarding-Erfahrung und Features, die in kürzlichen bezahlten Releases eingeführt wurden.
- Neuer Custom Workflow Designer wird standardmäßig – Moderne Designer fördern, User-Switch-Kontrollen entfernen, Admin-Flexibilität beibehalten
Die neue Custom Workflow Designer -Erfahrung ist jetzt die Standardeinstellung für alle Accounts.Benutzende sehen keine Umschaltlinks mehr, um zum klassischen Designer zurückzukehren, während Administratoren die Möglichkeit behalten, den Zugriff auf das vorherige Erlebnis bei Bedarf wieder zu aktivieren. Dieses Update fördert den Übergang zur modernen Workflow-Design-Benutzeroberfläche und behält gleichzeitig die administrative Kontrolle während der Übergangszeit bei.
REST API-/Webhook-Updates
API- und Webhook-Updates für diese Version finden Sie in der Acrobat Sign API-Dokumentation.
- mTLS-Schlüsselverwaltung für Webhooks – Acrobat Sign-generierte Schlüsseloption hinzufügen, Certificate Signing Workflow aktivieren, Sicherheits-Compliance verbessern
Entwickelnde können jetzt wählen, wie private Schlüssel für Webhook-mTLS-Authentifizierung in Acrobat Sign verwaltet werden. Zusätzlich zum bestehenden Modell, bei dem Kunden ihren eigenen privaten Schlüssel und ihr Zertifikat generieren und hochladen, kann Acrobat Sign jetzt den privaten Schlüssel und einen Certificate Signing Request (CSR) generieren. Kunden können den CSR verwenden, um ein Zertifikat von ihrer Zertifizierungsstelle zu erhalten und es hochzuladen, um die Konfiguration abzuschließen. Diese Option verbessert die Sicherheit, indem private Schlüssel in Acrobat Sign gespeichert bleiben und gleichzeitig die Kompatibilität mit dem bestehenden Webhook-mTLS-Verhalten gewährleistet wird.
- Initialisierung der digitalen Identität über login_hint-Parameter – Ermöglicht API-Absendern die Initialisierung der Authentifizierung der digitalen Identität mit einer empfängerspezifischen Login-Kennung.
Mehrere v6 REST API /agreements-Endpunkte unterstützen jetzt einen loginHint-Parameter, der es API-Absendern ermöglicht, die Digital Identity Gateway-Authentifizierung mit einer bekannten Login-Identifizierung wie einer E-Mail-Adresse oder Benutzer-ID-Nummer zu initialisieren.Der Identitätsanbieter steuert das Anwendererlebnis, aber die Identifizierung füllt typischerweise den Anmeldebildschirm vor, um hochvertrauensvolle Authentifizierungs-Workflows zu stärken und das Identitätsbetrugsrisiko zu reduzieren. Die Kennung erscheint in maskiertem Format auf der Digital Identity Gateway-Landingpage und im Auditbericht, um die Nachverfolgbarkeit zu bewahren und gleichzeitig sensible Daten zu schützen.
Die folgenden Endpunkte wurden aktualisiert, um den loginHint-Parameter zu enthalten:- POST /agreements
- PUT /agreements/{agreementId}
- PUT /agreements/{agreementId}/participantSets/{participantSetId}/participants/{participantId}/securityOptions
- GET /agreements/{agreementId}
- GET /agreements/{agreementId}/members/participantSets/{participantSetId}
- GET /agreements/{agreementId}/participantSets/{participantSetId}/participants/{participantId}/securityOptions
- GET /agreements/{agreementId}/members
- OEM 2.0 Identitäts- und Vertrauensgrenze-Verbesserungen – Die Funktion „Personalisierte/OEM-E-Mail-Adresse überall anzeigen" priorisiert jetzt Anwender, die vom selben Partner bereitgestellt wurden, und erstellt automatisch einen Empfänger, wenn keine Übereinstimmung gefunden wird
\nWenn die Funktion „Personalisierte/OEM-E-Mail-Adresse überall anzeigen" aktiviert ist, priorisiert die Auflösung der Vereinbarungsteilnehmer Anwender, die vom selben Partner bereitgestellt wurden, und erstellt automatisch einen Empfängerdatensatz, wenn kein passender Anwender existiert, wodurch eine konsistente Identitätsbehandlung über Accounts hinweg gewährleistet wird.
\n
\nZusätzlich zeigen Audit-Berichte mit aktivierter Personalisierte/OEM-E-Mail überall anzeigen-Funktion an, ob ein Absender partner-bereitgestellt ist oder ein persönliches Konto hat, und Signer-Flows führen Anwender an, zwischen Accounts zu wechseln, wenn identische E-Mail-Adressen in verschiedenen Account-Typen existieren, wodurch Verwirrung reduziert und unbeabsichtigter Zugriff verhindert wird.
Behobene Probleme
| Problem | Beschreibung |
|---|---|
| 4520028 | Zusammenfassung: In der Spalte „Gruppe“ auf der Seite „Verwalten" wurden falsche oder inkonsistente Werte angezeigt, wenn Benutzende mehreren Gruppen angehörten. Wurde die primäre Gruppe einer Benutzerin bzw. eines Benutzers geändert, wurde in Vereinbarungen die falsche Gruppe angezeigt. Dies bezog sich auch auf die zuletzt ausgewählte primäre Gruppe oder mehrere Gruppen, aber nicht auf die Gruppe, aus der die Vereinbarung ursprünglich gesendet wurde. |
| Lösung: Die Logik der Seite „Verwalten" wurde aktualisiert, um anstatt der aktuellen primären Gruppe der Benutzerin bzw. des Benutzer die sendende Gruppe der Vereinbarung (agreement_group_id) zu verwenden, wenn die Spalte „Gruppe“ gerendert wird. | |
| 4532690 | Zusammenfassung: Benutzende konnten Entwürfe von Vereinbarungen, die in selbstdefinierten Workflows erstellt wurden, nicht bearbeiten, wenn sowohl „Aktivieren, dass Vereinbarungen nur per Workflow gesendet werden können" als auch „Neues Sendeerlebnis mit selbstdefinierten Workflows aktivieren" aktiviert waren. Das System blockierte fälschlicherweise den Zugriff auf die Erstellungsseite beim Bearbeiten eines vorhandenen Entwurfs und behandelte es als neue Sendeaktion anstatt als Entwurfsbearbeitung. |
| Lösung: Die Logik der Seite „Erstellen“ wurde aktualisiert, um Entwurfsbearbeitungsszenarien zu erkennen und die Einschränkungsprüfung für Workflows zu umgehen. Dadurch können Benutzende vorhandene Entwürfe von Vereinbarungen bearbeiten, die in selbstdefinierten Workflows erstellt wurden. | |
| 4536764 | Zusammenfassung: Das Senden von Vereinbarungen über einen benutzerdefinierten Workflow führte zu einem Serverfehler aufgrund eines Fehlers bei der Verarbeitung bestimmter Vorlagen-PDFs. Der Fehler wurde durch ungültige oder fehlende Anmerkungsdarstellungsdaten in einem oder mehreren Quelldokumenten verursacht, was eine Rendering-Ausnahme während des Vorausfüllens auslöste. Das Problem war nicht konsistent reproduzierbar und konnte außerhalb der betroffenen Workflows nicht repliziert werden. |
| Lösung:\u00a0Verbesserte Behandlung von Rendering-Ausnahmen in der PDF-Verarbeitungsebene. | |
| 4537197 | Zusammenfassung: Bei der Verwendung des neuen Massenversand-Erlebnisses mit manuell eingegebenen Empfängernamen wurde das zweite Namensfeld während der Unterzeichnung entfernt, da erforderliche Empfängernamendaten dokumentübergreifend falsch verarbeitet wurden. |
| Lösung:\u00a0Die Dokumentverarbeitungslogik wurde aktualisiert, um alle Empfängernamenfelder korrekt beizubehalten, wenn Vereinbarungen im Massenversand gesendet werden. | |
| 4538172 | Zusammenfassung: Das Kopieren von Workflows, die Empfangsgruppen enthalten, schlug während der Sandbox-Synchronisation aufgrund ungültiger Empfangsgruppen-Referenzen mit der Meldung „Fehler beim Ausführen der Anforderung" fehl. Der Workflow verwendete umgebungsspezifische Empfängergruppen-IDs, die nicht zwischen Umgebungen übertragbar sind, was dazu führte, dass die Gültigkeitsprüfung während der Synchronisation fehlschlug. |
| Lösung: Die Verarbeitung der Sandbox-Synchronisation wurde aktualisiert, um Empfangsgruppen-Referenzen während Workflow-Kopiervorgängen korrekt zu validieren und zu verarbeiten. Dadurch werden Fehler verhindert, wenn Empfangsgruppen in beiden Umgebungen existieren. | |
| 4538251 | Zusammenfassung: In der neuen Massenversand-Funktion erschienen die Vollname- und E-Mail-Unterzeichnerinformationsfelder nicht während der Unterzeichnung oder im finalen Dokument, wenn die Quelldatei vorhandene AcroForm-Felder enthielt. Das Problem wurde durch eine fehlerhafte Verarbeitung von Zusammenführungsfeld-Daten beim Kombinieren von Unterzeichner-Informationsfeldern mit bereits vorhandenen Formularfeldern verursacht, wodurch die Felder in untergeordneten Vereinbarungen nicht gerendert wurden |
| Lösung:\u00a0Die Zusammenführungs- und Formularfeldverarbeitungslogik wurde aktualisiert, um Unterzeichner-Informationsfelder in Dokumenten mit vorhandenen AcroForm-Feldern korrekt anzuwenden. | |
| 4545485 | Zusammenfassung: Die Erstellung von Verträgen schlug zeitweise fehl, wenn die Miniaturbildgenerierung auf fehlerhafte PDF-Formularfelder stieß. Der Fehler wurde durch Quelldokumente verursacht, die Formularfelder ohne gültige Namen und ungültige verschachtelte Feldstrukturen enthielten, was Verarbeitungsfehler während der PDF-Generierung auslöste. |
| Lösung: Validierung und Nullprüfungen während der PDF-Verarbeitung wurden hinzugefügt, um fehlerhafte Formularfelder zu verarbeiten und Fehler während der Miniaturbildgenerierung und Vereinbarungserstellung zu verhindern. | |
| 4545814 | Zusammenfassung: Felder sind falsch ausgerichtet und Text-Tags bleiben sichtbar bei der Verarbeitung von Querformatdokumenten, die aus XDP-basierten Workflows generiert wurden. Falsche Koordinatenberechnungen in Querformat-Layouts verursachen eine unsachgemäße Feldplatzierung und verhindern, dass Text-Tags ordnungsgemäß analysiert und entfernt werden. |
| Lösung: Die Logik für das Rendern von Feldern wurde aktualisiert, um Formularfelder in Dokumenten im Querformat korrekt zu berechnen und zu platzieren. Dadurch wird eine ordnungsgemäße Ausrichtung und das Entfernen von Text-Tags während der Verarbeitung sichergestellt. | |
| 4545978 | Zusammenfassung: Sonderzeichen in Unterzeichnernamen werden im sichtbaren Signaturblock bei der lokalen digitalen Signaturerstellung falsch gerendert. Das Problem tritt auf, weil die im Dokument eingebettete Standardschrift keine ordnungsgemäße Kodierung für westeuropäische Zeichen hat, was eine falsche Zeichenersetzung beim Rendern der Signaturdarstellung verursacht. |
| Lösung: Die Konfiguration der eingebetteten Schriftart wurde aktualisiert, um die ordnungsgemäße Kodierung akzentuierter Zeichen einzubeziehen. Dadurch wird das korrekte Rendern der Namen von Unterzeichnenden in der Signaturdarstellung gewährleistet. | |
| 4547100 | Zusammenfassung: Geklonte mehrzeilige Textfelder rendern im signierten PDF inkonsistent. Im standardmäßigen Erscheinungsbildwörterbuch fehlen mehrzeilige geklonte Felder. Dies führt dazu, dass in geklonten Feldern weniger Zeilen angezeigt werden als im Quellfeld, auch wenn bei beiden Feldern dieselbe Größe und dieselben Einstellungen verwendet werden. |
| Lösung: Das standardmäßige Erscheinungsbildwörterbuch wurde zu mehrzeiligen geklonten Feldern hinzugefügt, damit geklonte Felder und Quellfelder in signierten Dokumenten konsistent gerendert werden. | |
| 4548305 | Zusammenfassung: In der Onboarding-Checkliste wird „BAA für HIPAA-Einsatzbereitschaft anfragen“ als ausstehend angezeigt, auch wenn HIPAA aktiviert ist. Übernommene HIPAA-bezogene Einstellungen werden von der Checklisten-Auswertungslogik fälschlicherweise als unvollständig angesehen, wodurch der Aufgabenstatus ausstehend bleibt, obwohl die Funktion aktiviert ist. |
| Lösung: Die Checklisten-Auswertungslogik wurde aktualisiert, um HIPAA-bezogene Einstellungen korrekt zu interpretieren, einschließlich vererbter Werte, sodass die Onboarding-Aufgabe den abgeschlossenen Zustand widerspiegelt, wenn HIPAA aktiviert ist. | |
| 4550731 | Zusammenfassung: Eine große Lücke erscheint zwischen der Signaturzeile und dem Zeitstempel beim Signieren von Dokumenten mit Fill & Sign. Das Problem tritt auf, wenn das Signaturfeld nicht breit genug ist, um den gerenderten Signaturinhalt aufzunehmen, was zu falschen Abständen in der Signaturdarstellung führt |
| Lösung: Das Rendern von Signaturen wurde aktualisiert, um die definierten Felddimensionen zu respektieren und den Abstand angemessen anzupassen, wodurch die Lücke zwischen der Unterstreichung und dem Zeitstempel reduziert wird. | |
| 4550906 | Zusammenfassung: Der Link „Kennwort ändern" verweist für bestimmte Benutzende auf eine ungültige URL, was einen Browser-Fehler verursacht. Das Problem tritt auf, wenn die Anwendung einen veralteten Endpunkt aus der Konfiguration liest anstatt der korrekten URL, was zu inkonsistentem Verhalten in verschiedenen Umgebungen führt. |
| Lösung: Der konfigurierte Endpunkt für die Kennwortänderung wurde aktualisiert, damit in betroffenen Umgebungen die korrekte URL verwendet wird. | |
| 4550992 | Zusammenfassung: Durch das Bearbeiten bestimmter Vorlagen in dem neuen Erlebnis wird zu der Seite „Vorlage erstellen" umgeleitet, anstatt die Vorlage im Bearbeitungsmodus zu öffnen. Das Problem tritt auf, weil das Erlebnis vom System auf Basis der Einstellungen der für die Vorlage verantwortlichen Person und nicht auf den Einstellungen der aktuellen Benutzerin bzw. des aktuellen Benutzers bestimmt wird. Dies führt beim Bearbeiten freigegebener Vorlagen zu falschem Routing. |
| Lösung: Die Vorlagen-Bearbeitungslogik wurde aktualisiert, um die Erlebniseinstellungen der aktuellen Benutzerin bzw. des aktuellen Benutzers und nicht die Einstellungen der für die Vorlage verantwortlichen Person zu verwenden. Dadurch wird gewährleistet, dass Vorlagen im korrekten Bearbeitungsmodus geöffnet werden. | |
| 4551756 | Zusammenfassung: E-Mails für Genehmigungsanfragen zeigen unaufgelöste Vorlagenvariablen im Empfängerfeld an, was zu einer falschen E-Mail-Formatierung führt. Das Problem tritt aufgrund eines Fehlers in der E-Mail-Vorlagen-Renderlogik beim Generieren von Berechtigungskonfliktbenachrichtigungen auf. |
| Lösung: Das Rendern von E-Mail-Vorlagen wurde aktualisiert, um Empfängerfelder korrekt aufzulösen und zu befüllen, wodurch sichergestellt wird, dass gültige E-Mail-Adressen in Genehmigungsanfrage-E-Mails angezeigt werden. | |
| 4551768 | Zusammenfassung: Unterzeichnende stoßen beim Zugriff auf oder Abschließen von Vereinbarungen aufgrund eines Fehlers in der Verarbeitung der Formularfelddarstellung auf einen unbehandelten Fehler. Ein fehlerhaftes Darstellungsobjekt verursacht eine ClassCastException während der Dokumentgenerierung, was zu einem Fehler beim Rendern des Vertrags führt. |
| Lösung: Die Verarbeitungslogik für Formularfelder wurde aktualisiert, um Darstellungsobjekttypen vor dem Casting zu validieren, wodurch Ausnahmen verhindert und sichergestellt wird, dass Vereinbarungen für die Unterzeichnung korrekt gerendert werden. | |
| 4552272 | Zusammenfassung: Stornierte oder abgebrochene Vereinbarungen werden auf der Seite „Verwalten“ unter „Wartet auf dich“ angezeigt. Das Problem tritt auf, wenn die Statusdaten von Teilnehmenden bei einem Neustart des Workflows nicht ordnungsgemäß bereinigt werden. Dadurch bleiben veraltete Sichtbarkeits- und Indizierungsdaten zurück, wodurch die Vereinbarung in falschen Ansichten angezeigt wird. |
| Lösung: Die Verarbeitung des Workflow-Neustarts und die Indizierungs-Logik wurden aktualisiert, sodass vorherige Statusdaten von Teilnehmenden korrekt gelöscht werden. Dadurch wird gewährleistet, dass Vereinbarungen nur in ihrem korrekten Status erscheinen. | |
| 4553158 | Zusammenfassung: In RTL-Sprachumgebungen auf iOS reagiert das Signatur-Bedienfeld nicht korrekt beim Zeichnen einer Signatur. Das Bedienfeld scrollt, anstatt Eingaben zu erfassen. Deswegen müssen Benutzende manuell scrollen, um zu zeichnen und die Signatur anzuwenden. Dadurch wird normales Signierverhalten, wenn das neue Signatur-Erlebnis für Empfangende aktiviert ist. |
| Lösung: Die Interaktionsbehandlung des Signatur-Panels für RTL-Layouts auf iOS wurde aktualisiert, um Zeichnungseingaben korrekt zu erfassen, ohne unbeabsichtigtes Scrollen zu verursachen. Dies ermöglicht die normale Signaturerstellung und -anwendung. | |
| 4553583 | Zusammenfassung: Workflows erlauben E-Mail-Adressen mit führenden oder nachgestellten Leerzeichen, was dazu führt, dass Vereinbarungen beim Senden im neuen Erlebnis stillschweigend fehlschlagen. Das System validiert oder normalisiert die Eingabe nicht, und es wird keine Fehlermeldung angezeigt, um das Problem anzuzeigen. |
| Lösung: Die Eingabebehandlung wurde aktualisiert, um automatisch Leerzeichen aus E-Mail-Adressen zu entfernen und das Speichern ungültiger Werte zu verhindern, und es wurde eine Behandlung für bestehende Workflows hinzugefügt, damit Vereinbarungen erfolgreich gesendet werden können. | |
| 4553676 | Zusammenfassung: Hyperlinks werden in der Ansicht „Verwalten“ falsch angezeigt, wo der Vereinbarungstitel an die URL angehängt wird, was zu fehlerhaften Links führt. Das Problem tritt aufgrund falscher URL-Analyse beim Rendern von Hyperlinks in der Manage-Oberfläche auf. |
| Lösung: Das Hyperlink-Rendern wurde aktualisiert, um ordnungsgemäße URL-Analyse zu verwenden, wodurch sichergestellt wird, dass Links unverändert bleiben und in allen Ansichten korrekt funktionieren. | |
| 4555021 | Zusammenfassung: Die Gültigkeitsprüfung des OTP schlägt mit dem Fehler „Abgelaufen“ fehl, auch wenn der Code sofort eingegeben wird. Das Problem tritt aufgrund einer Race-Bedingung im Authentifizierungsfluss auf, bei der mehrere Übermittlungsereignisse dazu führen, dass das OTP vorzeitig ungültig wird. |
| Lösung: Der Validierungsfluss für das OTP wurde aktualisiert, um doppelte oder schnelle Übermittlungsereignisse ordnungsgemäß zu verarbeiten. Dadurch wird ein vorzeitiger Ablauf verhindert und ermöglicht, dass gültige OTP-Eingaben erfolgreich sind. | |
| 4555028 | Zusammenfassung: Das Entfernen der nächsten Empfängerin bzw. des nächsten Empfängers zum Signieren kann mit einem Systemfehler fehlschlagen, und die Vereinbarung kann in einem ausstehenden Überarbeitungsstatus stecken bleiben. Das Problem tritt auf, wenn Empfangende eine aktive Erinnerung haben, die verhindert, dass die Vereinbarungsaktualisierung erfolgreich abgeschlossen wird. |
| Lösung: Die Logik zum Entfernen von Empfangenden wurde aktualisiert. So können Fälle verarbeitet werden, bei denen die bzw. der nächste Unterzeichnende aktive Erinnerungen hat, und die Vereinbarungsaktualisierung kann ohne Fehler abgeschlossen werden. | |
| 4555319 | Zusammenfassung: Webformularerstellenden werden in der Vorschau des Formulars nur die Optionen „Eingeben" und „Zeichnen" für Signaturen angezeigt, während Unterzeichnende alle verfügbaren Optionen sehen (Eingeben, Zeichnen, Bild, Mobile). Das Problem tritt auf, weil die aktivierten Signatureingabe-Einstellungen im Vorschaumodus nicht korrekt angewendet werden, wenn Erstellende nicht als Unterzeichnende fungieren. |
| Lösung: Das Vorschauverhalten von Webformularen wurde aktualisiert, sodass die vollständige Auswahl aktivierter Signatureingabetypen angewendet wird und Erstellende dieselben Signaturoptionen sehen wie Unterzeichnende. | |
| 4555345 | Zusammenfassung: Vereinbarungen mit mehreren Empfangenden vom Typ „Unterzeichnende mit beobachtender Person“ können im Entwurf nicht in der Vorschau geöffnet werden, und der Fehler „ParticipantSetsInfo kann nicht geändert werden“ wird angezeigt. Das Problem tritt in selbstdefinierten Workflows aufgrund fehlerhafter Logik für die Reihenfolge von Teilnehmenden und bezeugenden Personen auf, wodurch verhindert wird, dass die Vereinbarung in den Authoring-Status zurückkehrt. |
| Lösung: Die Logik für die Reihenfolge von Teilnehmenden und bezeugenden Personen in selbstdefinierten Workflows wurde aktualisiert, um die Ausführungsreihenfolge korrekt zu berechnen. Vereinbarungen können dadurch in den Authoring-Status zurückversetzt und normal fortgesetzt werden. | |
| 4555615 | Zusammenfassung: Payloads von Webhook-Ereignissen für delegierte und ersetzte Empfangende enthalten das Feld „privateMessage“ nicht. Das Problem tritt auf, weil die private Nachricht nicht an den Empfängerstatus weitergegeben wird, der zur Generierung von Webhook-Payloads verwendet wird, was zu fehlenden Daten für betroffene Ereignisse führt. |
| Lösung: Die Verarbeitung der Teilnehmendendaten wurde aktualisiert, um zu gewährleisten, dass in Webhook-Payloads private Nachrichten für delegierte und ersetzte Empfangende einbezogen werden. | |
| 4555687 | Zusammenfassung: Vereinbarungen können aufgrund eines Fehlers bei der Dokumentsichtbarkeitsvalidierung nach dem Signieren automatisch storniert und in einen ausgeblendeten Zustand versetzt werden. Wenn eine Teilnehmerin bzw. ein Teilnehmer delegiert oder ersetzt wird, wird die Zuordnung der Dokumentsichtbarkeit nicht korrekt übertragen. Dies führt zu einer Diskrepanz zwischen zugewiesenen Feldern und sichtbaren Dokumenten, wodurch wiederum eine automatische Stornierung ausgelöst werden kann. |
| Fehlerbehebung: Dokumentsichtbarkeitszuordnungen für neue Teilnehmende werden jetzt ordnungsgemäß von der Delegierungs- und Ersetzungslogik geklont, wodurch Validierungsfehler und unbeabsichtigte Vereinbarungsstornierungen verhindert werden. | |
| 4556516 | Zusammenfassung: Formularfelder können konfigurierte Schriftgrade ignorieren und in generierten Vereinbarungen inkonsistent rendern. Das Problem tritt in mehrzeiligen Feldern auf, wenn die Dokumentenverarbeitungs-Engine den Schriftgrad anpasst, um das Abschneiden von Text zu verhindern, wodurch feste Schriftgradeinstellungen überschrieben werden. |
| Lösung: Das Font-Rendering-Verhalten wurde aktualisiert, sodass mehrzeilige Felder feste Schriftgrad-Einstellungen respektieren. Das Verhalten entspricht nun der erwarteten Ausgabe und verhindert unbeabsichtigte Größenanpassungen. | |
| 4556967 | Zusammenfassung: Ausgewählte Kontrollkästchen können in der fertigen signierten PDF für Webformulare als nicht aktiviert erscheinen. Das Problem tritt auf, wenn bestimmte ausgeblendete Werte (zum Beispiel „nein“, „falsch“, „0“, „aus“, „nicht aktiviert“) verwendet werden, was dazu führen kann, dass Zustände von Kontrollkästchen während der Dokumentenverarbeitung falsch interpretiert werden, wenn Gibson aktiviert ist. |
| Fehlerbehebung: Die Verarbeitung von Kontrollkästchen wurde aktualisiert, um ausgeblendete Werte korrekt zu interpretieren und ausgewählte Zustände im finalisierten Dokument beizubehalten, wodurch Konsistenz zwischen der Unterzeichnung und dem unterzeichneten PDF gewährleistet wird. | |
| 4557222 | Zusammenfassung: Verknüpfungsfelder aus Feldmustern können auf der Authoring-Seite verschwinden, wenn sie innerhalb eines Workflows verwendet werden. Das Problem tritt auf, weil Verknüpfungsfelder nicht in den Vertragsformularfelddaten enthalten sind, die während des Workflow-basierten Authorings zurückgegeben werden, was zu fehlenden Feldern führt. |
| Lösung: Die Behandlung von Formularfeldern wurde aktualisiert, um Verknüpfungsfelder aus Feldmustern während der Workflow-Verarbeitung einzuschließen und sicherzustellen, dass sie korrekt zusammengeführt und auf der Authoring-Seite angezeigt werden. | |
| 4557272 | Zusammenfassung: Das Feld „Signierdatum“ kann nicht in der finalisierten signierten PDF angezeigt werden. Das Problem tritt auf, wenn das Rendern von Textfeldern während der Dokumentverarbeitung fehlschlägt und verhindert, dass das Datumsfeld im Ausgabedokument angezeigt wird. |
| Lösung: Das Rendern von Textfeldern wurde aktualisiert, um Null- oder leere Werte ordnungsgemäß zu verarbeiten und zu gewährleisten, dass das Feld „Signierdatum“ in signierten Dokumenten konsistent angezeigt wird. | |
| 4557282 | Zusammenfassung: In Optionsfeldern in Webformularen kann ein unerwarteter QuickInfo-Wert („object Object“) angezeigt werden, wenn sie mit dem neuen Vorlagenerlebnis erstellt werden. Das Problem tritt aufgrund der inkorrekten Behandlung leerer QuickInfo-Werte auf, wodurch Platzhalterdaten gerendert werden, anstatt unterdrückt zu werden. |
| Lösung: Die QuickInfo-Verarbeitungslogik wurde aktualisiert, damit leere Werte ordnungsgemäß ignoriert werden und damit verhindert wird, dass in Webformularen unbeabsichtigter Platzhaltertext erscheint. | |
| 4557589 | Zusammenfassung: Vorausgefüllte Kontrollkästchen können als nicht aktiviert erscheinen, wenn der Vertrag zur Unterschrift gesendet wird. Das Problem tritt auf, wenn doppelte oder widersprüchliche ausgeblendete Werte für Checkbox- oder Optionsfeld-Eingaben definiert sind, was zu einer inkorrekten Interpretation des ausgewählten Zustands während der Dokumentverarbeitung führen kann. |
| Fehlerbehebung: Feldwertbehandlung aktualisiert, um ausgeblendete Werte korrekt zu verarbeiten und vorausgefüllte Auswahlen zu bewahren, wodurch sichergestellt wird, dass Checkbox-Zustände konsistent bleiben, wenn Vereinbarungen generiert und gesendet werden. | |
| 4557672 | Zusammenfassung: Das neue Erlebnis für Unterschriftsanfragen kann einen allgemeinen Fehler („Die bereitgestellte Anfrage ist ungültig") anzeigen, wenn eine Vereinbarung gesendet wird, ohne das spezifische Feld zu identifizieren, das den Fehler verursacht. Dies kann auftreten, wenn Empfangendendaten (wie das Telefonnummernformat) die Validierung nicht bestehen, der Fehler den Benutzenden jedoch nicht deutlich angezeigt wird. |
| Lösung: Die Validierung wurde aktualisiert, um spezifische Fehlermeldungen auf Feldebene bereitzustellen. So können Benutzende ungültige Eingaben identifizieren und korrigieren, bevor die Vereinbarung gesendet wird. | |
| 4557680 | Zusammenfassung: Kontrollkästchen- oder Optionsfeld-Zuordnungen können in einigen Vereinbarungen fehlschlagen, wenn mehrere Dokumente kombiniert werden, wodurch erwartete Werte nicht angewendet werden. Das Problem tritt auf, wenn Standardwerte nicht exakt mit definierten Exportwerten übereinstimmen, was dazu führen kann, dass Felder als separate Gruppen behandelt werden und das Mapping-Verhalten unterbrochen wird. |
| Fehlerbehebung: Feldzuordnungslogik aktualisiert, um nicht übereinstimmende Standardwerte zu ignorieren und Felder dokumentübergreifend korrekt zu verknüpfen, wodurch die Konsistenz des Verhaltens von Kontrollkästchen und Optionsfeldern verbessert wird. | |
| 4557902 | Zusammenfassung: Eine zusätzliche Lücke kann zwischen der Unterschrift und dem Datums- und Zeitstempel in Fill and Sign-Vereinbarungen auftreten. Das Problem tritt aufgrund einer inkorrekten Abstandsberechnung in gut formatierten Signaturen auf, was zu einem inkonsistenten Layout im Vergleich zu anderen Signierungsabläufen führt. |
| Fehlerbehebung: Berechnung des Signatur-Layouts aktualisiert, um Signatur und Zeitstempel korrekt zu positionieren, unbeabsichtigte Abstände zu entfernen und konsistente Formatierung sicherzustellen. | |
| 4557947 | Zusammenfassung: Kontrollkästchen können in der finalisierten signierten PDF als nicht aktiviert erscheinen, wenn Bibliotheksvorlagen verwendet werden, obwohl die Unterzeichnerin bzw. der Unterzeichner sie ausgewählt hat. Das Problem kann auftreten, wenn Checkbox-Felder falsch konfiguriert sind oder bestimmte ausgeblendete Werte verwenden, was zu einer inkorrekten Interpretation des ausgewählten Zustands während der Dokumentverarbeitung führt. |
| Fehlerbehebung: Die Checkbox-Verarbeitung wurde aktualisiert, um ausgeblendete Werte korrekt zu interpretieren und ausgewählte Zustände zu bewahren, wodurch sichergestellt wird, dass Checkbox-Auswahlen im signierten Dokument erhalten bleiben. | |
| 4558295 | Zusammenfassung: Erforderliche Optionsfeld-Werte können im finalisierten unterschriebenen PDF fehlen. Das Problem kann auftreten, wenn Feldwerte Sonderzeichen enthalten (zum Beispiel Anführungszeichen oder Symbole), die nicht ordnungsgemäß verarbeitet werden, wodurch der ausgewählte Wert nicht in der Dokumentausgabe gerendert wird. |
| Lösung: Die Feldwertverarbeitung wurde aktualisiert, um Sonderzeichen korrekt zu behandeln und sicherzustellen, dass ausgewählte Werte in der signierten PDF erhalten und angezeigt werden. | |
| 4558307 | Zusammenfassung: Formularfelder können konfigurierte Schriftgrade ignorieren und in generierten Vereinbarungen inkonsistent rendern. Das Problem kann in mehrzeiligen Feldern auftreten, wenn die Dokumentenverarbeitungs-Engine den Schriftgrad anpasst, um Textabschneidung zu verhindern, wodurch feste Schriftgrad-Einstellungen überschrieben werden. |
| Lösung: Das Rendern von Schriftarten wurde aktualisiert, sodass mehrzeilige Felder feste Schriftgradeinstellungen respektieren, unbeabsichtigte Größenänderungen verhindern und eine konsistente Ausgabe gewährleisten. | |
| 4558554 | Lösung: Unterzeichnende können Vereinbarungen abschließen, ohne mit dem Signaturblock zu interagieren. Das Problem kann in Gibson-aktivierten Konten auftreten, wenn der Signaturblock während der Unterzeichnung nicht ordnungsgemäß gerendert oder durchgesetzt wird, wodurch der Abschluss nur mit dem Signaturfeld möglich ist. |
| Lösung:\u00a0Aktualisierte Signatur-Rendering- und Gültigkeitsprüfungslogik, um sicherzustellen, dass Signaturblöcke korrekt angezeigt und vor dem Vereinbarungsabschluss erforderlich sind. | |
| 4558725 | Zusammenfassung:\u00a0Text-Tags können beim Rendern fehlschlagen oder während der Vorschau nicht in Formularfelder konvertiert werden. Das Problem kann auftreten, wenn die hochgeladene PDF nicht unterstützte oder ungültige Elemente enthält (zum Beispiel Null-Anmerkungen oder vorhandene ausfüllbare Felder), die verhindern, dass die Text-Tag-Verarbeitung erfolgreich abgeschlossen wird. |
| Lösung:\u00a0Aktualisierte Text-Tag-Verarbeitung zur zuverlässigeren Behandlung von PDFs mit ungültigen oder nicht unterstützten Anmerkungen, wodurch Felder während der Vorschau wie erwartet generiert werden können. | |
| 4559285 | Zusammenfassung:\u00a0Die Telefon-Authentifizierung kann für bestimmte Regionen fehlschlagen, wenn eine Ländervorwahl in der neuen Signaturanfrage-Erfahrung ausgewählt wird. Das Problem tritt auf, wenn in der Benutzungsoberfläche eine unvollständige oder falsche Ländervorwahl angezeigt wird (z. B. „+1“ anstatt „+1246“ für Barbados). Dies kann beim Senden der Vereinbarung zu Validierungsfehlern führen. |
| Lösung: Die Verarbeitung der Ländervorwahl wurde aktualisiert, damit die korrekten vollständigen Vorwahlnummern verwendet werden und um zu gewährleisten, dass Telefonnummern in dem neuen Erlebnis ordnungsgemäß validiert und verarbeitet werden. | |
| 4560119 | Zusammenfassung:\u00a0Text in Formularfeldern kann in generierten Vereinbarungen falsch ausgerichtet erscheinen oder sich überlappen. Das Problem kann in mehrzeiligen Textfeldern auftreten, wenn durch die Engine zur Dokumentenverarbeitung Rendering-Unterschiede eingeführt werden, was im Vergleich mit der Authoring-Ansicht zu Layout-Verschiebungen führt. |
| Lösung: Die Verarbeitung von Text Layout für mehrzeilige Felder wurde aktualisiert, um die Ausrichtung zu verbessern und Überlappungen zu verhindern. Dadurch wird eine konsistentere Anzeige zwischen der Erstellung und den finalen Dokumenten gewährleistet. | |
| 4562058 | Zusammenfassung:\u00a0Der Empfängername kann unverändert bleiben, wenn eine andere E-Mail aus dem Adressbuch auf der Senden-Seite ausgewählt wird. Das Problem tritt auf, weil das Namensfeld nicht aktualisiert wird, wenn ein neuer Kontakt ausgewählt wird, was zu einer Diskrepanz zwischen dem angezeigten Namen und der ausgewählten E-Mail führt. |
| Fehlerbehebung:\u00a0Aktualisiertes Empfängerauswahlverhalten, sodass das Namensfeld immer aktualisiert wird, wenn ein neuer Kontakt ausgewählt wird, um sicherzustellen, dass Name und E-Mail synchron bleiben. | |
| 4566339 | Zusammenfassung:\u00a0Falsche Checkbox-Zustände können beim Verarbeiten statischer XFA-PDFs mit fehlerhaften Feldwerten auftreten. Das Problem kann auftreten, wenn nicht unterstützte oder ungültige XFA-Daten (z. B. String-Werte in numerischen Feldern) inkonsistent behandelt werden, insbesondere in Gibson-aktivierten Umgebungen, wo Checkbox-Standards falsch interpretiert werden können. |
| Fehlerbehebung:\u00a0Aktualisierte XFA-Behandlung in der Dokumentenverarbeitungs-Pipeline, um fehlerhafte Werte konsistenter zu normalisieren oder zu ignorieren, falsche Checkbox-Zustände zu verhindern und das Verhalten über Umgebungen hinweg anzugleichen. | |
| 4567278 | Zusammenfassung: Schreibgeschützte Textfelder werden u. U. nicht auf der Signaturseite angezeigt, wenn dynamische Teilnehmende aktiviert sind. Das Problem tritt aufgrund von Inkonsistenzen beim Rendern von Feldern während der Teilnehmerauflösung auf, was dazu führen kann, dass nicht bearbeitbare Felder in der Unterzeichneransicht weggelassen werden. |
| Fehlerbehebung:Die Feld-Rendering-Logik für dynamische Teilnehmende wurde aktualisiert, um zu gewährleisten, dass schreibgeschützte Felder konsistent einbezogen und während des Signierens angezeigt werden. | |
| 4568023 | Zusammenfassung: Optionen für Bild- und mobile Signaturen werden während des Signierens möglicherweise nicht in Webformularen angezeigt. Das Problem kann aufgrund inkonsistenten Ladens von Signaturoptionen im Eingabefluss des Webformulars auftreten. Dabei werden bestimmte Signaturmethoden nicht angezeigt, bis die Sitzung neu geladen oder über einen alternativen Pfad aufgerufen wird. |
| Lösung: Die Signaturinitialisierung auf Webformularen wurde aktualisiert, damit alle aktivierten Signaturoptionen konsistent geladen werden. Außerdem wird gewährleistet, dass Bild- und mobile Methoden an allen Zugangspunkten verfügbar sind. |
Adobe Acrobat Sign Version v17.1.1
Produktionsbereitstellung: 16. Juni 2026
GovCloud-Bereitstellung: 18. Juni 2026
Verbesserte Funktionalität
- Empfängerfilter in Berichten - Füge empfängerbasierte Filter zu Berichten und Datenexporten hinzu.
Füge einen Empfängerfilter zu modernen Reporting für Vereinbarungs- und Transaktionsberichte und Datenexporte hinzu. Administratoren können nach Empfänger-E-Mail filtern, um alle Vereinbarungen anzuzeigen, die den angegebenen Empfänger enthalten, unabhängig von der Rolle oder Signierreihenfolge. Der Filter unterstützt Autovervollständigung und Mehrfachauswahl-Verhalten, das mit dem bestehenden Absender -Filter übereinstimmt, und gilt sowohl für visuelle Berichte als auch für CSV-Exporte.
Änderungen der Experience
- Bio-Pharma (CFR)-Unterstützung in modernem eSign – ergänzt die Erfassung von Gründen für die Signatur und die erzwungene erneute Authentifizierung von Signaturzeiten
Bio-Pharma-Signatureinstellungen, einschließlich der Erfassung von Gründen für die Signatur und der erneuten Authentifizierung von Signaturzeiten, werden jetzt in der modernen eSign-Erfahrung unterstützt. Vereinbarungen mit diesen Einstellungen greifen nicht mehr auf das klassische Signiererlebnis zurück. Es ist keine Kundenaktion oder Änderung der Administrator-Einstellungen erforderlich.
Verfügbare Umgebungen: Sandbox, Commercial, Government | Verfügbare Service-Stufen: Acrobat Sign Solutions | Konfigurationsumfang: Unterstützung für Bio Pharma-Einstellungen in Modern eSign ist standardmäßig aktiviert.
REST API-/Webhook-Updates
API- und Webhook-Updates für diese Version finden Sie in der Acrobat Sign API-Dokumentation.
- Vertragsbenachrichtigungen über API unterdrücken – Granulare Steuerung für Empfänger-Messaging hinzufügen
Verwende die REST v6 POST /agreements API, um zu steuern, welche Benachrichtigungen beim Erstellen von Verträgen gesendet werden, indem du bestimmte E-Mail-Typen für Teilnehmer, CCs oder den Absender unterdrückst. Dies reduziert unnötige E-Mails und unterstützt sauberere, kontrolliertere Signiererlebnisse in integrierten Workflows.
Verfügbare Umgebungen: Sandbox, Kommerziell, Behörden | Verfügbare Dienstebenen: Acrobat Sign Solutions | Konfigurationsumfang: REST v6 API
Behobene Probleme
| Problem | Beschreibung |
|---|---|
| 4545881 | Zusammenfassung: Unterzeichnende, die in Acrobat „Herunterladen und Signieren“ verwenden, erhielten nach dem Hochladen einer digital signierten PDF möglicherweise den Fehler „Kann nicht von Adobe Acrobat Sign erkannt werden“, wenn in dem Zertifikat mit der digitalen ID kein erwarteter Wert von Unterzeichnenden-Namen wie commonName, givenName oder pseudonym enthalten war. Die Vereinbarung konnte nicht abgeschlossen werden, obwohl das signierte PDF hochgeladen wurde. |
| Lösung: Acrobat Sign verarbeitet jetzt digitale ID-Zertifikate mit fehlenden Unterzeichnernamen-Werten, ohne während der Validierung beim Hochladen einen Fehler auszulösen. Die Unterzeichnung kann erfolgreich abgeschlossen werden, obwohl der Unterzeichnername möglicherweise nicht angezeigt wird, wenn das Zertifikat keinen enthält. | |
| 4547132 | Zusammenfassung: Wenn Vereinbarungen über die POST /agreements API-Anfrage erstellt wurden und securityOption auf „Null“ gesetzt war, wurde externen Empfangenden u. U. „Keine“ als Authentifizierungsmethode zugewiesen, auch wenn die Kontoeinstellungen E-Mail OTP als Standard-Authentifizierungsmethode erforderten. Die interne Empfänger-Authentifizierung wurde korrekt angewendet, aber die externe Empfänger-Authentifizierung nicht. |
| Behebung:Acrobat Sign wendet jetzt korrekt die kontokonfigurierte Standard-Authentifizierungsmethode an, wenn API-erstellte Vereinbarungen Empfänger mit einem null securityOption-Wert enthalten. Externe Empfänger erhalten jetzt die erforderliche Standard-Authentifizierungsmethode anstelle von „Keine". | |
| 4553171 | Zusammenfassung: In Entwickelndenkonten, in denen das neue Vorlage-erstellen-Erlebnis verwendet wird, wurde auf der Seite „Verwalten“ in wiederverwendbaren Vorlagen möglicherweise das Präfix [NUR ZU DEMOZWECKEN] angezeigt, doch war das Präfix beim Bearbeiten des Vorlagennamens nicht verfügbar. Benutzer konnten das Präfix nicht aus dem vorhandenen Vorlagennamen entfernen, es sei denn, sie ersetzten den vollständigen Namen oder wechselten zum klassischen Vorlagen-Erlebnis. |
| Lösung: In dem neuen Vorlage-erstellen-Erlebnis wird der wiederverwendbare Vorlagenname und Vereinbarungsname am Wasserzeichen-Verhalten von Entwickelndenkonten ausgerichtet. Benutzer können den vollständigen Vorlagennamen, einschließlich des Präfixes [DEMO USE ONLY], bearbeiten, ohne zum klassischen Erlebnis zu wechseln | |
| 4556731 | Zusammenfassung: Nachdem eine Absenderin bzw. ein Absender eine Empfängerin bzw. einen Empfänger durch sich selbst ersetzt und dann die Vereinbarung an eine andere Empfängerin bzw. einen anderen Empfänger delegiert hatte, kehrte die Vereinbarung in den Status „In Bearbeitung“ zurück, doch die Option „Signiertes Dokument hochladen“ war weiterhin nicht verfügbar. Dies verhinderte, dass der Absender eine signierte Kopie für berechtigte in Bearbeitung befindliche Vereinbarungen nach dieser Delegationssequenz hochladen konnte. |
| Lösung: In Acrobat Sign wird die Option „Signiertes Dokument hochladen“ jetzt korrekt wiederhergestellt, nachdem eine Empfängerin bzw. ein Empfänger durch die Absenderin bzw. den Absender ersetzt und dann an eine andere Empfängerin bzw. einen anderen Empfänger delegiert wurde, wenn die Vereinbarung zum Upload signierter Dokumente berechtigt ist. | |
| 4557576 | Zusammenfassung: Wenn ein Signaturblock einer Empfängergruppe mit mehreren Mitgliedern zugewiesen war, konnte der E-Mail-Wert im Signaturblock abgeschnitten werden, anstatt klar angezeigt zu werden. Dies konnte die Empfängergruppen-Informationen schwer lesbar machen, bevor ein Gruppenmitglied die Unterzeichnung abschloss. |
| Lösung:Acrobat Sign zeigt jetzt Empfängergruppen-E-Mail-Informationen in Signaturblöcken an, ohne den sichtbaren Text abrupt abzuschneiden. Lange Empfängergruppen-E-Mail-Werte werden so verarbeitet, dass die angezeigten Informationen innerhalb des Signaturblocks lesbar bleiben. | |
| 4561898 | Zusammenfassung: Einige Empfangende stießen nach der Authentifizierung oder beim Abschließen der Signierung von Vereinbarungen, bei denen bestimmte PDF-Dokumente verwendet wurden, u. U. auf einen Serverfehler. Der Fehler wurde durch ein Problem bei der Verarbeitung von PDF-Strukturdaten während der Generierung signierter Dokumente verursacht, was den Unterzeichner daran hinderte, die Vereinbarung abzuschließen. |
| Lösung: Acrobat Sign verarbeitet jetzt PDF-Strukturdaten defensiver während der Signierung und Dokumentgenerierung. Die Behebung verhindert, dass Strukturbaum-Konflikte die Fertigstellung blockieren, und ermöglicht es Empfängern, betroffene Vereinbarungen erfolgreich zu authentifizieren, zu signieren und abzuschließen. | |
| 4562041 | Zusammenfassung: Einige Webhook-Benachrichtigungen können verzögert oder nicht veröffentlicht werden, wenn Acrobat Sign beim Erstellen der Webhook-Payload einen internen Serverfehler erhält. Bei dem betroffenen Konto waren am 19. März 2026 mehrere Ereignisse betroffen, einschließlich AGREEMENT_WORKFLOW_COMPLETED und weitere Vereinbarungsereignisse, wodurch nachgelagerte Workflows der Kundschaft verzögert wurden. |
| Lösung:Acrobat Sign verarbeitet jetzt Webhook-Payload-Generierungsfehler zuverlässiger, sodass fehlgeschlagene interne Antworten nicht so zwischengespeichert werden, dass sie die Ereignisbereitstellung blockieren oder verzögern. Die Lösung wurde durch Regressionstests validiert und soll verhindern, dass betroffene Webhook-Ereignisse durch denselben Payload-Generierungsfehler-Pfad verzögert werden. | |
| 4562458 | Zusammenfassung: Empfangende erhielten u. U. den Fehler „Ungültige Vereinbarungs-ID angegeben“, wenn sie eine Signatur-URL für Vereinbarungen öffneten, die an inaktive Benutzende auf angeforderten Konto-Domänen gesendet wurde, wenn für Empfangende eine Authentifizierung wie E-Mail-OTP oder Passwort-Authentifizierung verwendet wurde. Im Signierungsablauf wurde eine einmalig ausstehende, benutzende Person erstellt, um den Signierungsprozess fortzusetzen. Von der Anfrage für Signierungsinformationen konnten aber nur veraltete Vereinbarungsdaten gelesen werden, die die neu erstellte Teilnahme nicht enthielten. Dadurch wurde der Zugriff blockiert, bis der Signierungslink neu generiert oder die Daten aktualisiert wurden. |
| Behebung: Acrobat Sign ruft jetzt aktuelle Vereinbarungsteilnahmedaten ab, wenn authentifizierte Signier-URLs in diesem Workflow geöffnet werden. Dies verhindert, dass veraltete zwischengespeicherte Vereinbarungsdaten ungültige Vereinbarungs-ID-Fehler verursachen, und ermöglicht es Empfängern, die Authentifizierung abzuschließen und erfolgreich auf die E-Signatur-Seite zuzugreifen. | |
| 4566894 | Zusammenfassung: Einige abgelaufene Vereinbarungen, die aus mehreren Vorlagen erstellt wurden, konnten nicht von der Seite Verwalten kopiert werden. Wenn Benutzende „Kopie erstellen“ auswählten, schlug der Kopiervorgang mit „Vereinbarung kann nicht kopiert werden.“ Versuche es später erneut.“ fehl, da die Gültigkeitsprüfung für den Zugriff auf die Vorlage beim Kopieren von Vereinbarungen mit mehr als einer Vorlage fehlschlug. |
| Lösung: Acrobat Sign validiert jetzt korrekt Vorlageninformationen beim Kopieren von Vereinbarungen, die aus mehreren Vorlagen erstellt wurden. Betroffene Vereinbarungen können jetzt kopiert werden, ohne den Backend-Session-Fehler auszulösen. | |
| 4568666 | Zusammenfassung: Webhook-Benachrichtigungen konnten zeitweise für Vereinbarungen fehlschlagen, die Zeugen-Teilnehmer ohne zugewiesene Benutzer-ID enthielten. Das zentrale Vereinbarungsereignis wurde erstellt, aber die Webhook-Payload-Generierung kann fehlschlagen, wenn Teilnehmerdaten in unvorhersagbarer Reihenfolge verarbeitet wurden, wodurch einige erwartete Webhook-Ereignisse nach AGREEMENT_CREATED nicht zugestellt werden. |
| Lösung: Acrobat Sign behandelt jetzt Webhook-Teilnehmerdaten mit fehlenden Benutzer-IDs sicher während der Payload-Generierung. Dies verhindert, dass Zeugen-Platzhalter-Teilnehmer Webhook-Payload-Fehler verursachen und ermöglicht die konsistente Zustellung erwarteter Vereinbarungs-Webhook-Ereignisse. | |
| 4571682 | Zusammenfassung: Bei einigen Vereinbarungen, bei denen Power Automate Empfängergruppen vor der Reihe eines späteren Formularausfüllers geändert hat, konnten schreibgeschützte Felder für den nachfolgenden Formularausfüller nicht angezeigt werden. Nachdem die Formularausfüllerin ihre bzw. der Formularausfüller seine bearbeitbaren Felder ausgefüllt hatte, sind diese Felder u. U. auch aus der Vereinbarung verschwunden, obwohl die Felder noch korrekt zugewiesen und über die API als sichtbar markiert waren. |
| Lösung: Acrobat Sign bewahrt jetzt die Feldsichtbarkeit für nachfolgende Empfängergruppen nach Änderungen der Gruppenmitgliedschaft. Schreibgeschützte Felder, Signaturblöcke, Dropdown-Auswahlen und andere ausgefüllte Feldwerte bleiben für spätere Empfänger und im heruntergeladenen PDF für die behobenen Szenarien verfügbar. | |
| 4571845 | Zusammenfassung: Die persönliche Signatur kann mit einem Serverfehler fehlschlagen, wenn die E-Mail-Adresse des persönlichen Signierenden mit einem vorhandenen Benutzendenkonto auf einem anderen Shard übereinstimmt, wodurch der Vertrag nicht abgeschlossen werden kann. |
| Fehlerbehebung: Die Verarbeitung für persönlich unterzeichnende Personen wurde aktualisiert, um einen temporären Signierenden-Datensatz korrekt zu erstellen und zu verwenden. Dies verhindert Shard-übergreifende Benutzendekonflikte und ermöglicht den erfolgreichen Abschluss der Signiersitzung. | |
| 4573019 | Zusammenfassung: Die Reihenfolge von Empfängergruppen kann nach dynamischen Teilnehmer-Updates, die eine Mischung aus Empfängern und Empfängergruppen entfernen, falsch berechnet werden, wodurch die verbleibende Gruppe die falsche Weiterleitungsreihenfolge anzeigt. |
| Fehlerbehebung: Die Neuberechnung der Teilnehmer-Reihenfolge wurde aktualisiert, damit Empfängergruppen die korrekte Reihenfolge nach komplexen dynamischen Teilnehmerentfernungen beibehalten, einschließlich Fällen, in denen eine Gruppe auf ein einzelnes verbleibendes Mitglied reduziert wird. | |
| 4572455 | Zusammenfassung: Einigen Unterzeichnenden wurde nach Abschluss der Signierung u. U. die Meldung „Unbehandelter Fehler“ oder „Da hat etwas nicht geklappt.“ angezeigt, obwohl die Signatur angewendet und die Vereinbarung an die nächste Empfängerin bzw. den nächsten Empfänger weitergeleitet wurde. Das Problem trat auf, wenn dynamische Teilnehmer aktiviert waren und der Signaturfluss versuchte, das Dokument für den nächsten Unterzeichner vorzubereiten, aber die erwartete unterzeichnete Dokumentversion nicht finden konnte. |
| Lösung: In Acrobat Sign wird jetzt beim Vorbereiten einer Vereinbarung für die nächste Unterzeichnerin bzw. den nächsten Unterzeichner auf die korrekte signierte Dokumentversion geprüft. Dies verhindert, dass der Signierungsfluss nach einer erfolgreichen Signatur einen Fehler anzeigt, wenn dynamische Teilnehmer aktiviert sind. |
