← Voltar ao blogue

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 ultrapassar a fase em que «todos podem ver tudo» - e porque é que as permissões reais requerem um servidor.

Por Equipa Toolberry8 Tempo de leitura:

18 de julho de 2026 atualizado

O dia em que a sua equipa ultrapassa a fase em que «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. Isso são 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, por definição - foi concebido para um único operador ou para uma equipa de duas ou três pessoas que partilham tudo. As funções e as 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çam 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 da agenda e dos telefones, e uma colaboradora a tempo parcial para as semanas mais movimentadas. 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 do cofre, pensando que era uma duplicação.
  • 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 lá dentro.

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 colaboradores, 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 usadas de forma intercambiável e não deviam ser:

  • A autenticação é provar quem és. 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, coordenador, orçamentista, gestor administrativo, proprietário. As permissões subjacentes podem ser gerais (podes abrir faturas?) ou específicas (podes ver a coluna dos custos na fatura que estás autorizado a abrir?).

Precisas de ambas as coisas. Um login sem autorização subjacente 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 definir.
  2. Quem pode alterar os registos? Editar e eliminar trabalhos, clientes e histórico - e se fica algum rasto de quem o fez.
  3. Quem pode ver o registo completo? 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, imediatamente, sem ser necessário recolher um telemóvel.

Vale a pena dizer claramente: não se trata de presumir que a vossa 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 os funcionários negligentes foram a causa principal de 53% dos incidentes internos, contra 27% que foram maliciosos. As permissões protegem principalmente as pessoas de boa-fé de acidentes dispendiosos - e protegem-no da única saída indesejada que não previu.

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, mantê-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 real 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, e não vamos fingir o contrário. A versão Free foi concebida para um único operador, ou para uma equipa de duas ou três pessoas que confiam plenamente umas nas outras. 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 próprio, 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 na realidade.

O que procurar ao avaliar qualquer aplicação

Seis perguntas que vale a pena fazer numa demonstração, independentemente de quem for o fornecedor:

  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 acontecer apenas na aplicação, é apenas cosmética.
  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 um utilizador 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 já não cabem num único dispositivo.

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 consultiva. 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 carteira 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 sem mais nem menos quando chega. Cada gravação em fila tem de ser revalidada do lado do servidor no momento da sincronização, comparando-a com o que aquela função estava autorizada a fazer - a palavra do dispositivo não é prova.

A medida que resolve a maior parte destes problemas num sistema «local-first» consiste em definir o âmbito do que é sincronizado. Em vez de enviar o conjunto de dados completo para todos os dispositivos e ocultar partes do mesmo, 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, e não nove anos de registos completos. A permissão mais forte não é uma verificação. São os dados que nunca chegaram ao dispositivo, para começar.

É 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 «Por que é que o ToolBerry é “offline-first”» - com um servidor adicionado exatamente onde a confiança o exige.

Leitura adicional

Partilhar
XLinkedIn