Inventário de Artefatos, ModularCRM

Documento companheiro do DRS, ModularCRM. Responde: o que precisa existir e como deve ser. Cada artefato traz quatro campos: para que serve, com o que se relaciona, onde fica, e a especificação (a ficha técnica que basta para construir sem perguntar).

1. Estrutura multi-empresa

Organização (empresa cliente)

• Para que serve: representar cada empresa cliente como um espaço isolado.
• Relacionado com: membros, planos, todas as tabelas de negócio (por identificador de organização).
• Onde fica: base do isolamento; toda tabela de negócio referencia a organização.
• Especificação: identificador próprio, nome, metadados de configuração; é o valor que a RLS usa para isolar linhas. Toda tabela de negócio carrega esse identificador e é protegida por política de segurança em nível de linha.
• Estado (2026-07-11): o isolamento entre empresas está firme e o modo "entrar como empresa" do Super Admin funciona: a regra de isolamento aceita a empresa escolhida (só para Super Admin, só durante o modo, validada no banco) e cada entrada e saída fica no log de auditoria ({AUD-01} entregue).

Papel do membro

• Para que serve: definir o que cada pessoa pode fazer dentro de uma empresa.
• Relacionado com: organização, perfil de usuário, todas as telas (controle de acesso).
• Onde fica: vínculo entre pessoa e empresa.
• Especificação: três papéis, dono, administrador e membro; o Super Admin do fornecedor é marcado no perfil, com visão cruzada entre empresas. Além desses três papéis fixos, o produto prevê papéis personalizados por empresa, com permissão por módulo e por ação (ver, criar, editar, excluir, exportar), conforme o RF-PERM-001. O papel deve valer no banco, não só na tela.
• Estado (2026-07-14): os três papéis fixos funcionam. Os papéis personalizados não existem na prática: não há tela para criar nem para atribuir papel, e em produção há zero papéis cadastrados e nenhum membro que não seja dono, então o RF-PERM-001 segue não entregue (é o {AUD-37} do Roadmap). O que já é verdade desde 2026-07-14 é a metade-banco: as ações de escrita (criar, editar, excluir) em nove tabelas de gestão consultam uma função de autorização que espelha o mesmo controle do frontend, então um membro cujo papel nega escrever é recusado pelo banco mesmo chamando a API direto ({AUD-29} entregue, migration 089). Ver e exportar ainda valem só na tela ({AUD-36}), e o catálogo de módulos do código está menor que o do DRS e divergente em algumas telas ({AUD-38}). A trilha de ações de operador grava de fato desde 2026-07-12: um gatilho genérico registra criar, editar e excluir em 22 tabelas de gestão (migration 080) com autor, tipo, entidade, rótulo e data, e a tela de Registro de Auditoria lê essa trilha real ({AUD-10} entregue). Estado (2026-07-19): a metade-produto do RF-PERM-001 passou a existir: a tela de Papéis e Permissões foi entregue ({AUD-37}), com criação, edição e atribuição de papel personalizado por módulo e ação. O reforço no banco deixou de ser só das nove tabelas iniciais de escrita: chegou aos módulos secundários ({AUD-38b}), às tabelas acessórias e junções ({AUD-38c}, migration 100) e aos módulos de Configurações e Administração ({AUD-38d}, migration 101), e a permissão de ver passou a valer no banco nas quinze tabelas operacionais ({AUD-36}, migration 099). Exportar segue só na tela (colapsa em ver). Restam dois gaps medidos na fila da Onda AUD: a leitura de Configurações e Administração ainda não é reforçada por papel ({AUD-105}) e o padrão do membro sem papel libera editar Administração por omissão ({AUD-106}).

Plano

• Para que serve: definir limites, preços e recursos por empresa.
• Relacionado com: organização, cobrança, portal de agência.
• Onde fica: cadastro de planos, atribuível a empresas.
• Especificação: nome, limites, preço, recursos; atribuição a empresa é editável em tela sem alterar banco (RNF-008).
• Estado (2026-07-11): o vínculo entre empresa e plano passou a ser íntegro por gatilho no banco (identificador do plano como fonte da verdade, rótulo de plano como espelho sincronizado, plano inexistente ou inativo rejeitado); as seis empresas em produção têm vínculo íntegro, e o tenant piloto Hiit Fitwear está no plano Pro real com ciclo de cobrança iniciado ({AUD-07} do Roadmap, entregue).

