> ## Documentation Index > Fetch the complete documentation index at: https://docs.denari.com/llms.txt > Use this file to discover all available pages before exploring further. # Clients & entities > Work is always done for an entity. A client is the group its entities belong to. **Work is always done for an entity, and a client is the group its entities belong to.** Each entity also has a set of seats (partner, managers, preparer) that say who plays which part for that client. * An **entity** is a specific person or company you do work for, such as *John Smith* or *Smith Holdings LLC*. * A **client** is the group those entities belong to, such as *the Smith family*. A client can have one entity or many. ## Add a client Go to **Clients** and click **Add client**. The form has three steps. Type the client's name. Add each entity with its name, its type, and the states it files in. The states matter later: a service can add extra tasks when an entity files in more than one state. See [Service templates](/flows/service-templates#the-task-list). Turn on **Create a billing group** to set up who gets the invoice now: the group name, the firm owner, the billing email, contact name, and phone. You can also do this later. See [Billing groups](/flows/billing-groups). Click **Create client** when you're done. If your firm syncs clients from Practice CS, you can't add entities in Flows, and entity names are read-only. The sync keeps them up to date. ## Client statuses | Status | Meaning | | - | - | | **Prospect** | A possible client, usually made from a deal in the [Pipeline](/flows/pipeline). | | **Active** | A current client. A prospect becomes Active on its own when its engagement is turned on. | | **Inactive** | No longer active. | | **Lost** | You didn't win the work. | ## The client page A client page with its entities on the left, the selected entity's name, type and filing states, and the Relationship roles card below.

A client page with its entities on the left, the selected entity's name, type and filing states, and the Relationship roles card below.

Open a client to see three tabs: * **Entities.** Each entity's details and its relationship roles. * **Engagements.** Every engagement for this client in one list, with status and manager. * **Activity.** A history of changes. ## Relationship roles: who plays which part Each entity has a **Relationship roles** card with seven seats, one person per seat: **Partner, Tax Manager, CAS Manager, Assurance Manager, Payroll Manager, Admin Manager, Preparer.** These seats matter because tasks can be set to go to *the partner* or *the manager* instead of to a named person. When work is created, Flows looks up who sits in that seat for that entity and gives them the task. *The manager* means the manager for that service's category, so a tax return goes to the Tax Manager and bookkeeping goes to the CAS Manager. You can also fill these seats from an engagement. The partner you pick when setting one up, or change under **Firm partner** on its page later, becomes the partner on each of its entities. The manager seats work the same way: pick one per kind of service under **Managers** when setting up an engagement, or on its **Settings** tab later, or use a service's **Team** card. They all change the same seat on the entity. If a seat is empty when a task needs it, the task goes to [Available work](/flows/my-work#available-work) so someone can claim it. Nothing gets stuck. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.