Quem pode ver o quê: funções e permissões para uma empresa de serviços em crescimento

O dia em que a sua equipa ultrapassa a fase de «todos podem ver tudo» - e porque é que as permissões reais requerem um servidor.

Publicado em julho de 2026.

A resposta curta

Assim que tiver pessoal, alguém tem de decidir quem pode ver preços e margens, quem pode alterar um trabalho, quem pode ver toda a carteira de clientes e quem mantém o acesso depois de sair da empresa. A isso chamam-se funções e permissões. As permissões reais não podem ser aplicadas num dispositivo controlado pelo utilizador - precisam de um servidor que verifique cada ação em relação a uma identidade. O ToolBerry Free não tem funções aplicadas por servidor, por definição. Foi concebido para um único operador ou para uma pequena equipa que partilha um espaço de trabalho através de armazenamento partilhado, onde todos vêem tudo. As funções e permissões estão agora disponíveis no ToolBerry Pro, incluindo funções personalizadas que o próprio define, em vez de escolher a partir de uma lista fixa.

O dia em que as permissões começaram a fazer a diferença

A Renata passou quatro anos a limpar casas sozinha antes de começar a contratar pessoal. Não foi preciso muito para mudar tudo: uma segunda empregada de limpeza, uma terceira, a prima dela a tratar dos horários e dos telefonemas, e uma colaboradora a tempo parcial para as semanas mais ocupadas. Cinco pessoas - e a aplicação que tinha sido perfeita para uma pessoa tornou-se, de repente, um problema.

Quando era só ela, ter todo o negócio num único telemóvel era o ideal. Com cinco pessoas, a mesma configuração significava que:

• A empregada doméstica mais recente pode ver exatamente o que cada cliente paga - e disse a um deles que achava que o preço era elevado.
• A prima dela apagou um cliente com quatro anos de notas e códigos de cofre, pensando que era uma duplicata.
• Uma funcionária a tempo parcial de fim de semana tem a morada e o código do portão de todos os clientes no seu telemóvel pessoal - e também faz limpezas para outras duas empresas.
• A funcionária de limpeza que se demitiu em março ainda tem a aplicação instalada, com toda a base de dados nela.

Nada disto se deve ao facto de a Renata ter feito más contratações. A questão é que, algures entre duas e cinco pessoas, «todos podem ver tudo» deixou de ser uma configuração padrão razoável - e nada no software dela detectou isso.

Eis a parte que mais surpreende a maioria dos proprietários: as funções só se tornam uma questão real quando se chega aos cinquenta funcionários, ou mesmo aos vinte. Começam a ter importância por volta dos quatro ou cinco - no momento em que as pessoas que utilizam a aplicação já não são apenas tu e alguém a quem entregarias o teu cartão bancário. O que está em jogo continua a aumentar à medida que a empresa cresce, mas a linha que se ultrapassa é atingida cedo.

O que as funções e as permissões realmente significam

Duas palavras são utilizadas de forma intercambiável, mas não deveriam ser:

• A autenticação é provar quem você é. A porta da frente. Um login.
• A autorização é o que lhe é permitido fazer assim que estiver lá dentro. Em que salas pode entrar e o que pode tocar nelas.

Uma função agrupa a autorização em algo que um ser humano consegue compreender: técnico, despachante, orçamentista, gestor administrativo, proprietário. As permissões subjacentes podem ser gerais (podes abrir faturas?) ou específicas (podes ver a coluna de custos na fatura que estás autorizado a abrir?).

Precisas de ambas as coisas. Um login sem autorização associada significa apenas que toda a gente é identificada, mas continua a ver tudo.

As quatro perguntas a que toda a empresa em crescimento tem de responder

1. Quem pode ver as finanças? Preços, margens, o que cobra, o que paga. Esta é normalmente a primeira linha que os proprietários querem estabelecer.
2. Quem pode alterar os registos? Editar e eliminar trabalhos, clientes e histórico - e se fica algum registo de quem o fez.
3. Quem pode ver todo o registo? A lista completa de clientes ou apenas a rota de hoje. Esta é a questão que mais importa no dia em que alguém se vai embora para um concorrente.
4. O que acontece quando alguém sai? O acesso tem de poder ser revogado a partir de um ponto central, de imediato, sem ser preciso recolher um telemóvel.

