How to Assign Training Automatically in Cornerstone Based on Job Changes

Automatically assigning training after a job change in Cornerstone depends on where the job-change data lives. Compare User Groups and Dynamic Learning Assignments using Position, Last Hire Date, or User Custom Fields with an external approach using the CSOD Learning Assignment API.

An employee moves into a new position. They now need role-specific training, perhaps with a deadline tied to the transition.

How do you make Cornerstone assign that training automatically?

The answer depends less on the training itself and more on where the organization represents the job change.

If Cornerstone already contains reliable information that identifies the affected population, the simplest architecture is usually to let Cornerstone use that information to determine who should receive the training. A User Group built from the relevant user data can become the population for a Dynamic Learning Assignment.

If the authoritative job-change event exists outside Cornerstone—and the organization does not want or need to add that information to the Cornerstone user record—the alternative is to let the external system detect the event and create a standard assignment through Cornerstone's Learning Assignment API. Cornerstone explicitly describes external system events as a use case for that API. (Cornerstone Developer Portal)

The important distinction is this:

A person's current job is a state. A job change is an event.

If that distinction is not clear before the automation is built, organizations can end up assigning the right training to the wrong population—or creating an integration much more complicated than the requirement actually needs.

How do you assign training automatically in Cornerstone based on job changes?

There are three practical patterns:

• Cornerstone already contains fields that reliably define the population

  • Likely architecture: User Group → Dynamic Learning Assignment
  • Best fit: Role- or population-based automation

• Cornerstone needs one additional job-change indicator

  • Likely architecture: User Custom Field → User Group → Dynamic Learning Assignment
  • Best fit: When the LMS should own the assignment logic but existing fields are insufficient

• Job-change event remains outside Cornerstone

  • Likely architecture: HR/business system → Learning Assignment API → Cornerstone
  • Best fit: Event-driven assignment without adding the trigger data to Cornerstone

None is universally better.

The correct choice depends on whether the requirement is really "assign this training to everyone currently in this role" or "assign this training when someone transitions into this role."

Those questions sound similar, but they produce different data requirements.

First, define what your organization means by a "job change"

"Job change" can mean several different business events:

• a new position
• promotion
• transfer
• change in department or business unit
• change in location
• movement into a regulated role
• rehire
• change in employment classification

Cornerstone cannot infer the organization's business definition from the phrase "job change." The assignment architecture therefore needs a field, combination of fields, or external event that represents the actual business condition.

For example, Cornerstone's user architecture supports organizational-unit information on employee records, and its APIs explicitly include Position as an OU concept. Cornerstone employee records can also contain user custom fields. (Cornerstone Developer Portal)

That gives organizations several possible building blocks, but the existence of a field does not automatically make it the correct trigger.

Last Hire Date is not a general job-change date

This is an important example.

Cornerstone exposes Last Hire Date on the employee record, but Cornerstone's reporting documentation defines User Last Hire Date as the user's last hire date after the user was re-hired. (CSOD Media)

That makes Last Hire Date potentially useful for rehire-related training.

It should not, however, be treated as a generic date for promotions, transfers, or position changes unless the organization's own upstream data process has deliberately created some different business convention around it.

If the actual requirement is:

Assign this curriculum when somebody is rehired.

Last Hire Date may be relevant.

If the requirement is:

Assign this curriculum when somebody moves from Analyst to Manager.

You need information that represents that transition.

That may simply be Position, or it may require additional data.

Option 1: Use Cornerstone data, a User Group, and a Dynamic Learning Assignment

When the information needed to identify the learners already exists in Cornerstone, keeping the automation inside Cornerstone is usually the lowest-complexity approach.

A simplified architecture is:

HR / employee data feed
        ↓
Cornerstone user record
        ↓
Position / OU / user field
        ↓
User Group
        ↓
Dynamic Learning Assignment
        ↓
Learner transcript

Lernevate has previously described a related pattern for assigning Cornerstone learning based on business data using Edge and User Groups.

Cornerstone's reporting architecture also distinguishes between Standard and Dynamic assignments. Its technical documentation shows that Dynamic assignments have a processing frequency used to check for users meeting the assignment's user criteria. (CSOD Media)

That makes a Dynamic Learning Assignment a natural fit when the required population can be expressed using data Cornerstone already knows.

When Position may be enough

Suppose every employee in Position = Regional Manager must receive a management curriculum.

If the business requirement is simply that people in that position should receive the learning, Position may provide the necessary population definition.

The architecture stays relatively simple:

Position = Regional Manager
        ↓
User Group
        ↓
Dynamic Learning Assignment

The important governance question then becomes whether Position in Cornerstone is sufficiently reliable and timely to drive a required learning process.

If the HR feed updates the wrong Position, the assignment logic can be perfectly configured and still produce the wrong result.

Automation does not eliminate the dependency on upstream data quality.

Where Position alone stops being enough

Now change the requirement:

Assign transition training only when someone becomes a Regional Manager.

