Scenario practice questions

A consultant is designing a business rule to calculate an employee's bonus eligibility based on their hire date and employment type. The rule must trigger when either the hire date or employment type changes in Job Information. Which rule scenario and trigger should be used to ensure the rule evaluates both fields?

Trap 1: OnInit rule on Job Information

OnInit rules run when the Job Information portlet is loaded. They do not react to field changes. They are used for setting default values or controlling UI behavior on load. Since the rule must evaluate when Hire Date or Employment Type changes, OnInit is not suitable.

Trap 2: OnPostSave rule on Job Information

OnPostSave rules execute after the Job Information record is saved. They cannot modify the record or provide real-time calculations based on field changes. They are typically used for integrations or notifications. Thus, they do not meet the requirement of triggering on field changes.

Trap 3: OnSave rule on Job Information

An OnSave rule triggers only when the Job Information record is saved, not when individual fields change. If the user changes Hire Date and then saves, the rule runs, but it does not provide immediate feedback or trigger on field change. The requirement specifies triggering when either field changes, which suggests immediate evaluation.

A
OnInit rule on Job Information
Why it fails: OnInit rules run when the Job Information portlet is loaded. They do not react to field changes. They are used for setting default values or controlling UI behavior on load. Since the rule must evaluate when Hire Date or Employment Type changes, OnInit is not suitable.
B
OnPostSave rule on Job Information
Why it fails: OnPostSave rules execute after the Job Information record is saved. They cannot modify the record or provide real-time calculations based on field changes. They are typically used for integrations or notifications. Thus, they do not meet the requirement of triggering on field changes.
C
OnChange rule on Job Information with trigger fields Hire Date and Employment Type
An OnChange rule on Job Information can be configured with multiple trigger fields. When either Hire Date or Employment Type changes, the rule fires and recalculates bonus eligibility. This ensures both fields are monitored and the rule executes appropriately.
D
OnSave rule on Job Information
Why it fails: An OnSave rule triggers only when the Job Information record is saved, not when individual fields change. If the user changes Hire Date and then saves, the rule runs, but it does not provide immediate feedback or trigger on field change. The requirement specifies triggering when either field changes, which suggests immediate evaluation.

Question 2hardmultiple choice

A consultant is configuring a business rule on the Job Information portlet that must trigger only when the 'Employee Status' field changes from 'Active' to 'Terminated'. The rule should also consider that the change might occur due to a termination event or a manual edit. Which rule scenario and trigger condition should be used to ensure the rule fires only when the status changes to 'Terminated'?

Trap 1: Use the 'OnInit' rule scenario with a condition that checks if…

The OnInit rule scenario executes when the portlet is initialized or loaded, not when a change occurs. It would evaluate the condition when the user opens the Job Information portlet, which is not the desired trigger point. This would not reliably fire when the status changes, and it could fire multiple times during a session, leading to incorrect rule execution.

Trap 2: Use the 'OnSave' rule scenario with a condition that checks if…

An OnSave rule with a condition that only checks if Employee Status equals 'Terminated' would fire every time the record is saved with that status, even if the status did not change. This would cause the rule to trigger on unrelated edits to the Job Information record, such as a department change, while the employee is already terminated. It does not isolate the transition event.

Trap 3: Use the 'OnSave' rule scenario with a condition that checks if the…

While OnSave can reference previous values, it is not the appropriate scenario for detecting a specific field change. OnSave rules execute on every save, and although the condition would filter for the transition, the rule would still be evaluated on all saves, potentially causing performance overhead and unexpected behavior if other fields are edited simultaneously. OnChange is the intended scenario for field-level change detection.