Vale a pena dizer claramente: não se trata de partir do princípio de que a sua equipa é composta por ladrões. A maioria dos incidentes internos são erros comuns. O estudo «2025 Cost of Insider Risks» do Ponemon Institute revelou que a negligência dos colaboradores foi a causa principal de 53% dos incidentes internos, contra 27% que foram maliciosos. As permissões servem principalmente para proteger as pessoas de boa-fé de acidentes dispendiosos - e para o proteger de aquela saída indesejada que não viu chegar.

Por que razão as permissões precisam genuinamente de um backend

Eis a parte que a maioria do marketing de software ignora.

Num dispositivo que te pertence, controlas tudo o que nele está. Uma aplicação apenas local pode ocultar a coluna dos custos - torná-la a cinzento, deixá-la fora do ecrã - mas os dados continuam armazenados nesse dispositivo, e a verificação que os oculta é executada no hardware que o utilizador controla. Qualquer pessoa suficientemente determinada consegue contorná-la. Um campo oculto é uma cortina, não uma parede.

A aplicação efetiva tem de ocorrer num local fora do alcance do utilizador: um servidor que armazena a identidade e verifica cada pedido em relação a ela. «Esta pessoa tem permissão para ver as margens?» tem de ser respondida por uma máquina que controlas, não pela que está no bolso dela. Isso é um limite de confiança, não uma opção de ativação ou desativação - e é por isso que a autenticação e as permissões não podem ser feitas apenas offline.

A revogação torna isso óbvio. Não é possível anular o envio de dados que já se encontram no telemóvel de alguém. Retirar o acesso requer um guardião que tenha estado presente o tempo todo.

A situação atual do ToolBerry - com toda a honestidade

O ToolBerry Free não tem funções impostas pelo servidor, e não vamos fingir o contrário. A versão Free foi concebida para um único utilizador ou para uma pequena equipa que partilha um espaço de trabalho através de armazenamento partilhado e cujos membros confiam uns nos outros em tudo. Quem tiver o dispositivo tem os dados. Não é uma lacuna que estejamos a esconder - é uma consequência direta da mesma arquitetura que torna a versão Free gratuita, offline e sem necessidade de conta. Para uma pessoa e uma carrinha, é exatamente o ideal.

As funções e permissões estão disponíveis no ToolBerry Pro - incluindo funções personalizadas que pode nomear e definir por si mesmo, em vez de encaixar a sua equipa numa lista fixa de «Administrador / Utilizador». Uma empresa de controlo de pragas, uma empresa de limpeza e uma loja de canalização não têm as mesmas tarefas, por isso não devem ser forçadas a encaixar-se nas mesmas três funções. As permissões são uma das funcionalidades que, de qualquer forma, requerem um backend - a mesma linha que separa a versão Grátis da Pro no que diz respeito à sincronização, marcações, pagamentos e notificações. (Essa história está em «Grátis vs. Pro».)

Se gere uma equipa a sério, contacte-nos - podemos ajudá-lo a configurar funções que correspondam à forma como o seu negócio funciona realmente.

O que procurar ao avaliar qualquer aplicação

Seis perguntas que vale a pena fazer numa demonstração, independentemente de quem lhe estiver a vender:

1. A aplicação das restrições é feita do lado do servidor? Pergunte diretamente: «Se um técnico aceder ao código-fonte da aplicação no seu próprio telemóvel, consegue ver os custos?» Se a ocultação ocorrer apenas na aplicação, trata-se de uma medida superficial.
2. As funções correspondem a uma profissão? «Administrador» e «Utilizador» não são modelos de função. Técnico, despachante, orçamentista, administrativo e proprietário, sim.
3. É possível controlar campos, e não apenas ecrãs? Permitir que alguém abra um trabalho sem ver a margem é a necessidade real mais comum.
4. Existe um registo de auditoria? Quem alterou o preço e quando. Sem isso, as permissões são apenas metade de um sistema.
5. É possível desativar uma conta com uma única ação? Revogação centralizada, em todo o lado, sem ter de ir atrás de um dispositivo.
6. A aplicação de campo continua a funcionar offline com uma função restrita? As permissões não devem comprometer a fiabilidade pela qual comprou a aplicação.