2. Contatos e leads

Contato

• Para que serve: representar a pessoa (lead ou cliente).
• Relacionado com: empresa, tags, campos personalizados, conversas, oportunidades, atividades, identificadores de canal.
• Onde fica: entidade central do CRM.
• Especificação: dados de identificação (nome, telefone, e-mail), estado, avatar, metadados; campos personalizados por valor; vínculo de mesclagem quando unificado. Deduplicação por telefone, e-mail ou identificador de canal na entrada.
• Estado (2026-07-12): a exclusão de contato ganhou semântica honesta nas dependências (migration 079, {AUD-18} do Roadmap, entregue): automações agendadas e envios de formulário do contato são removidos junto, aberturas e cliques de campanha ficam anônimos preservando as métricas, e o vínculo de mesclagem é desfeito sem travar a exclusão.

Campo personalizado

• Para que serve: estender os dados de contato, empresa ou oportunidade.
• Relacionado com: contato, empresa, oportunidade, modelos de mensagem, automações.
• Onde fica: definições por empresa, organizadas em pastas.
• Especificação: nome, tipo do campo, objeto alvo (contato, empresa, oportunidade), pasta, chave única no estilo de variável de modelo (reutilizável em mensagens e automações). Paridade GHL: agrupamento por pasta e por objeto.

Tag

• Para que serve: segmentar contatos.
• Relacionado com: contatos, listas inteligentes, automações, pontuação.
• Onde fica: cadastro de tags por empresa.
• Especificação: nome; aplicável individual e em massa; usável como critério em filtros, listas e gatilhos.

Regra de pontuação

• Para que serve: pontuar leads por engajamento.
• Relacionado com: contatos, eventos (e-mail, agendamento, resposta, tag), automações.
• Onde fica: conjunto de regras global (Super Admin) e por empresa.
• Especificação: cada regra é evento gatilho, filtro, ação (somar ou subtrair pontos) e valor; o conjunto tem liga/desliga. Regras globais são herdadas e ajustáveis pela empresa (diferencial sobre o GHL).

Lista inteligente

• Para que serve: salvar e reutilizar combinações de filtros.
• Relacionado com: contatos, filtros, compartilhamento.
• Onde fica: listas por empresa, compartilháveis.
• Especificação: conjunto de filtros nomeado; visível para reuso e compartilhável entre operadores da mesma empresa.

3. Funil e vendas

Funil e estágios

• Para que serve: organizar o processo de venda.
• Relacionado com: oportunidades, contatos, automações.
• Onde fica: cadastro por empresa.
• Especificação: funil com estágios renomeáveis e reordenáveis; oportunidade pertence a um estágio; valor por estágio somado.

Oportunidade

• Para que serve: representar um negócio em andamento.
• Relacionado com: contato, funil, produtos, orçamentos.
• Onde fica: dentro de um funil.
• Especificação: vínculo com contato, estágio atual, produtos com preço, valor total; movimentação registrada no histórico.

4. Conversas e canais

Conversa e mensagem

• Para que serve: registrar o diálogo com o contato em qualquer canal.
• Relacionado com: contato, canal, anexos, notificações.
• Onde fica: inbox unificado por empresa.
• Especificação: conversa vinculada a contato e canal; mensagens com sentido (entrada/saída), anexos e carimbo de tempo; unificação por identificadores de canal.
• Estado (2026-07-11): o envio ficou honesto ({AUD-02} entregue): sem canal conectado o sistema bloqueia com aviso e não grava nada; com canal, o status gravado é o resultado real do despacho; o envio de e-mail não duplica mais o registro e leva o assunto e o encadeamento reais.

Configuração de canal