A
Use the 'OnInit' rule scenario with a condition that checks if Employee Status equals 'Terminated'.
Why it fails: The OnInit rule scenario executes when the portlet is initialized or loaded, not when a change occurs. It would evaluate the condition when the user opens the Job Information portlet, which is not the desired trigger point. This would not reliably fire when the status changes, and it could fire multiple times during a session, leading to incorrect rule execution.
B
Use the 'OnChange' rule scenario with a condition that checks if the previous value of Employee Status was 'Active' and the new value is 'Terminated'.
The OnChange rule scenario is designed to fire when a specific field's value changes. By checking that the previous value was 'Active' and the new value is 'Terminated', the rule triggers only on that exact transition. This works whether the change comes from a termination event or a manual edit, because the rule evaluates the field change regardless of the source. This is the precise way to detect a status transition.
C
Use the 'OnSave' rule scenario with a condition that checks if Employee Status equals 'Terminated'.
Why it fails: An OnSave rule with a condition that only checks if Employee Status equals 'Terminated' would fire every time the record is saved with that status, even if the status did not change. This would cause the rule to trigger on unrelated edits to the Job Information record, such as a department change, while the employee is already terminated. It does not isolate the transition event.
D
Use the 'OnSave' rule scenario with a condition that checks if the previous value of Employee Status was 'Active' and the new value is 'Terminated'.
Why it fails: While OnSave can reference previous values, it is not the appropriate scenario for detecting a specific field change. OnSave rules execute on every save, and although the condition would filter for the transition, the rule would still be evaluated on all saves, potentially causing performance overhead and unexpected behavior if other fields are edited simultaneously. OnChange is the intended scenario for field-level change detection.

Question 3hardmultiple choice

An administrator needs to configure a business rule on the Job Information object that prevents saving a record when the employee's 'Employment Type' is 'Regular' and the 'Standard Weekly Hours' field is empty. The rule must evaluate on save and block the save with a custom error message. Which rule scenario and configuration should the administrator use?

Trap 1: Create an onInit rule on Job Information that checks the fields and…

onInit rules run when the record is loaded, not when it is saved, so they cannot block a save. A warning severity also allows the user to proceed, which does not prevent saving. This combination fails both the timing and the blocking requirement of the scenario.

Trap 2: Create an onChange rule on the Standard Weekly Hours field that…

An onChange rule fires when the field value changes, not on save, so it would not block saving a record where the field was already empty before the edit. It also ignores the Employment Type condition, producing false errors for non-Regular employees. This does not satisfy the requirement to validate on save with the specified condition.

Trap 3: Create an onSave rule on the Employment Type field with a condition…

Rules are defined on objects, not individual fields, and triggering a workflow does not block the save. The requirement is to prevent saving and show a custom error message, which a workflow cannot accomplish. This approach misapplies rule scope and the wrong outcome for the validation scenario.

A
Create an onSave rule on the Job Information object with a condition checking Employment Type = Regular and Standard Weekly Hours is empty, and add a message with severity 'Error'.
An onSave rule on Job Information evaluates when the record is saved. A condition matching Employment Type = Regular and empty Standard Weekly Hours, combined with an error-severity message, blocks the save and displays the custom message. This is the supported pattern for validation on save in Employee Central.
B
Create an onInit rule on Job Information that checks the fields and displays a warning message when Standard Weekly Hours is empty for Regular employees.
Why it fails: onInit rules run when the record is loaded, not when it is saved, so they cannot block a save. A warning severity also allows the user to proceed, which does not prevent saving. This combination fails both the timing and the blocking requirement of the scenario.
C
Create an onChange rule on the Standard Weekly Hours field that raises an error when the field is cleared, regardless of Employment Type.
Why it fails: An onChange rule fires when the field value changes, not on save, so it would not block saving a record where the field was already empty before the edit. It also ignores the Employment Type condition, producing false errors for non-Regular employees. This does not satisfy the requirement to validate on save with the specified condition.
D
Create an onSave rule on the Employment Type field with a condition checking Standard Weekly Hours is empty, and configure the rule to trigger a workflow instead of an error message.
Why it fails: Rules are defined on objects, not individual fields, and triggering a workflow does not block the save. The requirement is to prevent saving and show a custom error message, which a workflow cannot accomplish. This approach misapplies rule scope and the wrong outcome for the validation scenario.

Question 4hardmultiple choice

A company uses Employee Central and has a requirement that when an employee's 'Job Information' record is created, the 'Cost Center' field must be populated based on the employee's 'Location'. The administrator has created a business rule with an OnSave trigger on Job Information. However, during testing, the Cost Center is not being set. What is the most likely cause?

Trap 1: The rule should be triggered on OnInit instead of OnSave.

