The solution is creating a Custom Report Type, explicitly defining the object (or objects, including relationships) and specifically selecting which fields should be available for reports built on that Report Type, since Custom Report Types exist precisely to expose data — especially custom objects and their relationships — that Standard Report Types were never automatically generated to cover. This cannot be worked around with filters within an existing report because the Report Type is chosen and locked in BEFORE any report-building begins, and it fundamentally determines the entire universe of fields and objects available to work with; filters can only narrow down which RECORDS appear among what the Report Type already exposes, they cannot add entirely new fields or objects that the underlying Report Type never included in the first place. If the needed fields simply are not present in the Report Type's available field list, no combination of filtering, grouping, or formulas within the report itself can retroactively add them.

Matrix format is required, because this request is fundamentally a two-dimensional cross-tabulation — Amount needs to be broken down by TWO independent grouping dimensions simultaneously, Sales Rep along one axis and Fiscal Quarter along the other, with the intersecting cells showing the summarized value for each specific Rep-and-Quarter combination. Summary format alone cannot satisfy this because it only supports grouping along a single dimension, expressed as nested ROW groupings — while Summary format could show Amount grouped by Sales Rep, and even add a second nested grouping level like Fiscal Quarter underneath each Rep, this would produce a long vertical list of nested groups rather than the genuine side-by-side, at-a-glance cross-tab structure the Sales Manager is actually asking for, where Quarters run across the top as columns and Reps run down the side as rows, letting patterns across both dimensions be compared visually in one compact grid.

A Cross-Filter filters records based on the EXISTENCE or ABSENCE of related records, rather than based on any field value on the record being reported on itself — for example, filtering Accounts based on whether they DO or DO NOT have any related Opportunity records at all. This answers a specific class of question that standard field filters are structurally incapable of addressing: "how many of these exist" or "do any related records exist" questions, since a standard field filter can only evaluate conditions against fields that actually exist ON the record being filtered, and there is typically no field on an Account directly capturing "count of related Opportunities" unless a Roll-Up Summary Field happens to exist for that specific purpose, which itself only works on Master-Detail relationships in the first place. A requirement like "show me every Account with zero Opportunities" is precisely the kind of relationship-existence question Cross-Filters were purpose-built to answer, where standard filtering has no mechanism to express the concept at all.

A Report Formula is the better fit when the calculation's meaning is genuinely dependent on the specific report's own context — particularly its grouping structure and aggregated totals — rather than being a standalone value that makes sense independent of any particular report, which is what a permanent object-level Formula Field is designed for. A calculation like "this Stage's percentage share of total pipeline," using PARENTGROUPVAL() to reference a Grand Summary total, only has meaning within the context of THIS specific report's grouping and filtering — the concept of "total pipeline" varies entirely depending on which records this particular report happens to include, meaning the same underlying Opportunity record's contribution to "percentage of total" would be a completely different number in a different report with different filters. A permanent Formula Field, by contrast, is appropriate for a calculation that produces a consistent, standalone, context-independent value regardless of which report or list view happens to display it, such as a straightforward date-difference calculation that means the same thing everywhere it appears.

This is not a bug — it is the expected, correct interaction between two genuinely independent access layers. Folder sharing, which is what gave both users Viewer access to see and run this specific report, only controls whether a user can access the REPORT DEFINITION itself; it does not override or bypass each individual user's own record-level access governed by the Sharing Model from Module 5, meaning Organization-Wide Defaults, Role Hierarchy, Sharing Rules, and Manual Sharing all still apply exactly as they would if the user were browsing the underlying records directly rather than through a report. If one user has broader record-level access than the other, perhaps due to a higher position in the Role Hierarchy or membership in a Sharing Rule's target audience, they will see more underlying records reflected in the report's results, even though both users are running the literally identical report definition from the identically shared folder. This is precisely why folder sharing and record-level sharing must be understood as two separate, independently-operating layers rather than a single unified access control.

This uses the standard Opportunities Report Type, since no custom object is involved, in Summary format grouped by Opportunity Owner, since the requirement needs a per-Rep breakdown rather than a two-dimensional cross-tab, so Matrix format is not necessary here. Filters need Stage equals Closed Won, to scope to deals that genuinely closed rather than all pipeline activity, combined with Close Date equal to Current Fiscal Year, directly leveraging the Fiscal Year configuration from Module 1 to correctly scope the time period regardless of the company's specific fiscal calendar. The core metric requires an Average Summary Field on the Amount column, giving each Rep's average deal size as a grouped aggregate. Finally, answering the comparative "below half the team average" part specifically requires a Summary Formula, since this depends on comparing each Rep's own grouped average against a team-wide Grand Summary average — using PARENTGROUPVAL(AVG(Amount), GRAND_SUMMARY) to reference that team-wide average, dividing it by two, and comparing each Rep's own AVG(Amount) against that benchmark, returning a Checkbox or similar flag wherever a Rep's average falls below that threshold.