Change Assignment

This topic lists the implementation considerations for Change Assignment process.

You can typically use field value defaulting and validation in these cases.
  • When and Why
    • Default action reason based on action.
    • Default action to Assignment Change for line managers.
  • Assignment
    • Default Regular or Temporary and Full Time or Part Time based on Assignment Category field.
    • Default Full Time or Part Time based on Working Hours. If the Full Time or Part Time value must be enforced, the field can be marked as read-only in the same business rule.
  • Additional Assignment Info
    • Defaulting and validation of Additional Assignment Info segments include single and multi-rows contexts.
    • Default Additional Assignment Info segment date with action date from When and Why.
    • Default fields in Additional Assignment Info segments based on values selected in When and Why or Assignment sections, or both.
    • Validate Additional Assignment Info data against existing data in the same single row EFF context.

This table lists the supported regions, attributes, exceptions, and the implementation recommendations for the Change Assignment process.

In the Conditions to Default and Validate Field Values To Default Field Values To Validate Field Values Implementation Guidelines

Reference Objects supported in conditions

  • employmentWorkers (If validation or defaulting involves data from multiple work relationships of the worker, then use this object. You can access one or all assignments from each of the work relationships within this object. All data returned by this object is retrieved directly from the database, reflecting the existing data rather than any modifications made in the current transaction.)
  • employmentWorkerWorkRelationships (If validation or defaulting involves data from multiple assignments of the selected work relationship of the worker, then use this object. You can access one or all assignments of the selected work relationship within this object. All data returned by this object is retrieved directly from the database, reflecting the existing data rather than any modifications made by the user in the current transaction.)
  • employmentWorkerAssignments (This object contains data of the selected assignment from database. This will be useful while defining defaulting or validation rules within When and Why section.All data returned by this object is retrieved directly from the database, reflecting the existing data rather than any modifications made in the current transaction.)
  • JobLov - For the selected values on the Assignment section
    • Job DFF
  • LocationLov
    • LocationsDFF - For the selected values on the Assignment section
  • GradeLaddersLov
  • GradeLov - For the selected values on the Assignment section
    • Grade DFF
  • DepartmentLov - For the selected values on the Assignment section
    • Department DFF
  • PositionLov
    • Position Valid grades
    • Position DFF - For the selected values on the Assignment section
  • Action
    • Action DFF - For the selected values on the Assignment section
  • Action Reason - For the selected values on the Assignment section
    • Action Reason DFF
  • personsLov
    • personProfile - For the selected values on the Assignment section
      • CertificationItems - For the selected values on the Assignment section
  • selfEmploymentDetail (This object contains the primary assignment information of the logged-in user.)
  • Assignment EFF

Sections that support Defaulting from BR

  • When and why (employmentWhenAndWhy)
  • Assignment (employmentAssignments)
  • Additional Assignment Info (PerAssignmentEITCategory)

Fields in When and why section that support defaulting

  • Correction Action Id
  • Correction Action Reason Id
  • Effective date
  • Business Unit
  • Position

Sections that support Validation from BR

  • When and why (employmentWhenAndWhy)
  • Assignment (employmentAssignments)
  • Additional Assignment Info (PerAssignmentEITCategory)
  • Not supported

Fields in When and why that aren’t supported in the conditions

  • ManageDirectsActionCode
  • ManageDirectsActionReasonCode
  • ManageDirectsActionTypeCode

Fields in When and why section that don't support defaulting

  • ManageDirectsActionReasonId
  • ManageDirectsActionId

Fields in Assignment section that don’t support defaulting

  • Default Expense account
  • People Group
  • Flags like Primary assignment flag, Primary work relationship and Primary flag
  • Business Unit and Position as they are taken from When and why
  • Assignment Notes
  • Assignment Type
  • Standard working hours and frequency
  • Synchronize from position Flag

Considerations for Implementing Change Assignment

  • The Effective Date of the transaction in the When and why section must be defaulted only once, when the user first enters the section. You need to ensure that the condition employmentWhenAndWhy.ActionDate == null is added accordingly.
  • Use employmentWhenAndWhy.ActionDate != null as the primary condition for defaulting and validation rules in the When and why section (excluding Effective Date Defaulting).
  • For rules involving Assignment attributes, use the following expression as the primary condition:
    • $fields.employmentAssignments.AssignmentId != null. This will help prevent the rule from being executed in previous sections like When and why.
  • When defaulting using the value property, if the corresponding attribute list of values (LoV) doesn’t respond, you need to set the default value using the actual value (for example, Action Id, Action Reason Id, Position Id, Business Unit Id).
  • A field-level warning message can’t be displayed on a read-only field.
  • Defaulting isn’t supported upon entering the When and why and Assignment sections for Correct Employment Details and Edit Pending Worker flows.
  • Defining rules using User Defined Tables isn’t supported.
  • Attribute LoVs don’t function accurately in Design Time if the LoV contains dependent attributes or country tags, in the case of lookup LoVs.
  • The null check with initialNumberValue isn’t working.
  • Any defaulting or validation of the transaction dates based on Payroll periods can't be done in 25B, it will be supported in a later release.
  • Weekly Working Hours section doesn’t support defaulting and validations in BR.
  • Field-level message support isn’t available within the extensible flexfield (EFF) fragment.
  • These considerations are specific to employment update flows and may not apply to other flows.