Answer
Security boundaries should be tested with a real scenario, not taken on faith. Ask the vendor to walk through exactly how a report would be restricted so that a regional manager sees only their own numbers while a finance director sees company-wide totals, using the same underlying Db2 for i tables. If that separation depends on manually filtered report copies rather than enforced access rules, it will eventually drift out of sync as new reports get built.
Scheduling and distribution matter more than they seem to in a demo. Buyers should ask how the tool handles a report that needs to land in someone's inbox every Monday morning before a leadership meeting, what happens if the underlying data job runs late, and whether failures generate an alert or fail silently. Drill-down from summary to source detail is worth testing directly during evaluation, since a tool that looks fast at the dashboard level can become painfully slow the moment a user tries to trace a total back to the individual transactions behind it, which is usually the exact moment leadership is asking the hardest questions.