> For the complete documentation index, see [llms.txt](https://docs.airops.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.airops.com/docs/pt/acoes/playbooks/run-a-playbook.md).

# Executar um Playbook

Execute Playbooks manualmente, a partir de Grids ou com Triggers

Pode executar um Playbook manualmente a partir do editor, de uma Grid ou automaticamente com um Trigger. Cada execução cria uma Session com detalhes de execução e Artifacts.

## Executar manualmente

Use uma execução manual quando estiver a testar um Playbook ou a executá-lo para um único caso de utilização.

1. Abra o editor do Playbook.
2. Clique em **Executar Playbook**.
3. Forneça quaisquer Inputs necessários.
4. Revise o resultado da Session e os Artifacts.

{% hint style="info" %}
As execuções iniciadas a partir do editor do Playbook usam tarefas de teste antes das tarefas de produção. Cada workspace tem 50.000 tarefas de teste gratuitas por mês que podem ser usadas para testes de Workflow e Playbook. Se o seu workspace usar todas as tarefas de teste, o AirOps usa tarefas de produção para execuções adicionais no editor. Pode rever a utilização de tarefas de teste em **Utilização** separador.
{% endhint %}

## Executar a partir de uma Grid

Use uma Grid quando quiser executar um Playbook publicado em linhas de dados estruturados.

1. Abra a Grid.
2. Clique em **+ Adicionar Coluna**.
3. Selecione o **Playbooks** separador.
4. Procure o Playbook.
5. Associe colunas da Grid, valores estáticos ou Brand Kits aos Inputs do Playbook.
6. Execute o Playbook para uma linha ou em massa.

{% hint style="info" %}
Quando um Playbook é executado a partir de uma Grid, usa a versão e os mapeamentos de Input configurados nessa coluna da Grid. As edições que fizer no chat da Session aplicam-se aos Artifacts, não ao Playbook. Para alterar o próprio Playbook, abra-o no editor.
{% endhint %}

Veja [Executar Playbooks na Grid](/docs/pt/acoes/grids/run-playbooks-in-grid.md) para seleção de versão, execuções em massa, estado da Session e revisão de Artifact.

### Voltar à Grid de origem

Depois de abrir um Playbook a partir de uma Grid, selecione **Voltar à Grid** nas ações rápidas do editor para voltar à folha de origem. Se abriu o Playbook diretamente, o AirOps retorna à Grid associada ou apresenta um seletor quando várias Grids estão associadas. A opção fica oculta quando não há Grids associadas ativas.

## Executar automaticamente

Use um Trigger quando o Playbook deva iniciar num horário agendado, a partir de um evento externo ou de um sinal do AirOps.

Os tipos de Trigger incluem:

* **Agendamento:** Executar com uma cadência recorrente.
* **Webhook:** Executar a partir de um pedido HTTP.
* **Monitor:** Executar quando o Parallel Web Systems detetar uma condição da sua consulta de monitorização.
* **AEO Insight:** Executar quando um limite de Insights ativado é atingido.

As execuções acionadas aparecem em Run History. As execuções que precisam de Human Review também aparecem na Inbox.

{% hint style="info" %}
Para configuração do Trigger, definições de versão e exemplos de payload de webhook, consulte [Gatilhos de Playbook](/docs/pt/acoes/playbooks/triggers.md).
{% endhint %}

## Versões e alterações de Input

As colunas da Grid e os Triggers podem usar **Predefinido** ou uma versão fixa do Playbook.

* **Predefinido** segue a versão publicada atual.
* **Fixada** continua a usar a versão selecionada até a alterar.

{% hint style="warning" %}
Se uma nova versão do Playbook alterar os Inputs, atualize quaisquer mapeamentos de colunas da Grid e a configuração de Input do Trigger antes de executar em escala. Novos Inputs obrigatórios sem valores mapeados ou configurados podem fazer com que as execuções falhem na validação ou sejam ignoradas.
{% endhint %}

## Rever Sessions

Cada execução produz uma Session. Uma Session contém:

* O registo completo da execução.
* Inputs usados para a execução.
* O modelo usado e os respetivos detalhes de raciocínio, quando disponíveis.
* Todos os Artifacts produzidos pelo Playbook.
* Estado de Human Review, quando o Playbook inclui blocos de revisão.

As Sessions são visíveis em **Histórico de execuções** no canto superior direito do editor do Playbook e na Inbox quando é necessária revisão.

A atividade da Session também mostra o progresso da revisão. A atividade do revisor é agrupada sob a tentativa de verificação que a produziu, enquanto as correções feitas pelo agente principal permanecem na linha temporal principal. Pode rever esta atividade durante uma execução ou depois de atualizar a Session.

## Colabore nos Artifacts

Os Artifacts suportam comentários, sugestões, menções, histórico de versões e edições assistidas por IA. Use estes controlos quando o resultado de uma Session precisar de revisão antes da publicação ou de utilização posterior. As edições afetam o Artifact dessa Session, não as instruções do Playbook.

Veja [Artefatos](/docs/pt/acoes/playbooks/artifacts.md) para o fluxo completo de colaboração, recuperação, ligação estável e Grid.

## Interromper ou executar novamente uma Session da Grid

Se uma Session estiver marcada como **Arquivada**, pode rever o seu histórico e artifacts, mas não pode enviar-lhe novas mensagens. Inicie uma nova Session para continuar o trabalho.

Numa Grid, as células do Playbook mostram o estado atual da Session. Pode abrir a Session a partir da célula, interromper uma Session em fila ou em execução e executar novamente Sessions terminais. Se uma Session tiver sido executada numa versão mais antiga do Playbook, a célula mostra um aviso para que a possa executar novamente na versão atual.

## Use dois Playbooks para monitorização e ação

Muitas configurações de Playbook usam um padrão de dois Playbooks.

O primeiro Playbook monitoriza dados e encontra trabalho para si. Pode ser executado com um Trigger, analisar os AirOps Insights, identificar oportunidades e enviá-las para uma Grid com o AirOps MCP, como URLs para atualizar ou prompts para segmentar.

O segundo Playbook age sobre essas linhas e produz o resultado. Pode executá-lo manualmente ou como uma ação da Grid na linha produzida pelo primeiro Playbook, como redigir uma publicação de blogue para um prompt-alvo ou atualizar uma página existente.

Um Playbook encontra o trabalho. O outro Playbook faz o trabalho e leva-o até um resultado. Pode usar qualquer um dos padrões em separado, mas normalmente são combinados.

{% hint style="info" %}
Um Playbook que monitoriza dados costuma usar Memory para evitar recomendar novamente o mesmo item dentro de uma janela configurada, como 60 dias.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.airops.com/docs/pt/acoes/playbooks/run-a-playbook.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.