Select Two (Multi-Select) Questions

Configure a Business Rule on the Job Information object that triggers on the 'onInit' event to set the Probation End Date when the record is loaded.

Why it fails: An onInit Business Rule executes when the portlet is initialized, not when the Employment Type changes. It would not respond to the user changing the Employment Type to Temporary. While it could set a default date, it would not dynamically update based on the selection. The requirement is to set the date upon change, so an onChange rule is needed, not onInit.

Create a Propagation rule on the Job Information object to copy the Employment Type value to the Probation End Date field.

Why it fails: Propagation rules copy values from one field to another but cannot calculate dates or set conditional values. Copying Employment Type to Probation End Date would not achieve the 90-day calculation and would result in an invalid date value. Propagation is not suitable for date arithmetic or conditional logic; it is used for defaulting or synchronizing identical data types.

Use a Picklist Center configuration to make the Contract End Date field mandatory when Employment Type is 'Temporary'.

Why it fails: Picklist Center manages picklist values and dependencies, not field-level mandatory enforcement based on another field's value. It cannot conditionally require the Contract End Date field. Mandatory field logic based on conditions is typically handled by Business Rules or field configuration settings, not by Picklist Center, which focuses on the list of values, not field properties.

Configure a picklist for 'Seniority Date' with predefined values.

Why it fails: A picklist is for selecting from predefined options, not for calculating dates. Seniority Date is a date value that must be derived from other fields, so a picklist is inappropriate. It would not provide the dynamic calculation needed and would require manual selection, which is error-prone.

Use the standard 'Hire Date' field and configure it as read-only.

Why it fails: The standard Hire Date field is used by the system for various processes and may be updated during rehire or other events. Making it read-only could break necessary updates and does not guarantee it represents the original hire date. It is not suitable for tracking an immutable original hire date.

Use a standard field for 'Seniority Date' and set it as a calculated field via the Data Dictionary.

Why it fails: The Data Dictionary does not support calculated fields in Employee Central. Calculations are performed via business rules, not through the Data Dictionary. While some fields may have system-calculated behavior, custom calculations require business rules. This option misrepresents the platform's capabilities.

OnDelete

Why it fails: OnDelete triggers when a Business Unit record is deleted. It is used to perform checks or actions before deletion, such as preventing deletion if there are dependent records. It is not relevant for validating parent-child relationships during save or change.

OnPostSave

Why it fails: OnPostSave triggers after the record is saved, so it cannot prevent saving an invalid hierarchy. It is used for actions that occur after save, such as sending notifications or updating related records. It would not enforce validation.

OnInit

Why it fails: OnInit runs when the object is initialized, before any user input. It cannot validate the Parent Business Unit selection because that value is not yet set. It is used for setting default values, not for validation.

Configure a workflow to send an email to the HR administrator to update the FTE field.

Why it fails: Sending an email or initiating a workflow does not automatically update the FTE field. It relies on manual action, which is not the requirement. The scenario calls for automatic recalculation, so this approach is inefficient and error-prone.

Set the 'Employment Type' field to 'Part-Time' again to trigger the rule recursively.

Why it fails: Setting the same field again would cause a recursive trigger, potentially leading to an infinite loop or performance issues. The rule is already triggered by the change, so this action is unnecessary and could cause errors. It does not contribute to calculating the FTE.

Use a 'Raise Error' operation to force the user to manually update the FTE field.

Why it fails: A 'Raise Error' operation would block the save and require manual intervention, which contradicts the requirement for automatic adjustment. It does not automatically recalculate the FTE; it only alerts the user. This is not the desired action for an automated process.

Use a scheduled job to run daily and update the Probation End Date for all employees whose Employee Class is 'Temporary'.

Why it fails: A scheduled job runs at fixed intervals and would not immediately react to the change. It could cause delays and would update all temporary employees, not just those who just changed. The requirement is for an immediate, event-driven update when the Employee Class changes, which a scheduled job does not provide.

Create a workflow that sends an email notification to the HR administrator whenever Employee Class changes.

Why it fails: A workflow sends notifications but does not automatically update the Probation End Date field. The requirement is for the system to update the date automatically, not to notify someone. Workflows are for approvals or alerts, not for field calculations.

Configure a field-level validation rule on the 'Employee Class' field to restrict values to 'Regular' and 'Temporary'.

Why it fails: A validation rule restricts allowed values but does not trigger any update to another field. While it might be good practice to limit values, it does not satisfy the requirement to automatically set the Probation End Date when the class changes. Validation is for data integrity, not for automation of field updates.

Set up a picklist dependency to filter Job Code values based on the selected Position.

Why it fails: A picklist dependency filters available options but does not set the value automatically. Even if the Job Code list is filtered to only valid codes for the position, the user must still select one. This does not meet the automatic update requirement and would not populate Cost Center at all.