• Para que serve: conectar cada canal por empresa.
• Relacionado com: conversas, integrações, contato externo.
• Onde fica: configurações da empresa.
• Especificação (matriz de canais, Apêndice B do DRS):
• WhatsApp: provedor Evolution (central própria, uma instância por empresa, conexão por QR) ou Meta Cloud (oficial paga); a empresa escolhe.
• Messenger e Instagram: pela conexão Meta da empresa.
• E-mail: recebimento por IMAP e envio por SMTP, com a senha de IMAP guardada cifrada.
• SMS: pelo Twilio.
• Webchat: por widget incorporável próprio e página pública de chat, em produção desde 2026-07-11.
• Estado (2026-07-11): WhatsApp, e-mail e SMS configuráveis; envio pelo inbox funciona. O chat público e o widget incorporável entraram em produção com a entrega do {AUD-04}: a página pública de chat e o widget embedado num site externo iniciam conversa que aparece no inbox, e o operador responde normalmente. O envio de mensagem numa empresa sem canal ativo ficou honesto ({AUD-02} entregue): bloqueia com aviso e não grava nada.
• Estado (2026-07-14): a criação de conta de e-mail em Caixas de Email foi corrigida ({AUD-34} do Roadmap, entregue): o identificador da empresa passou a acompanhar o envio, que antes faltava, e o interruptor de pular teste de conexão do Super Admin passou a ser respeitado pelo botão Salvar. Salvar a configuração de e-mail e a de SMS voltou a responder pela URL pública com o mesmo guardião de autenticação ({AUD-27} do Roadmap, entregue); as duas rotas que gravam credencial (senha SMTP, token do Twilio) agora exigem dono ou administrador da empresa.
• Estado (2026-07-17): o whatsapp ganhou um lugar único que responde se o canal da empresa está utilizável, uma sonda ao vivo do estado real, e os quatro pontos que despacham passaram a decidir por ele ({AUD-83} entregue); a rotina de lembrete parou de ler uma coluna que não existe ({AUD-84} entregue); e a credencial escrita por extenso no código foi removida, com o serviço passando a recusar subir sem a credencial da configuração ({AUD-90} entregue). Fica registrado que, para provisionar o canal de whatsapp de verdade, a instância do serviço externo precisa existir e ser pareada, o que o tenant piloto ainda não tem; o canal alternativo (Meta Cloud) está inutilizável nas duas pontas ({AUD-96}); e o serviço que mantém o estado do canal não reconcilia nem tem pulso, então a telemetria de estado do canal pode mentir por vencimento ({AUD-98}).

Resposta pronta (snippet)

• Para que serve: agilizar o atendimento.
• Relacionado com: conversas, campos do contato.
• Onde fica: cadastro por empresa.
• Especificação: texto reutilizável com substituição de variáveis do contato.

5. Automações

Automação

