2525275 - Forwarded and Referred Candidates not showing up in Reports - Recruiting Management

• Trying to report on candidates and their statuses in the Job Requisitions, but the report won't pull any data for candidates in 'Forwarded' or 'Invited to Apply' statuses.
• Recruiting V2 Adhoc Report: If the Referral Table is used to show "Forwarded" or “Invited to apply” referral records for candidates who have not yet applied to a requisition, the respective records will not show up in the report if corresponding fields from Candidate or Job Requisition Table are also included in the report.
• Recruiting V2 Secured Adhoc Report: for Referral fields, the 'Forwarded' and 'Invited to Apply' records NEVER show up if the candidate has not applied yet. Same with Agency and Agency Recruiter fields.

SAP SuccessFactors Recruiting Management

Valid for both Recruiting V2 & Recruiting V2 Secured:

1. Navigate to Analytics/Reporting from top menu;
2. Click on 'New' button;
3. Create a Recruiting V2 report, and select columns on Candidate, Application, Job Requisition and/or App Status Audit Trail.
4. Execute the report and observe that records for candidates in 'Forwarded' or 'Invite to Apply' statuses are missing.

Recruiting V2

The design of the Reporting domain necessitates that every table included in a report has a relationship to another table. And, the fact that candidate still hasn't applied to a Job Requisition when you add them in 'Forwarded' or 'Invite to Apply' statuses also implies on them not showing when you use 'App Status Audit Trail', because the behavior for candidates in these status is different from candidates that have applied.

Recruiting V2 Secured

The problem is compounded in Recruiting V2 secured domain as it includes an implicit filter on Job Requisition due to the Requisition Pill security selection (e.g. choosing the security operator such as “Hiring Manager”).

Recruiting V2

To work around this problem so correct data would be displayed while maintaining backward compatibility for existing reports, it was decided to split up the old Referral table into 3:

• one linked directly to Job Requisition;
• one to Candidate;
• and, the original, Referral table linked to Application.

The same was done for 'Agency' and 'Agency Recruiter' tables. This approach makes the join relationship between the entities explicit.

There are now 9 tables for referral and agency data:

• Referral Agency linked on Application
• Referral Agency linked on Candidate
• Referral Agency linked on Job Requisition 
• Referral Agency Recruiter linked on Application
• Referral Agency Recruiter linked on Candidate
• Referral Agency Recruiter linked on Job Requisition 
• Referrals linked on Application
• Referrals linked on Candidate
• Referrals linked on Job Requisition 

With this solution if a customer wants to join the old Referral table with the other 3 entities they have to select the corresponding Referral tables:

• If the customer only want Referrals: use any of the 3 tables;
• If the customer only want Referrals + Job Requisition: Use 'Referrals linked on Job Requisition', it will include Forwarded and Invited to Apply records;
• If the customer only want Referrals + Application: Use 'Referrals linked on Application'. Filters out referrals without applications, i.e. Forwarded and Invited to Apply records. Should fetch 1 record for each Job Requisition a Candidate has been referred and applied to;
• If the customer only want Referrals + Candidates:  Use 'Referrals linked on Candidate'. Apart from Forwarded and Invited to Apply records, this should include even agency referrals by duration i.e. without associated job reqs.

Recruiting V2 Secured

The Recruiting V2 Secured schema has 1 limitation – because of the implicit join on 'Job Requisition' the 'Referrals linked on Candidate' would make no sense. It would still always go through the join path of Job Requisition to Application, Application to Candidate, and Candidate to Referral, for example, and it would end up with the same dataset as the original Referrals linked on Application i.e. Forwarded and Invited to Apply records would still get filtered out.

Therefore, the secured schema only has 6 tables:

• Referral Agency linked on Application
• Referral Agency linked on Job Requisition 
• Referral Agency Recruiter linked on Application
• Referral Agency Recruiter linked on Job Requisition 
• Referrals linked on Application
• Referrals linked on Job Requisition

Quick Facts and Known Limitations:

• At one time, only Referrals linked on 1 out of Application, Candidate, and Job Requisition can be selected for a report. If 'Referrals linked on Job Requisition' table is selected the alternate tables linked on Application and Candidate are greyed out and cannot be selected and vice-versa.
• As a result, there is still no way to join together all the entities in the report – Job Requisition, Application, Candidate and Referral, and get ALL correct matching results in each row.
• In the secured report, there is no way to join together referrals with their associated candidate data in the same row if no application exists yet.
• The 'Referrals linked on Job Requisition' links to Job Requisition which links to Application which links to Candidate – but the candidate restriction gets lost in the relationship chain at the Job Requisition table.
• The 'Referrals linked on Application' maintains the candidate join but cannot show 'Forwarded' and 'Invited to Apply' records.

2716033 - How to know which job requisition a candidate has been forwarded to - Recruiting Management

employee, referral, forwarded, fwd, reporting, analytics, agency, candidate, invite, apply, reports, ad-hoc , KBA , LOD-SF-RCM , Recruiting Management , LOD-SF-ANA-ADH , Adhoc Reports & Report Builder , Problem