As verdadeiras vantagens e desvantagens

As funções acrescentam sobrecarga. Alguém tem de ser responsável pelo modelo de permissões e mantê-lo atualizado à medida que as pessoas entram e mudam de função. Isso é trabalho a sério, e uma equipa de duas pessoas que confia plenamente uma na outra ainda não precisa disso - mas a viragem ocorre por volta da quarta ou quinta pessoa, não da quadragésima.

Se for demasiado granular, ninguém o mantém. Comece com três funções, não com onze. Um modelo de permissões que ninguém atualiza é pior do que nenhum, porque acabará por confiar nele quando não deveria.

O modo offline e as permissões estão genuinamente em conflito. As permissões armazenadas em cache podem ficar desatualizadas; um dispositivo desligado não pode ser revogado em tempo real. Qualquer fornecedor honesto descreverá as desvantagens aqui, em vez de afirmar que o problema está resolvido.

Tem alguma pergunta?

Gostaríamos sinceramente de receber feedback de pessoas que gerem equipas reais. Quais são as três funções na sua empresa e qual é a única coisa que nunca deixaria um utilizador no terreno ver? Diga-nos em contact@toolberry.net.

ToolBerry Free: gratuito para sempre para operadores individuais. Pro: para equipas que precisam de sincronização em tempo real e funções definidas pelo servidor.

Para os curiosos em termos técnicos

A regra que rege tudo isto é antiga e pouco glamorosa: nunca confies no cliente.

Qualquer decisão de autorização executada no dispositivo do utilizador é meramente indicativa. São eles que controlam o processo, o armazenamento e a pilha de rede. Pode ofuscar o código e aumentar o esforço necessário, mas não pode garantir a segurança. Por isso, a fronteira tem de estar do lado do servidor: cada pedido chega com uma identidade (um token ou sessão), o servidor avalia a política em relação a essa identidade e devolve apenas o que a função permite.

O que nos leva à regra que realmente importa: filtrar na fonte, não se esconder na interface do utilizador. Se o dispositivo de um técnico receber toda a base de dados de clientes e a aplicação se limitar a recusar a sua apresentação, não criou uma permissão - criou uma sugestão armazenada localmente.

É isso que torna o modo offline combinado com o RBAC verdadeiramente difícil, e vale a pena ser preciso quanto ao motivo:

• Permissões desatualizadas. Um dispositivo que está offline há dois dias continua a aplicar uma função que podes ter alterado ontem.
• Atraso na revogação. Não é possível aceder a um dispositivo desligado para retirar o acesso. O melhor que se pode fazer é expirar as credenciais em cache e recusar a sincronização.
• Gravações não confiáveis. O trabalho criado offline não pode ser aceite tal como está à chegada. Cada gravação em fila tem de ser revalidada no lado do servidor, no momento da sincronização, em relação ao que essa função estava autorizada a fazer - a palavra do dispositivo não é prova.

A medida que resolve a maior parte destes problemas num sistema que privilegia o local é definir o âmbito do que é sincronizado. Em vez de enviar o conjunto de dados completo para todos os dispositivos e ocultar partes dele, uma função determina o que um dispositivo recebe - o telemóvel de um técnico contém o percurso de hoje e os clientes desse dia, não nove anos de registos completos. A permissão mais forte não é uma verificação. São os dados que, para começar, nunca chegaram ao dispositivo.

É assim que configuramos o ToolBerry Pro: as leituras «local-first» mantêm-se rápidas para tudo o que uma função está autorizada a conter, a sincronização é delimitada por função e cada gravação é validada no servidor no momento da entrada. A arquitetura subjacente é a mesma descrita em «Why ToolBerry Is Offline-First» - com um servidor adicionado exatamente onde a confiança o exige.

Leitura adicional

• Versão gratuita vs. Pro: A história do ToolBerry e para que serve cada plano - onde as funções se enquadram no panorama geral
• Por que razão o ToolBerry dá prioridade ao modo offline – a arquitetura subjacente
• O que todas as aplicações de serviços de campo realmente precisam (e o que é apenas excesso) - quando uma funcionalidade merece o seu lugar
• O ToolBerry é mesmo gratuito para sempre? - por que razão a versão Gratuita continua a ser gratuita