General Considerations for Salary

Here's a list of constraints that affect when and how you can use salary.

Constraints for Delivered Salary Rules

Constraint	Additional Information
You can assign or set defaults for only the Salary Basis, Salary Amount, and Next Salary Review Date attributes.	You can use the other attributes to query for values or write conditions, but don't update the other attributes.
You mainly use the Salary business object for salary basis of the user determined type.	You can use the Salary business object attributes to validate the other types of salary bases, but not to set defaults. You can default any type of salary basis, but you can default the salary amount only for salary determined by user type.
You can't default or validate values or percentages of incremental and simple salary components.	These components don't have business objects to support defaulting and validation.
You should avoid defaulting the salary amount.	Instead, set a validation rule to ensure that people enter the correct amount.
You can't set default values for any fields during criteria corrections.	The default attributes are set according to criteria, for example, about the assignment or job, the first time you propose the salary. If you go back and change criteria values, then return to the salary section, the salary basis isn't updated. Similarly when you correct an existing salary, none of the salary attributes default again, even though the criteria changed.
You can run object validation only on submit when the salary section is the last section of the compact guided flows.	If there are other sections such as Individual Compensation, then object validation runs when the person clicks the OK button in that section. Starting with release 22A, validation runs on both Continue and Submit.
You can't make the rule consider multiple changes that happen on a single day.	If you make multiple assignment changes in a day that affect the criteria determining the defaulting, the Salary section won't create the business object. It also won't treat the change as new salary because salary records don't support multiple changes in a day.
You can’t make the rule consider criteria changes when salary exists for the day.	When you create an assignment change on the same day that salary starts, and the changes affect the salary defaulting criteria, the salary section won't default. Salary treats the change as a correction.
You can't change values in other sections to fix validation issues in the salary section.	When Salary object rules raise an error, you can fix issues only in the salary section of the Offer and HR flows. You can't go back to previous sections. Only after you select a valid value can you return to previous sections, such as Assignment. If you need to change information in previous sections, then you need to cancel the transaction and start over. For example, the rule validates that the salary basis frequency has to be hourly for a part timer. When you get the error, you can't change the person's assignment to full time. You need to select a salary basis with an hourly frequency for the part timer.
You need to make sure that rules don't contradict or conflict with each other because all rules run simultaneously.	You could face exceptions if they contradict or conflict.
Field validation rules run when you change the value of the particular field and then press Tab or click elsewhere.	Rules won't run for changes made to other fields that affect salary amount, such as adjustment amount percentage, or component values when you use incremental, standard, or advanced components. An object validation, rather than a field validation rule, would be better suited to handle such scenarios.
You should avoid defaulting or validating values coming from the Download Salaries task.	Explicitly exclude these values using the HcmParam CMP_Download_Salary.