Building Blocks
Grupos
Decide o que alguém pode fazer no Gfacility — combinado com filtros principais que decidem o que alguém pode ver. Dois eixos separados, um modelo de autorização coerente.
Atualizado em 23/01/2026
Configuração · Building Blocks · 3.4
A autorização no Gfacility funciona em dois eixos separados: os Grupos decidem o que alguém pode fazer, os filtros principais decidem o que alguém pode ver. Este artigo cobre o lado do fazer. Um utilizador pode pertencer a vários grupos e recebe automaticamente os direitos combinados.
Porque é que isto importa para o negócio
"Nem toda a gente deve poder fechar tickets"
Privilégios por ação (ver / criar / editar / eliminar) por módulo.
"Os externos só veem os seus próprios tickets"
Direitos sobre "registos próprios" vs "outros registos" — uma dimensão dentro de cada grupo.
"Direitos de configuração separados da operação"
Editar definições exige direitos diferentes do trabalho diário — configurável separadamente.
"Futuro vs passado"
Uma reserva passada pode ser visível para todos; o planeamento futuro talvez apenas para a equipa de gestão.
O modelo de privilégios
Os privilégios são compostos por três dimensões. Para os direitos operacionais estão disponíveis as três; para os direitos de configuração apenas a primeira.
| Dimensão | Valores | O que controla |
|---|---|---|
| Ação | Ver · Criar · Editar · Eliminar | CRUD por módulo |
| Propriedade | Próprios · Outros registos | Apenas registos próprios ou também de outros |
| Intervalo temporal | Futuro · Passado | Para reservas, tarefas — nem sempre aplicável |
Operação versus Configuração
Os privilégios distribuem-se por dois separadores:
Operação
Utilização diária: tickets, reservas, tarefas, visitantes, catering. Todas as três dimensões.
Configuração
Definições: classificações, workflows, templates, os próprios grupos. Apenas a dimensão de ação (sem próprios/outros nem futuro/passado).
Importante: ver não diz nada sobre o quê
O privilégio “Ver” dá acesso a um módulo. Que registos dentro desse módulo vê efetivamente é decidido pelos filtros principais — uma camada de segurança separada. Um utilizador pode ter permissão para ver tickets de helpdesk, por exemplo, mas através de um filtro principal apenas vê os da sua própria organização.
Que decisões irá tomar?
Que papéis distingue?
Utilizador final, responsável pelo tratamento, gestor, admin. Um conjunto pequeno é mais fácil de gerir.
Próprios ou todos os registos?
Utilizadores finais tipicamente "próprios". Tratadores "outros" dentro do âmbito do seu workgroup.
Quem pode editar a configuração?
Limite a 2–5 pessoas. Demasiados admins = alterações descontroladas.
Como combina grupos?
Um utilizador fica com a união dos direitos dos grupos. Empilhar em vez de copiar = visão mais clara.