Position tells Cornerstone the person's current state. By itself, it does not necessarily tell the automation when that state began or what the person's prior position was.

That distinction can matter when organizations need to answer questions such as:

• Is the training required for existing managers or only newly promoted managers?
• Should somebody receive it again if they leave the role and later return?
• Is the due date based on the effective date of the transition?
• How would an auditor determine why an assignment was created?
• What happens when HR corrects a Position value after the effective date?

If those questions matter, the population may need more than Position = Regional Manager.

Option 2: Add a User Custom Field that represents the business event

Sometimes Cornerstone contains almost everything needed for the automation, but it is missing the one field that distinguishes being in a role from having just moved into the role.

In that case, a User Custom Field can provide the missing signal.

Cornerstone's Employee APIs explicitly support custom field ID/value pairs on employee records and expose custom-field metadata. (Cornerstone Developer Portal)

A possible architecture might therefore be:

HRIS
  ↓
Position
Job Change Effective Date
or Transition Type
  ↓
Cornerstone user record
  ↓
User Group criteria
  ↓
Dynamic Learning Assignment

The exact custom field is an architectural choice, not a Cornerstone requirement.

Depending on the organization's process, it could represent something like:

Job Change Effective Date

Role Transition Type

Requires Manager Transition Training

or another controlled business value.

The purpose is not to add fields simply because Cornerstone supports them. The purpose is to make the assignment rule represent the actual business requirement.

This can be a strong design when Cornerstone should remain responsible for deciding who receives the training and the HR integration can reliably maintain the required data.

It does create another governed data element, however. Someone must own its definition, population logic, updates, testing, and eventual retirement.

Option 3: Trigger the assignment externally with the CSOD Learning Assignment API

There is another possibility: do not put the job-change trigger into Cornerstone at all.

If the HRIS, integration platform, or another business system already knows that the employee changed jobs, that system can potentially trigger the learning assignment directly.

Cornerstone's Learning Assignment API is designed to create standard learning assignments. Cornerstone specifically describes an example in which an event occurring outside Cornerstone causes another system to POST the users, training, and assignment information to the API. Cornerstone then processes the assignment, and the calling system can check its status using the API. (Cornerstone Developer Portal)

The architecture becomes:

HRIS / business system
        ↓
Job-change event
        ↓
Integration / transformation logic
        ↓
Cornerstone Learning Assignment API
        ↓
Standard Learning Assignment
        ↓
Learner transcript

This is fundamentally different from a Dynamic Learning Assignment.

Cornerstone documents standard Learning Assignment API assignments as processing and assigning training once. (Cornerstone Developer Portal)

That characteristic makes the API particularly relevant when the business requirement itself is event-driven:

The HR system says employee 123 moved into role X. Assign curriculum Y.

The external process detects the event. Cornerstone performs the learning assignment.

What the API does not solve

Using the Learning Assignment API does not eliminate the need to define the business logic.

The integration still needs to know:

• what HR event qualifies
• which Cornerstone user corresponds to the employee
• which training corresponds to the new role
• when the assignment should be submitted
• what to do if the upstream event is corrected
• how integration failures should be monitored
• how the organization prevents unintended duplicate processing
• who owns the mapping between business roles and learning

Those are integration-governance responsibilities rather than features the API can decide for you.

Scale also needs to be considered. Cornerstone currently documents Learning Assignment API throttling of 20 requests per minute and a daily limit of 60,000 user-training assignment combinations. (Cornerstone Developer Portal)

For ordinary job-transition volumes that may never become relevant. For high-volume enterprise automation, it belongs in the architecture review before implementation.

Should job-change data be added to Cornerstone or left in the HR system?

This is usually the real architectural decision.

If Cornerstone already receives the necessary information, building another integration merely to tell Cornerstone something it already knows can create unnecessary technical debt.

Conversely, copying additional HR data into Cornerstone solely to trigger one learning event may create new data-governance responsibilities that provide little value elsewhere.

A useful comparison is:

• Existing Cornerstone field + Dynamic Learning Assignment

  • Advantages: Minimal new integration; assignment logic remains visible to the LMS team.
  • Main concern: Existing field must actually represent the business requirement.

• New Cornerstone User Custom Field + Dynamic Learning Assignment

  • Advantages: Can represent job-change logic more precisely while keeping automation in CSOD.
  • Main concern: Adds another data element that must be governed.

• External Learning Assignment API

  • Advantages: Leaves authoritative event logic in the source system; strong fit for discrete external events.
  • Main concern: Requires integration ownership, monitoring, mappings, and failure handling.

• Hybrid: synchronize a minimal trigger into Cornerstone

  • Advantages: Keeps HR as source while allowing CSOD to execute population logic.
  • Main concern: Both systems participate, so ownership must be explicit.

The deciding question should not be:

Can we technically do this with the API?

It should be:

Where should the logic that determines training eligibility live?

Why automatic job-change assignments become a reporting problem too

