From Scheduled Reports to Actionable Notifications 

Technical Guide | Reporting & Automation

How to use PiReport recurrence, data-aware delivery, recipient controls and monitoring to send fewer, more relevant updates 

A dashboard is valuable when someone is looking at it. An operational notification is valuable when it arrives at the moment a documented check finds something worth acting on. Panintelligence PiReport connects those two workflows: it can schedule charts and reports, distribute them, and monitor the result. Most importantly for exception-led workflows, a schedule can be configured so that no email is sent when the Table Chart used as the trigger contains no data. ^{[1, 5]} 

WORKING PRINCIPLE  Treat a Table Chart as the detection surface, the recurrence as the polling interval, and the Data option as the delivery gate. The Data option is configured on that Table Chart. This is scheduled conditional delivery; it is not an event-streaming or instantaneous alert mechanism. ^{[4, 5]} 

---

Dashboards still depend on someone looking 

piReport is an additional module used with piDashboard. It builds reports from dashboard elements such as charts and tables, supports text and report branding, and can distribute content by email or save it to a directory. The Reporting area is organised into Reports, Schedules and Monitoring: create the content, decide when and how it is sent, then inspect the scheduling process and issues. ^{[1, 2]} 

Start with the delivery prerequisites 

The official setup guidance makes three dependencies explicit: the licence must include the reporting module, SMTP must be configured for email delivery, and users need the relevant recipient/download permissions. These are production prerequisites, not final troubleshooting steps. ^{[2, 3]} 

Layer	Documented requirement	Why it belongs in readiness checks
Module	The Reporting icon is available when the licence includes the module.	If the module is not licensed, the workflow is not available.
Email	SMTP settings are required to use piReport email delivery.	A correct schedule cannot deliver mail without a working mail path.
Permissions	Users need recipient and download privileges appropriate to the content.	Recipient visibility and available output types are governed by configured privileges.

---

Cadence and significance are not the same 

A conventional recurring report sends because the clock says it is time. That is useful for weekly service summaries and month-end packs, but it becomes noisy when the real question is binary: does the monitored condition exist right now? Sending an empty trigger Table Chart on every check teaches recipients that most messages can be ignored. 

The opposite failure is to avoid scheduling entirely and rely on someone to revisit a dashboard. That makes detection dependent on attention and working patterns. A periodic check with conditional delivery separates evaluation from notification: the system can check frequently while contacting people only when the trigger Table Chart contains data. ^[5] 

DESIGN CONSEQUENCE  A frequent recurrence does not have to mean a frequent email. With the Data option enabled on a Table Chart, an evaluation can run on schedule while empty results remain silent. ^{[4, 5]} 

---

Noisy or invisible signals both carry operational cost 

Too many routine messages reduce the prominence of the exceptions that matter. Too few scheduled checks leave detection to manual dashboard review. Delivery failures add a third risk: a team may assume that silence means ‘no data’ when it actually means that SMTP, the scheduler, the renderer, a time-zone setting or the licence is misconfigured. The documentation therefore treats Monitoring as part of the reporting workflow and lists infrastructure checks for missing or corrupt scheduled output. ^{[2, 9, 13]} 

DELIVERY CHECK  Define what silence means. A healthy conditional schedule with an empty trigger Table Chart should be silent; a failed job should be visible in Monitoring and handled as an operational fault. ^{[5, 9]} 

---

The need-payoff: build a data-gated schedule 

1. Use a Table Chart as the detection surface 

For conditional delivery, use a Table Chart as the trigger. When Data is selected, the schedule proceeds only when that Table Chart contains data; when it is empty, no email is sent. A practical implementation pattern is therefore to make the Table Chart return no rows in the normal state and one or more rows when attention is required. The exact query and condition remain application-specific. ^[5] 

2. Create the schedule and complete the message 

Open Reporting, select Schedules and add a schedule. The email title is mandatory. The editor reports missing required information, including a missing subject or message. A schedule can also be opened from a saved report, which pre-populates the email title with the report name. ^{[2, 3]} 

3. Attach the content recipients need 

