Ações
A exclusão confirma uma vez e diz o que sai junto, o desfazer fica à mão, e a validação barra duplicados sem perder o digitado.
Quando usar
Use em toda tela ou formulário em que a pessoa exclui, restaura ou salva um registro, e em toda mensagem de validação que um salvamento pode mostrar.
Quando não usar
Limpar o que ainda não foi salvo em um formulário é uma ação diferente de excluir um registro salvo, e ela tem a própria confirmação. Os checks de intake seguem intake views.
Como funciona
Peça confirmação uma vez antes de excluir e diga o que vai junto com o registro
Uma exclusão abre uma confirmação. O diálogo nomeia o registro, diz se a ação pode ser desfeita e lista o que mais é removido ou limpo junto com ele.
Passa: exclua um registro em 3 cliques ou menos, confirmação incluída, e o diálogo nomeia o registro e o que vai junto com ele.
O Pipedrive pergunta: Are you sure you want to delete this file? This action cannot be undone. Cancel fica ao lado de um Delete vermelho.
O AutoSend pergunta Delete? Are you sure? e não nomeia nada.
O Cofounder diz: This removes Mobbin from the CRM. Related CRM links will be cleaned up. O botão diz Delete account.
O Relume nomeia Untitled Project e não diz o que vai junto.
O Apollo conta o que vai sair: Are you sure you want to delete the 1 deal?
A ZARA pergunta se remove os itens selecionados sem dizer quantos.
Mantenha o desfazer visível depois de uma ação destrutiva
Quando uma exclusão pode ser revertida, o caminho de volta continua na tela depois da exclusão. Um produto que exclui de forma permanente nunca é o modelo para um caminho que pode desfazer.
Passa: depois de uma exclusão, a pessoa restaura o registro na mesma tela, sem abrir configurações nem uma página de lixeira.
Deixe explícito o escopo de uma ação destrutiva
Excluir um registro e excluir uma pilha, uma view ou um grupo são ações diferentes, com rótulos diferentes. Cada uma diz o que remove.
Passa: em todo menu de ações, o rótulo de cada item destrutivo nomeia o que ele exclui, como em Delete record ou Delete stack.
- Troque isto
- Delete
- Por isto
- Delete record
Bloqueie a chave de duplicidade quando ela é digitada
Quando a pessoa digita um valor que já pertence a outro registro, o formulário avisa antes de salvar e aponta para o registro existente. Para uma pessoa, a chave é o email, e para uma organização é o domínio. Essas são as chaves de duplicidade do Core.
Passa: digite um email que outra pessoa já tem. O formulário bloqueia o salvamento, nomeia o registro existente e mantém todos os valores digitados.
Mantenha o que a pessoa digitou quando o salvamento falha
A mensagem de erro fica ao lado do campo a que ela se refere, e todo valor que a pessoa informou continua no formulário.
Passa: provoque cada erro de validação de um formulário. Depois de cada um, todo campo ainda tem o que foi digitado.
Exija um de um conjunto sem marcar cada campo como obrigatório
Quando um formulário precisa de pelo menos um entre vários campos, diga isso uma vez, acima dos campos. Marcar cada campo do conjunto como obrigatório diz à pessoa algo falso.
Passa: um formulário que precisa de um de um conjunto salva com qualquer campo do conjunto preenchido, e nenhum campo do conjunto leva marcador de obrigatório.
- Troque isto
- Email*, Phone*, LinkedIn*
- Por isto
- Fill at least one: Email°, Phone°, LinkedIn° (preencha pelo menos um)
Referências
A regra de exclusão copia três diálogos. O do Pipedrive diz “Are you sure you want to delete this file? This action cannot be undone.” com Cancel e um Delete vermelho. O do Cofounder diz “Delete account? This removes Mobbin from the CRM. Related CRM links will be cleaned up.” com Cancel e Delete account. O do Apollo diz “Confirm Deletion. Are you sure you want to delete the 1 deal?” com Cancel e Delete. A comparação de usabilidade de CRMs do revisor (2026-09-29/30) pede “Add a record-level Delete action with confirmation, copying Attio; delete in 3 clicks or fewer.” (comparação, linha 117). A contagem de exclusão dela é 3 cliques no Attio (comparação, linha 23), e a tabela de ações no registro compara exclusão e recuperação entre os produtos (comparação, linhas 2646 a 2666).
As outras cinco regras não têm captura de tela e se apoiam na comparação. No desfazer, o do nosso CRM foi testado, enquanto o Attio e o folk excluem de forma permanente (comparação, linha 1693). A comparação pede “Keep the visible Undo route; do not replace it with permanent deletion merely to match another product.” (comparação, linha 1699).
No escopo, a comparação pede “Keep destructive scope explicit.” com “Pass: deleting records is distinct from Delete stack and recovery remains visible.” (comparação, linha 2663).
Nos duplicados, a comparação mostra o Attio bloqueando um email duplicado ao salvar, enquanto o folk salvou um nome duplicado (comparação, linha 1544). Ela pede “Block duplicate email.”, copiando o aviso do Attio, mantendo o que foi digitado e deixando Email opcional (comparação, linha 1551). A mesma regra vale no nosso modelo, em que o email é a chave de duplicidade de uma pessoa no Core e o domínio é a chave de duplicidade de uma organização. A comparação deixa Email opcional, enquanto o Core precisa da chave para achar um duplicado, então esse ponto está em aberto.
Nos erros, a comparação pede “preserve input on errors” (manter o que foi digitado quando há erro) quando a criação de pessoas for unificada (comparação, linha 1483), e que os erros nomeados do folk sejam copiados para os resumos de validação (comparação, linha 865).
A regra de um de um conjunto vem do pedido da comparação: “Require at least one of the five input fields, rather than falsely marking every field individually required.” (comparação, linha 1823). Nossos marcadores de obrigatório não expressam esse caso, então o marcador em cada campo do conjunto é ° e a exigência aparece uma vez acima deles.