Permissões e perfis dentro de um App

Camada funcional

Um App publicado tem ações restritas — publicar um aviso, dar baixa num pagamento, apagar o registro de outra pessoa. Quem pode fazer o quê é decidido pela plataforma, sem o App precisar construir o próprio sistema de permissões.

O agente que constrói o App declara as permissões e os perfis para a plataforma — a partir daí, quem administra a organização passa a conceder e revogar esse acesso da mesma forma como faz para qualquer outro recurso.

Faz parte do mesmo sistema de acesso da organização

Permissão de App não é um mecanismo à parte: entra no mesmo vocabulário de concessões usado no resto da plataforma. Administrar quem pode o quê dentro de um App usa a mesma lógica — e a mesma tela — que administrar qualquer outro acesso da organização.

Quem pode receber uma concessão (13/08/2026): três sujeitos, não dois

Até então uma concessão de acesso a um App só podia ir para uma pessoa ou para um time. Agora existe um terceiro sujeito: um agente da organização, agindo dentro daquele App com identidade própria, no modo "próprio" de autenticação de agente. O próprio App fica de fora da lista de sujeitos que ele mesmo pode escolher — conceder acesso a si mesmo não teria significado.

Diferença que importa: o agente não tem baseline (não herda owner/admin de ninguém) e não herda concessão de time — só o que foi concedido a ele, diretamente, entra no cálculo. Uma pessoa com concessão de time continua herdando por junção a cada pergunta; um agente nunca é membro de time.

Revogar um acesso agora responde com honestidade quando não havia nada para revogar: tentar remover uma concessão que já não existe devolve 404 e não grava nada na trilha — antes, um DELETE que não casava linha nenhuma respondia "ok" mesmo sem ter revogado, e a tela dizia "removido" com o acesso ainda valendo.