6.3 Packages, Grades & Grade Profiles

6.3 Packages, Grades & Grade Profiles

Quick Summary: Build compensation packages as assignable bundles of grades and plans. Build compensation grades as pay-range guidelines, then add multiple grade profiles when different populations need different ranges under the same grade. Together with eligibility, this configuration drives clean defaults on Hire and Change Job (tasks T23–T24).

Section 6.1 named the objects; section 6.2 explained eligibility and defaulting. This section focuses on creating and configuring the two guideline containers that appear on almost every compensation design diagram: packages and grades with grade profiles.

Creating a Compensation Package

What you are building

A package is the set you want a population to receive: which grade guidance applies, which plans are in scope, and (via eligibility) who gets the set by default. Creating a package is setup work performed by compensation administrators—not a manager self-service action.

Conceptual create steps

1. Create Compensation Package (task naming may vary slightly by tenant menu, but the object is Package).
2. Provide a clear name and description (for example, "US Salaried Corporate Package").
3. Associate the compensation grade (or grades, per design) that supply pay guidelines for the package population.
4. Associate plans that belong in the set (salary plan, allowance plan, bonus plan eligibility, and so on).
5. Assign eligibility rules so the correct workers default into this package—and only this package.
6. Confirm default grade / grade profile / plans associations that defaulting will use on transactions.
7. Test with a sample Hire in a non-production tenant.

Configuration scenario: GlobalTech creates "US Hourly Retail Package" containing the Retail Hourly grade, US store grade profiles, an hourly plan, and a small shift allowance plan. Eligibility: Company = US Retail, Time Type includes part-time and full-time hourly, Job Family Group = Store Operations. Salaried corporate hires do not match and never default into retail hourly plans.

Package vs plan vs grade (quick contrast)

Exam trap: Creating a package does not by itself pay anyone. Workers receive compensation through events (Hire Propose Compensation, Request Compensation Change, and similar) that apply package defaults and plan amounts.

Compensation Grades: Structure and Purpose

A compensation grade is a named pay band. Typical attributes include:

• Grade name / code aligned to job architecture (for example G8, P3, M2).
• Minimum, midpoint, maximum amounts (and currency context as configured).
• Optional steps or additional structure depending on tenant design.
• Association to job profiles so roles advertise expected bands.
• Eligibility so only appropriate populations use the grade.

Why grades matter on the exam

• They validate and guide proposed base pay during staffing compensation steps.
• They support equity and market conversations (compa-ratio relative to midpoint).
• They connect job catalog (job profile) to pay architecture.

Realistic numbers example: Grade P3 has minimum 80,000, midpoint 100,000, maximum 120,000. A hire proposed at 95,000 is slightly below midpoint—allowed, and the grade still frames the decision. A proposal at 150,000 is above maximum and should trigger review or warning behavior per tenant policy.

Configuring a Grade with Multiple Grade Profiles

Task T24 explicitly expects you to configure a compensation grade with multiple grade profiles. A grade profile localizes or segments the grade:

Why multiple profiles

Global and multi-market employers rarely pay the same nominal range in every city or country. Rather than inventing dozens of unrelated grade names, they keep one grade (for example P3) and create profiles:

Each profile can carry its own range amounts and currency context while remaining under the same grade identity for reporting and job architecture.

Conceptual configuration steps

1. Create or open the compensation grade.
2. Add grade profile entries for each localization or segment needed.
3. Enter min / mid / max (and related attributes) per profile.
4. Attach eligibility rules (or target profile patterns) so workers in London get the London profile, not the US National profile.
5. Ensure the package defaulting path can select the correct profile for the worker's location or other criteria.
6. Validate on Hire for workers in each location: correct profile defaults; range checks use the profile amounts.

Grade P3
├── Profile: US - National     (USD 80k / 100k / 120k)
├── Profile: US - High Cost    (USD 95k / 120k / 145k)
└── Profile: UK - London       (GBP 55k / 70k / 85k)

Eligibility and "first match" thinking

Eligibility for grade profiles must be specific enough that a San Francisco worker does not accidentally default to National when High Cost is intended. Overlapping profile eligibility is a classic production defect. Design rules so each worker matches one intended profile; where multiple plan profiles exist, remember that the first matching profile can default into the transaction—order and specificity matter in design and testing.

Linking Packages, Grades, Profiles, and Jobs

A coherent architecture usually looks like this:

1. Job profiles point to expected grades (role architecture).
2. Grades contain profiles for market differentiation.
3. Packages include the grades and the plans for a pay program.
4. Eligibility rules bind populations to package + grade + profile + plans.
5. Hire / Change Job Propose Compensation defaults the set and lets users set plan amounts within guidance.

Configuration scenario: Job Profile "Software Engineer III" references Grade P3. Package "US Salaried Engineering" includes Grade P3 and the US salary plan. Grade P3 has National and High Cost profiles. A hire in Austin matches National; a hire in San Francisco matches High Cost. Both remain Grade P3 for talent framework reporting, but their range checks differ.

Exam Scenarios

Scenario A — Create package. Stem asks what you associate when creating a package. Prefer grades and plans plus eligibility—not security groups only, not report definitions.

Scenario B — Multiple profiles. Stem: "How do you support different pay ranges for the same grade in two cities?" Answer: configure multiple grade profiles under the grade with location-based eligibility—not create two unrelated job families solely for pay, and not edit Supervisory Organization subtypes.

Scenario C — Wrong range applied. A London hire validates against USD National numbers. Diagnosis: grade profile eligibility/defaulting failed; package/grade may be correct but profile selection is wrong.

Build Checklist (T23–T24)

• Package named for population and pay basis
• Default grade associated to package
• Required plans listed on package
• Package eligibility exclusive enough for defaulting
• Grade min/mid/max defined
• Multiple grade profiles created where markets differ
• Profile eligibility tested per location/segment
• Job profile ↔ grade alignment reviewed
• Sample Hire defaults package + correct profile + plans

If you can create a package and a multi-profile grade and explain how eligibility selects among profiles, you have the configuration depth HCM Core expects for packages and grades.