• Para que serve: executar sequências de ações a partir de gatilhos.
• Relacionado com: contatos, tags, mensagens, tarefas, funil, links rastreáveis.
• Onde fica: editor visual por empresa, organizadas em pastas.
• Especificação: exatamente um dos dezesseis gatilhos nomeados pelo RF-AUTO-002, e nenhum outro: contato criado, contato atualizado (só dispara nos campos que o administrador marcar), contato respondeu, mensagem recebida, e-mail recebido, formulário enviado, tag adicionada, tag removida, etapa alterada, oportunidade ganha, oportunidade perdida, limite de armazenamento atingido, agendamento marcado, lembrete de agendamento, clique em link rastreável (só dispara com contato atribuído, e qualquer link da empresa dispara), ou sem gatilho automático (a automação roda quando outra automação a chama ou quando o administrador manda executar à mão, RF-AUTO-043). A lista oferecida na tela não pode conter gatilho que o produto não dispara, e vem de uma fonte única, nunca mantida à mão em cada tela. Depois do gatilho: uma sequência de ações, passos de espera na fila, condições de saída; status rascunho ou ativa; métricas de inscritos total e ativos. A lista de ações oferecida na tela é exatamente a lista de ações que o motor executa, nos dois sentidos e vinda de uma fonte única, nunca mantida à mão em cada lado, pela mesma razão da regra dos gatilhos acima (RF-AUTO-044). Cada passo executado registra um desfecho honesto, e são três: concluído apenas quando o efeito aconteceu de verdade; ignorado quando faltou o dado do contato ou o canal da empresa, caso em que a automação segue; e falha quando a configuração é inválida ou houve erro real, caso em que a automação para (RF-AUTO-044). Ação que o produto não executa nunca é oferecida na tela nem registrada como concluída. A escolha de qual link dispara não existe nesta entrega, e é o {AUD-63}. Estado das ações (2026-07-16): a regra da lista de ações está violada nos dois sentidos, e a ficha desta automação afirmava até esta data, como se funcionassem, duas ações que o produto não executa. A tela oferece mover etapa e atualizar status da oportunidade, e o motor não tem nenhuma das duas: o passo é configurado, salvo, ativado, aparece verde e não faz nada, para sempre ({AUD-74}). A ação de mover a oportunidade de etapa no funil existe e funciona no motor, e não é oferecida na tela ({AUD-74}). A ação de criar tarefa está desativada, porque o cadastro de tarefas não existe, e ainda assim reporta o passo como concluído ({AUD-77}). A ação de condição avalia e não ramifica ({AUD-77}), e a de enviar fatura não emite fatura nenhuma e ainda registra no histórico do contato que emitiu ({AUD-76}). Nenhum passo de automação jamais tinha sido registrado como falha ou ignorado em toda a história do produto até 2026-07-16; o {AUD-68} fechou nesta data (commit 67224ec, merge 06e9724), com o executor passando a derivar o desfecho de cada rota do que ela de fato faz, e não mais da ausência de erro, exatamente como o RF-AUTO-044 passou a exigir. O que o {AUD-68} não corrige, por desenho, são os quatro cards abaixo: eles fazem a ação errada com sucesso, então não há erro nenhum para o novo desfecho detectar. Provisionar a partir desta ficha exige ler os quatro cards, {AUD-74}, {AUD-75}, {AUD-76} e {AUD-77}, todos ainda em aberto: até eles fecharem, a lista de ações da tela não é fonte confiável do que o produto faz. Estado dos gatilhos (2026-07-17): o fato contato criado passou a ser exaustivo por construção. As fases F3 e F4 do {AUD-65} entregaram (merge e4032e6) um trilho único: um gatilho no banco depois de cada inserção de contato (migration 093) notifica o canal próprio automation_event, o ouvinte do processo de saída enfileira na fila mcrm-automation-events, um consumidor novo (automation-worker) chama o emissor de eventos por HTTP no endpoint interno /internal/fire-event, e o motor de sempre dispara a automação, sem nunca criar execução direto. Com isso, os treze caminhos antes mudos passaram a disparar por construção, e os cinco emissores antigos foram removidos, então provisionar a automação de contato criado não depende mais de cada caminho lembrar de emitir. A chave geral foi ligada em 2026-07-17 sob observação, com o escopo contido na organização de teste, e cobre só o fato contato criado; os demais fatos (tag adicionada, etapa alterada, oportunidade, agendamento) seguem por disciplina, com o {AUD-85} aberto, e a durabilidade do salto do gatilho até o ouvinte é dívida do {AUD-99}. Estado dos gatilhos (2026-07-16): provisionar a partir desta ficha exige saber de três coisas que a especificação acima descreve e o produto não cumpre. Primeira: o gatilho de contato criado é oferecido, mas treze dos dezoito caminhos que criam contato não o emitem, então a automação simplesmente não dispara neles ({AUD-65}, {AUD-66}, {AUD-57}); dos cinco que emitem, quatro são do backend, com emissão provada, e o quinto é do frontend, com emissão não provada e falha silenciosa por desenho ({AUD-85}). Segunda: a configuração do gatilho só é honrada para contato respondeu e e-mail recebido; para todos os outros, inclusive contato criado, o motor ignora qualquer configuração e casa com tudo ({AUD-81}), o que significa que a tela oferece um filtro que não filtra. Terceira: a especificação acima descreve o gatilho de contato atualizado como disparando “só nos campos que o administrador marcar”, e essa promessa depende do mesmo filtro que hoje não existe no motor. Estado dos gatilhos (2026-07-15): a tela oferece catorze dos dezesseis; o lembrete de agendamento e o contato atualizado voltaram ao requisito por decisão de produto de 2026-07-15, e o clique em link rastreável entrou na mesma data e foi entregue no mesmo dia pelo {AUD-51}, merge 109857f. Os dois que restam são backlog especificado nos cards {AUD-52} e {AUD-53}, não defeito.

Link rastreável

