Placing Reports
How to put a Folio report where people will read it: on a Lightning page, in a Flow, behind a link, or on a public Experience site.
Overview
Every placement uses the same component, Folio Report Viewer, and points it at one report. Readers see the report exactly as it looks in the Editor's preview, with the tools you allow.
There are two ways to point at a report:
| Shows | Use it for | |
|---|---|---|
| Report Unique Name | Whichever version of the report is live. Follows you as you add versions. | Almost everything. |
| Record Id | One specific version, the Folio Definition record with that Id. | Pinning a page to a version that must not change. |
To find a report's unique name, open it on Folio Reports and click Go to Definition. It is the Unique Name field on that record, something like won-revenue-by-industry. It does not change when the report is renamed.
Archiving a report takes it off every page that shows it by unique name. Restoring it puts it back. A placement using a record Id keeps showing that version even when archived.
People reading a placed report need permission to run the viewer; see Setup.
Lightning pages
In the Lightning App Builder, drag Folio Report Viewer onto an app page or a Home page and set:
| Setting | |
|---|---|
| Report Unique Name | The report to show. |
| Utility Bar | Which tools readers get. See The Utility Bar setting. |
| Utility Bar Config (JSON) | Used only when Utility Bar is custom. |
Until Report Unique Name is set, the component shows No report selected.
On a record page, the viewer shows the record itself as a report, so it only works on Folio Definition record pages. That page ships with the viewer already on it. To show a report beside, say, an Account, put it on an app page and link to it, or build a small component of your own as described under For developers.
The Utility Bar setting
Each placement decides which tools appear above the report, within what the report itself allows in the Editor's Style tab.
| Value | Tools shown |
|---|---|
config | The report's own choice. The default. |
full | Every tool and every export format, whatever the report says. Meant for admin pages. |
none | No utility bar. |
custom | Only the tools named in Utility Bar Config (JSON), and only where the report allows them too. |
For custom, the JSON names each tool to show:
{ "export": { "modes": ["pdf", "csv"] }, "chart": { "enabled": true } }
That shows Export offering only PDF and CSV, and the chart toggle, and no Filter. The keys are export, filter and chart. Export modes are xlsx (Excel Simple), xlsxFormatted (Excel Formatted), pdf, csv and json (Copy as JSON). A tool the report has turned off stays off here.
Flow screens
Add Folio Report Viewer to a screen and set either Record Id or Report Unique Name, plus Utility Bar and Utility Bar Config (JSON) as above. All four take a value or a Flow variable, so a Flow can decide at run time which report to show.
Links to a report
The Folio Report Viewer tab shows whichever report its link names, which makes it a way to send someone a report without building a page. Add one of these to the tab's address:
| Add | Shows |
|---|---|
?c__folioname=won-revenue-by-industry | The live version of the report with that unique name. |
?c__foliorid= and a record Id | That Folio Definition record. |
Opened without either, the tab says No report selected.
The same two parameters work on any Lightning or Experience page holding a viewer that has no report set in its own settings. A report set in the page's settings always wins over the address. On an Experience site the c__ can be left off: ?folioname= works too.
Experience sites and guest users
Add Folio Report Viewer to a page in Experience Builder and set Report Unique Name. On a record page for a Folio Definition, Record Id fills itself in and you can leave the name blank.
For logged-in site members, grant what any reader needs (see Setup) through a permission set assigned to them.
Showing a report to guests
A guest, someone visiting the site without logging in, normally has no access to your data at all, so a report would show them nothing. Two things change that.
Grant the guest user the viewer. On the site's guest user profile, or a permission set assigned to it:
- Under Apex Class Access, add
Folio_FormViewer. - Under Object Settings, give Folio Definitions Read, with read access to its fields.
Turn on Run Elevated for the report. Open its Folio Definition record (Go to Definition) and check Run Elevated. The report then reads its data with full access instead of the visitor's own, so a guest sees exactly what the report is built to show.
That is the whole grant. The guest gets no access to the objects the report reads from; the report reads them on the guest's behalf.
Run Elevated makes the report's own definition the security boundary. Everything the report is built to show, every visitor sees, whatever their access. Check its columns and filters as carefully as you would a sharing rule. Only holders of Flourish Folio: Admin can edit report definitions, which is what keeps that boundary in trusted hands.
It applies to the report, not to a site. Once a site's guests can run the viewer, they can open any report with Run Elevated on, by its unique name or record Id, including ones you never placed on that site. Keep Run Elevated to reports whose contents are fine to be public.
Run Elevated is set on the report, not on the page, so a site cannot ask for it and a report without it stays limited to what the visitor can see. It does not apply to the Editor's preview, which always runs as the person building.
Archiving the report takes it off any page that shows it by unique name, at once.
For developers
Using the viewer in your own component
Your org's own Lightning web components can place the viewer in their templates, which is how to put a report on a record page for another object, drive it from your own controls, or combine it with other content. Folio's Apex is not callable from your code; the component is the way in.
The tag keeps the underscore in the component's name:
<toflourish-folio_report-viewer
unique-name="won-revenue-by-industry"
toolbar-mode="config"
runtime-filters={filters}>
</toflourish-folio_report-viewer>
folio-report-viewer, with a hyphen, will not resolve.
| Property | |
|---|---|
unique-name | The report's unique name. Set this or record-id. |
record-id | A Folio Definition record Id, for one specific version. |
toolbar-mode | config, full, none or custom, as in The Utility Bar setting. |
toolbar-config | The JSON for custom, as a string. |
runtime-filters | Extra conditions from your component. See below. |
Filtering from your component
runtime-filters takes a list of conditions that are added to the report's own filters, so your component can offer its own period picker, region selector or record context:
filters = [
{ id: 'region', field: 'Account.Region__c', operator: 'equals', value: 'West' },
{ id: 'stage', field: 'StageName', operator: 'in', value: ['Prospecting', 'Qualification'] }
];
The conditions are applied when the report reads its data, so counts, subtotals, totals, the chart and exports all respect them. Setting the property reruns the report. They are kept apart from the reader's own Filter tool, so a reader clearing their filters does not clear yours.
Each condition takes a field on the report's object (or a lookup path such as Account.Region__c), an operator from the list in Report JSON, and a value. Every field and value is checked the same way as a saved report's filters, so a condition cannot reach fields the report could not.
Rerunning a report
Call reload() on the element to read the data again, for example after your component saves a record the report counts.
this.template.querySelector('toflourish-folio_report-viewer').reload();