OnInit triggers when the form loads, but the requirement is to set Cost Center when the record is created, which is a save event. OnSave is appropriate for setting values during save. Changing to OnInit would not solve the issue and might set the value prematurely.

Trap 2: The rule is missing a condition to check if the record is new.

While checking if the record is new might be useful, the OnSave trigger fires on both create and update. If the rule is not setting Cost Center even on create, the issue is likely not the condition. Adding a condition would not fix the underlying problem.

Trap 3: The rule must be created on the 'Location' object instead of Job…

The rule triggers on Job Information creation, so it should be on Job Information. Creating it on Location would not trigger when Job Information is created. The base object is correct; the issue lies in rule configuration or activation.

A
The rule should be triggered on OnInit instead of OnSave.
Why it fails: OnInit triggers when the form loads, but the requirement is to set Cost Center when the record is created, which is a save event. OnSave is appropriate for setting values during save. Changing to OnInit would not solve the issue and might set the value prematurely.
B
The rule is missing a condition to check if the record is new.
Why it fails: While checking if the record is new might be useful, the OnSave trigger fires on both create and update. If the rule is not setting Cost Center even on create, the issue is likely not the condition. Adding a condition would not fix the underlying problem.
C
The 'Cost Center' field is not included in the rule's target field list or the rule is not active.
If the rule is not active or the Cost Center field is not specified as a target, the rule will not set it. This is a common configuration oversight. The administrator should verify the rule is active and that the target field is correctly mapped in the rule action.
D
The rule must be created on the 'Location' object instead of Job Information.
Why it fails: The rule triggers on Job Information creation, so it should be on Job Information. Creating it on Location would not trigger when Job Information is created. The base object is correct; the issue lies in rule configuration or activation.

Question 5easymultiple choice

A company wants to track employee participation in internal training courses. Each employee can attend many courses, and each course can have many employees. The administrator needs to create an MDF object to store this relationship. Which object type should be created?

Trap 1: A generic MDF object with a field of type 'User' and a field of…

A generic object with a User field and a String field can only link one employee to a course name per record. It does not model the many-to-many relationship properly and would require duplicate course definitions. This does not meet the requirement of tracking multiple employees per course and multiple courses per employee.

Trap 2: A foundation object for courses and a separate foundation object…

Creating two unrelated foundation objects does not establish any link between employees and courses. Without an association, the system cannot track which employee attended which course, so this configuration fails to capture the required many-to-many participation data.

Trap 3: A composite MDF object with a parent-child structure where the…

Composite objects model parent-child relationships where the child belongs to a single parent, not many-to-many associations. Using a composite would force each employee record to belong to one course, which contradicts the requirement that employees attend many courses and courses have many employees.

A
A generic MDF object with a field of type 'User' and a field of type 'String' for the course name.
Why it fails: A generic object with a User field and a String field can only link one employee to a course name per record. It does not model the many-to-many relationship properly and would require duplicate course definitions. This does not meet the requirement of tracking multiple employees per course and multiple courses per employee.
B
A foundation object for courses and a separate foundation object for employees, with no association between them.
Why it fails: Creating two unrelated foundation objects does not establish any link between employees and courses. Without an association, the system cannot track which employee attended which course, so this configuration fails to capture the required many-to-many participation data.
C
A generic MDF object with two association fields: one referencing the Employee object and one referencing the Course object.
A generic MDF object with two association fields creates a junction object that models a many-to-many relationship. Each record links one employee to one course, and multiple records allow many employees per course and many courses per employee. This is the standard pattern for many-to-many associations in Employee Central.
D
A composite MDF object with a parent-child structure where the parent is the course and the child is the employee.
Why it fails: Composite objects model parent-child relationships where the child belongs to a single parent, not many-to-many associations. Using a composite would force each employee record to belong to one course, which contradicts the requirement that employees attend many courses and courses have many employees.

Question 6mediummultiple choice

An Employee Central administrator is configuring the 'Job Information' portlet and needs to ensure that the field 'Employee Class' is automatically populated based on the selected 'Company' and 'Business Unit'. The administrator wants to use a business rule to set the default value. Which trigger type should be used for this business rule?

Trap 1: OnSave

