Como personalizar a Prompt Library do Copilot em Power Apps

O que é a prompt library do Copilot em model-driven apps

Quando o painel de chat do Copilot é aberto dentro de uma model-driven app, ele não começa com uma tela em branco. Aparece uma lista de sugestões de prompt organizadas em grupos, o que a Microsoft chama internamente de Sparks. São atalhos que o usuário clica em vez de digitar, pensados para reduzir a fricção de “não sei o que perguntar para a IA”.

Por padrão, esses Sparks são gerados automaticamente a partir do schema da tabela ativa: nome das colunas, tipo de dado, relacionamentos. Funciona, mas é genérico. Um prompt como “resuma este registro” serve para qualquer tabela e não carrega nenhum conhecimento do processo de negócio por trás daquele formulário.

A plataforma permite substituir ou complementar essa geração automática por uma lista curada, definida por quem conhece o processo. Isso é feito fora do designer da app, dentro do Copilot Studio, através de um tópico que escuta um evento de sistema chamado RequestSparks.

Por que vale o esforço de personalizar

Prompt genérico tem baixa taxa de clique. Se o usuário abre o painel e vê sugestões que não refletem o que ele realmente precisa fazer naquele registro, ele ignora a lista e digita manualmente, ou pior, fecha o painel. Curar os Sparks é uma forma de codificar conhecimento operacional na interface: em vez de “resuma este chamado”, o prompt pode ser “liste os SLAs em risco deste chamado e sugira a próxima ação”, algo que só faz sentido para quem desenhou o processo.

Há também um efeito de adoção. Times de operação costumam medir uso de Copilot por engajamento com o painel, não só por volume de perguntas digitadas. Prompts relevantes aumentam esse número sem exigir treinamento de usuário final, porque a sugestão já está na tela.

Pré-requisitos antes de abrir o Copilot Studio

• Copilot habilitado no ambiente: o recurso de IA generativa do Dataverse precisa estar ativo no ambiente onde a app roda. Isso é uma configuração de ambiente, não da app individual.
• Copilot habilitado na app model-driven: o controle de chat precisa estar ligado nas configurações da app, senão o painel nem aparece para o usuário final.
• Acesso ao Copilot Studio: editar o tópico de sistema exige permissão de maker no ambiente, tipicamente papel de administrador de sistema ou de ambiente. Não é uma tarefa para o usuário de negócio fazer sozinho sem revisão técnica.
• Licenciamento do Copilot Studio: a execução de tópicos consome mensagens do orçamento de Copilot Studio do ambiente, conforme os direitos de uso incluídos na licença ou add-on contratado. Antes de liberar em produção, vale confirmar com quem administra a licença se o volume esperado de aberturas do painel cabe no consumo mensal, porque cada disparo do evento é uma execução de tópico.

Passo a passo: criando o tópico que escuta RequestSparks

1. Localize o bot de sistema do Copilot Studio

Cada ambiente com o Copilot do Dataverse habilitado tem um agente de sistema associado, reservado para orquestrar o painel de chat das apps model-driven. Ele aparece na lista de agentes do Copilot Studio do ambiente, geralmente com um nome vinculado ao Dataverse ou à app. Não é preciso criar um bot novo, a customização acontece dentro desse agente existente.

2. Crie o tópico e configure o gatilho de evento

Dentro do agente, crie um tópico novo em branco e defina o gatilho como Event, selecionando RequestSparks na lista de eventos de sistema disponíveis. Esse evento é disparado toda vez que o painel do Copilot é aberto e precisa montar a lista de sugestões, antes de qualquer interação do usuário.

É neste ponto que costuma haver confusão: existem vários eventos de sistema listados no Copilot Studio para apps model-driven, alguns relacionados a ações de coluna, outros a comandos. RequestSparks é especificamente o que controla a biblioteca de prompts inicial, não o processamento de uma pergunta já digitada.

3. Monte SparksGroups e SparksArray em Power Fx

Dentro do tópico, use um nó de fórmula Power Fx para popular duas estruturas: uma tabela de grupos e uma tabela de prompts vinculados a esses grupos. A convenção usada pela plataforma é ter um array de grupos (SparksGroups) e um array de itens (SparksArray), onde cada item referencia o grupo ao qual pertence pelo nome.

// Define os grupos que vão aparecer como cabeçalho na lista de sugestões
Set(
    Topic.SparksGroups,
    Table(
        { Name: "Ações rápidas" };
        { Name: "Análise do registro" }
    )
);

// Define os prompts individuais, cada um vinculado a um grupo pelo campo GroupName
Set(
    Topic.SparksArray,
    Table(
        {
            GroupName: "Ações rápidas";
            Text: "Resuma este registro em três frases";
            Prompt: "Resuma o registro atual em ate tres frases, destacando status, responsavel e proxima acao"
        };
        {
            GroupName: "Ações rápidas";
            Text: "Sugira uma resposta ao solicitante";
            Prompt: "Redija uma resposta profissional ao solicitante com base no historico deste registro"
        };
        {
            GroupName: "Análise do registro";
            Text: "Quais riscos este caso apresenta?";
            Prompt: "Liste riscos operacionais ou de prazo associados a este registro, considerando prioridade e SLA"
        }
    )
)