Use a workflow rule to update Job Code and Cost Center after the Job Information record is saved.

Why it fails: A workflow rule can trigger actions after save, but it is not designed to update field values on the same record. Workflow rules typically route for approval or trigger notifications. They cannot directly modify the Job Information record's fields. Therefore, this approach would not achieve the automatic field update.

Configure the Job Code and Cost Center fields as required fields in the Job Information portlet.

Why it fails: Making these fields required ensures they are populated but does not automatically update them based on the position. The user would still need to manually enter the correct values. The requirement is for automatic synchronization, not just mandatory entry. Required fields do not provide the dynamic update logic needed.

Create a workflow that triggers when Job Title changes and routes a task to the HR administrator to manually update the Job Code.

Why it fails: A workflow would require manual intervention, which contradicts the requirement for automatic update. Workflows are for approvals or notifications, not for automated data updates based on mappings. This approach would be inefficient and error-prone. The requirement is to automatically update Job Code, so a workflow is not appropriate. This step does not achieve the automation goal.

Use a data import to update the Job Code field in Job Information whenever Job Title changes.

Why it fails: A data import is a batch process that must be manually triggered or scheduled, not an automatic real-time response to a field change. It would not immediately update Job Code when Job Title changes. This approach is not automated and would introduce delays. The requirement is for automatic update upon change, so data import is not suitable. It does not meet the real-time aspect.

Configure a propagation rule to copy the Job Title from Job Information to the JobTitleMapping object to trigger the mapping.

Why it fails: Propagation rules are used to copy values from a parent object to a child object or vice versa, but they do not perform lookups or mappings. Propagation would simply copy the Job Title to the JobTitleMapping object, which does not help in retrieving the Job Code. Propagation is not the right tool for this requirement; it would not trigger the mapping logic. This step is unnecessary and incorrect.

Define a picklist for 'Employee Class' and associate it with the 'Job Classification' field to ensure values are consistent.

Why it fails: Associating a picklist with the Job Classification field would not automatically update the Employee Class field. Picklists define allowed values for a field but do not perform cross-field updates. This approach would not satisfy the requirement for automatic updates based on a mapping.

Use a propagation rule to copy the 'Job Classification' value to the 'Employee Class' field.

Why it fails: A propagation rule copies a value from one field to another, but it does not perform a mapping or transformation. Copying the Job Classification value directly to Employee Class would not achieve the required mapping, as the values are likely different. Propagation is not suitable for this scenario.

Configure a workflow that sends an email notification to the HR administrator whenever the 'Job Classification' changes, prompting them to manually update the 'Employee Class' field.

Why it fails: A workflow notification does not automatically update the Employee Class field; it only alerts an administrator to do so manually. This does not meet the requirement for automatic updates and introduces delay and potential human error. The requirement specifically asks for automatic updates based on a predefined mapping.

Create a workflow that routes the Pay Grade change for approval.

Why it fails: A workflow would be used for approval processes, but it does not automatically set the Pay Grade. The requirement is to automatically set the value based on the Employee Class, which is achieved through a business rule, not a workflow.

Configure the 'Pay Grade' field as a read-only field in the Job Information configuration.

Why it fails: Making the Pay Grade field read-only would prevent users from manually editing it, but it does not enable a business rule to set its value. In fact, if the field is read-only, the business rule may still be able to set it programmatically, but this is not a required action. The rule can set the value regardless of the field's editability.

Add a 'Valid When' condition to the Pay Grade field to ensure it matches the Employee Class.

Why it fails: A 'Valid When' condition would validate that the Pay Grade is correct after the fact, but it would not automatically set the Pay Grade when the Employee Class changes. The requirement is to automatically populate the Pay Grade, not just validate it.

Configure a 'Valid When' rule on the Location field in Job Information to filter by legal entity.

Why it fails: While a 'Valid When' rule can be used to filter locations based on legal entity, it is not a mandatory configuration step for the Location foundation object itself. The requirement is to ensure locations are correctly set up for use, which does not necessarily include filtering by legal entity. Filtering is an optional business requirement, not a core setup step. Moreover, the question asks for valid configuration steps for the Location object, not for Job Information.

Assign the Location object to a specific employee group to control visibility.

Why it fails: Location foundation objects are not assigned to employee groups for visibility control. Employee groups are used for time-off plans, benefits, and other configurations, but not for restricting access to foundation object records. Visibility of foundation objects is typically controlled through role-based permissions (RBP) on the object itself, not through employee groups. This step is not a valid configuration for Location.

Set up a business rule that automatically creates a new Location when a new legal entity is created.

Why it fails: There is no standard requirement or mechanism to automatically create Location records when a legal entity is created. While business rules can automate certain actions, creating foundation object records is typically a manual or import-based process. This step is not a standard configuration step for the Location foundation object and is not necessary for its setup.