Permissões no Pipefy ajudam times a trabalhar com mais controle, segurança e autonomia, mesmo em operações complexas e colaborativas. Quando esse modelo está claro, fica mais fácil saber quem pode fazer o quê, em qual contexto e por quê.
Quando esse modelo não está claro, surgem situações comuns:
- Alguém vê o pipe, mas não consegue editar
- Um admin não consegue fazer uma ação específica
- Usuários são adicionados e depois surgem dúvidas sobre cobrança
- Permissões em databases parecem não seguir o pipe
📖 Este guia existe para organizar esse modelo mental e ajudar você a entender como as permissões funcionam no Pipefy:
Por que permissões no Pipefy geram dúvidas no dia a dia
Muitos usuários esperam um modelo simples de permissões, algo como “tem acesso” ou “não tem acesso”. No Pipefy, o controle funciona por camadas e contextos.
Uma mesma pessoa pode:
- Ter acesso a um pipe, mas não editar cards
- Ser admin de um pipe, mas não da organização
- Visualizar dados de um database, mas não alterá-los
Isso não é um erro. É o resultado de um modelo pensado para dar controle e segurança, principalmente em ambientes colaborativos e regulados.
Quando essas camadas não estão claras, a experiência parece confusa. Quando o modelo faz sentido, as decisões ficam muito mais simples.
Como o modelo de permissões do Pipefy funciona
Antes de falar de funções ou admins, vale entender onde as permissões se aplicam. No Pipefy, elas não vivem em um único lugar.
De forma simplificada, existem quatro grandes contextos:
- Organização: onde ficam as configurações globais, gestão de usuários e controles mais amplos.
- Pipes: onde o trabalho acontece. Aqui entram funções, acesso a cards, fases e automações.
- Databases: estruturas de dados compartilhadas, com regras próprias de visualização e edição.
- Cards e fases: ações específicas dentro de um fluxo, como editar campos, mover cards ou executar ações.
Entender em qual contexto você está tentando agir resolve grande parte das dúvidas.
Admin da organização x Admin do pipe: qual é a diferença?
Admin da organização
É quem tem controle sobre o ambiente como um todo. Normalmente pode:
- Gerenciar usuários da organização
- Acessar configurações globais
- Visualizar e administrar múltiplos pipes
- Acessar o painel do administrador
Esse papel está ligado à governança.
Admin do pipe
É quem administra um pipe específico. Normalmente pode:
- Editar a estrutura do pipe
- Configurar fases, campos e automações
- Gerenciar permissões dentro daquele pipe
Esse papel está ligado à operação.
Ser admin de um pipe não significa ter acesso total à organização. Ser admin da organização não significa operar todos os pipes no dia a dia.
Funções no pipe: o que muda entre usuários
Dentro de um pipe, as permissões são controladas por funções.
As funções definem o que cada pessoa pode fazer naquele fluxo, por exemplo:
- Criar ou editar cards
- Mover cards entre fases
- Editar campos específicos
- Acessar automações
Funções padrão
Atendem a maioria dos cenários e já vêm prontas para uso.
Funções personalizadas
Fazem sentido quando:
- O time precisa de controles mais específicos
- Diferentes áreas usam o mesmo pipe
- Há necessidade de separar responsabilidades com mais precisão
💡 Um erro comum é criar funções personalizadas sem antes validar se o problema não é apenas quem está atribuído à função.
Grupos de usuários: para que servem e o que não fazem
Grupos de usuários ajudam a facilitar a gestão, mas não criam novas permissões.
Eles servem para:
- Adicionar várias pessoas de uma vez a um pipe ou database
- Manter acessos organizados por time ou área
- Reduzir trabalho manual ao gerenciar permissões
O que grupos não fazem:
- Não alteram o que a função permite
- Não substituem funções
- Não ignoram regras do pipe ou database
💡 Se alguém não consegue fazer algo, o problema raramente é o grupo. Normalmente é a função associada.
Databases: por que as permissões seguem outra lógica
Databases não seguem exatamente a mesma lógica dos pipes.
Um database é uma fonte de dados que pode alimentar vários pipes. Por isso:
- Ele tem permissões próprias
- O acesso ao pipe não garante acesso ao database
- Editar dados no pipe não significa poder editar o database
Além disso, ter acesso a um pipe que possui conexão com outro não concede automaticamente o mesmo nível de acesso a ambos. Cada pipe mantém suas próprias regras de permissão.
Por exemplo, se uma automação estiver vinculada a mais de um pipe e o usuário não for membro de um deles, ocorrerá um erro de permissão ao tentar acessá-la.
Cenários comuns:
- O usuário vê o campo, mas não consegue alterar o valor
- O usuário acessa o card, mas não o registro do database
- Mudanças no database não refletem como esperado no pipe
💡 Sempre que a dúvida envolve dados compartilhados, vale checar primeiro as permissões do database.
Tipos de usuários e cobrança: visão geral
Outro ponto frequente de dúvida é entender quem é cobrado.
De forma geral:
- Usuários com acesso ativo à plataforma contam como usuários
- Tipos específicos de acesso podem não gerar cobrança
- O que importa é o nível de participação e acesso concedido
Usuários convidados, como convidados externos ou convidados da empresa, não geram cobrança enquanto permanecem nesse tipo de acesso. No entanto, ao serem adicionados diretamente a um pipe, esses usuários passam automaticamente a ser membros da organização, o que pode alterar seu nível de acesso e impacto em cobrança.
Se a dúvida estiver ligada a cobrança, vale sempre revisar:
- Como a pessoa foi adicionada
- A que ambientes ela tem acesso
- Se o acesso é contínuo ou pontual
Checklist rápido para resolver dúvidas sem abrir ticket
Antes de abrir um chamado, vale passar por este checklist:
A pessoa não vê o pipe
→ Verificar se ela foi adicionada ao pipe ou ao grupo correto.
A pessoa vê o pipe, mas não consegue editar cards
→ Verificar a função atribuída dentro do pipe.
A pessoa é admin, mas não consegue fazer determinada ação
→ Confirmar se é admin do pipe ou da organização.
O campo aparece, mas não pode ser editado
→ Verificar permissões do database associado.
Ao visualizar uma tela de erro de permissão
→ Isso indica que o usuário não possui acesso ao endpoint solicitado, seja ao card, ao pipe, ao database ou à organização.
Dúvida sobre cobrança
→ Revisar tipo de usuário e nível de acesso concedido.
💡 Na maioria dos casos, a resposta está em identificar o contexto certo da permissão.
Ainda com dúvidas sobre permissões?
Use este guia como referência sempre que precisar revisar acessos, papéis ou erros de permissão. Se algo não se comportar como esperado, o próximo passo é verificar o contexto correto antes de ajustar configurações ou acionar o suporte.