Employee Central Core practice questions

Configure the field as Read Only in Corporate Data Model and assign a dynamic role-based permission override.

Why it fails: Configuring the field as Read Only prevents any manual overwriting by HR administrators, which directly contradicts the requirement stating that the field must still be manually editable after automatic population from the department selection.

Define the field as a Foundation Object derived field with restricted write permissions assigned to the HR Administrator role.

Why it fails: Foundation Object derived fields lock the value to the parent object attribute and do not allow free-form manual overwriting by HR administrators unless complex UI overrides are custom coded, which is not standard Employee Central behavior.

Set the field type to Dynamic Destination in Configure Business Objects and map it directly to the department foundation object.

Why it fails: Dynamic Destination mapping is used primarily for picklist filtering or parent-child associations rather than providing a default value that can be subsequently and independently overwritten by an HR administrator on the transaction screen.

Configure Object Definitions to apply a default value expression directly on the object field properties.

Why it fails: Object Definitions define data types, associations, and standard properties, but they do not possess the dynamic logical execution capabilities required to conditionally alter field behavior based on runtime user selections.

Configure Business Rules and assign them to the onChange event of the employee class field in Corporate Data Model or Succession Data Model.

Why it fails: While Business Rules are correct, assigning them via Succession Data Model XML is legacy behavior. Modern implementations utilize Configure Business Rules and Configure Object Definitions for MDF or propagation rules.

Configure Business Rules and attach them to the saveRules event inside the propagation rule framework for Employee Central portlets.

Why it fails: Save rules execute upon data submission rather than providing real-time UI responsiveness. Relying solely on save rules would fail to update the field value dynamically on the screen before the record is saved.

Configure a business rule on the Job Information block that sets the Payroll Provider field based on the Legal Entity field.

Why it fails: A business rule can set a default, but it does not restrict the field to legal-entity-specific values. Users could still override the field with an incorrect provider, and no validation would prevent an invalid combination. The requirement is to enforce, not merely populate, the correct provider.

Convert the Payroll Provider field to a generic object field and populate it with the legal entity's payroll provider.

Why it fails: A generic object field can store a reference to a payroll provider object, but it does not automatically populate based on legal entity. Additional configuration and business rules would still be needed, and the field would not inherently enforce the correct provider.

Create a payroll provider picklist and assign it to the Payroll Provider field, then use legal entity-specific picklist values.

Why it fails: Picklist values can be restricted by country or legal entity, but they do not automatically derive the correct value from the legal entity. The user still selects from a list, and the field remains editable. This does not enforce the exact provider mapping required.

Set the field to 'Required' in the Manage Data > Picklist Center for the Employment Type picklist.

Why it fails: Picklist Center manages picklist values, not field-level requiredness. Marking a picklist as required there would not enforce that the field on the employee record must be filled; it only controls the picklist options. This does not meet the requirement of preventing save without a value.

Use the Import Employee Data tool to set a default value for Employment Type for all employees.

Why it fails: Importing data can populate values, but it does not enforce requiredness going forward. The requirement is to ensure every record has a value before saving; a default value only helps for new records if configured, but does not block saving when the field is empty. This is not a validation configuration.

Create a business rule that displays an error message when Employment Type is blank, and attach it to the Job Information portlet.

Why it fails: While business rules can validate data, they are not the primary mechanism for enforcing required fields. The scenario asks to enforce that a value must be present before saving; required field configuration is simpler and more direct. A business rule might be used for conditional requiredness, but not for a standard always-required field.

Use a string field with a maximum length of 255 characters and rely on data entry guidelines.

Why it fails: A plain string field offers no validation or predefined list, so users could enter any value. This leads to inconsistent data and does not meet the requirement for a predefined list. It also lacks the ability to store related certification metadata.

Use a text field with a validation rule that checks against a list of valid certifications.

Why it fails: A text field with validation can restrict values, but it requires maintaining the valid list within the rule, which is less flexible and harder to update. It also does not provide a user-friendly selection interface and cannot store additional certification details.

Create a picklist and assign it to the certification name field.

Why it fails: A picklist can provide a predefined list, but it is not the best choice for MDF objects because picklists are primarily used for standard fields. MDF objects typically use a generic object or a composite association for such references, and a picklist would not allow additional attributes like certification code.

