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

# Flags

> Risks and opportunities on an account — raised automatically, assigned to someone, and marked addressed when your team has decided what to do.

A flag marks an account as being in a state worth acting on: a **risk** like usage falling away before a renewal, or an **opportunity** like a trial that's outgrown its plan. Flags open on their own when an account matches a rule, and close on their own when it stops.

Find them under **Flags** in the sidebar.

<Note>
  A flag is not the same thing as an [indicator](/accounts/indicators). An indicator is a number or a yes/no computed
  from product events — it's an input. A flag is something a person is meant to do something about.
</Note>

## What a flag carries

|               |                                                                                                          |
| ------------- | -------------------------------------------------------------------------------------------------------- |
| **Kind**      | Risk or Opportunity                                                                                      |
| **Account**   | Who it's about                                                                                           |
| **Opened**    | When the account first matched. How long a risk has been open is usually the most telling thing about it |
| **Assignee**  | Who's looking at it. Set to the account's CSM by default                                                 |
| **Addressed** | Whether someone has decided what to do                                                                   |

## Addressed is not the same as closed

This is the distinction worth knowing, because it's what stops a long-running risk nagging a team that has already dealt with it.

* A flag **closes** by itself, when the account no longer matches the rule. Nobody closes a flag by hand.
* A flag is **addressed** by a person, meaning "we've seen this and it's handled". The condition may well still be true.

So a flag can sit addressed for weeks while the underlying situation persists — that's correct and intended. It drops off the **Needs attention** list and stays visible under **Addressed**. If you addressed something too early, **Reopen** puts it back.

When the condition finally does clear, the flag closes whether or not it was addressed.

If the same condition comes back later, that's a **new** flag rather than the old one reopening, so the history reads as two separate episodes instead of one that flickered.

## Filtering the list

| Filter              | Shows                                                        |
| ------------------- | ------------------------------------------------------------ |
| **Needs attention** | Open, and nobody has addressed it. The working list          |
| **Addressed**       | Open, but your team has already decided. Useful for a review |
| **All open**        | Both of the above                                            |
| **Closed**          | Conditions that have since cleared                           |

## Where flags come from

A flag rule points at a [segment](/accounts/segments) and a kind. Any account in that segment gets a flag of that kind; when it leaves the segment, the flag closes.

Using segments means flag rules inherit everything segments already do, including the customers/accounts level — so a rule on a customer-level segment raises one flag per customer rather than one per account.

Rules are checked every hour.

Deleting a rule stops it raising anything new. Flags it already raised are kept, since removing them would rewrite what your team saw and acted on.

## Reading flags elsewhere

Flags are readable over the API and from MCP with `list_flags` and `get_flag`, filtered by status, kind or account. The same `needsAttention` filter is available, so an assistant can be asked what needs attention today and get back the list you'd see on the page.

They're read-only there. Opening and closing belongs to the rules, and marking one addressed is a statement about your team that should carry a real person's name rather than an API key's.

## Parent accounts

A flag on a child account also shows on its [parent](/accounts/parent-accounts), labelled with the account it came from. The parent doesn't get its own copy — one flag stays one flag, so a customer-level count never doubles it.

A parent shows as needing attention when any of its accounts has an open, unaddressed flag.