Learn, Practice, and Improve with SAP C_THR97_2405 Practice Test Questions

Explanation:

In SAP SuccessFactors Onboarding, embedded signatures allow users to sign documents directly within the Onboarding portal without navigating to external sites. To enable this, specific Role-Based Permissions (RBP) must be configured under Onboarding or Offboarding Object Permissions.

Signature (D):
This is the core metadata object permission. It allows the system to recognize and handle the signature entity associated with a process task. Without this permission, the signature task cannot be initiated or tracked for the specific user role.

Sign Document (B):
This is the action-based permission. It grants the user the specific right to interact with the document to provide their electronic signature. It is essential for the "DocuSign" or "SAP SuccessFactors e-signature" integration to function correctly during the Document Flow step.

Why the Other Options are Incorrect

A. Document Signature:
This is a common "distractor" answer. While it sounds like a valid technical term, it does not exist as a specific permission object in the SuccessFactors RBP Framework for Onboarding.

C. Consent:
This permission pertains to Data Privacy Consent Agreements (DPCA). While "consent" is a part of the onboarding experience, it governs the user’s agreement to have their data processed, not the legal signing of employment documents or tax forms.

References
SAP Learning Hub (THR97): Refer to the "Document Management and e-Signature" unit, which details the RBP requirements for both native and third-party signature providers.

Explanation:

To configure the specific fields used for rehire checks, you must navigate to Manage Business Configuration (BCUI) in the Admin Center.

The system uses a specific element called rehireConfig (under the "Other Configurations" section) to define the matching logic. Within this tool, you select which fields—such as First Name, Last Name, Date of Birth, or National ID—the system should evaluate when a new hire is initiated. If the data entered for a new candidate matches an existing record in the system based on these parameters, a "Potential Rehire" alert is triggered.

Why the Other Options are Incorrect

B. Rehire Inactive Employee:
This is the actual functional tool used by HR to manually process a rehire. It is an action tool, not a configuration tool for field matching logic.

C. Manage Data:
While Onboarding uses many Metadata Framework (MDF) objects configured here, the specific logic for rehire field matching is stored in the Business Configuration (BCUI) rather than as a generic data object.

D. Manage Configuration UI:
This tool is used to design the visual layout (screen look and feel) of MDF objects. It does not control the backend logic or parameters for data matching.

References
SAP SuccessFactors Onboarding Implementation Guide: Refer to the section "Configuring Rehire Check Parameters."

Explanation:

In SAP SuccessFactors Onboarding, rehire checks are designed to trigger at specific "gateways" to prevent duplicate profiles and ensure historical data integrity.

When Onboarding is Initiated (C):
The "First Rehire Check" occurs immediately when the candidate is passed from Recruiting (RCM) or an external ATS into Onboarding. The system compares the incoming data against existing records based on the parameters set in Manage Business Configuration.

The Review Hire Data step (A):
The "Second Rehire Check" occurs during this manual task. If the Onboarding specialist modifies key identifying fields (like National ID or Date of Birth) during the review, the system re-runs the matching logic to see if the updated information now matches an inactive employee.

Why the Other Options are Incorrect

B. Manage Pending Hires:
This is the final step where the record is pushed to Employee Central (EC). While a final validation occurs here, it is technically the "Hire" action, not the specific Onboarding "Rehire Check" logic defined in the onboarding configuration.

D. After Personal Data Collection:
The Personal Data Collection step happens after the initial rehire checks. While the system captures more data here, the primary rehire "checks" are strategically placed earlier (Initiation) and during the administrative review (Review Hire Data) to stop duplicate processing as soon as possible.

References
SAP SuccessFactors Onboarding Implementation Guide: Refer to the "Rehire Coordination" section, which outlines the two-step verification process.

Explanation:

To create a functional custom task in SAP SuccessFactors Onboarding, you must go beyond simply creating a data container; you must make it interactable for the user within the Onboarding program.

Create a UI in Manage Configuration UI (D):
After a Metadata Framework (MDF) object is created, it has no "face." You must use Manage Configuration UI to build the specific screen (fields, layout, and labels) that the onboarding participant will see when they click on the custom task. Without this UI, the task cannot be rendered in the Onboarding dashboard.

Link the custom MDF object to the custom task (B):
Once the object and its UI are ready, you must navigate to Manage Onboarding and Offboarding Tasks. Here, you define the task and explicitly link it to the MDF object you created. This tells the system which data structure to trigger when the task is assigned to a new hire or manager.