Set the Cost Center field to Required in the Configure Object Definitions for Job Information.

Why it fails: Setting a field as Required in Configure Object Definitions makes it mandatory for all employees in all contexts, which may be too broad if the requirement applies only during specific edit scenarios. Additionally, this setting affects the object definition globally and may not respect conditional logic.

Configure a field criteria in the Job Information block to make Cost Center mandatory.

Why it fails: Field criteria in the Job Information block control visibility and editability, not mandatory validation. While you can hide or show fields, they do not enforce that a value must be entered before saving. A different mechanism is needed for mandatory enforcement.

Use a picklist restriction to require a selection for Cost Center.

Why it fails: Picklist restrictions limit which values can be selected, but they do not force a selection to be made. An empty field would still be allowed unless additional validation is applied. Picklists control the set of valid values, not whether a value is required.

Use a workflow rule to send an email notification 90 days after the hire date so the administrator can manually update the Benefits Eligibility Date.

Why it fails: A workflow notification only alerts a user; it does not automatically populate or update a field. This approach introduces manual effort and risk of error, and it does not satisfy the requirement that the date must recalculate automatically if the hire date is corrected.

Create a business rule on the Employment Info object that triggers on save and sets the Benefits Eligibility Date field to Hire Date plus 90 days.

Why it fails: Business rules can calculate dates, but the Employment Info object does not contain the standard Hire Date field in SAP SuccessFactors Employee Central; Hire Date is stored on the Job Information object. A rule on Employment Info would fail to reference the correct source field and would not recalculate when the hire date is corrected.

Set up a scheduled job that runs daily to update the Benefits Eligibility Date for all employees based on their hire date.

Why it fails: Scheduled jobs can perform bulk updates, but they are not real-time and would not recalculate immediately when a hire date is corrected. This approach also requires custom development and maintenance, whereas a calculated field provides the required automatic recalculation natively.

Configure a Country/Region-specific MDF object with a composite association to Company.

Why it fails: Country/Region-specific configuration applies to legal entities and addresses, not to filtering pay grades by Company. A composite association would not automatically filter the Pay Grade dropdown in Job Information; additional rule logic would still be needed, making this option incorrect for the stated goal.

Create a new Business Rule that validates Pay Grade against Company.

Why it fails: A validation rule only blocks invalid combinations after entry; it does not restrict the dropdown list or dynamically filter options based on Company. The field would still display all pay grades, forcing users to guess and potentially triggering errors, which is not the desired dependency behavior.

Modify the Pay Grade picklist and assign a parent picklist of Company.

Why it fails: Pay Grade is typically a MDF object, not a simple picklist, and standard picklists do not support parent-child filtering in Employee Central. Assigning a parent picklist would not dynamically filter the values shown in Job Information, so the dependency would not be enforced as required.

Create a new event reason in Manage Data, assign it to all events, and use a business rule to restrict it to Hire and trigger onboarding.

Why it fails: Assigning the event reason to all events would make it available for any event, which violates the requirement that it be only for Hire. Using a business rule to restrict it is not the standard approach; event reasons are inherently tied to specific events via configuration.

Create a new event reason in the Picklist Center, assign it to the Hire event, and configure the onboarding process in Onboarding configuration.

Why it fails: Event Reasons are not managed in Picklist Center; they are separate entities. While onboarding processes are configured in Onboarding, the association to the event reason is done in the Event Reason configuration, not directly in Onboarding. This option misplaces the configuration steps.

Create a new MDF object for event reasons, define a picklist for event types, and use a business rule to trigger onboarding.

Why it fails: Event Reasons are not created as MDF objects; they are standard configuration objects. Using a business rule to trigger onboarding is not the standard method; onboarding is associated directly in the Event Reason configuration. This approach is overly complex and not aligned with standard functionality.

Use a workflow to set the Event Reason after the hire event is submitted.

Why it fails: A workflow can trigger actions after submission, but it does not set the Event Reason during the hire process. The Event Reason is typically required at the time of the event, and a workflow would be too late and not allow override before submission.

Configure the Event Reason field as a required field and set default values for Hire and Rehire in the Corporate Data Model.

