Skip to content

Reporting Assumptions

Last updated: 2026-06-15.

This page captures process-relevant reporting assumptions. These are not mutating business workflows, but they affect how process owners should interpret Power BI and exported report data.

CRM Overview Model

Current implemented assumptions:

  • CRM contacts, companies, deals, MSP plans, MSP seats, MSP plan history, and MSP seat history are loaded from middleware report endpoints.
  • Company is the primary slicer path for contacts, deals, and MSP plans.
  • MSP Seat visuals use denormalized contact details such as contact email and lead status rather than an active Power BI relationship from Contacts to MSP Seats.
  • Current MSP plan and current MSP seat exports are active-only backend exports. For current MSP active-seat counts, Billing_Status values Active and Onboarding are both included when the seat billing dates are in range and the linked plan is active.
  • Historical MSP plan and seat tables are reconstructed at refresh time from CRM billing start/end date ranges. They are not filtered by the seat's current Billing_Status, because a seat that is now Ended can still be valid for a historical month.
  • MSP plan exports include PO_User_Count as a plan-level PO user count for comparison with active seat reporting.
  • MSP plan pricing and monthly revenue are not reported from Managed Services Plan fields in the CRM overview model.
  • Empty contact company or lead source values are normalized to blank/null-style values, and empty lead status becomes Uncategorised.

Process implication:

  • Historical MSP reporting depends on billing date ranges being maintained correctly in CRM.
  • PO_User_Count is a reporting comparison value. It does not currently drive MSP invoice generation or active seat eligibility.
  • MSP revenue should not be interpreted from the MSP plan tables; revenue reporting needs invoice-line data.
  • Seat lead status in visuals is copied from the linked Contact at export time; it should be read as reporting context, not as the source of seat billing eligibility.
  • Current MSP active-seat numbers include onboarding seats for operational visibility; MSP invoice generation has its own billing-eligibility rules.

Project Timesheets Model

Current implemented assumptions:

  • Current timelogs come from the live Delivery Model timelog report.
  • Archived timelogs come from a separate archived backfill report.
  • The final Power BI timelogs table appends current and archived rows.
  • Delivery Model status in Power BI is derived from Valid_Until: a date before the refresh date is reported as completed; blank, today, and future dates are reported as active.
  • Archived backfill should not be scheduled for routine refresh after a successful import; it should be refreshed manually after historical edits.
  • User filtering should use the final users query, which combines current users with fallback users found in timelogs.

Process implication:

  • Historical project edits may require a cache reset and a manual Power BI refresh before they appear in reporting.

Archived Timelog Backfill

Current implemented assumptions:

  • The archived backfill discovers Delivery Model projects, keeps archived projects, fetches logs through Zoho Projects REST APIs, and caches a generated CSV.
  • The default historical range starts at 2024-01-01 and ends at the last day of the previous month.
  • Cache reset mutates generated cache files only. It does not change CRM, Projects, Xero, or Power BI model definitions.
  • If a generation lock is fresh, reset returns a conflict and leaves the existing job alone. Locks older than 30 minutes are treated as stale.

References

  • CRM overview model: pbi/crm-overview/README.md
  • Project timesheets model: pbi/project-timesheets/README.md
  • Archived timelog backfill: docs/archived_timelog_backfill.md