This article has been written assuming the reader has fair amount of HCM knowledge about Pay ranges. I will not focus on Pay range as an object but will talk more about scenarios around it in SuccessFactors (SF) Employee central (EC). I realized that some information related to this topic is available in bits and pieces at various places, so I planned to write one with detailed insights for the community.

Organizations pay different compensation amounts to employees within same job grade or same job function, hence they establish a range based on market pay rates and set up minimum pay, mid-point pay and the maximum pay for each pay range. Depending upon various factors including employee performance, employee experience etc. the employee compensation is adjusted within the pay range.

SF has inbuilt functions to derive the Pay range depending upon the pay range object configuration in the system. It is very important to understand how Pay range is derived in SF EC so that you follow the correct config steps and then standard functions can do the magic for you. It is suggested to use those functions instead of configuring a custom solution to derive pay range.

As per customer’s requirements and scenarios you can create associations of pay range with other objects ex. Legal Entity, Pay grade etc. Since every client is different, hence the requirements are different too. Some derive pay range based upon the Company, Pay grade and Location.

Some clients have complex requirements where pay range is derived based upon not only these standard attributes but other custom attributes as well. Firstly, you have to configure those custom attributes as MDF and then create associations on pay range object.

For each attribute that is required to derive pay range, you must create an association between it and pay range. Since for association you need an object so for custom attributes you must create a custom MDF before creating the association. Let’s say you have a requirement to derive pay range based on 5 attributes, out of which 2 are custom. So association in corporate data model will look something like this.

For standard functions to derive pay range, you must have all these attributes on Position MDF as well as Job Information object. We will discuss more about this later in this article.

• Let’s talk about deriving pay range on the Position object.

Step 1: If your customer has a requirement to derive pay range based on custom attributes also, then create a custom MDF object for each of them.

Step 2: Configure these attributes on Position object. Make sure the custom attributes are not of type ‘STRING’ but ‘Generic object’ and Valid values source has correct technical name of the custom MDF object.

Step 3: Create a Basic business rule with base object “Position’ and set the Pay range and its attributes using function ‘Get Pay Range by Position’ and ‘Get Pay Range attributes’. Below screenshot can be referred.

Step 4: Assign this business rule on all attributes (including pay range) associated with pay range.

Step 5: Make the visibility of Pay range of Pay range mid, min and max as ‘View’ on the Position object. As you are deriving these values through a business rule, it makes sense to keep these fields as read only.

Step 6: This step is very important if you have configured UI for the position object. In that case you must assign the business rule (from step 3) in the position configuration UI.

Now, you are ready to test it on Position object. You can create a new position and update all the attributes. As business rule is assigned on all the attributes so you may see pay range getting derived before populating all the attributes that are required to derive the pay range. This is because the system looks for a pay range which matches all of the configured objects associated with pay range. If some attributes are optional and blank, then system will derive the pay range accordingly. Hence, it is very important that you configure and sequence these attributes (based on which pay range should be derived) on pay range object correctly. For ex. if pay range is derived based on 4 attributes and only first is populated then pay range will be derived considering only one attribute. Therefore, make sure the attributes are updated correctly on pay range object so that pay range is derived correctly on position.

So basically, if one exact match is found, that is populated in the pay range field. If several matches are found, then the first match will be used by the system.

Therefore, it becomes critical to have correct Pay range data loaded in the system. Further, this testing may take more time if you have many attributes based on which pay range is derived and you have a bulk of pay ranges in the system. In case you don’t have pay range data already loaded, then you have to create at least a couple of pay ranges with different combination of its attributes.

• Let’s talk about deriving pay range on the Compensation information portlet.

You can see the pay range field in compensation information portlet when you click on Compa-ratio or Range penetration, but those values are transient fields. Follow below steps to derive pay range on comp info.

Step 1: If you have a requirement to have pay range field on Comp info for reporting purpose etc. then make sure that data type and properties of attributes based on which pay range is derived are exactly same on Position object and Job information portlet.

Step 2: Secondly, you have to create custom fields for Pay range, min, max and mid values on Compensation information portlet and set the Visibility to ‘View’ i.e., read only.

Step 3: Create an ‘Onsave’ business rule on Job info to derive pay range when attributes that derive pay range are changed/updated on Job Info. For example, refer below screenshot. If your requirement is that location can change on Job Info that should derive pay range on compensation information, then write the rule like this (this is just an example I’m sure you will have more attributes to add in the ‘If’ condition). Make sure as per your requirement you check all those attributes in the If condition. Function to get the pay range is ‘Pay range from Job Information‘

Step 4: Create another ‘Onsave’ business rule on Job Info to derive Pay range fields i.e., Mid, Min and Max. You need separate rule for this because if you update these fields in previous rule then you may get values defaulted from previous pay range instead from the new pay range because pay range is not yet saved in database. Our requirement is to update these fields from new Pay range that is derived from previous rule.