Building reports that get read · lesson 4 of 4
Scheduling and sharing reports
In this lesson
- Set up a recurring report delivery that matches how the reader actually works
- Share a report so it stays useful after the person who built it moves on
Building a good report once is only half the job. Most reports in ProFinda are meant to recur, and how you schedule and share them determines whether they keep getting read six months later or quietly become the report everyone has stopped opening.
Match frequency to the decision, not the data
Data in ProFinda can refresh daily, but that does not mean a report should be delivered daily. Ask how often the reader actually makes a decision based on it. A resourcing lead reviewing staffing weekly needs a weekly report; a partner who reviews utilisation once a month at a leadership meeting gains nothing from a daily email and will likely start ignoring it. Set delivery frequency to the reader’s decision cycle.
Setting up the schedule
- Open the report and choose the scheduled delivery option rather than exporting manually each time.
- Set the frequency to match the reader’s decision cycle, established above, not the platform’s fastest refresh option.
- Choose delivery as a link into ProFinda rather than a static export where possible, so the reader always sees the current data rather than a snapshot that ages between sends.
- Add the recipients directly, rather than relying on someone forwarding the report on, so delivery does not depend on a person remembering.
Don’t be the only one who can rebuild it
A report that only its original builder understands is a single point of failure. When you build a recurring report, note down - even briefly, in the report’s description field - the grouping, baseline, and population decisions covered in the previous lesson, so a colleague could rebuild or adjust it if you are unavailable. This matters more than it seems while you are still around to answer questions about it.
Sharing beyond the schedule
Scheduled delivery covers the expected reader, but reports are often useful to people who ask for them later - a new team lead, someone preparing for a one-off meeting. Sharing the saved report directly, rather than rebuilding it from scratch each time someone asks, keeps the organisation working from one consistent view rather than several slightly different versions of the same underlying question.
Key takeaways
- Match delivery frequency to the reader's decision cycle, not to how often the data changes
- A report that only one person knows how to rebuild is a liability
- Document the report's assumptions alongside it, not just in the builder's memory