A scheduled email can contain a chart from the Chart Library, a report, or both. Items are added one at a time. For conditional delivery, the Table Chart determines whether the schedule proceeds; the output format is a separate choice. A chart is attached as PDF by default, and the CSV option can additionally include its data. Once the Table Chart trigger contains data, the configured delivery can therefore include the PDF and, when selected, the underlying CSV. Use the smallest attachment set that supports the action. ^[7] 

4. Choose the recurrence and time zone deliberately 

The recurrence panel supports Weekday, Day of Month, By Minute and By Hour patterns. Weekday is selected by default. The scheduled hour uses the time zone configured under Dashboard Configuration > Settings > General Settings > Time Zone Location Settings. For conditional delivery, the recurrence is also the interval at which the platform checks whether the trigger Table Chart contains data. ^{[4, 5]} 

5. Enable the data gate on the Table Chart 

Select the Data box for the scheduled Table Chart. With Data enabled, a check with no Table Chart data does not send an email. A periodic recurrence, such as hourly, can be used to check for data existence. ^[5] 

6. Choose recipients within the permission model 

Dashboard users can be selected as recipients only when they have an email address and the Can Be an Email Recipient privilege; role-based privileges override user-level privileges, and configured user restrictions apply. Scheduling to external addresses requires the Can Schedule to Email permission. The documentation states that external recipients receive a PDF version of the report or chart and that multiple external addresses are separated with semicolons, without a trailing semicolon. ^[6] 

When one report must be distributed with different filter values, the report-filter guidance warns that creating multiple filter-specific schedules is not normally as effective as bursting a schedule by role or user restrictions. Use the permission model as a scaling mechanism rather than multiplying near-identical schedules without review. ^[14] 

SECURITY CHECK  For dashboard users, piReport applies existing security restrictions and user permissions to distributed content. Treat external delivery as a separate governance decision, and consider encrypted schedule attachments when the material is sensitive. ^{[1, 8]} 

7. Confirm the job in Monitoring 

A newly scheduled report appears in Monitoring with a Waiting status until its delivery time. At that point, the status changes to show whether delivery succeeded. The time displayed in Monitoring uses the same configured dashboard time-zone setting. ^[9] 

---

Use the scheduling mode that matches the job 

Mode	Trigger	Delivery behavior	Best fit
Recurring	Configured time pattern	Sends the configured content when the recurrence is due.	Weekly summaries, month-end packs and other calendar-led reporting.
Conditional recurring	Time pattern plus Table Chart data	With Data selected on the Table Chart, suppresses email when the table has no rows.	Exceptions or faults represented by rows in the trigger Table Chart.
Manual	UI action or API request	Creates a one-off job and does not reschedule an existing recurring job.	Ad-hoc re-runs, workflow-triggered delivery and controlled testing.

Manual scheduling was introduced in the 2025_07 release. A manual job runs once, does not change the next recurring job, and can be created in the UI or through the documented endpoint below. The API creates a job for immediate processing rather than directly sending the email. Only one manual job may be Active or Waiting for a particular schedule at a time, and the authenticated user needs the required access and permission. ^[10] 

PREVIEW CAVEAT  A manual run immediately before a recurring job is due can result in both being sent because the manual job does not reschedule the recurring one. ^[10] 

POST /schedules/{id}/send 

---

Production details that determine trust 

Make message context dynamic with scheduler variables 

Global, Magic and User Variables can be referenced in the scheduler’s email subject, email message, replacement attachment name, S3 object location and web service URL. When the email is produced, the variable is replaced with the relevant information. This can make a notification self-describing without creating a separate schedule for every date or user-specific label. ^[11] 

Encrypt schedule output when required 

Schedule-level encryption applies to email attachments and files saved to a directory or S3 bucket. Supplying an attachment password encrypts all attached files into one ZIP named after the schedule. When encryption is enabled, the individual attachments are not also saved separately to folders. ^[8] 

Configure the email path explicitly 

Current environment-variable documentation includes SMTP server, port, username, optional sender address, password, SSL and TLS settings. It also documents OAuth-related SMTP variables introduced in November 2025. PI_EMAIL_ALLOW_UNVERIFIED_CERTS exists, but the documentation labels allowing unverified TLS certificates as not recommended. ^[12] 

