Where the job profile and the compensation go in Change_Job_Request

A Staffing Change_Job request can change a worker's job profile and their compensation in the same event. The job profile goes in Change_Job_Data > Change_Job_Detail_Data > Job_Details_Data > Job_Profile_Reference. The compensation goes in Change_Job_Data > Propose_Compensation_Sub_Process, which runs the Propose Compensation subprocess of the Change Job business process with the values you send.

The part that decides whether it works is not in the XML. Workday's Change Job guide says that when you populate a subprocess in the request, the Change Job business process definition must have that step. Workday warns that when the definition and the request are out of line, the information may not load, or the event can stay In Progress after the web service call has returned. A definition with no Propose Compensation step, or a condition rule that skips it for this kind of change, is exactly that mismatch.

The request

A trimmed request, checked element by element against the Staffing service's v45.1 schema. The IDs are placeholders.

<bsvc:Change_Job_Request bsvc:version="v45.1" xmlns:bsvc="urn:com.workday/bsvc">
  <bsvc:Business_Process_Parameters>
    <bsvc:Auto_Complete>false</bsvc:Auto_Complete>
    <bsvc:Run_Now>true</bsvc:Run_Now>
  </bsvc:Business_Process_Parameters>
  <bsvc:Change_Job_Data>
    <bsvc:Worker_Reference>
      <bsvc:ID bsvc:type="Employee_ID">21001</bsvc:ID>
    </bsvc:Worker_Reference>
    <bsvc:Effective_Date>2026-12-01</bsvc:Effective_Date>
    <bsvc:Change_Job_Detail_Data>
      <bsvc:Reason_Reference>
        <bsvc:ID bsvc:type="Change_Job_Subcategory_ID">Promotion_Promotion</bsvc:ID>
      </bsvc:Reason_Reference>
      <bsvc:Job_Details_Data>
        <!-- the new job profile -->
        <bsvc:Job_Profile_Reference>
          <bsvc:ID bsvc:type="Job_Profile_ID">Senior_Accountant</bsvc:ID>
        </bsvc:Job_Profile_Reference>
      </bsvc:Job_Details_Data>
    </bsvc:Change_Job_Detail_Data>
    <!-- the new compensation, as the Propose Compensation subprocess -->
    <bsvc:Propose_Compensation_Sub_Process>
      <bsvc:Business_Sub_Process_Parameters>
        <bsvc:Auto_Complete>false</bsvc:Auto_Complete>
      </bsvc:Business_Sub_Process_Parameters>
      <bsvc:Propose_Compensation_for_Position_Data>
        <bsvc:Compensation_Guidelines_Data>
          <bsvc:Compensation_Package_Reference>
            <bsvc:ID bsvc:type="Compensation_Package_ID">Package_Finance</bsvc:ID>
          </bsvc:Compensation_Package_Reference>
          <bsvc:Compensation_Grade_Reference>
            <bsvc:ID bsvc:type="Compensation_Grade_ID">Grade_P3</bsvc:ID>
          </bsvc:Compensation_Grade_Reference>
        </bsvc:Compensation_Guidelines_Data>
        <bsvc:Pay_Plan_Data bsvc:Replace="false">
          <bsvc:Pay_Plan_Sub_Data>
            <bsvc:Pay_Plan_Reference>
              <bsvc:ID bsvc:type="Compensation_Plan_ID">Salary_Plan</bsvc:ID>
            </bsvc:Pay_Plan_Reference>
            <bsvc:Amount>82000</bsvc:Amount>
            <bsvc:Currency_Reference>
              <bsvc:ID bsvc:type="Currency_ID">USD</bsvc:ID>
            </bsvc:Currency_Reference>
            <bsvc:Frequency_Reference>
              <bsvc:ID bsvc:type="Frequency_ID">Annual</bsvc:ID>
            </bsvc:Frequency_Reference>
          </bsvc:Pay_Plan_Sub_Data>
        </bsvc:Pay_Plan_Data>
      </bsvc:Propose_Compensation_for_Position_Data>
    </bsvc:Propose_Compensation_Sub_Process>
  </bsvc:Change_Job_Data>
</bsvc:Change_Job_Request>