Why it fails: The Corporate Data Model does not control Event Reason defaults on employee records. Setting it as required only enforces a value but does not automatically derive it based on event type. This approach fails to meet the automatic derivation requirement.

Create a picklist for Event Reason and assign it to the field, then use a business rule to set the value based on the event type.

Why it fails: While a picklist is necessary for the Event Reason field, it does not automatically set the value. A business rule is needed, but simply assigning a picklist does not derive the value. This option is incomplete and does not ensure the correct Event Reason is set.

Define a valid values source for the Equipment object using a picklist.

Why it fails: A picklist provides static or dynamic options for a field, not a relationship to another object. While you could use a picklist to select equipment types, it does not create the required association between the Equipment MDF object and the Employee Profile object for tracking assignments.

Create a composite association from the Equipment object to the Employee Profile object.

Why it fails: A composite association would make the Equipment object a child of Employee Profile, which is not appropriate for independent equipment records. Composite associations are used when the child object cannot exist without the parent, but equipment assignments are separate entities that should be linked via a regular association.

Add a field of type 'User' to the Equipment object and populate it with the employee's user ID.

Why it fails: Using a User field type links to a user account, not to the Employee Profile MDF object. This would not create a proper association for reporting or navigation from the Employee Profile, and it does not support multiple equipment items per employee in the intended MDF relationship.

Create a business rule that sets the Event Reason based on the Job Classification field change.

Why it fails: While business rules can sometimes set field values, Event Reason derivation is specifically handled through the derivation rule configuration in the object definition, not through a general business rule. A business rule would not be triggered in the same way and may not integrate with the standard derivation logic.

Set up the Event Reason picklist to filter values based on Job Classification.

Why it fails: Filtering the picklist would limit the available Event Reasons, but it would not automatically select the correct one. The user would still need to choose from the filtered list. Automatic derivation requires a rule that sets the value without user intervention.

Configure the Event Reason field as a required field in the Job Information block.

Why it fails: Making Event Reason required ensures that a value must be selected, but it does not automatically derive the correct value based on Job Classification changes. The requirement is for automatic selection, not just mandatory entry. Required field setting alone does not fulfill the derivation need.

Configure Time Account Payout rules to trigger on legal entity change.

Why it fails: Time Account Payout rules handle monetary payout of unused balances upon termination, not proration during transfers. They are not designed to prorate balances when an employee moves between legal entities while remaining employed. Using payout rules would incorrectly treat a transfer as a termination event.

Create a business rule that updates the Time Account balance field directly on legal entity change.

Why it fails: Directly updating Time Account balance fields via business rules is not supported because balances are calculated by the Time Off engine. Business rules can trigger other actions, but they cannot override the core proration logic. This approach would lead to data inconsistencies and is not a recommended practice.

Configure the Legal Entity object to include a time account proration field.

Why it fails: The Legal Entity object does not contain a field for time account proration. Proration is controlled at the employee level through Time Off configurations, not by adding fields to Legal Entity. This option misplaces the configuration and would not achieve the required proration.

Base Object: Compensation Information; Event: onSave

Why it fails: Compensation Information holds salary and pay data, not hire date or country. Using this base object would not have access to the required fields. Even with onSave, the rule would not function correctly because the necessary data is not present in this object.

Base Object: Employee Information; Event: onChange

Why it fails: Employee Information may contain some data, but hire date and country are typically in Job Information. The onChange event triggers when a field changes, not on save, which might not capture all save scenarios. This combination does not meet the requirement to run on Job Information save.

Base Object: Job Information; Event: onChange

Why it fails: While Job Information is the correct base object, the onChange event fires when a specific field changes, not when the entire object is saved. The scenario requires the rule to run on save, so onSave is more appropriate. onChange might miss updates where the field itself didn't change but other data did.

OnPostSave

Why it fails: OnPostSave triggers after a record is saved, similar to OnSave, but it still does not target specific field changes. It is used for actions that must occur after the save transaction completes. Using it here would cause notifications on any save, not just job title changes, leading to unnecessary alerts.

OnSave

Why it fails: OnSave triggers when a record is saved, but it does not specifically detect changes to a particular field. It would fire on any save event, potentially causing unnecessary notifications. The requirement is to trigger only when the job title changes, so a more specific trigger is needed.

