👤 Para usuários com processo em produção que distribuem trabalho entre membros do time
🔐 Disponível para todos os planos (distribuição em rodízio é recurso de planos pagos)
🎯 Para quem quer que todo card entre numa fase já com um dono definido, sem depender de alguém lembrar de atribuir
Um card acabou de entrar na fase de análise. Ele tem prazo, tem os dados preenchidos, tem tudo, menos alguém encarregado de tocá-lo. Ninguém recebe notificação, ninguém sente que aquilo é seu, e o card fica parado esperando que alguém, em algum momento, repare que ele existe. Quando o volume é pequeno, a pessoa que modelou o processo cobre essa lacuna na memória. Quando o volume cresce, a lacuna vira gargalo silencioso: trabalho que ninguém pegou porque, formalmente, não era de ninguém.
Ao terminar este artigo, você vai saber escolher o mecanismo de atribuição automática certo para o seu processo, de modo que todo card chegue numa fase de trabalho já com um responsável definido, sem que uma atribuição nova apague quem já era responsável antes. O Pipefy oferece mais de um caminho para isso, e a escolha entre eles é o que separa um processo em que o trabalho flui de um em que ele empaca.
📖 O que você vai entender aqui:
O que está em jogo quando um card não tem dono
Antes de configurar qualquer coisa, vale separar dois problemas que parecem o mesmo e não são.
O primeiro é o card órfão: entra numa fase e ninguém é notificado, porque nenhuma regra definiu quem responde por ele ali. O segundo é mais sutil: o responsável errado, ou pior, a substituição indevida. Você configura uma atribuição na fase de análise, e ela apaga o solicitante que já constava como responsável desde a abertura. O card ganhou um dono novo e perdeu o antigo, e a rastreabilidade de quem iniciou aquilo se foi junto.
A pergunta que orienta toda a decisão a seguir é: o responsável desta fase precisa somar às pessoas que já acompanham o card, ou substituir? Na maioria dos processos, a resposta é somar. Alguém que abriu a solicitação continua interessado no desfecho dela.
Quando a atribuição fixa por fase já resolve
O caso mais comum tem a solução mais direta. Se toda vez que um card entra numa fase o responsável é sempre a mesma pessoa ou o mesmo par de pessoas, a atribuição fixa por fase resolve com uma automação.
O raciocínio é: você define uma regra que dispara quando o card entra na fase e adiciona o responsável daquela etapa. Um detalhe importante para a sua tranquilidade: a ação nativa de adicionar responsável soma a pessoa aos responsáveis já existentes, não substitui. Quem já estava no card continua. E o responsável definido assim permanece com o card nas fases seguintes, não some quando o card avança. Ou seja, o mecanismo nativo já resolve a responsabilidade acumulada ao longo do fluxo, sem que você precise de nada além da automação.
Critério de decisão: use atribuição fixa por fase quando o responsável de cada etapa é previsível e estável. É o caso da maioria dos processos de aprovação com um aprovador definido por etapa.
- Saiba mais: Automação: atualize o campo de responsáveis para o passo a passo de configuração da regra.
Quando o responsável depende do contexto do card
Nem todo processo tem um responsável fixo por fase. Em muitos, quem aprova depende de algo que só se sabe quando o card é criado: a área do solicitante, o valor da compra, o país da operação. Um pedido de Engenharia vai para um aprovador; o mesmo pedido vindo de Vendas vai para outro.
Aqui a decisão muda. Em vez de fixar uma pessoa na regra da fase, você guarda a relação entre contexto e responsável num database de aprovadores, cada registro amarrando um departamento aos seus respectivos aprovadores. O card se conecta a esse registro por um campo de conexão preenchido na entrada, e a automação atribui o responsável puxando o valor de dentro do registro conectado, de forma dinâmica, e não um nome cravado na regra.
A vantagem prática: quando um aprovador muda, você edita um registro no database e todos os processos futuros já respeitam a mudança. Você não precisa reabrir automação por automação para trocar um nome.
Critério de decisão: use atribuição via database quando o responsável varia conforme um dado do card e você quer um único lugar para manter essa relação. Quanto mais o "quem aprova" muda com o tempo, mais esse caminho compensa.
- Saiba mais: Como criar uma automação para definir responsáveis via database para ver a montagem do database e da conexão.
Quando o objetivo é equilibrar a carga do time
Há um terceiro cenário que não é sobre quem é o responsável certo, e sim sobre não sobrecarregar sempre a mesma pessoa. Fila de atendimento, triagem, análise de documentos: qualquer membro qualificado do time pode pegar, e o que você quer é distribuir de forma equilibrada.
Para isso existe a distribuição em rodízio, o round robin. Em vez de mandar todo card para uma pessoa, a automação reveza entre os membros que você definiu, entregando os cards de maneira uniforme entre eles.
Critério de decisão: use rodízio quando qualquer pessoa da lista pode assumir o card e o objetivo é equilíbrio de carga, não correspondência a um contexto. Se importa *quem* pega, é database ou atribuição fixa. Se importa que a fila ande de forma justa, é rodízio.
O rodízio é um recurso de planos pagos. Antes de desenhar o processo em cima dele, confirme a disponibilidade no seu plano para não construir uma dependência que a sua conta não sustenta.
A regra de ouro: um responsável por fase, e sem substituição indevida
Independente do mecanismo escolhido, duas diretrizes de modelagem sustentam todos eles e evitam retrabalho no futuro.
A primeira: mantenha um único campo de responsável por fase. Vários campos de responsável na mesma etapa geram ambiguidade sobre quem de fato responde pelo card ali, e complicam qualquer automação ou integração que dependa desse valor.
A segunda: você quer somar responsáveis, não trocar. Como a atribuição nativa já adiciona sem substituir e o responsável persiste pelas fases seguintes, o mecanismo nativo cobre bem a maioria dos processos. Em cenários de integração externa ou atribuição em massa fora do fluxo normal de fases, existe um caminho mais técnico via chamada HTTP que garante o mesmo comportamento de somar sem substituir. Esse caminho é assunto do artigo de fundamentos técnicos, não uma etapa que você configura no dia a dia.
- Saiba mais: Fundamentos técnicos e Service Account para o cenário de atribuição via HTTP.
O que acontece se o responsável sair da empresa
Vale um cuidado que só aparece meses depois de tudo configurado. Quando a atribuição prende um nome específico, seja fixado na automação ou como membro de um registro de database, a saída dessa pessoa da empresa quebra a regra em silêncio: os cards passam a entrar na fase sem o responsável esperado.
Por isso o caminho via database escala melhor no longo prazo. Trocar o aprovador que saiu vira editar um registro, não caçar cada automação que mencionava aquele nome. E manter as atribuições apoiadas na Service Account, e não em contas pessoais, evita que uma saída interrompa o processo. Esse é o tipo de decisão que não dói agora e economiza uma tarde inteira de manutenção depois.
Antes de avançar, confirme que você entende:
☐ A diferença entre card sem dono e responsável substituído sem querer, e por que a atribuição nativa soma em vez de trocar
☐ Qual dos três caminhos serve ao seu caso: responsável fixo por fase, responsável por contexto via database, ou rodízio para equilibrar carga
☐ Que você consegue definir, agora, qual mecanismo aplicar na próxima fase de trabalho do seu processo para que nenhum card entre nela sem responsável