Repare na separação entre Text, o rótulo curto que aparece no botão de sugestão, e Prompt, o texto completo que é efetivamente enviado ao modelo quando o usuário clica. Essa distinção existe porque um rótulo bom para interface costuma ser curto demais para gerar uma resposta útil se enviado ao pé da letra. Vale escrever o Text pensando em legibilidade na tela e o Prompt pensando em instrução clara para o modelo, com contexto suficiente para reduzir alucinação.

4. Retorne as variáveis de saída e publique

O evento de sistema espera receber as variáveis preenchidas de volta antes de encerrar o tópico. Confirme, no painel de variáveis do tópico, quais são as variáveis de saída esperadas pelo evento no seu ambiente, porque o nome exato pode variar entre versões do Copilot Studio. Depois de mapear SparksGroups e SparksArray como saída, salve o tópico e publique o agente. Sem a publicação, a app continua usando a versão anterior do comportamento, mesmo que o tópico esteja salvo.

5. Teste dentro da app antes de liberar

Abra a model-driven app, entre em um registro da tabela alvo e abra o painel do Copilot. Os grupos e prompts customizados devem substituir, total ou parcialmente, a lista gerada automaticamente. Teste em pelo menos três cenários: registro novo sem dados preenchidos, registro existente com histórico e um usuário com permissões restritas na tabela, para confirmar que nenhum prompt sugerido referencia um dado que aquele perfil não deveria ver.

Personalizando por tabela e por contexto

Um único tópico pode atender várias tabelas se o evento expuser o nome lógico da tabela atual como variável de contexto. Nesse caso, use um Switch em Power Fx para montar arrays diferentes conforme a tabela, em vez de duplicar tópicos.

Set(
    Topic.SparksArray,
    Switch(
        Topic.TableLogicalName;
        "incident"; Table(
            { GroupName: "Suporte"; Text: "Priorize este chamado"; Prompt: "Avalie a prioridade deste chamado com base em SLA e impacto relatado" }
        );
        "opportunity"; Table(
            { GroupName: "Vendas"; Text: "Próximo passo desta oportunidade"; Prompt: "Sugira o proximo passo comercial desta oportunidade com base no estagio atual" }
        );
        // valor padrão para tabelas sem regra especifica
        Table(
            { GroupName: "Geral"; Text: "Resuma este registro"; Prompt: "Resuma o registro atual em ate tres frases" }
        )
    )
)

Essa abordagem centraliza a manutenção em um lugar só, o que ajuda governança, mas cria um tópico mais longo e mais arriscado de editar sem revisão. Em ambientes com muitas tabelas customizadas, considerar dividir em tópicos menores por área de negócio costuma compensar a duplicação, porque reduz o raio de impacto de um erro de fórmula.

Limitações e pegadinhas reais

• O tópico é global para todos os usuários da app. Não existe personalização nativa por usuário ou por segurança de linha dentro da lógica do Power Fx do tópico sem você mesmo construir essa checagem, consultando o papel de segurança ou a equipe do usuário via conector do Dataverse dentro do tópico.
• Prompt sugerido não valida permissão de dado. Se o texto do prompt referencia um campo sensível, o modelo pode tentar acessá-lo mesmo que o usuário não tenha visibilidade direta no formulário. Vale revisar cada prompt pensando em quem vai vê-lo, não só no que ele deveria fazer.
• Consumo de mensagens do Copilot Studio. Cada abertura do painel dispara o evento e executa o tópico, o que conta no orçamento de mensagens do ambiente. Em apps de alto volume de acesso, isso pode ser uma fração relevante do consumo mensal, vale medir antes de generalizar a customização para todas as tabelas.
• Publicação não é automática. Editar e salvar o tópico não muda o comportamento em produção até publicar o agente. É um erro comum testar, ver que “não funcionou” e não perceber que faltou publicar.
• Solução gerenciada versus não gerenciada. Se o ambiente segue um ciclo de ALM com solução gerenciada, o tópico customizado precisa ser exportado como parte da solução para viajar entre dev, teste e produção. Editar diretamente em produção funciona para prototipagem, mas quebra o rastreio de versão se não for capturado na solução depois.

Onde isso se encaixa na arquitetura de governança

Prompt library customizada é conteúdo de negócio disfarçado de configuração técnica. Quem escreve o texto dos Sparks está, na prática, definindo qual pergunta a organização considera relevante fazer sobre aquele processo, e isso muda com o tempo. Faz sentido tratar esse tópico como um artefato versionado, com dono definido e revisão periódica, da mesma forma que se trata um relatório ou um formulário de negócio, não como um ajuste único de configuração que se esquece depois de publicado.

Vale também documentar, fora do Copilot Studio, o racional de cada prompt: por que aquele texto foi escolhido, para qual perfil de usuário ele foi pensado, e quando foi revisado pela última vez. Sem isso, o tópico vira uma caixa preta que ninguém quer mexer depois que quem escreveu sai do projeto.

Personalizar a prompt library é um ajuste pequeno em superfície, mas mexe direto na percepção de utilidade do Copilot dentro da operação. É esse tipo de detalhe de arquitetura que costuma aparecer quando revisamos implantações de Copilot com clientes na Trinapse, decidindo o que vale automatizar via evento de sistema e o que exige orquestração mais ampla no Copilot Studio.