Analisar

Nada conta enquanto alguém não der o aval.

Com as aprovações ligadas, uma resposta submetida fica à espera de uma decisão de aprovar ou rejeitar, com um comentário opcional, antes de contar como concluída. Pode indicar uma lista de aprovadores por inquérito; se não o fizer, qualquer editor da organização pode decidir. Quem decidiu e o momento em que decidiu são registados pela base de dados a partir da sessão autenticada, e não fornecidos pelo navegador — que é a diferença entre um registo de auditoria e uma afirmação.

As aprovações são de passo único apenas. Uma decisão por resposta, sem cadeias, sem delegação, sem substituição por ausência, sem escalamento e sem lembretes automáticos. Se o seu processo precisa de uma cadeia de três fases, mais vale sabê-lo nesta página do que na terceira semana de uma implementação.

Como o estado se move de facto

Uma resposta chega em estado de espera. É uma submissão completa — todas as respostas, todos os carregamentos, todas as assinaturas guardadas como seriam de outro modo — mas assinalada como ainda não decidida. Um aprovador abre-a e aprova-a ou rejeita-a, com um comentário opcional em qualquer dos casos. É toda a máquina de estados, e a brevidade é deliberada: não há «devolvido para alteração» nem um ciclo de ressubmissão que reabra o registo a quem respondeu. Uma resposta rejeitada mantém-se onde está e continua legível dentro da organização.

A decisão não altera os dados. A vista de resultados continua a contar a resposta nos seus gráficos por pergunta. A aprovação é uma decisão registada sobre uma submissão, não um filtro que a esconde.

O que é escrito, e quem o escreve

São guardadas quatro coisas em cada decisão. Duas delas são a razão de esta funcionalidade existir.

Decisão

Aprovada ou rejeitada. Não há um terceiro estado depois de tomada a decisão.

Quem decidiu

Retirado da sessão autenticada pela base de dados, não de um campo enviado pelo navegador.

Data e hora

Escritas no servidor no momento em que a decisão é registada, e não lidas do relógio de quem analisa.

Comentário

Opcional tanto ao aprovar como ao rejeitar, guardado com a decisão e visível apenas dentro da organização.

Muitas ferramentas dizem-lhe quem aprovou uma coisa. A pergunta que vale a pena fazer a um fornecedor é de onde veio esse nome. Se é o cliente que envia a identidade do aprovador com a decisão, qualquer pessoa capaz de invocar o ponto de acesso pode escrever qualquer nome e qualquer hora no registo de auditoria.

Aqui, a identidade e o momento são retirados da sessão autenticada pela própria base de dados. Um navegador não os pode propor, logo não os pode errar. É o mesmo alicerce do resto da plataforma: segurança ao nível da linha em toda a parte, isolamento entre organizações fixado no servidor, e regras como a data de fecho e o limite de respostas aplicadas por acionadores de base de dados e não pela interface.

Quem responde nunca vê a decisão

O estado de aprovação é invisível para quem preencheu o formulário. Submete, recebe o ecrã de agradecimento, e fica por aí. Não há acompanhamento de estado nem um e-mail automático a dizer que foi recusado.

Isto é uma escolha e não uma omissão. Uma rejeição costuma ser processual — a prova errada anexada, um pedido fora do âmbito, um duplicado — e um «rejeitado» automático e seco é uma má forma de o dizer a um cidadão. As autarquias já têm processos para comunicar decisões, com a formulação, a via de recurso e o número de referência que os acompanham. Uma fila interna de aprovação não deve tornar-se discretamente uma carta de decisão sem enquadramento.

Onde isto encaixa na administração local

O caso mais comum é um formulário que não é bem um inquérito: um pequeno programa de apoios, um pedido de reserva de um campo, uma comunicação de alteração de circunstâncias, uma alteração de licença. Chega qualquer coisa, um técnico olha para ela, e ou entra ou não entra. Essa decisão única é todo o fluxo de trabalho, que é precisamente o caso para que as aprovações foram construídas. Mais sobre a adequação ao setor na página da administração local.

