Make Every Report Count: Turn Scheduled Reports into Actionable Notifications

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. 

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.

Figure 1. A Table Chart provides the Data trigger; output format is configured separately. 

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.

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. 

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.

Figure 2. The Data option on a Table Chart converts a time-based recurrence into a data-gated delivery decision. 

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. 

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. 

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

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. 

Figure 3. Conditional recurrence uses a Table Chart as its data trigger; recurring and manual modes solve different jobs. 

Use the scheduling mode that matches the job 

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. 

POST /schedules/{id}/send 

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. 

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

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 

Figure 4. Monitoring separates a valid no-data silence from a delivery or rendering failure. 

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

A production-ready acceptance checklist 

1. Confirm the licence exposes Reporting and the required PiReport capability.
2. Validate SMTP or OAuth-based SMTP settings using the supported configuration for the deployment. 
3. Give internal recipients an email address and Can Be an Email Recipient privilege; check role-level overrides. 
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. Choose a recurrence that matches the required detection interval and confirm the configured dashboard time zone. 
6. Enable Data on the Table Chart and test both branches: an empty table must suppress delivery; a populated table must deliver. 
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.
8. Run an authorised manual job for controlled validation, remembering that it does not move the next recurring job. 
9. Verify Monitoring shows the expected lifecycle and retain an operating response for failed jobs. 

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. 

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.