Skip to main content
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 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.
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.
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.

​
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.
If publishing keeps asking you which portal to use, the fix is upstream: set the client entity on the document’s attributes. Then publishing becomes a one-click confirm for good.

​
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

Document requests are behind their own feature flag while the feature settles — see Access & permissions.