Why the Other Options are Incorrect

A. Create a custom MDF object:
While this is a prerequisite step, it is not the act of "creating the task" itself. The question asks how to create the onboarding program task, which involves the integration of the object, not just the existence of the object.

C. Configure the visibility of the custom MDF object:
Visibility settings (like "Editable" or "Read Only") are attributes of the fields within the object, but they are not the mechanism used to create or define the task within the Onboarding program.

References:
SAP SuccessFactors Onboarding Implementation Guide: Refer to the "Defining Custom Tasks" section, which outlines the mandatory sequence: Create MDF Object → Create UI → Link to Task in Manage Onboarding Tasks.

Explanation:

In SAP SuccessFactors Onboarding, the rehire process is specifically triggered when the system identifies a "match" between a new candidate and an existing (inactive) employee record. To manage this within the Onboarding flow, the administrative user must have permissions that specifically include the "(by 'match' in New Hire)" suffix.

Rehire Inactive Employee (by 'match' in New Hire) (A):
This permission allows the user to perform a rehire using the candidate's existing Employment Profile. This maintains the continuity of the employee's original assignment and history.

Rehire Inactive Employee with New Employment (by 'match' in New Hire) (D):
This permission allows the user to rehire the candidate but creates a completely new employment record. This is often used if the legal entity or the nature of the employment has changed significantly enough to warrant a fresh start in the system.

Why the Other Options are Incorrect

B & C (Standard Rehire Permissions):
These permissions exist, but they are used for the manual rehire process performed directly within Employee Central (via the Rehire Inactive Employee tool). They do not cover the automated "matching" logic that occurs specifically during the Onboarding sequence when a candidate is pushed from Recruiting.

References
SAP SuccessFactors Onboarding Implementation Guide: Look under the "Setting Up Rehire Check" section, specifically the "Granting Permissions for Rehire" subsection.

Explanation:

In the standard integration between SAP SuccessFactors Recruiting (RCM) and Onboarding (ONB), the candidate's status in the Talent Pipeline is the primary trigger for the data transfer.

Hireable (C):
To successfully initiate Onboarding, a candidate must be moved to a status that is internally configured as "Hireable." When a recruiter moves a candidate to this status, the system recognizes that the selection process is complete and the pre-hire data is ready to be mapped into the Onboarding module.

Why the Other Options are Incorrect

A. Hired:
While a candidate can be in "Hired" status to initiate onboarding, "Hireable" is the specific industry-standard prerequisite for the initiation phase. Usually, a candidate is moved to "Hired" after the onboarding process is finalized or the "Manage Pending Hires" step is completed.

B. None:A candidate cannot be in a null status; the system requires a defined pipeline stage to map the transformation of the applicant to a pre-hire.

D. Initiate onboarding:
This is the action name, not the pipeline status. You perform the action of "Initiate onboarding" because the candidate is in the "Hireable" status.

References
SAP SuccessFactors Recruiting and Onboarding Integration Guide: See the section on "Configuring the Talent Pipeline for Onboarding."

Explanation:

To integrate DocuSign with SAP SuccessFactors Onboarding, the system requires a secure handshake via the DocuSign eSignature API. While a standard user login (email and password) is used for the initial "Grant Access" consent step, the persistent connection and activation of the feature within the Admin Center require two specific technical identifiers found in the DocuSign Apps and Keys settings:

DocuSign API Account ID (D):
This is a unique GUID (Globally Unique Identifier) that identifies your specific DocuSign corporate account in the DocuSign ecosystem. It ensures that the documents generated in SuccessFactors are routed to the correct organizational "bucket" in DocuSign.

DocuSign User ID (B):
This is a unique GUID assigned to the specific administrator user account that is used to authorize the integration. Note that this is not the user's email address or username, but the long alphanumeric string associated with that user profile in DocuSign's backend.

Why the Other Options are Incorrect

A. DocuSign Account Password:
While you need your password to log in to DocuSign initially to grant consent, it is not stored or used as a configuration parameter in the SuccessFactors "Configure DocuSign eSignature" tool. Modern integrations use OAuth tokens for security rather than storing administrative passwords.

C. DocuSign Account Username:
This usually refers to the administrator's email address. In the technical configuration for Onboarding, the system specifically requires the User ID GUID, not the human-readable username or email.

References
SAP SuccessFactors Onboarding Implementation Guide: Refer to the "Configuring DocuSign eSignature" section, which explicitly lists the API Account ID and User ID as the two mandatory fields for activation.