Duas coisas combinam com isto. O carregamento de ficheiros, porque estes formulários trazem provas — um orçamento, uma fatura, uma fotografia — guardadas num contentor privado e legíveis apenas pela organização através de URL assinados de curta duração. E as assinaturas eletrónicas, que guardam a marca, o método, o texto exato do acordo e um resumo SHA-256 desse texto, de modo que alterar a formulação mais tarde altera o resumo. Uma decisão registada sobre uma declaração com resumo dá-lhe um registo de quem concordou com o quê e de quem aprovou. São assinaturas eletrónicas simples, não qualificadas, pelo que saber se isso é prova suficiente para um determinado programa é uma questão para quem tutela esse programa.

O que as aprovações não fazem

Quatro coisas ficam fora do limite do passo único, e vale a pena nomeá-las.

  • Sem cadeias. Não é possível encaminhar uma resposta para um chefe de equipa e depois para a área financeira. Uma decisão encerra o assunto.
  • Sem delegação nem substituição por ausência. Um aprovador não pode passar a sua fila a um colega enquanto está fora.
  • Sem escalamento e sem lembretes. Nada vai atrás de um aprovador ao fim de três dias. Uma resposta em espera espera.
  • Sem encaminhamento condicional. As perguntas que alguém vê podem depender de respostas anteriores através da lógica condicional; quem analisa o resultado não pode.

A razão é a superfície exposta. Cadeias, delegação, substituições e escalamentos trazem consigo prazos, estados de ausência, regras de reatribuição e um motor de notificações, e cada um deles é um sítio onde uma decisão se pode perder. Um analista com aprovar, rejeitar e um comentário cobre o caso comum e explica-se numa frase. Se precisa mesmo de uma cadeia, use um sistema de gestão de processos para o fluxo de trabalho e isto para a receção, ou diga-nos como é a sua cadeia.

Levar a decisão para os seus outros sistemas

O momento conta. Um webhook dispara quando a resposta chega — assinado com HMAC-SHA256 num cabeçalho X-NumoForms-Signature, com um segredo por webhook —, ou seja, antes de alguém ter analisado o que quer que seja. Um sistema que receba essa carga está a receber uma candidatura, não uma candidatura aprovada, e deve tratá-la como tal. As notificações por e-mail comportam-se da mesma forma. Nenhuma delas transporta a decisão, e a exportação CSV também não, pois tem uma coluna por pergunta e nenhuma coluna para o aval. A decisão vive na vista de resultados, pelo que hoje viaja para outro sistema através da pessoa que a tomou.

Perguntas frequentes sobre aprovações

O que é um passo de aprovação numa resposta a um inquérito?

Um passo de aprovação mantém uma resposta submetida em espera até alguém a aprovar ou rejeitar, com um comentário opcional. Até lá, não conta como concluída. A decisão, quem decidiu e o momento são escritos pela base de dados a partir da sessão autenticada, em vez de serem fornecidos pelo cliente.

Quem pode aprovar uma resposta?

Pode definir uma lista de aprovadores por inquérito. Se não o fizer, qualquer editor da organização pode decidir. Não existe um tipo de lugar separado para aprovadores — os aprovadores são pessoas que já têm acesso ao espaço de trabalho.

Quem responde fica a saber que a sua resposta foi rejeitada?

Não. O estado de aprovação nunca é mostrado a quem responde, que vê o ecrã de agradecimento normal ao submeter. Uma rejeição é uma decisão interna sobre o registo, não um veredicto entregue à pessoa, pelo que é você que a contacta, da forma que o caso exigir.

São suportadas cadeias de aprovação com vários passos?

Não. As aprovações são de passo único apenas: uma decisão de aprovar ou rejeitar por resposta. Não há fases sequenciais, não há aprovação em paralelo, não há delegação, não há escalamento e não há lembretes automáticos. Um processo que precise de uma cadeia de três fases não é servido por isto hoje.

O que acontece se o único aprovador estiver de férias?

Não acontece nada automaticamente — não há delegação nem substituição por ausência. Indique mais do que um aprovador no inquérito, ou deixe a lista de aprovadores vazia para que qualquer editor da organização possa decidir.

Coloque uma decisão por trás do formulário.

Ative as aprovações e cada resposta submetida fica à espera de um único aprovar ou rejeitar, com um comentário opcional, antes de contar como concluída. Quem decidiu e a data e hora são escritos pela base de dados a partir da sessão autenticada, pelo que o registo de auditoria não é algo fornecido pelo navegador.

  • Aval de passo único: aprovar ou rejeitar, com um comentário
  • Aprovadores designados por inquérito, ou qualquer editor da organização
  • Quem responde nunca vê a decisão
Comece a construir