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

# Conversations

> Keep requester messages, operator collaboration, status, and related work together.

A conversation is the record operators use to follow a request from intake to resolution. It has a
stable reference number, requester, status, priority, assignment team, and assignee.

Messages can arrive through Slack, Microsoft Teams, email, or operator-created work. Team members
work from one record in **Conversations** while requesters continue in the external channel.

## Create a conversation for someone else

You can choose another active workspace member as the **Requester** if you have Viewer or higher
access to any active team with Conversations or Assets enabled. Organization Admins and Owners
also qualify. The destination team can differ from the team that gives you this access.

<Steps>
  <Step title="Open New conversation.">
    From **Conversations**, select **New conversation**.
  </Step>

  <Step title="Choose the requester.">
    In **Requester**, select the person who needs help.
  </Step>

  <Step title="Choose the destination team.">
    In **Team**, choose a team with Conversations enabled. You can choose a team
    you do not belong to.
  </Step>

  <Step title="Describe the request.">
    Enter **Subject** and **Details**.
  </Step>

  <Step title="Create the conversation.">
    Select **Create conversation**. Flow records you as the opener and the selected person as
    the requester.
  </Step>
</Steps>

For example, an IT Viewer can file an HR conversation for a colleague without joining HR.
Creating it does not grant access to HR's queue or private conversation history. Your existing
permissions still determine what you can read or change. You can follow the filed conversation's
requester view, which excludes private team notes.

Without qualifying team access or an organization administrator role, the form fixes **Requester**
to yourself. If that access disappears while the form is open, Flow resets the requester to you
and clears the selected asset. Your subject and details stay in the draft.

Choosing another requester does not grant permission to start automations or act in connected
applications as that person. Catalog requests have their own eligibility and approval rules.
See [Permissions](/setup/permissions#creating-conversations).

## Filter conversations by status

Use the **Status** chip next to the assignment filters to choose which conversations appear.
The assignment counts use the same status selection as the list.

* **Status: Active** excludes resolved, closed, and canceled conversations.
* **Status: All** includes conversations in every status you can access.

Home starts with **Status: Active**. The Conversations page starts with **Status: All**.
Changing the status selection keeps your assignment filter. On the Conversations page, it also
keeps your search and other filters. Selecting specific values in **State** updates the Status chip
to show that selection.

## Conversation views

| View | Audience | Use it for |
| - | - | - |
| **Chat with Flow** | Team members | Ask Flow for ticket-specific help, summaries, and next steps |
| **Requester chat** | Team members | Read external requester messages and reply through an available channel |
| **Work notes** | Team members | Record internal context, investigation notes, and handoffs |

Content from **Chat with Flow** and **Work notes** is not sent to the requester. Put anything the
requester should receive in **Requester chat**.

## Reply to a requester

<Steps>
  <Step title="Open the conversation.">
    From the Conversations page, select the conversation.
  </Step>

  <Step title="Read the Requester chat.">
    Select **Requester chat** to read the existing thread and its channel context.
  </Step>

  <Step title="Choose a channel.">
    Choose an available route under **Communication Channel**.
  </Step>

  <Step title="Send the reply.">
    Write the reply and select **Send**.
  </Step>
</Steps>

Flow currently offers Slack and email reply routes when the conversation contains a valid route
back to the requester. The selector shows only the routes available for that conversation.

## Keep internal and requester context separate

<Steps>
  <Step title="Explore in Chat with Flow.">
    Select **Chat with Flow** to explore an answer or next action.
  </Step>

  <Step title="Record context in Work notes.">
    Add operational context to **Work notes** when the team needs it later.
  </Step>

  <Step title="Move relevant information to Requester chat.">
    Move only the relevant requester-facing information into **Requester chat**.
  </Step>

  <Step title="Confirm before resolving.">
    Before resolving the conversation, confirm that the requester received any closing message your
    process requires.
  </Step>
</Steps>

## Status and related work

The conversation side rail can include:

* Approval decisions
* Executed automations
* Linked access requests
* Related records from a connected ticketing system
* Relevant knowledge and linked assets
* Recent activity

These sections appear only when the conversation has related data. Use them to understand what
happened before asking the requester to repeat information.

Flow can summarize the known issue, suggest next steps, and check related approvals or automations.
It does not treat facts missing from the current record as known.

## Related topics

* [Request tracking](/setup/request-tracking)
* [Channels](/setup/channels/overview)
* [Help desk](/setup/help-desk)
* [Ticketing integrations](/integrations/ticketing/overview)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.