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

# How portals work

> Portals hang off client entities, are created on first publish, and hold only what you put in them.

Portals has a small model. Learning it takes a minute and explains almost every behavior you will run into.

## One portal per client entity

A portal belongs to a **client entity** — a legal entity — not to a client group. Both are the same ones you use everywhere else in Denari; see [Client Groups & Client Entities](/general/clients-and-entities) if the distinction is new.

For a client group with a single entity, the difference never shows. For a group made up of several entities, it matters: **each entity gets its own portal**, and a document published to one is not visible in the others.

<Accordion title="Example">
  Take the fictional client group **Harvest Foods**, made up of three client entities:

  * Harvest Manufacturing, LLC
  * Harvest Distribution Services Inc.
  * Harvest Retail Ventures LLC

  Harvest Foods does not have "a portal." It has up to three — one per entity — each holding only what was published to that entity. The manufacturing entity's financial statements never leak into the retail entity's portal.
</Accordion>

This is the safe default. Separating by legal entity means a document can only reach the people entitled to that entity's records.

## Two things must both be true

A client sees a document only when **both** of these have happened:

1. The document has been **published** to that entity's portal.
2. The person's email has been **granted access** to that entity, by inviting them.

They are independent. You can publish documents to a portal nobody has been invited to (nothing is visible to anyone), and you can invite someone to a portal with nothing in it (they sign in to an empty page). Neither is an error — but both need doing.

## Portals create themselves

There is no **New portal** button. A portal is created **lazily**, the first time someone publishes a document to that entity. Denari never bulk-creates a portal for every entity in your firm — that would produce hundreds of empty portals and a much larger surface for an accidental publish.

| Situation | What you see |
| - | - |
| Entity has never had a document published | It does not appear in the portals list |
| You publish the first document | The portal is created and appears in the list |
| You unpublish the last document | The portal drops off the list again |
| You open a portal for an entity with nothing published | The page loads and says **No documents published yet** |

## The entity attribute is the routing rule

When you publish, Denari resolves the document's **client entity attribute** and uses it to pick the portal.

* **Exactly one entity** — it's preselected in the dialog. One click to confirm.
* **More than one entity** — the dialog asks which of them you mean.
* **No entity at all** — the dialog offers your firm's full entity list.

There is a guardrail you cannot click past: **if a document is tagged to one or more entities, it can only be published to one of those entities.** The picker only offers the tagged entities, and the server rejects anything else. Only untagged documents can be sent to an arbitrary entity — the case where you have to choose deliberately.

<Tip>
  If publishing keeps asking you which portal to use, the fix is upstream: set
  the client entity on the document's [attributes](/documents/attributes). Then
  publishing becomes a one-click confirm for good.
</Tip>

## A portal holds records, not copies

Publishing does not copy or move anything. The portal stores a reference to the document in your library, which means:

* The document keeps its attributes, versions, comments, and history.
* The portal always shows the document's **current version**.
* Unpublishing removes the reference. The document itself is untouched.
* Deleting the document from your library removes it from the portal too.

## What a portal contains

| Surface | Who creates it | Who acts on it |
| - | - | - |
| **Published documents** | Firm publishes from Documents | Client previews and downloads |
| **Document requests** | Firm creates on the portal page | Client fulfills by uploading |
| **Client uploads** | Client uploads from the portal | Firm reviews in the intake queue |
| **Access grants** | Firm invites by email | Client signs in |

Document requests are behind their own feature flag while the feature settles — see [Access & permissions](/portals/access).


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