PI_EMAIL_SMTP_SERVER 
PI_EMAIL_PORT 
PI_EMAIL_USERNAME 
PI_EMAIL_ADDRESS          # optional 
PI_EMAIL_PASSWORD 
PI_EMAIL_SSL              # boolean 
PI_EMAIL_TLS              # boolean 
PI_EMAIL_USE_OAUTH        # OAuth option documented from Nov 2025 
PI_EMAIL_OAUTH_CLIENT_ID 
PI_EMAIL_OAUTH_CLIENT_SECRET 
PI_EMAIL_OAUTH_TOKEN_URL 
PI_EMAIL_OAUTH_SCOPES 

---

Troubleshoot silence as an observable state 

Monitoring should be the first place to distinguish a conditional no-send from an execution problem. Panintelligence’s support guidance then provides a concrete infrastructure checklist rather than a speculative one. ^{[9, 13]} 

Observed symptom	Documented checks	Interpretation
Job remains Waiting	Confirm scheduled time and dashboard time-zone settings.	The job may not yet be due in the platform’s configured time zone.
Schedule not sent	Review Monitoring errors, SMTP, ports, running services and licence options.	The mail or scheduling path may be unavailable or misconfigured.
Attachment is corrupt	Review report size, logs and renderer health.	Content generation may have failed even if the schedule was created.
Email arrives blank	Check scheduler services and themes.	The delivery path ran, but report rendering/content needs investigation.

---

A production-ready acceptance checklist 

1. Confirm the licence exposes Reporting and the required piReport capability. ^{[2, 3]} 

2. Validate SMTP or OAuth-based SMTP settings using the supported configuration for the deployment. ^{[2, 12]} 

3. Give internal recipients an email address and Can Be an Email Recipient privilege; check role-level overrides. ^[6] 

4. Build the detection surface as a Table Chart so normal operation produces no rows and the exception produces data; validate this with representative source data. ^[5] 

5. Choose a recurrence that matches the required detection interval and confirm the configured dashboard time zone. ^{[4, 5]} 

6. Enable Data on the Table Chart and test both branches: an empty table must suppress delivery; a populated table must deliver. ^[5] 

7. Test the separation between trigger and output: verify the Table Chart gate, the default PDF, the optional CSV, recipient permissions and encryption behavior before production distribution. ^{[1, 7, 8]} 

8. Run an authorised manual job for controlled validation, remembering that it does not move the next recurring job. ^[10] 

9. Verify Monitoring shows the expected lifecycle and retain an operating response for failed jobs. ^{[9, 13]} 

---

Fewer messages, higher signal 

Conditional scheduling gives product and operations teams a clean division of responsibility. The Table Chart expresses the condition in rows. The recurrence defines how often it is evaluated. The Data option on the Table Chart decides whether an empty result should remain silent. Delivery format is configured separately, with PDF as the default and CSV available as an additional chart-data attachment. Recipient privileges and restrictions govern distribution, while Monitoring shows whether the job ran successfully. The result is not ‘real-time alerting’ in the event-stream sense; it is an auditable way to turn periodic Table Chart evaluation into relevant delivery. ^{[1, 4, 5, 6, 9]} 

RECOMMENDED NEXT STEP  Choose one operational condition that is currently checked manually. Build or identify a Table Chart that is empty in the normal state, configure its Data trigger in a non-production environment, choose and test the required output formats, and prove the empty, populated and failed-job paths before expanding the pattern. ^{[5, 9]} 

---

Documentation basis 

Panintelligence behavior and configuration details in this guide were checked against the official pi Documentation pages below on 3 August 2026. Recommendations are identified as implementation patterns rather than product guarantees. 

[1] piReport – an overview – Panintelligence pi Documentation 

[2] Creating a new report – Panintelligence pi Documentation 

[3] Creating a Schedule – Panintelligence pi Documentation 

[4] Creating a Recurring Schedule – Panintelligence pi Documentation 

[5] Scheduling only when data exists – Panintelligence pi Documentation 

[6] Choosing the Email Recipients – Panintelligence pi Documentation 

[7] Adding Attachments – Panintelligence pi Documentation 

[8] Encrypting Attachments and Reports – Panintelligence pi Documentation