AroFlo data via API

Hi Zerbe,

That approach is a useful workaround for a simple reporting need, especially where the requirement is only to pick up a scheduled report once a day and load it into Power BI. For a small or low-risk use case, I can see why it would be attractive because it avoids the complexity and cost of a proper integration.

However, I would be cautious about treating this as a robust business solution.

Pulling a download link from an emailed AroFlo report and saving the file into SharePoint introduces a number of reliability risks:

1. Email is not a dependable integration layer
   The process depends on the email being delivered on time, not being blocked, not changing format, and not being affected by mailbox rules, security filtering, attachment/link expiry, permissions, or security changes.
2. AroFlo reports can contain duplication issues
   AroFlo reporting is known to produce duplicate records in certain reporting scenarios, particularly where reports include related records, line items, labour, materials, assets, invoices, or other one-to-many relationships. If the emailed report is being treated as the source extract, those duplicates can flow directly into the ETL process and cause inflated totals, incorrect counts, duplicated jobs, and unreliable Power BI outputs.
3. The method has limited ability to reconcile data quality issues
   Because the process is based on consuming a flat exported report, there is limited ability to validate whether duplication is expected, accidental, or caused by the way the report has been configured. A proper data-layer approach can apply deduplication rules, keys, reconciliation checks, and entity-level validation before the data reaches Power BI.
4. It does not handle mass historical data well
   Email export and file-based methods are not well suited to loading large volumes of historical data. File size limits, report export limits, email delivery limits, SharePoint file handling, Power Automate run limits, and Power BI refresh constraints can all become issues when trying to extract years of historical AroFlo data.
5. Report links and file structures can change
   If AroFlo changes the email format, report link structure, export format, column names, report filters, or report configuration, the Power Automate flow or Power BI model may break without warning.
6. Limited error handling and data assurance
   A scheduled email export does not usually provide the same level of validation as a proper ingestion process. For example, it may be difficult to confirm whether the extract is complete, whether rows are missing, whether the report failed upstream, whether duplicate rows were introduced, or whether the data represents a consistent point in time.
7. Poor scalability
   This approach may work for one or two simple reports, but it becomes difficult to manage once the business needs multiple datasets, historical snapshots, incremental loads, relationships between AroFlo entities, or more frequent refreshes.
8. Weak auditability and governance
   For a business-critical reporting environment, you generally want logging, retry handling, monitoring, data lineage, access controls, reconciliation, and clear failure alerts. Email-based file drops are much harder to govern and support over time.
9. Power BI still needs a reliable data model
   Saving files into SharePoint only solves the file delivery problem. It does not address data modelling, historical tracking, schema changes, relationships between AroFlo entities, deduplication, refresh reliability, or the need to preserve a clean historical reporting layer.

For a proper business-grade solution, the more reliable pattern is to land the AroFlo data into a controlled data layer first, such as a database, data lake, or warehouse. That layer can handle API limits, incremental extraction, retries, validation, deduplication, historical storage, transformation, monitoring, and schema management. Power BI can then report from a stable, governed dataset rather than depending on emailed report exports.

So I agree your method may be the easiest low-cost workaround, but I would not recommend it as the foundation for a reliable production reporting solution where the business depends on the outputs. In that case, a data-layer approach is much more maintainable, scalable, and supportable.