> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Set up your first workflow

> Build and publish your first Ravenna workflow: trigger on a form submission, branch on a condition, assign the ticket, notify Slack, then read the run log.

A workflow is background automation. Something happens, and Ravenna reacts the same way every time, with no one watching. This step builds one on top of the MFA reset form from the previous step: when the form is submitted, route the ticket, escalate it if the requester is fully locked out, and tell the team in Slack.

**Time:** about 20 minutes.

<Tabs>
  <Tab title="Interactive walkthrough" />

  <Tab title="Step-by-step">
    <Steps>
      <Step title="Create the workflow">
        Open **Workflows** in the sidebar, pick or create a collection, then click **New** > **Workflow**. Ravenna creates an untitled draft and opens the builder. Rename it in the header to something you will recognize in six months, such as "MFA reset routing".

        Draft workflows never run on their own, so nothing you do until you publish can affect a real ticket.
      </Step>

      <Step title="Add the trigger">
        Every workflow has exactly one trigger. Choose **Form Submitted** and filter it to the **MFA reset** form.

        The filter is the important part. Without it the workflow fires for every form in the workspace.

        <Tip>
          **Form Submitted** also fires when form values are updated on an existing ticket, not only at creation. If you want creation only, use **Ticket Created** filtered by form instead.
        </Tip>

        <Callout icon="link" color="#6B7280">Learn more about [every trigger](/documentation/automate/workflows/triggers-actions#triggers)</Callout>
      </Step>

      <Step title="Branch on the answer">
        Add an **If / Else** action. Set the condition against the "fully locked out" field from the form, using the value picker rather than typing anything by hand.

        Click any field input to open the picker, then choose from the trigger's data: ticket properties, requester name and email, custom field values, and Slack thread details. Values resolve when the workflow runs.

        <Callout icon="link" color="#6B7280">Learn more about [dynamic values](/documentation/automate/workflows/workflow-builder#data-flow-and-dynamic-values)</Callout>
      </Step>

      <Step title="Act on each branch">
        On the "yes, fully locked out" branch:

        * **Set Priority** to High
        * **Add Assignee**, pointing at whoever holds the on-call rotation

        On the other branch:

        * **Add Tags** with something like `mfa-standard`

        You do not have to decide an action the moment you add a step. An unconfigured step appears as a **Select action event** placeholder, and it can still take steps below it, so you can lay out the shape first. Publishing requires every placeholder to be filled in.
      </Step>

      <Step title="Notify the team">
        Add a **Send Message** action to your triage channel. Include the ticket's **Display ID** from the value picker, so the message reads `ITOPS-142` rather than an internal identifier.

        Both branches can point at this same step. Where two paths reconnect, the step waits for both parents and runs using whichever completed, so a failure on one branch does not silently stop the notification.

        <Callout icon="link" color="#6B7280">Learn more about [converging branches](/documentation/automate/workflows/workflow-builder#converging-branches)</Callout>
      </Step>

      <Step title="Test it as a draft">
        Trigger the workflow manually with test data, then open the run and read the step log. Each step records its raw and resolved inputs, its outputs, how long it took, and how every dynamic value resolved.

        Read the resolved inputs, not just the green ticks. A workflow that "succeeds" while sending a message with an empty ticket ID is the most common first mistake.
      </Step>

      <Step title="Publish it">
        Click **Publish**. Ravenna validates the workflow first, checking that the trigger is configured, every step has its required fields, and there are no unconnected or placeholder steps. Fix anything it flags, then confirm.

        Editing a published workflow is allowed, but changes only take effect when you publish again.

        <Callout icon="link" color="#6B7280">Learn more about [publishing and validation](/documentation/automate/workflows/publish)</Callout>
      </Step>

      <Step title="Submit a real form">
        Submit the MFA reset form from Slack as a normal employee would. Then open the workflow's run history and confirm the run completed, the priority and assignee landed, and the triage message posted.
      </Step>
    </Steps>
  </Tab>
</Tabs>

## Let Copilot build the next one

Once you know what the builder is doing, describing a workflow is faster than assembling it. Copilot generates the trigger, the steps, and the connections from a description.

<Prompt description="When a ticket in ask-it has had no reply for 4 business hours, post a reminder in the triage channel with the ticket link and the assignee.">
  When a ticket in ask-it has had no reply for 4 business hours, post a reminder
  in the triage channel with the ticket link and the assignee.
</Prompt>

Copilot cannot publish. It builds the draft, you open it, review it, and publish it yourself.

<Callout icon="link" color="#6B7280">Learn more about [building automations with Copilot](/documentation/automate/copilot/build-automations)</Callout>

## Workflows and agents hand off through the ticket

This trips up most people once, so it is worth being explicit: an agent cannot trigger a workflow, and a workflow cannot ask an agent a question. They connect through ticket state.

The agent handles the conversation and, when it is done, creates or updates a ticket: submits a form, sets a category, adds a tag, changes status. The workflow triggers on that change.

That is why escalation instructions let you name a form and category. Those are not decoration, they are the interface between the two systems.

<Callout icon="link" color="#6B7280">Learn more about [agents and workflows together](/documentation/automate/workflows/overview#using-both-together)</Callout>

## When a run goes wrong

Runs end in one of six states, and two of them are easy to confuse. **Completed with errors** means the run reached the end but a step errored on the way. **Failed** means it halted. Both are worth looking at, only one stops the automation.

Failed runs can be retried, and you can subscribe to failure notifications by email or Slack rather than discovering the problem from a complaint.

<Callout icon="link" color="#6B7280">Learn more about [monitoring, retries, and failure notifications](/documentation/automate/workflows/monitor)</Callout>

## Next

Automation handles the predictable requests. Knowledge handles the ones people ask in their own words.

<Card title="Set up knowledge" icon="arrow-right" href="/guides/day-one/set-up-knowledge">
  Point Ravenna at your documentation so the AI answers from your own sources.
</Card>


## Related topics

- [Set up a form](/guides/day-one/set-up-form.md)
- [Copilot recipes](/guides/how-to/copilot-recipes.md)
- [Day one](/guides/day-one/overview.md)
- [SLAs and business hours](/guides/playbooks/slas-and-business-hours.md)
- [Set up your first channel](/guides/day-one/set-up-first-channel.md)