• Para que serve: medir cliques nos links enviados em mensagens.
• Relacionado com: mensagens, histórico do contato, RF-CONV-014.
• Onde fica: cadastro por empresa, usado em mensagens.
• Especificação: link curto que redireciona ao destino e contabiliza cada clique recebido, com criação, listagem e exclusão por empresa. Campos do cadastro: rótulo, endereço curto e destino, mais o contador de cliques. O endereço curto é único em todo o produto, e não por empresa. Quando a automação insere o link numa mensagem, ela o insere já com o id de envio daquele contato: um id opaco, por par de link e contato, o mesmo em todos os envios daquele par, válido só dentro do próprio link, e que nunca é o identificador do contato (RNF-010). Clique com id de envio válido: atribuído ao contato, registrado no histórico dele e dispara as automações do gatilho de clique em link. Clique sem id de envio, ou com id que não pertence àquele link: redireciona e conta, sem atribuir e sem disparar. Estado (2026-07-15): entregue. O {AUD-51} fechou nesta data, merge 109857f: o produto passou a gravar o clique com o contato atribuído, por um id opaco de envio por par de link e contato emitido pela RPC issue_link_token, a lançar o clique no histórico do contato e a disparar a automação ativa no gatilho de clique em link. Este artefato agora conta cliques por pessoa, não só por link.

6. Calendário e agendamento

Calendário

• Para que serve: disponibilizar horários para agendamento.
• Relacionado com: agendamentos, Google Calendar, contatos.
• Onde fica: cadastro por empresa.
• Especificação: regras de disponibilidade (dias, horários, duração, intervalos), exceções pontuais, sincronização bidirecional com o Google, página pública de agendamento sem login, reagendamento por link seguro, confirmações e lembretes.
• Estado (2026-07-11): criar calendário, a grade da agenda e a página pública de agendamento funcionam; a página pública lê por rotas públicas do backend com lista fechada de campos (sem acesso anônimo ao banco), agenda com vínculo a contato, recusa horário ocupado e cancela por link ({AUD-03} entregue). Sincronização com o Google depende da liberação do aplicativo Google.

7. Cobrança e agência

Fatura

• Para que serve: cobrar as assinaturas.
• Relacionado com: organização, plano, portal de agência.
• Onde fica: por empresa e no nível da agência.
• Especificação: valor, vencimento, status (aberta, paga, vencida); cobrança V1 por Pix manual; renovação por rotina e lembretes; painel de receita recorrente para o Super Admin.
• Estado (2026-07-11): o vínculo de plano foi corrigido ({AUD-07} entregue): a empresa com plano pago tem referência íntegra ao cadastro de planos, os limites aplicados na tela respeitam o plano vinculado, o MRR do painel passou a ler o preço real do cadastro (sem mapa fixo no código), e o cron diário de faturamento, que respondia 401 desde 2026-04-19 por só aceitar o segredo via parâmetro de URL, foi corrigido e provado com o comando exato do crontab (fatura de teste gerada, empresa marcada em atraso, rollback limpo).

Modelo pronto (snapshot)

• Para que serve: replicar configuração para novas subcontas.
• Relacionado com: subcontas, funis, campos, automações.
• Onde fica: portal de agência.
• Especificação: captura de configuração aplicável a uma subconta, com registro do resultado da aplicação.

8. Integrações e API pública

Conexão de integração

• Para que serve: ligar a empresa às plataformas externas.
• Relacionado com: Meta, Google, canais, conversões.
• Onde fica: integrações da empresa.
• Especificação: autorização por empresa (OAuth), tokens guardados cifrados em repouso, status por conexão, revogável; nunca expõe token em tela.
• Estado (2026-07-10): conexão Meta por empresa funciona e o fluxo de autorização abre corretamente. Achado da auditoria, resolvido: os tokens da conexão Meta (usuário, página e CAPI) estavam em texto puro e foram cifrados em repouso em 2026-07-10 ({AUD-14} do Roadmap, entregue); o navegador deixou de receber qualquer segredo da integração.
• Estado (2026-07-14): dez rotas do servidor de integrações que ficavam mortas pela reescrita do Nginx (entre elas eventos do Google Calendar, reprocessar nomes de contatos do Meta, relatórios de Google Analytics, Meta Ads e Google Meu Negócio, e formulários do Meta Leads) voltaram a responder pela URL pública, agora com o mesmo guardião de autenticação e acesso à empresa do {AUD-26} ({AUD-27} do Roadmap, entregue).
• Estado (2026-07-23): a identificação do aplicativo Meta e a configuração do fluxo deixaram de morar fixas no código e passaram a ser editáveis pela operação numa tela própria (sub-fatia 1 do {C-MCRM-2}, 2026-07-22). A partir de 2026-07-23 o caminho primário de autorização é o Login do Facebook para Empresas pelo aplicativo dedicado, e o tipo do acesso recebido é perguntado à própria Meta antes de guardar: acesso de usuário de sistema fica gravado como permanente, sem data de vencimento, e acesso comum continua sendo estendido para longa duração com vencimento registrado; sem resposta da Meta, nunca se grava como permanente por adivinhação. Na mesma entrega, a verificação de assinatura dos webhooks da Meta deixou de deixar passar quando o segredo não estava disponível: agora ela nega, e durante a troca de aplicativo aceita tanto o segredo novo quanto o legado, para não derrubar de uma vez as conexões que ainda assinam pelo aplicativo antigo. Falta ainda o que depende de gente e do {C-MCRM-1}: a autorização de verdade na Meta e a gravação do segredo do aplicativo novo. O estado mostrado na tela ainda não distingue conexão permanente de conexão de longa duração nem acusa conexão morta, o que é a sub-fatia 4 e fecha o {AUD-42}.

