Hi
1.First, check report access
If a user cannot view the Approval Report, first verify whether the report has been shared with that user/group and whether they have the required access to the underlying data.
2. Validate the source of Approval information
When creating a personalized view, check where the Approval/Approver/Approval State fields are coming from. For actual approval transaction details, these are generally available from the sysapproval_approver table.
3. Choose the correct reporting table
* Use sysapproval_approver` when the requirement is to report on approval transactions, approvers, approval state, or approval history.
* Use sc_req_item`** when the primary requirement is RITM/request information and approval details are additional information.
4. Dot-walking can be considered
If the report is based on `sc_req_item` and the required approval information is available through a valid reference relationship, dot-walking can be used to access the related fields.
5. Consider multiple approval records
One RITM can have multiple approval records in `sysapproval_approver`. Therefore, reporting directly from `sysapproval_approver` may result in multiple rows for the same RITM—one for each approval record.
Recommendation
For an approval-focused report, use `sysapproval_approver` as the primary source.
For an RITM-focused report, use `sc_req_item` and use the available relationship/dot-walking where appropriate.
The key is to first identify what the report needs to measure** and then select the appropriate table.
