> ## 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. # Invite a client > Add a person's email to a client entity's portal so they can sign in and see what you've published. Publishing a document and giving a person access are two different actions. Publishing puts a file in a portal; **inviting** is what lets someone open it. Until you invite somebody, a portal is a page only your firm can see. This is the step everything else depends on, and you only do it once per person. Have the client's email address in hand before you start. You do not create a password for them, and they do not create one either. ## Invite someone Select **Portals** from the product switcher. The list shows every client entity that has a portal — click the one you want. If you're already inside a different portal, **← All portals** takes you back. It sits in the **CLIENT PORTAL** card at the top of the page, directly under the client entity's name. One address at a time. Two people at the same client? Send the first invite, then repeat for the second. Denari emails them an invitation that sets up their account. An **Invitation sent** toast confirms it. The **Clients** tab lists everyone you've invited and whether they've signed in yet. See [Check who has access](#check-who-has-access) below. A client portal page. The invite-by-email field sits in the top card directly under the client entity name, above the published documents.

A client portal page. The invite-by-email field sits in the top card directly under the client entity name, above the published documents.

## How signing in works **There are no passwords, ever.** * **The invitation is one-time**, and its only job is to create the account. * **Every sign-in after that emails a fresh code** which the client enters to get in. So clients need access to their inbox each time they visit, but there is never a password to forget, reset, or store. Nothing for your firm to manage either. If a client says they can't get in, the answer is almost always their inbox — a code that went to spam, or an address that forwards somewhere they don't check. Confirm the address in **Admin › Clients** before re-sending anything. ## What the invite does and doesn't do | Does | Doesn't | | - | - | | Create the client's account | Set or require a password | | Grant access to **that one client entity's** portal | Grant access to the client's other entities | | Let them see everything published there, now and later | Notify them about individual documents or requests | That last row matters: an invite is the only email Denari sends on its own. Publishing a document or creating a request does **not** notify anyone. If something is urgent, tell the client yourself. ## One person, several entities A single client login can span several businesses. If the person you're inviting needs more than one entity — say they run two of a client group's companies — **invite them from each entity's portal in turn**, using the same email address each time. Their access accumulates. **Admin › Clients** then lists all of their entities on one row, and when they sign in they see one page covering everything, with chips at the top to filter to a single business. See [Clients across multiple portals](/portals/multiple-portals). Re-inviting somebody who already has access is safe. They're granted the new entity, and Denari does not stack a second invitation on top of a pending one — you'll see **Client already had access** instead of **Invitation sent**. ## Check who has access Go to **Admin › Clients**. The tab appears once your firm has Portals enabled, and lists every external person your firm has invited: The Clients tab in Admin, listing invited portal clients with their email, the client entities they can access, and whether their invite is pending or accepted.

The Clients tab in Admin, listing invited portal clients with their email, the client entities they can access, and whether their invite is pending or accepted.

| Column | Shows | | - | - | | **Name** | Their name, or their email until you set one | | **Email** | The address the invitation went to | | **Portal access** | A badge per client entity they can currently see | | **Invite status** | **Invite pending**, **Accepted**, or **Invite expired** | | **Invited** | The date you sent the first invitation | **Invite status** is the one to read. It stays **Invite pending** until they sign in for the first time, then flips to **Accepted**. **Invite expired** means the invitation lapsed before they used it and needs re-sending. The row's `⋯` menu holds two actions: * **Edit name** — clients are created with just the front of their email address as a name, so this is worth doing for anyone you'll be looking up later. * **Resend invitation** — only offered when they haven't accepted yet. Denari won't stack invitations, so if one is still pending you'll see **An invitation is already pending** rather than a second email going out. One email address maps to exactly one role. An address already used by a staff member at your firm, or by a client of a different firm, is refused with **That email already belongs to another account**. Use a different address for their portal access. ## Next Put something in the portal for them to find. The page they land on after signing in. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.