> ## 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.

# Channels, views, and categories

> Decide what belongs in a channel, what belongs in a view, and what belongs in a category or tag, so your workspace stays navigable as volume grows.

Almost every messy Ravenna workspace has the same cause: someone made a channel when they needed a view. Channels multiply, routing gets ambiguous, and nobody knows where to send a request.

The reference docs describe what each of these does. This page makes the call.

## The one-line version

| Use          | For                                              | Rule of thumb                                         |
| ------------ | ------------------------------------------------ | ----------------------------------------------------- |
| **Channel**  | Intake. Where requests arrive and who owns them. | Few. Add one only when the process genuinely differs. |
| **View**     | Slicing work that already arrived.               | Many. Free to create, free to delete.                 |
| **Category** | The primary topic of a ticket, set by AI.        | 5 to 10, non-overlapping, one per ticket.             |
| **Tag**      | Everything else you want to label.               | As needed, but with a naming convention.              |

## Channels are intake surfaces, so keep them few

A channel answers two questions: where does this request arrive, and which team owns it. That is the whole job.

<CardGroup cols={2}>
  <Card title="Create a channel when" icon="circle-check">
    * Requests arrive through a **different door**: a different Slack channel, a different email address, the Portal
    * A **different team** owns the work
    * The **process is fundamentally different**, for example quick questions versus multi-step approvals with provisioning
  </Card>

  <Card title="Reach for something else when" icon="circle-x">
    * You want to see a subset of tickets. That is a **view**.
    * You want to label a kind of request. That is a **category** or a **tag**.
    * One person wants their own list. That is a **private view**.
  </Card>
</CardGroup>

<Warning>
  Over-segmenting is the failure mode, and it is expensive to undo. Every extra channel is another place a request can land in the wrong channel, another set of settings to keep in sync, and another decision you are pushing onto requesters who do not know your org chart.
</Warning>

Most workspaces should start with **one general channel plus a triage channel**, then add more as real patterns emerge from real volume. If you cannot name the distinct process a proposed channel exists to serve, you want a view.

<Callout icon="link" color="#6B7280">Learn more about [channel design patterns](/documentation/tickets/channels#channel-design-patterns)</Callout>

## Views are how work streams get sliced

Views are the answer to nearly every "can we see just the..." question. They are cheap, private or shared, and reversible.

Five views cover most teams:

| View                 | Filters                          | Group by | Job                   |
| -------------------- | -------------------------------- | -------- | --------------------- |
| Unassigned           | Assignee is none, status open    | Channel  | The triage list       |
| My tickets           | Assignee is me, status open      | Priority | Personal work         |
| Breaching soon       | Breaching Within a few hours     | Due date | Act before the breach |
| Waiting on requester | Status is waiting                | Due date | Follow-up             |
| Recently resolved    | Status done, updated last 7 days | Channel  | Quality review        |

Two mechanics that shape how you design them:

* **Filters are AND only.** There is no OR inside one view. To see A or B, build two views.
* **Shared views are for team workflows, private views are for personal preference.** Do not share your personal list; do not privatize the triage list.

Do not save one-off queries as views. Ad-hoc filtering exists for that, and a sidebar of forty views is the same problem as forty channels.

<Callout icon="link" color="#6B7280">Learn more about [view design recommendations](/documentation/tickets/organize/views#view-design-recommendations)</Callout>

## Categories are the primary topic, set by AI

One category per ticket, assigned automatically. That constraint is the point: it forces a single answer to "what is this about", which is what makes reporting and agent rules work.

Get categories right by treating them as a classifier you are training, not a taxonomy you are designing:

* **Start with 5 to 10.** More than that and the AI starts guessing between neighbors.
* **Make them non-overlapping.** "Password Issues" and "Login Problems" will be picked at random. Combine them.
* **Write descriptions for the classifier, not for humans.** "Hardware issues including laptops, monitors, and peripherals" beats "Hardware".
* **Give 5 to 10 example phrases in the words your employees actually use.** "I can't access my email" and "Locked out of my account" train the model. "authentication failure" does not, because nobody types that.
* **Read your default category weekly for the first month.** Tickets piling up there are telling you which category is missing.

<Callout icon="link" color="#6B7280">Learn more about [writing effective categories](/documentation/tickets/organize/categories#best-practices)</Callout>

## Tags are everything else

Multiple per ticket, set manually, by AI, or by a workflow. Use them for the dimensions a category cannot carry: `vip`, `needs-review`, `escalated`, `dns-outage`.

Two habits keep tags useful:

* **Pick a naming convention and stick to it.** Lowercase and hyphenated is fine. Without one you get `VIP`, `vip`, and `Vip`.
* **Prune quarterly.** Tags accumulate faster than anything else in the product, and a tag nobody filters by is noise in the picker.

Incident and campaign tags are the best use of tags, because they are inherently temporary and cut across categories.

<Callout icon="link" color="#6B7280">Learn more about [tags versus categories](/documentation/tickets/organize/tags#tags-vs-categories)</Callout>

## A worked decision

Someone asks: "Can we have a channel for laptop requests?"

Walk it back against the three tests:

| Test                                           | Answer                            |
| ---------------------------------------------- | --------------------------------- |
| Do laptop requests arrive somewhere different? | No, same Slack channel            |
| Does a different team own them?                | No, same IT team                  |
| Is the process fundamentally different?        | Only in that it involves shipping |

<Tip>
  So: a **form** for laptop requests, a **category** so they classify and report cleanly, a **view** filtered to that category for whoever handles hardware, and a **workflow** for the shipping steps. No new channel.
</Tip>

If instead the answer had been "Facilities owns hardware and they have their own Slack channel", that is a channel.

## Next

<CardGroup cols={2}>
  <Card title="Public vs private channels" icon="lock" href="/guides/best-practices/public-vs-private-channels" horizontal>
    Once you know how many channels you need, decide who sees them.
  </Card>

  <Card title="IT help desk" icon="headset" href="/guides/playbooks/it/help-desk" horizontal>
    This structure applied end to end.
  </Card>
</CardGroup>


## Related topics

- [Set up your first channel](/guides/day-one/set-up-first-channel.md)
- [Expenses and invoices](/guides/playbooks/finance/expenses-and-invoices.md)
- [IT](/guides/playbooks/it/overview.md)
- [Guides](/guides/overview.md)
- [Public vs private support](/guides/best-practices/public-vs-private-channels.md)