Novidades
Introdução
- Guia de início rápido para admins
- Guia de início rápido para usuários
- Para desenvolvedores(as)
- Biblioteca de tutoriais em vídeo
- Perguntas frequentes
Administrar
- Visão geral do Admin Console
- Gerenciamento de usuários
- Adicionar, editar e revisar usuários ativos
- Criar usuários focados em funções
- Revisar usuários que não concluíram a verificação
- Verificar usuários com erros de provisionamento
- Alterar nome/endereço de email
- Editar a associação de grupo de um usuário
- Editar a associação de grupo de usuários por meio da interface de grupo
- Promover um usuário a uma função de admin
- Tipos de identidade de usuário e logon único
- Alternar identidade de usuário
- Autenticar usuários com o MS Azure
- Autenticar usuários com a federação do Google
- Perfis de produto
- Experiência de logon
- Configurações de conta/grupo
- Visão geral das configurações
- Configurações globais
- Nível de conta e ID
- Nova experiência para destinatários
- Fluxos de trabalho de autoassinatura
- Envio em massa
- Formulários da Web
- Fluxos de trabalho de envio personalizados
- Fluxos de trabalho do Power Automate
- Documentos da biblioteca
- Coletar dados de formulário com contratos
- Visibilidade de documento limitada
- Anexar uma cópia em PDF do contrato assinado
- Incluir um link no email
- Incluir uma imagem no email
- Arquivos anexados a emails receberão o nome
- Anexar relatórios de auditoria a documentos
- Mesclar vários documentos em um
- Baixar documentos individuais
- Fazer upload de um documento assinado
- Delegação para usuários da minha conta
- Permitir que destinatários externos deleguem
- Autoridade para assinar
- Autoridade para enviar
- Autoridade para adicionar selos eletrônicos
- Definir um fuso horário padrão
- Definir um formato de data padrão
- Usuários em vários grupos (UMG)
- Permissões de admin de grupo
- Substituir destinatário
- Relatório de auditoria
- Rodapé da transação
- Mensagens e orientações nos produtos
- PDFs acessíveis
- Cliente do setor de saúde
- Configuração da conta / Configurações de marca
- Preferências de assinatura
- Assinaturas bem formatadas
- Permitir que destinatários assinem por
- Permitir que signatários alterem seus nomes
- Permitir que os destinatários usem a assinatura salva
- Divulgação do cliente e Termos de uso personalizados
- Navegar pelos destinatários em campos de formulário
- Reiniciar fluxo de trabalho do contrato
- Recusar-se a assinar
- Permitir fluxos de trabalho de carimbo
- Exigir que signatários informem o cargo ou empresa
- Permitir que os signatários imprimam e insiram uma assinatura manuscrita
- Mostrar mensagens ao assinar eletronicamente
- Exigir que signatários usem um dispositivo móvel para criar assinaturas
- Solicitar endereço IP dos signatários
- Excluir o nome da empresa e o cargo dos carimbos de participação
- Aplicar dimensionamento adaptável do desenho de assinatura
- Assinaturas digitais
- Selos eletrônicos
- Identidade digital
- Configurações de relatório
- Nova experiência de relatório
- Configurações clássicas de relatório
- Configurações de segurança
- Configurações de logon único
- Configurações de lembrete pessoal
- Política de senha de logon
- Nível de segurança da senha de logon
- Duração da sessão da Web
- Tipo de criptografia PDF
- API
- Acesso às informações de usuários e grupos
- Intervalos de IP permitidos
- Compartilhamento de conta
- Permissões de compartilhamento da conta
- Controles de compartilhamento de contrato
- Verificação de identidade de signatário
- Senha de assinatura do contrato
- Nível de segurança da senha do documento
- Bloquear signatários por geolocalização
- Autenticação por telefone
- Autenticação baseada em conhecimento (KBA)
- Permitir extração de página
- Validade do link do documento
- Fazer upload de um certificado de cliente para webhooks e retornos de chamada
- Carimbo de data e hora
- Configurações de envio
- Mostrar a página Enviar após o logon
- Experiências da criação de contrato
- Solicitar nome do destinatário ao enviar
- Bloquear valores de nome para usuários conhecidos
- Funções de destinatário permitidas
- Permitir testemunhas eletrônicas
- Grupos de destinatários
- CCs
- Campos obrigatórios
- Anexar documentos
- Compactar campo
- Modificar contratos
- Remover destinatários de contratos em andamento
- Nome do contrato
- Idiomas
- Mensagens privadas
- Tipos de assinatura permitidos
- Lembretes
- Proteção com senha de documentos assinados
- Enviar notificação de contrato por meio de
- Opções de identificação do signatário
- Visão geral
- Senha de assinatura
- Autenticação baseada em conhecimento
- Autenticação por telefone
- Autenticação por WhatsApp
- Senha de uso único por email
- Autenticação do Acrobat Sign
- Assinatura digital baseada em nuvem
- Autenticação de identidade digital
- Documento de identidade
- Relatórios de identidade do signatário
- Preencher campos de formulário com dados de identidade verificada
- Proteção de conteúdo
- Habilitar transações da Notarize
- Expiração do documento
- Visualizar, posicionar assinaturas e adicionar campos
- Ordem de assinatura
- Adicionar a mim mesmo
- Link para baixar o contrato
- Bordas do campo de formulário
- Liquid Mode
- Controles de fluxo de trabalho personalizados
- Opções de upload para a página de assinatura eletrônica
- URL de redirecionamento para confirmação pós-assinatura
- Limitar o acesso a contratos compartilhados
- Mostrar a página Enviar após o logon
- Modelos de mensagem
- Configurações de Bio-Pharma
- Integração de fluxo de trabalho
- Configurações de autenticação
- Integração de pagamento
- Mensagens para signatários
- Configurações de SAML
- Configuração de SAML
- Instalar o serviço de federação do Microsoft Active Directory
- Instalar Okta
- Instalar OneLogin
- Instalar a federação de identidade da Oracle
- Configuração de SAML
- Governança de dados
- Configurações de carimbo de data e hora
- Arquivo externo
- Idiomas da conta
- Configurações de email
- Migração de echosign.com para adobesign.com
- Opções de configuração para destinatários
- Orientações com respeito aos requisitos normativos
- Acessibilidade
- HIPAA
- GDPR
- 21 CFR parte 11 e EudraLex anexo 11
- Clientes do setor de saúde
- Suporte a IVES
- “Armazenamento” de contratos
- Considerações para a UE e Reino Unido
- Baixar contratos em massa
- Reivindicar um domínio
- Links para denunciar abuso
- Requisitos e limitações do sistema
Enviar, assinar e gerenciar contratos
- Opções do destinatário
- Cancelar um lembrete de email
- Opções na página de assinatura eletrônica
- Visão geral da página de assinatura eletrônica
- Abrir para ler o contrato sem campos
- Recusar-se a assinar um contrato
- Delegar autoridade de assinatura
- Reiniciar o contrato
- Baixar um PDF do contrato
- Exibir o histórico do contrato
- Exibir as mensagens do contrato
- Converter de uma assinatura eletrônica para uma assinatura manuscrita
- Converter de uma assinatura manuscrita para uma assinatura eletrônica
- Navegar pelos campos do formulário
- Limpar os dados dos campos de formulário
- Ampliação e navegação da página de assinatura eletrônica
- Alterar o idioma usado nas ferramentas e informações do contrato
- Revisar os Avisos legais
- Ajustar as preferências de cookies do Acrobat Sign
- Enviar contratos
- Página Enviar (composição)
- Visão geral dos pontos importantes e recursos
- Seletor de grupo
- Adicionar arquivos e modelos
- Nome do contrato
- Mensagem global
- Prazo de conclusão
- Lembretes
- Proteger o PDF com senha
- Tipo de assinatura
- Localidade do destinatário
- Ordem/fluxo de assinatura do destinatário
- Funções para destinatários,
- Autenticação de destinatários
- Mensagem particular para o destinatário
- Acesso do destinatário ao contrato
- Partes copiadas
- Verificação de identidade
- Enviar um contrato somente para você
- Enviar um contrato para outras pessoas
- Assinaturas manuscritas
- Ordem de assinatura dos destinatários
- Envio em massa
- Página Enviar (composição)
- Criar campos em documentos
- Ambiente de criação no aplicativo
- Detecção automática de campo
- Arrastar e soltar campos usando o ambiente de criação
- Atribuir campos de formulário aos destinatários
- Função de preenchimento prévio
- Aplicar campos com um modelo de campo reutilizável
- Transferir campos para um novo modelo de biblioteca
- Ambiente de criação atualizado ao enviar contratos
- Criar formulários e tags de texto
- Criar formulários usando o Acrobat (Acroforms)
- Campos
- Tipos de campo
- Tipos de campo comuns
- Campos de assinatura eletrônica
- Campo Iniciais
- Campo Nome do destinatário
- Campo Email do destinatário
- Campo Data de assinatura
- Campo de texto
- Campo de data
- Campo de número
- Caixa de seleção
- Grupo de caixas de seleção
- Botão de opções
- Menu suspenso
- Sobreposição de link
- Campo de pagamento
- Anexos
- Carimbo de participação
- Número da transação
- Imagem
- Empresa
- Título
- Carimbo
- Aparência do conteúdo do campo
- Validações de campo
- Valores de campos ocultos
- Definir condições para mostrar e ocultar
- Campos calculados
- Formulários verificados
- Tipos de campo
- Perguntas frequentes sobre criação
- Ambiente de criação no aplicativo
- Assinar contratos
- Gerenciar contratos
- Visão geral da página Gerenciar
- Copiar um Contrato
- Delegar contratos
- Substituir destinatários
- Limitar a visibilidade do documento
- Cancelar um contrato
- Criar novos lembretes
- Revisar lembretes
- Cancelar um lembrete
- Acessar fluxos do Power Automate
- Mais ações...
- Como a pesquisa funciona
- Visualizar um contrato
- Criação de um modelo a partir de um contrato
- Ocultar ou reexibir contratos
- Fazer upload de um contrato assinado
- Modificar os arquivos e campos de um contrato enviado
- Editar o método de autenticação de um destinatário
- Adicionar ou modificar uma data de expiração
- Adicionar uma nota ao contrato
- Compartilhar um contrato individual
- Deixar de compartilhar um contrato
- Baixar um contrato individual
- Baixar os arquivos individuais de um contrato
- Baixar o relatório de auditoria de um contrato
- Baixar o conteúdo dos campos de um contrato
- Relatório de auditoria
- Relatórios e exportações de dados
- Visão geral
- Conceder aos usuários acesso aos relatórios
- Gráficos de relatório
- Exportações de dados
- Renomear um relatório ou exportação
- Duplicar um relatório ou exportação
- Agendar um relatório ou exportação
- Excluir um relatório ou exportação
- Verificar o uso de transações
Recursos e fluxos de trabalho avançados de contratos
- Formulários web
- Criar um formulário web
- Editar um formulário web
- Desabilitar ou habilitar um formulário web
- Ocultar ou reexibir um formulário web
- Localizar o URL ou o código de script
- Preencher campos de formulário web com parâmetros de URL
- Salvar um formulário web para concluir mais tarde
- Redimensionar um formulário web
- Modelos reutilizáveis (modelos de biblioteca)
- Formulários do governo dos EUA na biblioteca do Acrobat Sign
- Criar um modelo de biblioteca
- Alterar o nome de um modelo de biblioteca
- Alterar o tipo de um modelo de biblioteca
- Alterar o nível de permissão de um modelo de biblioteca
- Copiar, editar e salvar um modelo compartilhado
- Baixar os dados de campo agregado de um modelo de biblioteca
- Transferir a propriedade de formulários web e modelos de biblioteca
- Fluxos de trabalho do Power Automate
- Visão geral da integração com o Power Automate e direitos incluídos
- Habilitar a integração do Power Automate
- Ações no contexto da página Gerenciar
- Acompanhamento do uso do Power Automate
- Criar um novo fluxo (exemplos)
- Acionadores usados para fluxos
- Importação de fluxos de fora do Acrobat Sign
- Gerenciar fluxos
- Editar fluxos
- Compartilhar fluxos
- Desabilitar ou habilitar fluxos
- Excluir fluxos
- Modelos úteis
- Somente admins
- Arquivar o contrato
- Arquivar o contrato de formulário web
- Salvar documentos de formulários web concluídos na biblioteca do SharePoint
- Salvar documentos de formulários web concluídos no OneDrive for Business
- Salvar documentos concluídos no Google Drive
- Salvar documentos de formulários web concluídos no Box
- Extração de dados do contrato
- Notificações de contrato
- Enviar notificações personalizadas por email com o conteúdo do contrato e o contrato assinado
- Receba notificações do Adobe Acrobat Sign em um canal do Teams
- Receba notificações do Adobe Acrobat Sign no Slack
- Receba notificações do Adobe Acrobat Sign no Webex
- Geração de contrato
- Gerar documento a partir de um modelo do Word e formulário do Power App, e enviar para assinatura
- Gere um contrato a partir de um modelo do Word no OneDrive e obter a assinatura
- Gerar contrato para a linha selecionada do Excel e enviar para revisão e assinatura
- Fluxos de trabalho de envio personalizados
- Compartilhar usuários e contratos
Integrar a outros produtos
- Visão geral das integrações do Acrobat Sign
- Acrobat Sign para Salesforce
- Acrobat Sign para Microsoft
- Outras integrações
- Integrações gerenciadas por parceiro
- Como obter uma chave de integração
Acrobat Sign Developer
- APIs REST
- Webhooks
- Sandbox
Suporte e solução de problemas
Documentação de pré-lançamento e cronograma de lançamentos do Adobe Acrobat Sign
O Adobe Acrobat Sign implementa pelo menos três atualizações por ano, categorizadas como versões principais ou secundárias. Atualizações secundárias adicionais podem ser lançadas conforme necessário para resolver problemas do sistema ou do cliente.
- As versões principais trazem atualizações importantes, novos recursos e vários aprimoramentos.
- As versões secundárias se concentram em melhorias menores e ajustes na experiência do usuário. Elas ocorrem entre as atualizações principais, geralmente uma ou duas vezes por ciclo.
Para evitar interrupções, os novos recursos são desabilitados por padrão e devem ser habilitados manualmente por um(a) admin de conta ou de grupo.
Para clientes da área de Saúde e Ciências Biológicas que exigem validação de conformidade, o Acrobat Sign possui parceria com um fornecedor terceiro que oferece um pacote de validação para cada versão principal que contém recursos, a fim de minimizar os fatores de risco.
Esta página de Notas de pré-lançamento é atualizada regularmente à medida que novas informações ficam disponíveis, portanto, o conteúdo é relativamente dinâmico.
Embora a página esteja traduzida, o processo leva tempo, o que pode resultar em versões traduzidas que são ligeiramente diferentes da versão oficial em inglês dos EUA.
Para obter informações mais precisas e atualizadas, recomendamos consultar a página em inglês dos EUA.
O Adobe Acrobat Sign segue um cronograma estruturado para publicar notas de versão e atualizações de documentação:
8 semanas antes da versão de produção
- A página de pré-versão publica um resumo dos recursos e atualizações esperados, geralmente quatro semanas antes do início da Sandbox.
- Todas as alterações de recursos após este ponto são anotadas na seção Errata.
- Problemas resolvidos não são incluídos neste estágio.
4 semanas antes da versão de produção (inicio da sandbox)
- A página de pré-versão é atualizada com a documentação detalhada sobre os recursos novos e atualizados.
- Os links para a documentação de suporte de pré-versão são adicionados conforme necessário e estão disponíveis somente em inglês dos EUA.
- A seção inicial de Problemas resolvidos é publicada (com as atualizações em andamento) nas próximas quatro semanas.
Dia do lançamento
- As notas oficiais da versão são atualizadas com os detalhes dos recursos finais e os links para a documentação de suporte da produção.
- A página de pré-lançamento é atualizada para destacar o próximo ciclo de lançamento de versão.
- A documentação é publicada após a verificação da versão no sistema ativo, normalmente após as 19h00 (horário do Pacífico), embora atualizações complexas possam demorar mais.
- A lista final dos Problemas resolvidos é adicionada às notas de versão em inglês dos EUA, e as versões traduzidas são atualizadas posteriormente.
Versão da Government Cloud
- O ambiente da Government Cloud geralmente é atualizado entre dois dias e várias semanas após a versão de produção, pois alguns recursos podem exigir avaliação adicional antes da implantação.
A documentação da sandbox foi projetada para o ambiente de produção. Links encontrados nos URLs de produção de destino do conteúdo de pré-lançamento, o que significa que esses links podem levar a uma documentação antiga ou resultar em uma 404, se a página de destino for nova e ainda não tiver sido publicada (por exemplo, quando o link estiver levando a um novo recurso na mesma versão).
As novas páginas serão publicadas quando a versão for publicada e os links serão resolvidos corretamente para seus URLs de produção.
Disponibilidade da sandbox
Clientes que acessam o ambiente de sandbox do Acrobat Sign geralmente podem acessar as funcionalidades da nova versão quatro semanas antes do lançamento.
- O ambiente da Sandbox precisa passar por todos os procedimentos de garantia de qualidade de produção no mesmo nível de qualidade que o ambiente de produção normal.
- A Adobe esforça-se para ter 99,9% de disponibilidade no ambiente de sandbox, mas os clientes devem observar que o SLA unificado da Adobe não cobre formalmente a sandbox.
- O ambiente de sandbox usa os mesmos procedimentos de página de status e interrupção que o ambiente de produção normal.
Este artigo contém informações de pré-lançamento. As datas de lançamento, recursos e outras informações estão sujeitas a alterações sem aviso prévio.
Adobe Acrobat Sign versão v17.0.1
Implantação da sandbox: 17 de fevereiro de 2026
Implantação da produção: 17 de março de 2026
Implantação da GovCloud: 19 de março de 2026
Funcionalidade aprimorada
- Criar uma cópia – Pontos de acesso expandidos, reutilização mais rápida de contratos.
Criar uma cópia agora está disponível diretamente nos filtros Em andamento e Aguardando você na página Gerenciar, bem como na página de confirmação pós-envio. Esses pontos de entrada adicionais facilitam a reutilização de contratos em mais pontos do ciclo de vida de envio, reduzindo a necessidade de reiniciar do zero.
Este recurso estará disponível no ambiente de sandbox em 20 de fevereiro de 2026.
Observação: com esta versão, os controles administrativos para desabilitar este recurso serão removidos do menu do administrador, estabelecendo Criar uma cópia como um recurso padrão disponível para todos os usuários qualificados.
- Ambientes disponíveis: sandbox, comercial, governamental | Níveis de serviço disponíveis: Acrobat Sign Solutions | Escopo de configuração: conta e grupo, habilitado por padrão.
Atualizações de REST API/Webhook
As atualizações abaixo são apresentadas nas notas de pré-lançamento para fins de divulgação. A documentação completa de atualizações de API e Webhook poderá ser encontrada na documentação do desenvolvedor do Acrobat Sign quando a atualização da versão for entregue aos servidores de produção.
- Exibição de email personalizada OEM 2.0 – Identidade mais clara do remetente e destinatário em experiências incorporadas e entrega correta de email.
Para parceiros OEM 2.0 que usam fluxos de trabalho incorporados, o Acrobat Sign agora exibe o endereço de email personalizado do usuário, em vez do endereço de email registrado do parceiro nas principais superfícies da interface e notificações. Contratos, filas como “Aguardando você” e endereços de email “Revisar e assinar” refletem consistentemente a identidade personalizada, preservando o endereço de email registrado internamente para autenticação e direitos. Isso melhora a clareza para remetentes e signatários e evita que emails sejam enviados para endereços registrados como de não entrega.
Ambientes disponíveis: sandbox, comercial | Níveis de serviço disponíveis: Acrobat Sign Solutions | Escopo de configuração: API - apenas parceiros OEM 2.0
- Notificação de webhook para falhas de entrega de SMS – Visibilidade em tempo real de envios de SMS com falha, correção automatizada e paridade com rejeições de endereço de email.
O Acrobat Sign agora emite um novo evento de webhook, AGREEMENT_PHONE_BOUNCED, quando um contrato enviado via SMS não pode ser entregue devido a problemas como números de telefone inválidos, rejeição da operadora ou linhas bloqueadas. Isso permite que os clientes detectem falhas de entrega de SMS quase em tempo real e acionem automaticamente ações de acompanhamento, como corrigir números de telefone, tentar novamente a entrega ou abrir casos de suporte, eliminando pontos cegos e reduzindo atrasos em fluxos de trabalho de assinatura mobile-first.
Ambientes disponíveis: Sandbox, Comercial, Governamental Níveis de serviço disponíveis: Acrobat Sign Solutions Escopo de configuração: API
- Cargas úteis de webhook – Campo extendedStatus de participante condicional adicionado para atualizações de participação dinâmica, melhorando a visibilidade do estado do participante.
As notificações de webhook agora incluem um campo extendedStatus em cada objeto de participante (memberInfos[]) quando o remetente modifica um contrato em andamento usando participação dinâmica. Este campo fornece detalhes adicionais do ciclo de vida do participante, mantendo o campo status existente inalterado para compatibilidade com versões anteriores.
{
"participantSets": [
{
"id": "",
"memberInfos": [
{
"company": "TestCo",
"email": "signer2@someDomain.dom",
"id": "CBJCHBCAABAAJiZV9cH",
"name": "Signer Two",
"status": "ACTIVE",
"extendedStatus": "REMOVED"
}
],
"order": ,
"role": "",
"status": ""
}
]
}
- Valores de status (inalterados): ACTIVE, REPLACED.
- extendedStatus valores: ATIVO, SUBSTITUÍDO, REMOVIDO, CONCLUÍDO.
Ambientes disponíveis: Sandbox, Comercial, Governamental Níveis de serviço disponíveis: Acrobat Sign Solutions Escopo de configuração: API
Errata de versão
Não há itens que tenham saído desta versão até agora.
Problemas resolvidos
| Problema | Descrição |
|---|---|
| 4543515 | Resumo: um evento de rejeição de email de webhook pode ser gerado incorretamente para um signatário válido após o signatário assinar com sucesso e o contrato avançar para a próxima etapa. Isso pode ocorrer quando um delegado no mesmo grupo de assinatura tem um endereço de email inválido e o remetente substitui o delegador original. Nesses casos, o sistema pode atribuir incorretamente o evento de rejeição “assinado em nome de...” ao signatário válido em vez do participante cujo email realmente é rejeitado. |
| Correção: a lógica de atribuição de evento foi corrigida para que os eventos de rejeição de email sejam associados apenas ao participante cujo email realmente é rejeitado. Um evento de rejeição não é mais gerado para um signatário válido que já concluiu a assinatura, e as notificações de webhook agora refletem o participante e endereço de email corretos. | |
| 4544548 | Resumo: as chaves de integração criadas pela interface web podem expirar após 10 anos, mesmo que a página de criação declare que a chave fornece “acesso permanente.” Quando uma chave atinge seu tempo de vida de 10 anos, as chamadas de API começam a retornar um erro de token expirado, o que pode interromper integrações existentes inesperadamente. |
| Correção: as mensagens da interface foram atualizadas para remover o texto “acesso permanente” e exibir claramente a data de expiração das chaves de integração. O texto atualizado agora declara que a chave mantém acesso até a data de expiração ou até ser revogada manualmente, fornecendo transparência sobre o tempo de vida padrão de 10 anos. | |
| 4546301 | Resumo: a entrega de evento de webhook pode ser atrasada em até várias horas em contratos com documentos muito grandes, mesmo quando a criação do contrato é concluída e as etapas iniciais de processamento parecem terminar em minutos. Durante a janela de atraso, o serviço de entrega de webhook pode receber repetidamente respostas DOCUMENT_NOT_AVAILABLE ao tentar recuperar documentos do contrato, e o evento de webhook pode não ser entregue até que o serviço pare de tentar novamente ou os documentos se tornem disponíveis. |
| Correção: o tratamento de disponibilidade de documentos foi corrigido para que contratos grandes façam a transição de forma confiável para um estado onde os documentos são recuperáveis sem respostas DOCUMENT_NOT_AVAILABLE prolongadas. Como resultado, os eventos de webhook são entregues sem atrasos de várias horas causados por tentativas de recuperação de documento contra documentos indisponíveis. | |
| 4547823 | Resumo: A mensagem privada de um destinatário pode não ser exibida para alguns signatários quando um contrato é criado no estado de criação pela API e depois editado na experiência Gerenciar. Neste cenário, a interface pode mostrar o valor da Mensagem Privada como “Nenhum” ou em branco, mesmo que os dados do contrato incluam o valor da mensagem privada correto.Este comportamento aparece em cenários de conta compartilhada onde um usuário muda para a conta de outro usuário para editar o rascunho, e pode afetar apenas destinatários específicos enquanto outros são exibidos corretamente. |
| Correção: uma verificação foi adicionada para recuperar o contexto de compartilhamento ativo e retornar a mensagem privada para usuários compartilhados autorizados. Como resultado, o valor da Mensagem Privada agora é exibido corretamente ao visualizar ou enviar um rascunho criado por API do fluxo de criação. | |
| 4548274 | Resumo: a Data de Modificação para modelos da biblioteca pode não atualizar após um modelo ser editado e salvo na nova experiência de modelo. Os usuários podem ver campos recém-adicionados ou atualizados no modelo, mas a Data de Modificação permanece inalterada na interface Gerenciar e nas visualizações administrativas, o que faz parecer que o modelo não foi modificado recentemente. Isso ocorre porque a nova experiência atualiza os campos de formulário por um caminho que não atualiza também o carimbo de data e hora modificado do modelo. |
| Correção: o comportamento de atualização da data modificada foi alinhado na nova experiência de modelos e nas operações de API relacionadas. O caminho de código que salva alterações de campo do modelo agora também atualiza a Data de Modificação do modelo para que reflita o horário real da alteração mais recente. | |
| 4548564 | Resumo: assinaturas e campos de formulário podem aparecer invisíveis no PDF assinado quando são colocados sobre anotações de carimbo pré-existentes no documento de origem. Nos modelos afetados, as anotações de Carimbo se sobrepõem ou obscurecem os campos interativos durante o processamento, fazendo com que as assinaturas concluídas e outros campos fiquem ocultos no documento assinado final. |
| Correção: o tratamento das anotações de carimbo foi atualizado para processar e nivelar com segurança as anotações de Carimbo pré-existentes a fim de que não obscureçam mais os campos de formulário ou assinaturas.Os campos colocados sobre áreas carimbadas agora permanecem visíveis durante a assinatura e no PDF totalmente finalizado. | |
| 4549103 | Resumo: um evento de rejeição de email pode ser registrado novamente para um destinatário anteriormente incorreto depois que o remetente substitui esse destinatário por um endereço de email válido.Em alguns casos, a trilha de auditoria pode mostrar um segundo evento de rejeição para o endereço de email antigo, e o status do contrato pode refletir “endereço de email rejeitado” mesmo que o novo destinatário receba, visualize ou assine o contrato com sucesso.Esse comportamento pode fazer parecer que o contrato ainda está direcionado tanto para o endereço de email antigo quanto para o novo. |
| Correção: o fluxo de trabalho de substituição de signatário foi atualizado para evitar o envio de emails de notificação adicionais para um destinatário substituído cujo email já foi rejeitado.O sistema agora verifica o histórico de rejeições anteriores antes de enviar notificações relacionadas à substituição, garantindo que nenhum novo evento de rejeição seja gerado para o endereço de email antigo após a substituição. | |
| 4549306 | Resumo: usuários cujos endereços de email contêm determinados caracteres especiais (por exemplo: um apóstrofo) podem não conseguir fazer logon nas páginas de logon públicas genéricas adobesign.com ou echosign.com.Após inserir o endereço de email e clicar no campo de senha, a página pode recarregar e limpar o campo de endereço de email em vez de redirecionar o usuário para o fragmento correto ou página de logon SSO.Isso impede que os usuários afetados concluam a autenticação e bloqueia integrações que dependem do ponto de acesso de logon público. |
| Correção: a lógica de resolução de shard de logon foi corrigida para tratar e decodificar adequadamente endereços de email contendo caracteres especiais antes de construir o URL de redirecionamento entre shards.Os usuários com formatos de endereço de email afetados agora são redirecionados corretamente para seu fragmento designado e página de logon SSO sem que o campo de endereço de email seja limpo. | |
| 4549331 | Resumo: assinaturas e outros campos de formulário podem aparecer ausentes ou invisíveis no PDF assinado quando determinados recursos de processamento de documentos estão habilitados e o PDF de origem contém coordenadas de caixa de página inválidas (por exemplo: valores incorretos de CropBox ou MediaBox).Neste cenário, campos que dependem de coordenadas de página podem renderizar fora da área de página visível, fazendo com que assinaturas concluídas pareçam ausentes mesmo que a assinatura seja concluída com sucesso. |
| Correção: o tratamento de caixa de página de PDF foi corrigido para normalizar com segurança valores inválidos de CropBox e MediaBox durante o processamento do documento.Como resultado, a inserção de assinatura e campo de formulário agora se alinha à área de página visível, e PDFs assinados exibem assinaturas conforme esperado. | |
| 4550367 | Resumo: a criação de um formulário web pode falhar com um “erro de servidor” genérico após selecionar Visualizar e Adicionar Campos quando a autenticação de signatário padrão do grupo do remetente está definida como Telefone e a conta não tem cota de autenticação por telefone disponível, mesmo que a autenticação de signatário do formulário web esteja definida para um método que não seja telefone (por exemplo: Adobe Sign).Como resultado, todos os usuários na conta afetada podem ser impedidos de criar formulários web em todos os documentos. |
| Correção: a criação de formulários web agora avalia a cota apenas para o método de autenticação realmente configurado para o signatário do formulário web e não aplica mais verificações de cota de autenticação por telefone baseadas apenas na configuração de autenticação padrão do grupo.Isso evita erros falsos de esgotamento de cota e permite que formulários web sejam criados normalmente. | |
| 4551011 | Resumo: quando um remetente carrega determinados PDFs digitalizados, adiciona campos de assinatura e envia o contrato, o PDF pode não exibir assinaturas visíveis após a conclusão da assinatura.Esse comportamento pode ocorrer quando o PDF carregado contém metadados de limite de página inválidos (as coordenadas MediaBox e CropBox aparecem invertidas), o que pode fazer com que as camadas de aparência de assinatura e outros campos sejam renderizadas fora da área de página visível. |
| Correção: o tratamento de limite de página do PDF foi atualizado para processar corretamente PDFs com valores de coordenadas de MediaBox e CropBox inválidos ou invertidos, para que o conteúdo de aparência de assinatura e campo de formulário seja renderizado dentro da área de página visível e permaneça visível no PDF assinado final. | |
| 4551427 | Resumo: alguns destinatários, que já têm contas ativas e corretamente provisionadas, recebem contratos como destinatários “pseudousuário”, então o contrato não aparece na visualização normal de gerenciar.Isso acontece quando os endereços de email dos destinatários incluem espaços no início ou no final, o que impede o sistema de corresponder o email ao usuário existente e faz com que um registro de pseudousuário seja criado. |
| Correção: a análise de email e a pesquisa de usuário foram atualizadas para normalizar os endereços de email dos destinatários (remover espaços no início e no final) antes de correspondê-los aos usuários existentes.Como resultado, os contratos endereçados a usuários existentes são entregues à conta registrada, em vez de ser criado um destinatário pseudousuário, mesmo se o email for inserido com espaços (em conteúdos de API e listas de destinatários de fluxo de trabalho). | |
| 4553198 | Resumo: quando um contrato inclui pelo menos um destinatário configurado para entrega por SMS e pelo menos um destinatário configurado para entrega somente por email, cancelar o contrato através da API não envia uma notificação de cancelamento por SMS para o destinatário de SMS.O contrato é cancelado com sucesso e as notificações por endereço de email são entregues, mas os destinatários de SMS não recebem uma mensagem de cancelamento. |
| Correção: o fluxo de trabalho de cancelamento foi corrigido para garantir que as notificações de cancelamento por SMS sejam enviadas a todos os destinatários configurados para entrega por SMS quando um contrato é cancelado, independentemente dos métodos de entrega de outros destinatários. | |
| 4554463 | Resumo: quando os contratos incluem botões de opção clonados que compartilham o mesmo nome de campo em documentos combinados, apenas uma instância da opção selecionada permanece selecionada no PDF final assinado.Embora os campos apareçam visualmente como caixas de seleção, eles são implementados como botões de opção.Após a assinatura, o valor selecionado não se propaga consistentemente em todas as instâncias clonadas, causando mapeamento incorreto ou incompleto da seleção esperada. |
| Correção: a lógica de tratamento de campos de formulário foi corrigida para que os botões de opção clonados armazenem e propaguem o valor de exportação selecionado, em vez de um valor de índice interno.Isso garante que todas as instâncias clonadas do mesmo campo de botão de opção reflitam a seleção correta no PDF assinado. | |
| 4554593 | Resumo: algumas integrações de parceiros que usam os pontos de acesso OAuth legados para atualizar tokens de acesso começaram a falhar com erros HTTP 401.O serviço rejeitou as solicitações de atualização de token com um erro indicando que o aplicativo não tem permissão para usar os pontos de acesso OAuth legados e deve usar os pontos de acesso OAuth v2.Isso impediu que os clientes autenticassem o Acrobat Sign através de aplicativos de parceiros, mesmo com integrações que funcionavam anteriormente. |
| Correção: o serviço de autenticação foi corrigido para que aplicativos de parceiros, configurados para usar o fluxo OAuth legado, possam atualizar tokens com sucesso novamente, em vez de serem incorretamente forçados aos pontos de acesso OAuth v2. | |
| 4554614 | Resumo: quando um signatário usa a experiência moderna de assinatura eletrônica em um contrato que requer autenticação do signatário e está configurado para exigir aceitação dos termos de uso antes da assinatura, clicar em Clique para assinar aciona um redirecionamento de 5 segundos para a experiência de assinatura clássica.A mensagem de redirecionamento avisa que as assinaturas e iniciais inseridas na assinatura moderna serão apagadas, forçando o signatário a inseri-las novamente e efetivamente assinar duas vezes. |
| Correção: o fluxo de atualização de token de assinatura foi corrigido para que, quando o signatário aceitar os termos de uso antes da assinatura, o token de assinatura reemitido mantenha os detalhes de autenticação do signatário.Isso impede que a etapa final de assinatura falhe na autenticação e elimina a substituição forçada da assinatura moderna para a experiência clássica. | |
| 4555656 | Resumo: sob condições específicas de tempo, uma transição de estado de contrato pode parecer ter sucesso, mas na verdade não altera o estado do contrato.Quando uma notificação de webhook é recebida antes que o processamento de backend seja concluído, chamadas de API subsequentes podem usar dados de status de contrato obsoletos.Nesta janela, certos métodos de transição de estado retornam HTTP 200 OK mesmo que o contrato não esteja em um estado válido para a transição solicitada.Como resultado, os fluxos de trabalho de automação podem assumir que a transição teve sucesso enquanto o contrato permanece no estado original. |
| Correção: a lógica de transição de estado de contrato foi atualizada para impor uma validação rigorosa antes de aplicar uma transição.Se o contrato não estiver em um estado válido, a API agora retorna uma resposta de erro clara em vez de retornar sucesso silenciosamente.Isso garante que transições inválidas sejam explicitamente rejeitadas, permite que sistemas de chamada tentem novamente de forma apropriada e impede que contratos permaneçam em um estado não intencional sem visibilidade. |