Assignment automation eventually becomes reporting data.

When somebody asks why an employee received a required course, the organization should be able to explain the chain:

Business rule
    ↓
Employee data
    ↓
Population / trigger
    ↓
Learning assignment
    ↓
Transcript
    ↓
Compliance reporting

If that chain is unclear, reporting teams often inherit the problem later.

Lernevate's guidance on making Cornerstone report-ready before building more dashboards emphasizes the same principle: assignment logic and underlying data quality need to be trustworthy before downstream reporting can be trusted.

For job-change learning, this matters particularly when the training is mandatory.

A report showing 98% completion is not very useful if the organization cannot confidently explain whether everyone who changed into the regulated role was actually assigned.

The automation design and the compliance-reporting design are therefore connected.

Questions to answer before you build this

Before choosing a Dynamic Learning Assignment or the Learning Assignment API, an L&D leader should be able to get clear answers to these questions:

1. What exact business event creates the training requirement? Is it current Position, entry into a Position, rehire, transfer, location change, or something else?
2. Which system is authoritative for that event? Cornerstone, the HRIS, or another business application?
3. Does Cornerstone already receive enough information to identify the correct learners? If yes, avoid adding an integration without a reason.
4. Do we need current state or event history? Position = Manager and became a Manager on August 15 support different rules.
5. Could the employee leave and later re-enter the population? Decide what training should happen in that scenario before configuring reassignment behavior.
6. What information will explain the assignment later? If the program is audited, the organization should be able to reconstruct the rule and source data that drove it.
7. Who owns failures? For a Cornerstone-native design, that may be Learning Operations. For an API design, HRIS or integration teams may also be involved.
8. How will the population be validated? Compare the learners identified by the automation against the authoritative business population before relying on compliance reporting.
9. Will this pattern expand? One job-change curriculum may be simple. Fifty role-triggered programs can become a role-to-learning rules engine that needs formal ownership and governance.

Those answers usually make the technology choice much easier.

The Lernevate perspective

Use the simplest architecture that preserves the meaning of the business event.

If Cornerstone already contains clean, governed data that defines who needs the training, a User Group and Dynamic Learning Assignment can keep the solution inside the learning platform without unnecessary integration work.

If the missing requirement is a small piece of employee data that Cornerstone should reasonably know, synchronizing a controlled User Custom Field may be cleaner than creating an external assignment service.

If the event fundamentally belongs outside Cornerstone and there is no reason to reproduce the data in the LMS, the Learning Assignment API gives the external system a documented way to trigger a standard learning assignment.

Most importantly, do not confuse current state with change.

A Position can tell you where an employee is now.

A job-change date, transition indicator, or external HR event can tell you that something happened.

That distinction determines whether the automation remains understandable six months later or turns into another assignment process nobody is completely confident changing.

If your team is considering job-change automation in Cornerstone, it is worth defining the trigger, system of record, assignment behavior, and reporting requirement together before choosing the implementation. Lernevate can help evaluate whether the requirement belongs in Cornerstone configuration, the HR data feed, an API integration, or some combination of the three.

FAQs

Can Cornerstone automatically assign training when an employee changes position?

Yes, provided the organization has a reliable way to identify the affected employee. When suitable user information already exists in Cornerstone, a User Group and Dynamic Learning Assignment can be used as the Cornerstone-native pattern. When the event exists only outside Cornerstone, the Learning Assignment API can create a standard assignment from an external trigger. (Cornerstone Developer Portal)

Can I use Position to trigger automatic training in Cornerstone?

Position can be useful when the requirement is based on the employee's current role. Cornerstone's user architecture represents Position as an organizational-unit concept. If the requirement depends specifically on when the employee entered the Position, additional event or date information may be necessary. (Cornerstone Developer Portal)

Should I use Last Hire Date for job-change training?

Only for an appropriate rehire-related requirement. Cornerstone documents Last Hire Date as the user's last hire date after being rehired. It should not be assumed to represent promotions, transfers, or other job changes. (CSOD Media)

When should I use a User Custom Field for job-change automation?

Consider a User Custom Field when Cornerstone should own the learning-assignment logic but its existing employee data does not adequately represent the business condition. Cornerstone employee records support custom field values, so an upstream process can maintain a purpose-designed transition date, status, or other controlled field when appropriate. (Cornerstone Developer Portal)

Does the Cornerstone Learning Assignment API create Dynamic Learning Assignments?

No. Cornerstone documents the Learning Assignment API as creating standard learning assignments, which process and assign training once. Dynamic assignments are a separate assignment type. (Cornerstone Developer Portal)

What if the job-change information exists only in our HRIS?

You do not necessarily have to add it to Cornerstone. Cornerstone explicitly supports a Learning Assignment API use case where an event outside Cornerstone prompts an external system to submit a standard learning assignment. The organization should decide whether keeping the event external or synchronizing a minimal trigger into Cornerstone creates the cleaner long-term operating model. (Cornerstone Developer Portal)