OnSave triggers after the user saves the record, so it cannot set a default value before the user sees the form. It is used for validation or post-save actions, not for dynamic defaulting. In this scenario, the requirement is to populate a field based on other selections, which must happen before save, so OnSave is incorrect.

Trap 2: OnPostSave

OnPostSave triggers after the record is saved, so it cannot set a field value before save. It is used for actions like sending notifications or updating related objects after save. Since the requirement is to populate Employee Class before the user saves, OnPostSave is not appropriate.

Trap 3: OnInit

OnInit triggers when the rule is first loaded, not when a field changes. It is used to set initial values on page load, but it will not react to subsequent changes in Company or Business Unit. Therefore, it cannot dynamically update Employee Class based on user selections, making it unsuitable for this scenario.

A
OnSave
Why it fails: OnSave triggers after the user saves the record, so it cannot set a default value before the user sees the form. It is used for validation or post-save actions, not for dynamic defaulting. In this scenario, the requirement is to populate a field based on other selections, which must happen before save, so OnSave is incorrect.
B
OnChange
OnChange triggers when a specified field changes, allowing the rule to set another field's value dynamically. Here, when Company or Business Unit changes, the rule can set Employee Class. This meets the requirement to automatically populate based on selections. OnChange is the correct trigger for dependent defaulting.
C
OnPostSave
Why it fails: OnPostSave triggers after the record is saved, so it cannot set a field value before save. It is used for actions like sending notifications or updating related objects after save. Since the requirement is to populate Employee Class before the user saves, OnPostSave is not appropriate.
D
OnInit
Why it fails: OnInit triggers when the rule is first loaded, not when a field changes. It is used to set initial values on page load, but it will not react to subsequent changes in Company or Business Unit. Therefore, it cannot dynamically update Employee Class based on user selections, making it unsuitable for this scenario.

Question 7hardmultiple choice

An administrator needs to create a business rule that triggers when an employee's 'Job Information' is updated and sends a notification to the HR manager. The rule must only run when the 'Event Reason' is 'Promotion'. Which rule scenario should be used?

Trap 1: Create an onChange rule on the Event Reason field that sends a…

An onChange rule on Event Reason would fire whenever the field changes, regardless of the new value. It would not limit the notification to promotions only unless a condition is added. However, the scenario requires triggering on Job Information update, not just on the field change, so this rule type is not the best fit.

Trap 2: Create an onInit rule on the Job Information portlet that checks…

onInit rules run when the portlet is initialized, which is typically when the page loads, not when the record is saved. They are used for defaulting values and cannot reliably detect an update. Therefore, this rule type does not meet the requirement of triggering on update.

Trap 3: Create a scheduled job that runs daily to check for Job Information…

A scheduled job introduces a delay and does not trigger immediately upon update. It also may send duplicate notifications if not carefully designed. The requirement is for a rule that triggers when Job Information is updated, so a real-time onSave rule is appropriate, not a batch job.

A
Create an onChange rule on the Event Reason field that sends a notification whenever the field changes.
Why it fails: An onChange rule on Event Reason would fire whenever the field changes, regardless of the new value. It would not limit the notification to promotions only unless a condition is added. However, the scenario requires triggering on Job Information update, not just on the field change, so this rule type is not the best fit.
B
Create an onInit rule on the Job Information portlet that checks the Event Reason and sends a notification when the portlet loads.
Why it fails: onInit rules run when the portlet is initialized, which is typically when the page loads, not when the record is saved. They are used for defaulting values and cannot reliably detect an update. Therefore, this rule type does not meet the requirement of triggering on update.
C
Create an onSave rule on the Job Information object with a condition that checks if Event Reason equals 'Promotion' and then triggers a notification.
An onSave rule on Job Information executes when the record is saved. By adding a condition that evaluates the Event Reason field, the rule only proceeds when the event reason is Promotion. This satisfies the requirement to trigger only for promotions and to send the notification.
D
Create a scheduled job that runs daily to check for Job Information records with Event Reason 'Promotion' and sends notifications.
Why it fails: A scheduled job introduces a delay and does not trigger immediately upon update. It also may send duplicate notifications if not carefully designed. The requirement is for a rule that triggers when Job Information is updated, so a real-time onSave rule is appropriate, not a batch job.