Scheduled

Why it fails: Scheduled triggers run at defined intervals, not in response to field changes. They are suitable for batch processes like nightly calculations, but they would not provide immediate notification upon a job title change. This option introduces delay and does not meet the real-time requirement.

Create a business rule that hides the field for all employees except those in the 'Project Management' department.

Why it fails: While a business rule can control field visibility based on department, it is not a required step to make the field available. The field can be added to the layout and made editable, but conditional visibility would require a rule. However, the question asks for required steps to capture the field, not to conditionally display it.

Set the field as required in the Job Information block to ensure data is always entered.

Why it fails: Making the field required is not mentioned in the requirements. The scenario only states the field should be available and editable; it does not mandate that it must be filled. Setting it as required could cause issues if project codes are not always applicable.

Configure a picklist for the 'Project Code' field to restrict values to a predefined list.

Why it fails: A picklist is not required because the field is a text field for entering project codes. If the requirement were to select from a list, a picklist would be needed, but the scenario specifies a text field. Adding a picklist would change the field type and is not a necessary step.

Set up a composite association between Division and Department.

Why it fails: A composite association would make Department a child of Division, meaning a department cannot exist without a division. While this might seem logical, it is not the standard way to link foundation objects. Foundation objects typically use valid values associations or business rules for such relationships, not composite associations.

Configure a propagation rule to copy the division from Department to Job Information.

Why it fails: Propagation rules copy data from one object to another, but they do not validate relationships. While copying the division might be useful, it does not ensure that the cost center is valid for the department. The requirement specifically asks for validation, not just data copying.

Create a picklist for cost centers and assign it to the Department object.

Why it fails: A picklist for cost centers would provide a static list, but it would not validate that the selected cost center belongs to the department. The requirement is to validate the cost center against the department, which requires a dynamic check, not a simple picklist assignment.

Position

Why it fails: The Position object stores data for individual positions, including headcount, but it does not automatically derive values from job classification. You could manually set the headcount, but the requirement is for automatic population based on job classification, which requires a rule or a different configuration approach.

Job Classification

Why it fails: The Job Classification object defines attributes for job classifications, but it does not control position headcount. While you could store a default headcount there, there is no standard automatic link to the Position object without a business rule or MDF association. This option alone does not fulfill the requirement.

MDF Picklist

Why it fails: An MDF picklist provides a list of values for a field, but it does not perform calculations or derive values from other objects. It cannot automatically set the maximum headcount based on job classification. Using a picklist would require manual selection and would not meet the automation requirement.

Create a Generic Object for Department with a field of type 'Association' to Division.

Why it fails: Creating a Generic Object for Department with an association to Division is not the standard approach. Department and Division are typically standard MDF objects, and the association should be defined on the Division object, not on Department, to enable filtering.

Use the 'Dependent Picklist' feature on the Department field to filter Division values.

Why it fails: Dependent Picklist is used for picklists, not for MDF object associations. While it can filter values based on another field, it is not applicable to MDF objects like Department and Division. The correct approach involves association and possibly a business rule.

Configure a Business Rule that validates the selected division against the selected department.

Why it fails: A Business Rule can validate the selection, but it does not automatically filter the available divisions based on the selected department. Filtering is achieved through the association and the use of a 'Dependent Picklist' or similar mechanism, not a validation rule.

Use the 'Purge Data' function within the Admin Center.

Why it fails: The Admin Center does not provide a 'Purge Data' function for Job Information records. Data purging is handled through the Data Retention Management tool, which allows administrators to define retention periods and purge data based on policies. Using a non-existent function would not achieve the desired result and could lead to confusion.

Use the 'Manage Data' tool to manually delete each record one by one.

Why it fails: The Manage Data tool allows administrators to view and edit individual records, but it does not support permanent deletion. It is designed for data correction and maintenance, not for purging data in bulk. Manually deleting records is not possible through this tool, and it would be inefficient for large-scale purges.

Use the 'Import and Export Data' tool to overwrite the records with blank values.

Why it fails: The Import and Export Data tool is used for mass data updates, but it does not permanently delete records; it only updates fields. Overwriting with blank values would leave the records in the system, potentially violating retention policies. This method does not achieve permanent deletion and is not the intended use of the tool.