Chave de API

• Para que serve: autenticar integrações externas da empresa.
• Relacionado com: API pública, escopos, auditoria.
• Onde fica: área de desenvolvedores por empresa.
• Especificação: chave guardada com hash forte, escopos de permissão; chamadas fora do escopo ou sem chave válida rejeitadas.

Assinatura de eventos de saída

• Para que serve: entregar eventos do sistema a destinos externos.
• Relacionado com: eventos, fila, auditoria.
• Onde fica: área de desenvolvedores por empresa.
• Especificação: destino, evento assinado, segredo de assinatura cifrado; entrega com assinatura verificável, novas tentativas, fila de mortos e reenvio manual; idempotência por chave; limite de requisições por política.

Formulário público

• Para que serve: captar leads.
• Relacionado com: contatos, campos personalizados, incorporação.
• Onde fica: por empresa, publicável e incorporável.
• Especificação: campos configuráveis, URL pública e código de incorporação; cada envio cria ou atualiza contato com deduplicação.
• Estado (2026-07-10): validado de ponta a ponta na auditoria (criar formulário, publicar, enviar pela URL pública e o lead aparecer com origem "formulário").

9. Artefatos do backlog de paridade GoHighLevel

Os módulos abaixo entram com a Fase 6 do Roadmap e detalham-se na seção 11 do DRS. Em 2026-07-10 o backlog foi recortado ao escopo interno do produto: saíram Telefonia, Cursos e comunidades, Sites institucionais, Funis e Loja, e a revenda do modo Agência.

Objeto personalizado e associações (extensão do CRM)

• Para que serve: deixar cada empresa criar tipos de registro próprios e ligá-los entre si com papéis nomeados.
• Relacionado com: contatos, empresas, oportunidades, automações, API.
• Onde fica: configurações de objetos por empresa.
• Especificação: ver RF-LEAD-014 a 025 (seção 11.2 do DRS).

Módulo de Marketing

• Para que serve: marketing de saída (email, social, anúncios; gestor de afiliados do cliente em avaliação).
• Relacionado com: contatos, automações, campanhas, relatórios.
• Onde fica: módulo novo por empresa.
• Especificação: ver RF-MKT (seção 11.10 do DRS).

Módulo de Inteligência Artificial (traga sua própria chave)

• Para que serve: bot de conversa, geração de conteúdo e ações de IA nas automações.
• Relacionado com: conversas, automações.
• Onde fica: módulo novo por empresa; IA gratuita padrão da Modulareasy, com opção de IA paga usando a chave do próprio cliente, por subconta.
• Especificação: ver RF-AI (seção 11.11 do DRS). IA de voz saiu com a telefonia.

Módulo de Reputação e presença online

• Para que serve: solicitar e gerir avaliações (Google, Facebook).
• Relacionado com: contatos, conversas, automações, Google Business, Meta.
• Onde fica: módulo novo por empresa.
• Especificação: ver RF-REPU (seção 11.12 do DRS). A parte de diretórios (Yext) depende de serviço externo.

Gestão de subcontas e provisionamento interno

• Para que serve: provisionar cliente novo rápido, configurar por modelo, aprovar e controlar acesso e isolamento das subcontas.
• Relacionado com: organizações, snapshots, permissões.
• Onde fica: painel super-admin da Modulareasy.
• Especificação: ver RF-AGY-007 a 015 (seção 11.9 do DRS). Sem revenda, cobrança nem white-label.