Chave do problema
Última atualização em
2 de abr de 2026
Notas de versão do Adobe Sign: 2021
Adobe Sign: março de 2021
Funcionalidade aprimorada
Formulários web com vários signatários
As contas que utilizam formulários web agora podem permitir vários destinatários externos no processo de assinatura.
Os destinatários adicionais são definidos pelo signatário inicial:
Use modelos de biblioteca para criar formulários web
Os autores agora podem usar modelos de biblioteca existentes para criar novos formulários web.O arquivo é importado com todos os campos intactos:
"Modo líquido" no Adobe Sign para visualização em dispositivos móveis
O Liquid Mode é um recurso opcional para gerar uma exibição responsiva para que você possa melhorar a visualização dos documentos com base no tipo de dispositivo do signatário.
O documento assinado é armazenado na versão "PDF" padrão, enquanto os destinatários podem ver o Liquid Mode em celulares e podem alternar para visualizar o documento original.
Agora você pode fazer upload do documento HTML e gerar uma visualização em modo líquido para celulares.
Mais detalhes sobre a opção Liquid Mode podem ser encontrados aqui >
Bloquear o valor do nome para usuários conhecidos ao assinar por meio de métodos de assinatura por imagem ou desenho
Há situações em que a capacidade de alterar o nome do destinatário durante a cerimônia de assinatura é indesejável. O Adobe Sign oferece flexibilidade nesse quesito em relação à preferência de nome do signatário. Em ambientes de maior conformidade, essa flexibilidade é inaceitável, por isso há um novo controle para bloquear os nomes dos destinatários do contrato.
Os administradores agora podem impedir que destinatários com valores de nome conhecidos alterem esses valores ao aplicar uma assinatura desenhada ou por imagem.
Situações em que o valor do nome é conhecido:
- Ao enviar para um destinatário com uma Adobe Sign ID
- Ao enviar o nome por meio da API
- Quando os campos de informações do signatário são preenchidos durante o preenchimento do formulário
- Quando o nome é bloqueado durante a conclusão de uma autenticação por KBA ou documento de identidade
Mais detalhes sobre este recurso podem ser encontrados aqui >
Melhorias na autenticação baseada em conhecimento
Foram adicionados controles ao método KBA de autenticação de identidade que podem exigir que o remetente forneça um nome para o destinatário e esse valor de nome fica bloqueado durante o processo de assinatura.
Opções para segurança aprimorada de email
Duas novas opções estão disponíveis para melhorar a segurança do email. Por padrão, ambas configurações estão ativadas:
- Incluir um link em emails para visualizar o contrato assinado
- Incluir uma imagem da primeira página do contrato em emails
- Ativada por padrão
- Quando habilitado, uma imagem da primeira página do contrato fica visível em algumas distribuições de email
Atualizações da API REST v6
Cabeçalhos padrão em toda solicitação da API REST V6
Por padrão, toda solicitação de API REST v6 agora tem os cabeçalhos padrão abaixo:
/AGREEMENTS
Todos os endpoints /agreements que têm um agreement id no caminho agora retornam um código de erro 404 AGREEMENT_DESTROYED se o acordo foi excluído por meio das ferramentas GDPR.
MODELOS DE BIBLIOTECA
PUT /libraryDocuments/{libraryDocumentId} - Ampliado para incluir o novo campo ownerId
Nota
Somente a API REST v6 é afetada.
Qualquer chamada de API REST v6 que não inclua esses cabeçalhos documentará explicitamente essa ausência.
- GET /libraryDocuments - Expandido para incluir o novo campo ownerEmail
- GET /libraryDocuments/{libraryDocumentId} - Expandido para incluir os novos campos: ownerId, ownerEmail e ownerName
Novos campos no objeto LibraryDocumentInfo:
Campos com comportamento atualizado:
FORMULÁRIOS WEB (/WIDGETS)
- POST /widgets - Usar um libraryDocumentId para criar um formulário web agora é compatível com um ID válido
Código de status adicionado:
- PUT /widgets - Usar um libraryDocumentId para criar um formulário web agora é compatível com um ID válido
Código de status adicionado:
- PUT /widgets/{widgetId} - Expandido para incluir o novo campo ownerId
Código de status adicionado:
Alterações de experiência
- GET /widgets/{widgetId} - Expandido para incluir os novos campos: ownerId, ownerEmail, ownerName, e creatorName
Novos campos no objeto WidgetInfo:
Campos com comportamento atualizado:
/MEGA SIGN
NEW:
- GET /megaSigns/{megaSignId}/formFields - Recupera os detalhes do campo de formulário de um contrato principal Mega Sign
Parâmetros:
Objeto de resposta:
- PUT /megaSigns/{megaSignId}/formFields - Atualiza os campos de formulário de um acordo Mega Sign
Parâmetros:
Objeto de resposta:
ATUALIZADO
- POST /megaSigns - AUTHORING foi adicionado como um valor de estado para dar suporte à criação de um modelo Mega Sign
Parâmetro alterado:
- PUT /megaSigns/{megaSignId}/state - AUTHORING foi adicionado como um valor de state para dar suporte à criação de um modelo Mega Sign.Como resultado, megaSignCancellationInfo não é mais um campo obrigatório
As páginas Início e Gerenciar modernas foram ativadas para todas as contas restantes
Todas as contas tiveram seu controle atualizado para habilitar as páginas modernas de Página inicial e gerenciar para seus usuários.
Os controles no menu de administrador permanecem disponíveis para contas que devem reverter para a experiência clássica:
Nível de serviço do Adobe Sign e ID da conta expostos no menu de administrador
Os administradores agora podem encontrar seu ID da conta na página Configurações globais:
O ID do grupo pode ser encontrado na página Configurações do grupo:
Configuração HIPAA explícita
Há uma nova página disponível que mostra claramente quando a conta está habilitada para gerenciar contratos sujeitos aos requisitos HIPAA.
- Esse controle é mostrado somente no nível da conta. Os administradores do nível de grupo não têm acesso
- Este controle é apenas de visualização, para indicar claramente quando a conta está configurada
- Entre em contato com seu gerente de sucesso ou o suporte para ativar a configuração HIPAA
Mais informações sobre as configurações HIPAA podem ser encontradas aqui >
O botão "Call to action" foi alterado para clientes que usam o aplicativo Outlook Desktop em sistemas Windows
Os destinatários que usam o aplicativo Outlook Desktop verão uma alteração no botão “chamada para ação” nos emails do Adobe Sign.
A nova experiência remove o botão HTML azul e, em vez disso, fornece um link de texto clicável:
Nota
Esta alteração afeta apenas aplicativos Outlook Desktop em sistemas Windows. Outros aplicativos de email e sistemas operacionais continuam recebendo o modelo com o botão azul.
Delegação de contratos com assinaturas digitais
A capacidade de delegar um contrato com assinaturas digitais anexadas foi aprimorada para permitir delegação da notificação por email original ao destinatário, através de delegação automática quando configurada por um usuário, e através da ação Substituir signatário atual na página Gerenciar .
Interface atualizada para a integração de pagamentos
A interface Payments foi atualizada para ter os controles de autenticação melhor expostos, criando um processo de configuração mais fácil.
O valor máximo para Governança de dados foi aumentado para 5475 dias (15 anos)
Clientes que usam regras de governança de dados para excluir automaticamente contratos do sistema Adobe Sign agora podem definir essa data de exclusão para um máximo de 15 anos (em vez de dez).
O rótulo de texto de nível de campo para validação do Número de Previdência Social dos EUA foi atualizado:
O rótulo de texto de nível de campo para validar o Número de Previdência Social dos EUA foi atualizado para esclarecer que o SSN é dos EUA:
Lembrete: Autenticação social foi removida
Conforme anunciado em novembro, o método de autenticação usando identidade social foi removido da lista de métodos de autenticação no menu Administrador.
Lembrete: Integração pessoal do Twitter foi removida
Conforme anunciado em dezembro, a possibilidade dos usuários fazerem conexões pessoais autenticadas com o Twitter foi excluída.
Usuários inativos receberão uma notificação por email quando incluídos em um contrato
Usuários definidos com status inativo agora recebem uma notificação por email instruindo o destinatário a delegar o contrato para outro usuário.
Problemas resolvidos
Adobe Sign: maio de 2021
Funcionalidade aprimorada
Transferir a propriedade de modelos de biblioteca e formulários web para um usuário diferente
Alterar o proprietário de um ativo pode ser feito por qualquer administrador na conta que tem acesso a ele.
O administrador pode atribuir a propriedade do ativo a qualquer usuário sob sua autoridade.
- Administradores de conta têm acesso a todos os ativos compartilhados e a todos os usuários. Portanto, os administradores de conta podem reatribuir a propriedade de qualquer modelo de biblioteca ou formulário web a qualquer outro usuário em sua conta
- Se o ativo estiver configurado para estar disponível apenas para um usuário (o proprietário), ele não será compartilhado e, portanto, não estará disponível para reatribuição a um novo proprietário
- Administradores de grupo podem acessar apenas modelos de biblioteca e formulários web nos grupos em que têm autoridade de administrador
- Administradores de grupo só podem reatribuir um ativo para um usuário cujo grupo principal esteja sob sua autoridade administrativa
PONTOS DE ACESSO DE API ATUALIZADOS COM SUPORTE À TRANSFERÊNCIA DE ATIVOS
Os pontos finais descritos abaixo estão disponíveis somente na API REST v6.
Estendido para oferecer suporte à atualização do proprietário do documento da biblioteca.
LibraryDocumentInfo:
Códigos de status de erro adicionais:
Estendido para oferecer suporte à atualização do proprietário do widget.
WidgetInfo:
Códigos de status de erro adicionais:
Novos campos no objeto LibraryDocument:
Novos campos no objeto LibraryDocumentInfo:
Campos com comportamento atualizado:
Novos campos no objeto WidgetInfo:
Campos com comportamento atualizado:
Alterações de experiência
O valor de retorno padrão do REST v6 GET /workflows{workflowId} foi alterado
A chamada de API da REST v6 GET /workflows{workflowId} foi atualizada para retornar a versão atual do WorkflowID (vs. o ID da versão original, que era o valor retornado antes da versão de maio)
Esta atualização alinha a experiência padrão da API com a experiência do Webhook, fornecendo o mesmo WorkflowID, o que deve melhorar o desenvolvimento e gerenciamento de aplicativos.
Se, por qualquer motivo, sua conta precisar que a API retorne o ID original (como fazia antes da versão de maio), entre em contato com o suporte para solicitar que sua conta retorne os IDs da versão base para fluxos de trabalho
Problemas resolvidos
Adobe Sign: junho de 2021
Usuários em vários grupos (UMG)
Os administradores em várias contas de grupo agora podem conceder aos usuários em suas contas acesso a vários grupos, abrindo a opção para utilizar grupos como uma forma de modelo de fluxo de trabalho, aplicando controles de envio e assinatura específicos para os modelos de biblioteca disponíveis para o grupo.
As contas corporativas e empresariais existentes que desejam atualizar podem analisar o processo de atualização aqui >
Um resumo das diferenças de impacto pode ser encontrado aqui >
Introdução ao Liquid Mode no Sign
Ative a exibição do Liquid Mode para celulares para HTML enviado por meio da página Enviar ou da API sendAgreement. A opção para ativar o Liquid Mode no Sign para HTML agora está disponível na lista de menus do Administrador no nível da conta e do grupo.
Detalhes completos sobre documentos do Liquid Mode podem ser encontrados aqui >
Nota
No momento, o Liquid Mode está disponível apenas nos ambientes NA1, NA2 e NA4.
Atualizações perfeitas de formulários da web
Os formulários da Web no status Rascunho podem ser editados para alterar:
- o Nome do formulário web
- do endereço de email do(s) contrassignatário(s)
- o endereço de email das partes em CC
- os arquivos anexados que serão editados
- os campos no formulário web (anteriormente disponível)
Atualizar um formulário web Ativo permite editar os elementos de formulário sem alterar o URL original, permitindo um processo tranquilo se você precisar atualizar o conteúdo de um formulário web que já foi incorporado ou enviado ao seu público-alvo. Os elementos que podem ser editados são:
- os arquivos (documentos) e campos aplicados aos recipients
- autenticadores (na página Gerenciar)
- Partes copiadas no email (na página Gerenciar)
Nota
Para ativar a ótima funcionalidade de formulários da Web, você deve ativar a opção Permitir participantes adicionais no menu Configurações globais:
Carimbo de participação: Título do controle e exibição da empresa
Foram adicionados controles para permitir ou suprimir o recipient Título e Empresa (derivado do perfil de usuário) no campo de carimbo do participante.
Mais detalhes podem ser encontrados na página Tipos de campo >
Opções de pesquisa aprimoradas: Correspondências de prefixo e frase
Foram introduzidas opções de pesquisa avançadas para permitir padrões de pesquisa mais específicos que ajudarão a reduzir a lista de contratos devolvidos.
Mais detalhes sobre como a pesquisa funciona no Adobe Sign podem ser encontrados aqui >
OAuth 2.0 é o novo padrão
Uma nova versão (aprimorada) do endpoint OAuth foi adicionada para evitar erros de uso. Com esta versão:
- api_access_point / web_access_point retorna somente na Solicitação de token de acesso (no corpo)
- O Adobe Sign não aceita o segredo como um parâmetro de consulta
- A rotação do segredo do cliente é compatível
O endpoint OAuth v1 continuará funcionando para conexões existentes nos próximos meses para garantir o acesso contínuo.
A descontinuação do OAuth v1 será anunciada na página de notificações técnicas quando programada.
Rotação de segredo do cliente
Os Segredos do cliente do aplicativo podem ser alterados por qualquer administrador com acesso à ID do aplicativo na interface do Adobe Sign:
Alterações de experiência
Os administradores de grupo podem ver somente os aplicativos de API que estão sob sua autoridade enquanto administradores
A visibilidade dos aplicativos anexados à conta agora é limitada para mostrar apenas os aplicativos que estão no escopo administrativo do usuário. Somente administradores de grupo verão a alteração de comportamento:
- Os usuários veem os aplicativos que eles possuem
- Administradores de grupo veem os aplicativos relativos aos grupos sobre os quais têm autoridade de administrador
- Os administradores de conta veem todos os aplicativos na conta
O envio de email ao remetente quando um contrato for concluído foi atualizado
A notificação final de email em função de um contrato enviada ao remetente foi atualizada para fornecer uma lista abrangente de todas as partes notificadas sobre o contrato concluído.
Somente o remetente original receberá este modelo de email.
Resultado da API REST v6 atualizado para GET /agreements/{agreementId}/signingUrls
Antes da versão de junho, ao chamar GET /agreements/{agreementId}/signingUrls, a API retornaria um 404 imediatamente após a criação do contrato.
Por pouco tempo após o erro 404 ser apagado, a resposta retornaria uma resposta não-404, mas incluiria apenas os signingURLs do remetente. (Enquanto a participação do signatário ainda estava sendo definida.)
Após o lançamento em junho de 2021, um 404: o código AGREEMENT_NOT_EXPOSED será retornado até que a lista completa de URLs de assinatura seja concluída, quando um código 200 for entregue.
Os clientes que não desejam continuar tentando a chamada de API até que a resposta 200 seja retornada são incentivados a usar Webhooks e responder ao evento AGREEMENT_CREATED.
Problemas resolvidos
Adobe Sign: agosto de 2021
Mudança de experiência
- Suporte ao Aadhaar International – os clientes de todas as instâncias do Adobe Sign agora podem usar o serviço opcional Aadhaar como um provedor de assinatura digital. Anteriormente, essa opção estava disponível apenas para contas na instância IN1. O complemento Aadhaar pode ser comprado a um custo adicional por transação de assinatura.
- Atualização REST v6: POST /users – A chamada de API REST v6 POST /users foi atualizada para criar o usuário no Grupo padrão da conta se o parâmetro opcional primaryGroupId não estiver definido. Somente a v6 da API REST é afetada por essa alteração.
Problemas resolvidos
|
|
Descrição |
|---|---|
|
4299495 |
Corrigido um problema no Designer de fluxo de trabalho que impedia que uma URL definida pelo cliente nas instruções funcionasse. |
|
4308294 |
Corrigido um problema no arquivo CSV de relatório onde os campos Para e Nome do destinatário poderiam ficar em branco quando o mesmo email de destinatário é usado mais de uma vez no contrato. |
|
4310569 |
Os modelos do Adobe Sign foram removidos das opções de sandbox. |
|
4311098 |
Corrigido um problema onde administradores de grupo não conseguiam atualizar usuários em um grupo por upload em massa de CSV. |
|
4311723 |
Corrigido um problema onde a chamada de API GET /groups/ID/users falharia se o usuário estivesse em uma instância diferente do Adobe Sign. |
|
4312103 |
Corrigido um problema onde usuários SAML criados via upload em massa ficariam em estado Criado (em vez de principal). |
|
4312309 |
Corrigido um problema em que administradores de grupo não conseguiam reatribuir a propriedade de formulários web se outros usuários em seu grupo os tivessem criado. |
|
4312840 |
Corrigido um problema com a ativação de novos usuários quando um segundo email de ativação era enviado para o novo usuário e o link do segundo email era usado. |
|
4314751 |
Corrigido um problema onde a opção de recusar o contrato não estava visível ao assinar em nome de outro usuário. |
|
4315033 |
Corrigido um problema em que administradores da conta não conseguiam redefinir senhas quando o modo SAML estava definido como Obrigatório. |
|
4315605 |
Corrigido um problema em que imagens de documento de identidade não eram processadas com sucesso. |
|
4316057 |
Corrigido um problema em que o Documento de identidade produzia um erro indicando que os quatro cantos do documento não puderam ser encontrados. |
|
4316474 |
Corrigido um problema em que "Assinar em nome de" estava visível em contas em que a opção não estava habilitada. |
|
4316659 |
Correção de um problema em que o endereço de email de “actingUserEmail” em uma chamada de GET/agreements/id retornava um email gerado pelo sistema após a assinatura completa do contrato. |
|
4317095 |
Corrigido um problema onde um nome de destinatário seria importado para o rótulo Participante 1 quando a autenticação baseada em conhecimento era usada para o primeiro signatário. |
|
4317221 |
Corrigido um problema em que e-mails de notificação automática para webhooks com falha seriam enviados ao criador do webhook apesar de estar configurado para não notificá-lo. |
|
4317347 |
Corrigido um problema em que a autenticação do OAuth no Power Automate redirecionava o usuário para a página inicial. |
|
4317429 |
Corrigido um problema onde administradores não conseguiam atualizar a propriedade Pode enviar para usuários ao atualizar via upload em massa de CSV. |
|
4317548 |
Corrigido um problema em que alguns clientes usando o iPad veriam a página da Web em vez da página otimizada para dispositivos móveis. |
|
4317629 |
Corrigido um problema de exibição em que nomes que contêm apóstrofe exibiam o código HTML do apóstrofe. |
|
4318175 |
Correção de um problema em que os usuários enfrentavam um erro ao arquivar uma conta por meio do link de email. |
|
4319012 |
Correção de um problema em que os usuários criados via REST v5 e v6 POST /users não eram criados no grupo padrão. |
|
4320197 |
Corrigido um problema em que o Relatório de identidade do signatário não podia ser baixado da página Gerenciar devido ao botão estar inativo. |
Adobe Sign: setembro de 2021
Funcionalidade aprimorada
- Sandbox — os clientes da camada Enterprise têm a opção de comprar acesso a um ambiente Sandbox para testar modelos, workflows de clientes, aplicativos de API e muito mais. Esses objetos podem ser movidos da produção para a sandbox para atualizações em um ambiente seguro e, em seguida, movidos de volta para a produção depois que as atualizações são verificadas e estão prontas para implantação.
- Suporte à assinatura digital ECDSA - O Adobe Sign agora oferece suporte a assinaturas digitais mais seguras e eficientes baseadas no formato ECDSA, que usa criptografia de curva elíptica conforme definido no padrão ANS X9.62-2005.
As curvas NIST com funções de hash SHA-2, conforme definidas pelas normas FIPS, agora são compatíveis, dando aos nossos parceiros provedores de serviços de confiança (TSP) do Cloud Signature Consortium a opção de fornecer aos signatários credenciais de curva elíptica mais rápidas e seguras, incluindo aquelas que atendem aos requisitos recomendados para uso pelo governo federal dos EUA e pelo de Singapura.
- Liquid Mode atualizado — A experiência de assinatura do Liquid Mode foi estendida além dos contratos para incluir formulários web. Os formulários do Liquid Mode podem melhorar drasticamente a experiência do signatário, reduzindo a necessidade de ter que pinçar e aplicar zoom para visualizar o conteúdo do formulário e, ao mesmo tempo, melhorando o foco nos campos que precisam ser preenchidos.
Além disso, o Liquid Mode não está mais restrito aos fragmentos norte-americanos.Todas as contas corporativas e empresariais agora têm acesso independentemente da localização.
- Os novos TSPs — Cleverbase (Países Baixos), PrimeSign (Áustria), Sectigo (Global) e TrustPro (Irlanda) são os novos Provedores de serviço confiáveis do Cloud Signature Consortium que fornecem certificados para aplicar assinaturas digitais seguras que atendem aos mais altos padrões e requisitos de conformidade.
- Personalizar os campos Para e CC nos cabeçalhos de email para destinatários - Clientes que se preocupam com o vazamento de endereços de email através dos cabeçalhos de email para destinatários podem optar por ocultar os valores de endereço de email nos campos Para e CC.
- Essa opção está disponível para contas corporativas e de camadas de negócios e pode ser configurada nos níveis de conta e grupo.
- Os controles do recurso podem ser acessados ao navegar até Configurações da conta > Configurações de email > Personalizar campos Para e CC.
Alterações de experiência
- Aceitação dos termos de uso da Adobe nas páginas de assinatura eletrônica - Para estar em conformidade com os requisitos legais da Adobe, o Adobe Sign está atualizando o comportamento de aceitação dos termos de uso (ToU) na página de assinatura eletrônica. Na nova experiência, todos os destinatários "desconhecidos" devem aceitar os termos de uso e política de privacidade do Adobe Sign (clicando no botão Continuar ) antes de interagir com o contrato. Esta aceitação é distinta de qualquer ToU personalizado que a conta do cliente possa ter configurado, que continuará a seguir a configuração de aceitação TOU/CD da conta.
- Um destinatário "desconhecido" é qualquer endereço de email que não seja um email de usuário registrado e ativo em uma conta confiável.
- Os usuários "conhecidos" aceitaram o ToU do Adobe Sign como parte do processo de registro quando verificaram sua conta de usuário. Portanto, não serão solicitados a aceitá-lo novamente.
Veja abaixo um exemplo do fluxo de consentimento implícito para um contrato com um ToU personalizado e configurado pelo cliente:
- Aceite os termos de uso do Adobe Sign selecionando o botão Continuar (depois de abrir o contrato).
- Preencha os campos do contrato conforme necessário.
- Aceite a Divulgação do Cliente e os ToU personalizados selecionando o botão Clique para Assinar.
- Valores de nome de bloqueio estendidos a assinaturas digitadas - A versão de março introduziu uma configuração para ativar/desativar a capacidade de um recipient editar seu valor de nome ao assinar, desde que o nome tenha sido fornecido ou conhecido (por meio de API ou perfil de usuário). As assinaturas digitadas foram excluídas desse recurso, resultando na capacidade de alguns signatários alterarem o valor do nome durante o processo de assinatura. A versão de setembro atualiza esse recurso para manter a configuração de bloqueio de nome para todos os tipos de assinatura, inclusive assinaturas digitadas.
- Clientes que habilitaram Digitar nome e iniciais e desabilitaram Signatários podem alterar nome ou iniciais verão uma mudança de comportamento – o valor do nome não é mais editável durante o processo de assinatura para assinaturas digitadas.
- Os clientes que desejam permitir a edição do nome-valor durante o processo de assinatura devem ativar a configuração Os signatários podem alterar o nome ou as iniciais (no menu Preferências de assinatura ).
- Usuários inativos podem assinar contratos — o Adobe Sign está tratando os usuários inativos como se fossem desconhecidos do sistema (para fins de assinatura de contratos vinculados). Quando um usuário inativo precisa assinar um contrato, uma nova userID de uso único é criada expressamente para a finalidade de assinar esse contrato. A userID de uso único é independente da userID inativa e da conta que a controla. Ela tem várias ramificações:
- Os contratos enviados a um usuário inativo podem ser assinados, pois o status Inativo não se aplica à userID de uso único gerada para o contrato.
- Os contratos assinados pela userID de uso único não são ativos da userID inativa e não residem na conta da userID inativa.
- Os compartilhamentos da userID inativa não refletirão contratos assinados por userIDs de uso único.
- Gerar relatórios com a userID inativa não refletirá contratos assinados pela userID de uso único.
- Se a userID inativa for reativada, eles não verão os registros dos contratos assinados pelas userIDs de uso único na página Gerenciar.
Há duas exceções ao comportamento acima:
- Contratos enviados ao usuário antes de serem sinalizados como Inativos não podem ser assinados (o contrato já estava vinculado à userID inativa).
- Usuários explicitamente configurados para não ter permissão para assinar contratos continuarão sendo impedidos de qualquer ação de assinatura.
Os usuários inativos não podem fazer logon no sistema do Adobe Sign e enviar contratos sob sua autoridade (por qualquer método).
- Segurança aprimorada para acesso a formulários da web por senha — os formulários Web agora contam com um atraso após várias tentativas malsucedidas de acessar um URL protegido por senha.
- Suporte ao Aadhaar International — agora os clientes de todas as instâncias do Adobe Sign podem usar o serviço opcional Aadhaar como um provedor de assinatura digital. Anteriormente, essa opção estava disponível apenas para contas na instância IN1. O complemento Aadhaar pode ser comprado a um custo adicional por transação de assinatura.
- Compartilhamento limitado de contratos - O compartilhamento de contratos foi limitado ao compartilhar o contrato para um endereço de email externo.
- As contas com várias licenças podem compartilhar qualquer contrato por até dez vezes.
- Contas individuais podem compartilhar um contrato até cinco vezes.
- O compartilhamento de contratos com usuários internos é irrestrito.
- As contas com várias licenças podem compartilhar qualquer contrato por até dez vezes.
- O nome personalizado da empresa na autenticação por telefone foi removido do serviço — o valor personalizável do nome da empresa que podia ser inserido no método de autenticação por telefone foi removido do serviço conforme anunciado na Notificação técnica de junho.
- As contas habilitadas para HIPAA agora podem acessar os controles de imagens e links em emails de recipients na página Global/Configurações de grupo.
- A ordem em que os anexos de arquivo são incluídos no PDF final foi atualizada para classificar por número de página primeiro e depois por posição do campo (ao ler da esquerda para a direita; de cima para baixo)
- O recurso Substituir recipient na nova página Gerenciar agora permite que o remetente inclua uma mensagem opcional para o novo recipient.
Consulte o recurso Substituir recipient para obter mais detalhes >
- Os signatários externos que acessam contratos concluídos agora deverão passar por um processo de autenticação quando a autenticação de vários fatores tiver sido configurada para o contrato (em vez de fazer logon no Adobe Sign).
- Os formulários web agora informam os valores de campo de formulários web não verificados ao serem acessados dados de campo por meio do recurso Baixar dados do campo de formulário na página Gerenciar.
Atualizações da API
- Opção Ler contrato para formulários Web — duas novas chamadas da API REST v6 estão disponíveis para fornecer acesso à visualização de formulários Web:
- GET /widgets/<resourceId>
- GET /widgets/<resourceId>/combinedDocument/url
- GET/workflows/{workflowId} agora retorna a função de participante na resposta.
Problemas resolvidos
| 4292343 | Aprimoramento da clareza da assinatura ao usar a opção de assinatura TYPE em dispositivos móveis. |
| 4295123 | Correção de um problema que podia impedir que as assinaturas digitais ficassem visíveis ao serem abertas em um navegador. |
| 4299289 | Aprimoramento da experiência Substituir recipient permitindo que o remetente inclua uma mensagem para o novo recipient. |
| 4299857 | Correção de um problema que podia fazer com que um contrato assinado não aplicasse o selo do certificado. |
| 4304261 | Correção de um problema que podia fazer com que a opção Ler contrato não fosse preenchida no menu Opções |
| 4308516 | Correção de um problema em que os usuários eram solicitados constantemente a obter o consentimento do administrador ao usar o OneDrive |
| 4310225 | Correção de um problema com contratos que contêm várias assinaturas que acionavam um erro de servidor: Mensagem de erro: a assinatura aplicada a este documento é inválida. Apague e assine novamente. |
| 4310416 | Atualização da API REST v5 para criar usuários em um estado ativo quando criada usando POST /users |
| 4311287 | Correção de um problema em que o botão de navegação Grupo desaparecia em contas habilitadas para UMG depois que os usuários eram removidos de um grupo. |
| 4311956 | Correção de um problema em que o tamanho da fonte designada para um campo não era refletido na experiência do signatário. |
| 4312302 | Correção de um problema que removeria a opção Redefinir senha se o modo SAML fosse definido como Obrigatório. |
| 4312735 | Correção de um problema que fazia com que as notificações de eventos compartilhados fossem entregues quando as notificações compartilhadas estavam desativadas. |
| 4313025 | Correção de um problema em que uma função Preenchedor de formulários não podia preencher funções não atribuídas quando o roteamento híbrido estava ativado. |
| 4313030 | Correção de um problema em que as contas ativadas por UMG disparavam um erro usando um fluxo de trabalho personalizado se o grupo principal do remetente não tivesse permissão para enviar. |
| 4313264 | Atualização da configuração HIPAA habilitada para permitir o acesso às configurações de link/imagem de email na página Configuração global. |
| 4315839 | Correção de um problema com workflows personalizados que não permitiam o pré-preenchimento de campos quando o remetente também era o segundo recipient. |
| 4316058 | Comportamento do campo de relatório atualizado para permitir zeros à esquerda em campos de texto. |
| 4317382 | Correção de um problema com botões de opção que exibiam o código HTML para apóstrofos na dica de ferramenta |
| 4317978 | Atualização do modo como os Anexos de arquivo são ordenados no PDF final para agrupar anexos com base no número de página do campo em primeiro e na posição relativa do campo em segundo (ao ler da esquerda para a direita; de cima para baixo). |
| 4318598 | A chamada de API REST v6 de GET/workflows/{workflowId} agora retorna a função de participante na resposta. |
| 4318606 | O recurso "Baixar dados do campo de formulário" na página Gerenciar agora retorna valores de campo para formulários web que ainda não foram verificados. |
| 4318617 | Correção de um problema em que as contas ativadas pelo UMG não permitiam que um administrador de grupo reenviasse um convite. |
| 4318679 | Correção de um problema intermitente que podia fazer com que os documentos com assinatura manuscrita não fossem carregados. |
| 4318926 | Correção de um problema que podia acionar um erro (a funcionalidade de cookie fica desativada no navegador) ao gerar um contrato de um dispositivo móvel. |
| 4318991 | Correção de um problema que podia fazer com que a configuração de falha máxima de logon fosse ignorada se SAML fosse definido como Permitido. |
| 4319068 | Os recipients externos agora devem passar por um segundo processo de autenticação de fator (em vez de fazer logon no Adobe Sign) para obter acesso aos contratos concluídos quando a autenticação de vários fatores estiver configurada. |
| 4319422 | Correção de um problema em que um recipient podia ser substituído sem confirmar a senha (para contrato autenticado por senha) |
| 4319455 | Correção de um problema no compartilhamento avançado em que as configurações podiam não ser persistentes após serem salvas. |
| 4320123 | Correção de um problema que podia acionar um erro durante a tentativa de exibir e aprovar um contrato na página Gerenciar. |
| 4320205 | Correção de um problema que podia impedir o progresso de salvamento ao pré-preencher um contrato usando o compartilhamento avançado. |
| 4320542 | Correção de um problema de contas habilitadas para UMG em que todas as afiliações de grupo de um usuário podiam ser removidas se um grupo fosse removido usando a Pesquisa. |
| 4321357 | Correção de um problema que podia acionar um erro na página de envio quando o KBA era selecionado para autenticação e a opção "Exigir nome no envio" estava ativada. |
| 4322445 | Criação aprimorada para garantir uma cor de fundo consistente. |
| 4322956 | Correção de um problema com modelos de email personalizados nos quais os recipients não visualizavam o endereço de email real do signatário. |
| 4323609 | Em desenvolvimento - Correção de um problema em que os contratos concluídos ao fazer upload de um documento assinado não acionavam a notificação do webhook AGREEMENT_WORKFLOW_COMPLETED. |
| 4323968 | Aprimoramento do recurso de bloqueio de assinatura para incluir assinaturas digitadas quando o valor do nome é fornecido por meio de perfil ou API. |
Adobe Sign: outubro de 2021
Funcionalidade aprimorada
- Links para denunciar abuso — contas de pequenas empresas e individuais agora incluem um link para os recipients acessarem um método a fim de relatar atividades potencialmente abusivas relacionadas a solicitações de contrato recebidas.
- Integração com Notarize - a integração do Adobe Sign com a plataforma de autenticação online remota (RON) da Notarize, Inc. permite que os clientes adicionem este serviço às suas transações com o Adobe Sign. Disponível para habilitação para clientes dos EUA de níveis corporativo e comercial, vendido diretamente pela Adobe por meio do programa ETLA. As transações da Notarize podem ser compradas como um complemento por um custo adicional, apenas para esses clientes.
- Enviar atualizações nas páginas - Clientes com autenticação habilitada podem selecionar a opção Requer notarização no documento do recipient, à direita do método de autenticação:
- Enviar atualizações nas páginas - Clientes com autenticação habilitada podem selecionar a opção Requer notarização no documento do recipient, à direita do método de autenticação:
Nota
Os clientes que usam a página Enviar incorporada em seus aplicativos ou integrações também terão acesso à funcionalidade do tabelião.
Depois que o contrato é configurado e o remetente clica em Próximo, ele recebe opções de configuração adicionais para o processo de autenticação:
- Atualizações de API - Há atualizações significativas nas APIs para oferecer suporte à Integração do Notarize:
POST /agreements
A API POST /agreements foi atualizada para oferecer suporte ao envio de um contrato para autenticação.
- Uma nova função, NOTARY_SIGNER, deve ser usada para indicar um participante de uma sessão notarial.
- Um novo atributo NotaryInfo foi adicionado à definição AgreementInfo para conter todas as opções associadas à criação de um novo contrato que exija autenticação.
|
Nome do parâmetro |
Objeto REST |
Descrição |
||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
memberInfos |
ParticipantInfo[] |
A matriz de objetos ParticipantInfo, contendo dados específicos do participante (por exemplo, email). Todos os participantes na matriz pertencem ao mesmo conjunto. |
||||||||||||||||
|
Função |
|
A função assumida por todos os participantes no conjunto (signatário, aprovador etc.) |
Extensão FileInfo
A definição de FileInfo terá de ser expandida para indicar quais documentos devem ser autenticados.
|
Nome do parâmetro |
Tipo |
Padrão |
Obrigatório |
Descrição |
|---|---|---|---|---|
|
documento |
Document |
|
opcional |
Um documento associado ao contrato. |
|
label |
Sequência de caracteres |
|
opcional |
O valor de rótulo exclusivo de um elemento de informações de arquivo. No caso de um fluxo de trabalho personalizado, isso mapeará um arquivo para o elemento de arquivo correspondente na definição do fluxo de trabalho. |
|
libraryDocumentId |
Sequência de caracteres |
|
opcional |
ID de um documento da biblioteca existente que será adicionado ao contrato |
|
transientDocumentId |
Sequência de caracteres |
|
opcional |
ID de um documento temporário que será adicionado ao contrato |
|
autenticar |
verdadeiro |
falso |
opcional |
Indica que este documento precisa ser autenticado. |
Extensão ParticipantInfo
A definição de ParticipantInfo foi expandida para permitir que o método de autenticação notarial seja especificado.
|
Nome do parâmetro |
Tipo |
Padrão |
Obrigatório |
Descrição |
|---|---|---|---|---|
|
|
Sequência de caracteres |
N/A |
obrigatório |
Email do participante. |
|
notaryAuthentication |
Enum |
MULTI_FACTOR_AUTHENTICATION |
opcional |
MULTI_FACTOR_AUTHENTICATION - A autenticação notarial é executada usando um método de autenticação de dois fatores |
NotaryInfo
Um novo campo opcional notaryInfo foi adicionado à definição de AgreementInfo para conter o objeto NotaryInfo que especifica opções adicionais associadas com autenticação.
|
Nome do parâmetro |
Tipo |
Padrão |
Obrigatório |
Descrição |
|---|---|---|---|---|
|
notaryType |
Enum |
Se somente o Serviço Notarize de Tabelião sob demanda estiver ativado na conta, |
obrigatório |
NOTARIZE_NOTARY - O Serviço Notarize fornece o tabelião |
|
payment |
Enum |
BY_SENDER |
opcional |
Só se aplica se o tipo == NOTARIZE_NOTARY |
|
appointmentStart |
Sequência de caracteres |
"" |
opcional |
Sequência formatada ISO_DATE_TIME Consulte ISO_ZONED_DATE_TIME |
|
note |
Sequência de caracteres |
nenhuma |
opcional |
Notas da sessão de autenticação. |
|
notaryEmail |
Sequência de caracteres |
"" |
opcional |
email para trazer seu próprio tabelião |
Exemplo /agreement
PUT|GET /agreements/{aid}
A API PUT /agreements/{aid} oferecerá suporte à atualização de um contrato com opções de autenticação. A API GET /agreements/{aid} retornará todas as opções definidas para a notarização do contrato. Consulte a seção POST /agreements para exibir atributos atualizados.
Códigos de erro
Os códigos de erro existentes para POST /agreements permanecem inalterados. Definimos um novo código de erro, conforme fornecido abaixo:
|
Código de erro REST |
Código do status HTTP |
Mensagem |
Cenário |
|---|---|---|---|
|
PERMISSION_DENIED |
403 |
A configuração do usuário ou o token de escopo OAuth não permitem o envio de contrato para autenticação. |
Esse erro será lançado quando a função for definida como NOTARY_SIGNER e o chamador da API (isto é, o remetente em potencial) não tiver o recurso de tabelião ativado e/ou se o provedor de serviços de tabelião não estiver definido. |
Impacto da documentação
No objeto AgreementInfo da solicitação, o elemento "status" incluirá o novo status do contrato "WAITING_FOR_NOTARIZATION".
POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens
A API pode ser usada pelos clientes (signatários notários) para obter um token de assinatura que permite concluir a fase de assinatura eletrônica do fluxo.
- O novo recurso de assinatura foi adicionado para capturar a nova função — ACCEPT_BEFORE_NOTARIZATION.
- Os tokens de assinatura não devem ser obtidos para concluir a fase de notarização.
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status
A API pode ser usada por clientes (signatários notários) para concluir a fase de assinatura eletrônica do fluxo. Para acomodar a nova função, um novo valor de status enum foi introduzido — ACCEPTED_BEFORE_NOTARIZATION.
|
Atributo |
Tipo |
Descrição |
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Status |
Enum<String>
|
|
||||||||||||||
O signatário notário pode seguir a sequência abaixo de chamadas de API para concluir a fase de assinatura eletrônica:
- GET /agreements/{agreementId}/members - para obter a ID do participante e a ID do conjunto de participantes do signatário notário
- POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens - para solicitar o token de assinatura para o signatário notário com o recurso ACCEPT_BEFORE_NOTARIZATION
- POST /transientDocuments - para fazer upload do documento revisado
- PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status - enviar o documento revisado e completar a fase de assinatura eletrônica.
Novo evento do webhook
Os clientes podem se inscrever no novo evento webhook, AGREEMENT_READY_FOR_NOTARIZATION, para serem notificados quando o contrato estiver pronto para autenticação. O evento não é visível na interface de webhooks e pode ser assinado por meio da chamada da API POST /webhooks.
Impacto da documentação
As APIs a seguir não foram modificadas, mas a respectiva documentação foi atualizada para incluir o novo status de contrato "WAITING_FOR_NOTARIZATION" ou a nova função "NOTARY_SIGNER".
GET /agreements
Em resposta ao objeto UserAgreements/UserAgreement, o elemento "status" agora inclui o status correspondente "WAITING_FOR_NOTARIZATION".
GET /agreements/{agreementId}
Em resposta ao objeto AgreementInfo, o elemento "status" agora inclui o status correspondente "WAITING_FOR_NOTARIZATION".
GET /agreements/{agreementId}/events
A API foi atualizada para dar suporte a novos eventos READY_TO_NOTARIZE e NOTARIZED.
Em resposta ao Evento de objeto
- O elemento "participantRole" agora inclui a nova função NOTARY_SIGNER.
- O elemento "type" inclui os novos eventos READY_TO_NOTARIZE e NOTARIZED. O elemento "description" será "Documento enviado para notarização" e "Documento autenticado recebido", respectivamente
GET /agreements/{agreementId}/members/participantSets/{participantSetId}
Em resposta ao objeto DetailedParticipantSetInfo, o elemento "status" agora inclui o status correspondente "WAITING_FOR_NOTARIZATION".
PUT /agreements/{agreementId}
O objeto Solicitar AgreementInfo agora inclui o status "WAITING_FOR_NOTARIZATION".
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}
O status WAITING_FOR_NOTARIZATION é um dos valores de elemento "status" no objeto DetailedParticipantSetInfo.
POST /agreements/{agreementId}/view
O status WAITING_FOR_NOTARIZATION foi adicionado como uma das exibições permitidas.
GET /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingInfo
Se o participante especificado no caminho de solicitação tiver uma função de signatário notário, a API retornará a configuração de assinatura ACCEPT_BEFORE_NOTARIZATION, assim como em todas as outras configurações de assinatura para este contrato/participante.
Problemas resolvidos
| Problema | Descrição |
| 4308901 | Correção de um problema em que delegar um contrato com autenticação por telefone exibia um erro, se o número de telefone delegado tivesse o mesmo código de país. |
| 4314113 | Correção de um problema em que as datas de expiração padrão não podiam ser editadas pelos usuários ao enviar um novo contrato |
| 4318558 | Correção de um problema em que a substituição do destinatário pela autenticação por telefone exibia o erro “A ID do conjunto de participantes especificada é inválida” |
| 4319038 | Correção de um problema em que o remetente não recebia a opção de “Verificação de identidade de destinatários externos” ao usar o fluxo de trabalho “Enviar em massa”. |
| 4319798 | Correção de um problema em que o foco do cursor podia saltar para um campo diferente durante a seleção de um botão de opção. |
| 4320154 | Correção de um problema que podia impedir que um modelo de biblioteca fosse salvo em uma nova relação de grupo. |
| 4323013 | Correção de um problema em que abrir um formulário da web na página Gerenciar acionava o erro: “O documento ainda não está disponível ou não terá páginas para visualização.” |
| 4323554 | Correção de um problema em que os carimbos de data/hora do evento para atualizar direitos de administrador podiam produzir dois registros com os mesmos valores de hora. |
| 4323609 | Correção de um problema em que fazer upload de um contrato assinado na página Gerenciar não acionava o webhook AGREEMENT_WORKFLOW_COMPLETED. |
| 4325142 | Correção de um problema em que os modelos de email personalizados não apresentavam o valor de nome correto para um participante, se cancelassem o contrato. |
| 4326747 | Correção de um problema que podia resultar no carregamento incompleto da página Enviar em massa, omitindo as ações Upload e Enviar. |
| 4326855 | Correção de um problema que podia impedir que os destinatários recusassem a aprovação de um contrato. |
| 4327000 | Correção de um problema que podia causar falha nas credenciais de Smart-Id, com o erro indicando que nenhum algoritmo foi encontrado. |