Get the reference ID values from the tenant rather than guessing them. Workday's Change Job guide recommends two ways: run the Integration IDs report and search for the business object (for example Change Job Subcategory for the reason), or make the same change by hand once in the UI and read the reference IDs from the related actions of that event. The second also shows you which fields the business process actually asks for.

What each compensation element does

Compensation_Guidelines_Data sets the package, grade, grade profile and step. The schema marks the grade as required whenever you send a package.

Pay_Plan_Data holds salary or hourly plan assignments. Per plan, Amount is required if the plan has no default amount, its decimal places must match the currency, and it cannot be combined with a percent. Frequency_Reference is required if the plan has no default frequency. The Replace attribute on Pay_Plan_Data decides what happens to the worker's other plans: false (the default) adds or updates the plans you send and leaves the rest, true replaces the worker's existing plans with the ones in the request. The other plan types (Allowance_Plan_Data, Bonus_Plan_Data, Merit_Plan_Data, Commission_Plan_Data and so on) follow the same pattern.

Initialize_Using_Defaulting_Logic, if true, asks Workday to fill compensation from the position's default compensation or, failing that, eligibility rules. Two documented catches: Workday does not populate values when the worker is eligible for more than one package, grade, grade profile or plan type, and with defaulting on, the plan-level Replace attribute does not apply. With it false, Workday says the resulting compensation is carried forward as is from the source position. When you are setting an explicit new salary, as above, leave it out.

Auto_Complete, Skip and the business process definition

There are two sets of processing options, and they do different jobs.

Business_Process_Parameters at the top applies to the Change Job event. Auto_Complete set to true processes the whole event automatically: Workday approves every approval, bypasses reviews and to-dos, and suppresses notifications. Left out or false, the event is initiated as if it were submitted online, with approvals, reviews, notifications and to-dos in place. Run_Now makes the transaction finish processing before the response is returned.

Business_Sub_Process_Parameters inside Propose_Compensation_Sub_Process applies to the compensation subprocess only. It has its own Auto_Complete, plus Skip, which skips the subprocess if the definition marks it skippable. The schema documentation for that wrapper adds the detail behind many half-finished loads: if Workday finds errors while processing the subprocess, it sets that subprocess's Auto Complete to false and leaves it for manual processing. The event then sits In Progress with the Propose Compensation step waiting for someone.

Line the request up with the definition before you load:

  • If the definition has a Propose Compensation step, send Propose_Compensation_Sub_Process with valid data.
  • If it has the step but you are not changing pay in this request, make the step optional or skippable and send the subprocess with Skip set to true, which is the same alignment Workday recommends for Assign Pay Group.
  • If a condition rule decides whether the step runs, check that it evaluates true for this change, because a skipped step drops whatever compensation you sent.

When the initiator is an integration system user, Workday ignores the validations configured on the initiation step. If you need them enforced on a web service load, Discard_On_Exit_Validation_Error makes critical validation conditions block the step, and Workday then creates no event.

Security for the web service

Workday's guide lists the error "Processing error occurred. The task submitted isn't authorized." for a security gap. Change Job (Web Service) is secured by the Change Job business process policy: the account needs the initiating action Change Job (Web Service), unconstrained or with access to the worker's organizations. Run View Security for Securable Item on Change Job (Web Service) to see the policy, and activate pending security policy changes after editing it.

Read the result back

A successful response returns Event_Reference, the ID of the Change Job event, and any Exceptions_Response_Data. That proves an event was created, not that the change is complete. Workday's guide lists two quiet failures: the call succeeds but the event is still in progress, and the call succeeds but some changes are missing because condition rules skipped steps.

So check three things for a test worker:

  1. Open the event from Event_Reference and read its process history. Every step should be complete, including Propose Compensation, or awaiting the approvers you expect.
  2. On the worker, confirm the job profile as of the effective date.
  3. Confirm the compensation as of the effective date: the plan, amount, currency, frequency and grade you sent.

If a load went wrong, Workday's recovery path is Mass Cancel Business Processes for events still in progress and Mass Rescind Business Processes for completed ones, both needing the Business Process Administrator domain, then a corrected rerun. The Change Job web service cannot correct or delete an event itself. For large volumes, Workday points to the Import Change Job web service and suggests testing both in a sandbox to see which performs better.

If you are on REST instead, the equivalent is several calls on one job change event; Workday's batch protocol sample runs them as one transaction.

Sources checked