# The reports portal

> A place for the people you build reports for. Publish to readers who sign in, limit each to their own rows, and let them ask cherry about the numbers.

The console is where your team builds reports. Most of the people a report is for never build anything. A regional manager wants this month's numbers for their region, and a director wants the pack. Giving them the console would hand them a rail of pages they will never use and, worse, the whole warehouse behind the one report they came for.

The **reports portal** is the other half. It is a separate site at `reports.sanda-os.com.au` that shows only the reports you publish to someone, lets them ask cherry about the numbers, and has nothing on it that can change anything.

![The portal's home page for a reader named Dana: a greeting, a box to ask cherry, three suggested questions and a starred report.](https://docs.sanda-os.com.au/media/portal-home.png "The portal home for a reader")

## Who can sign in

| Role | What they do on the portal |
|---|---|
| **Reader** (Reader · reports portal only) | Signs in to the portal and nowhere else. Can be limited to their own rows with [data rules](#limit-what-a-reader-sees). |
| Read-only, member, admin, owner | Can open the portal as well as the console. Data rules do not apply to them. Owners and admins see every published report. |

A reader who opens the console is sent to the portal. Readers have a seat in your workspace, so invite them as you invite anyone: **Settings · Team**, then **Invite someone**, with the role **Reader · reports portal only**. See [members and roles](https://docs.sanda-os.com.au/workspace/members-and-roles).

## Set up the portal

:::steps
1. **Invite your readers.** Do this under **Settings · Team**, as above. You can also change an existing member's role there.
2. **Publish a report.** Open a report, press **publish** in the toolbar and fill in the pane. See [Publish a report](#publish-a-report).
3. **Give readers data rules.** If readers should see only their own rows, set rules under **Activate · Reports**, on the **Portal** tab. See [Limit what a reader sees](#limit-what-a-reader-sees).
4. **Check it as they will.** In the portal, use the **Viewing as me** menu to see it as a reader does. See [Check a reader's view](#check-a-readers-view).
:::

## Look after the portal

Owners and admins run the portal from **Activate · Reports**, on the **Portal** tab. **Open the portal** at the top right takes you to it.

![The Portal tab of the Reports page: The portal settings, Published reports and Readers and their data.](https://docs.sanda-os.com.au/media/portal-admin.png "The Portal tab")

**The portal** panel sets how it greets people:

| Setting | What it does |
|---|---|
| **Name** | What the portal calls itself. Empty uses your workspace's name. |
| **A reader with no data rules sees** | **Every row the reports show**, or **Nothing, until their rules are set**. Choose nothing when every reader is meant to be limited, so nobody sees everything by accident before their rules exist. |
| **Welcome** | A few lines under the greeting on the home page, up to 600 characters. |
| **The portal is open** | Switched off, readers are told the portal is closed. Owners and admins can still open it to get it ready. |
| **Readers can ask cherry** | Switched off, cherry disappears from the portal and the reports are all that is left. |

Press **Save**. **Published reports** lists what is on the portal, with each report's group, audience, when it was published and how many people have read it. Use the arrows to put them in order. Featured reports come first, then this order. **View** opens a report on the portal.

## Publish a report

Publishing puts a **copy** of a report on the portal, and it is a decision: the readers see the version you published, not the report you keep working on. A board pack can be reworked for a week without the board watching it happen.

:::steps
1. **Open the report.** Go to the report's canvas. Only owners and admins see the **publish** button.
2. **Press publish.** The pane opens on the right.
3. **Fill it in.** Set the **Name on the portal**, a one-line **Description**, and a **Group** such as finance, operations or board. The portal's home groups reports under these.
4. **Choose who can open it.** **Everyone in the workspace** reaches every member and reader, each seeing only their own rows where they have data rules. **Only the people I choose** shows a list of members to tick. Owners and admins can always open it.
5. **Feature it if it matters.** **Feature it** puts the report first on the portal's home.
6. **Press Publish.**
:::

A report with no blocks cannot be published.

What is frozen at the moment you publish is the report's **layout**: its blocks, filters and colours. The numbers are not frozen. Readers see the current figures each time they open a report, read from your warehouse.

Once a report is published the pane says **on the portal**, when it was published and how many people have read it. If you have changed the report since, it says so: **This report has changed since it was published. Readers still see the published version until you update it.** **Update to this version** sends the new layout. **Save and update** appears when the report has not changed, and saves changes to the portal details, such as its group or audience. **Unpublish** takes the report off, and nobody there can open it any more. **view on the portal** opens it.

## What a reader sees

**The home page** opens with a greeting, your workspace's name, the reader's role and the date, and your welcome if you wrote one. When cherry is on, a large box for it sits in the middle with three suggested questions. Below it is **Your reports** as tiles, with a search box, **Find a report**. Each tile draws a miniature of the report's layout, with its name, description, group and when it was last opened. Starred reports come first, then everything, with a chip for each group when there is more than one. Featured reports lead. A reader with nothing published to them sees **Nothing has been published to you yet.**

**A report** is the same page a [shared link](https://docs.sanda-os.com.au/reports/sharing#what-the-person-with-the-link-sees) shows, laid on paper that scales to the window. On the portal it fills the width, up to 175%, because a reader on a wide screen came to read the numbers. Beside the title are the reader's only actions:

- **Star** a report to keep it near the top.
- **Refresh** reads every figure again.
- **Print** prints the page at the width.
- **Ask cherry** opens a pane about this report, when cherry is on.

A zoom bar at the foot of the window zooms out and in, shows the current zoom (press it to return to the width), and fits the whole report on screen. Tables can be sorted, selected and downloaded, and a reader gets only the rows their rules allow. The foot of the page says when the figures were read and when the report was published.

## Limit what a reader sees

A **data rule** names a field and the values a reader may see. It is applied to every query the portal runs for that reader, whether it is a block on a report or an answer from cherry.

:::steps
1. **Open the rules.** On the **Portal** tab, under **Readers and their data**, press **Data rules** beside the reader.
2. **Add a rule.** Press **Add a rule**. In **Field**, choose a dimension from your semantic fluid (the list offers them) or write a column in full as `schema.table.column`.
3. **List the values.** In **May see**, type the values separated by commas, such as `north, south`.
4. **Save.** Press **Save rules**.
:::

A few facts about how rules work:

- A reader must match **all** of their rules, and within one rule any of its values will do. A field can have only one rule, so put all its values in it. A reader can have up to 20 rules.
- Rules are applied **after** the report's own filters, so nothing on the report can replace one.
- If a block's table cannot reach a rule's field, the block is **not shown** to that reader. They see a message such as "This block cannot be shown with the data you have access to." rather than an unfiltered figure.
- The reader is told what applies, once, above the report: for example **Showing your part of the data: region is north**.
- **Rules are for readers only.** Anyone with the console has the SQL shell, the explorer and search, none of which can apply a per-person filter, so a rule on them would be a promise with a hole in it. The **Readers and their data** panel says so, and refuses a rule for anyone but a reader. Make someone a reader to limit what they see.

:::caution
Written analysis is text saved on the report. Every reader sees a text block as it was written, whatever their rules. If a report goes to readers who are limited to their own rows, keep whole-business figures out of its text blocks.
:::

With **A reader with no data rules sees** set to **Nothing, until their rules are set**, a reader without rules sees the reports without their figures, and a message saying their access has not been set up.

### Check a reader's view

When your workspace has more than one member, owners and admins get a **Viewing as me** menu in the portal's top bar. Choose **As** a person, and the portal draws exactly as that person sees it: their reports and their data rules. A note at the top says so, with **Back to my view**. Nothing you open while previewing is counted as theirs. Use it to check a rule before a reader finds it wrong.

## cherry on the portal

If **Readers can ask cherry** is on, a reader can ask about the numbers in their own words, from the home page's box or from a report. The home page sends the question to cherry's own page, **Conversations**, which lists their earlier conversations on the left. Every conversation is kept and can be deleted by the person who had it. On a report, **Ask cherry** opens a pane that knows which report is open, with suggestions such as "Summarise this report in three lines" and "What changed since last month?".

cherry here is a smaller cherry than the console's. It looks things up and runs queries against your semantic fluid, using the definitions your team agreed, and it cannot change anything. It cannot write its own SQL or search documents, and it does not show the SQL it ran, because for a reader that would carry their own rule. A reply streams in, with the rows behind it folded underneath. For a reader with rules, its answers use only the part of the data they may see.

Questions asked on the portal count against your workspace's daily AI limit. See [models and usage](https://docs.sanda-os.com.au/cherry/models-and-usage).

## Sign in and the handoff

The portal has no sign-in form of its own. **Sign in** on the portal goes to the console's sign-in, the same one your team uses, and brings the reader straight back to the page they wanted. You open the portal from the console with **Open the portal** on the **Portal** tab, and anyone with console access has **Open sanda** in the portal's account menu to go back. The two sites share a sign-in but not a session, so sanda passes you across with a code that works once and lasts two minutes. The code only works when you come from the console: opened from a link on another website, it signs nobody in and goes to the portal's home.

If a sign-in takes too long the portal says so and asks the reader to sign in again. A person who has not been invited is asked to contact whoever sends them their reports.