Skip to content

updateJob

Deprecated

This endpoint will stop working on 1 August 2027. Migrate to POST /v1/jobs/{jobId}/version in the new API; the migration guide has the recommended order of work and the important model differences.

The new API has no PATCH/PUT endpoint for jobs - all changes go via versioning. Open a new job version with POST /v1/jobs/{jobId}/version, apply your changes, then either submit/approve (POST /v1/jobs/{jobId}/versions/required-approvals/...) or cancel (POST /v1/jobs/{jobId}/version/cancel). Activity diffing (add/update/delete) from the legacy body is handled implicitly by supplying the desired activity set in the version payload.

Open POST /v1/jobs/{jobId}/version in the new API →

View legacy reference

/rest/workflow/job/updateJob

POST
  • Updates a Job.  
  • Can contain multiple job records.  
  • Looks up job by Job Ref if not blank, otherwise by Job Client Ref and Client ID.
  • Updates activities if "activities" field is present:
    • If activityRef exists updates activity.
    • If activityRef does not exist, adds activity.
    • Removes any other activities (limited based on sourceSupplierId)
  • If the supplierSourceId field is populated restricts the deletion of activities to only activities assigned to the specified supplier
  • If the replaceDescription field is populated replaces the current job description with the description supplied.
  • If the appendDescription field is populated appends the description to the job description.
  • If the targeDate field is supplied sets the target date.
  • If the priorityID field is supplied the priority on the job will be set (and the target date calculated based on the priority - if target date has also been supplied this will override the priority based target date).
  • If the damageId field is supplied the damage on the job will be set.
  • If the createVersion field is supplied and set to:
    • 1 - a version will be created.
    • 2 - a version will be created only if the data supplied is different to the current data on the job.
  • If the submitVersion field is supplied and set to 1 the created version will be submitted.  If this is set to 1 but the createVersion was not set to 1 this will be ignored.
  • If jobPlannedStartdate field is populated appends to job_planned_startdate, otherwise, nothing will be done.
  • If jobPlannedEnddate field is populated appends to job_planned_enddate, otherwise, nothing will be done.
  • If jobStartdate field is populated appends to job_startdate, otherwise, nothing will be done.
  • If jobEnddate field is populated appends to job_enddate, otherwise, nothing will be done.
  • If jobCompletedDate field is populated appends to job_completed_date, otherwise, nothing will be done.

acceptable request representations:

  • application/json

{    "jobs" : [        {            "jobRef":"",            "jobClientRef":"abc123",
            "clientId":"23",
            "sourceSupplierId" : "23",

            "activities": [                {                    "libraryActivityCode" : "5647",                    "activityRef" : "act123",                       "supplierId" : "323",                                     "description" : "optional desc",                    "quantity" : "3",                    "completedQuantity": "2"                }            ],
            "replaceDescription":"some text",            "appendDescription":"some text to append",
            "targetDate":"30/09/2012",
            "priorityId":"3",
            "damageId":"9",            "jobPlannedStartdate": "11/07/2011 12:32:17",            "jobPlannedEnddate": "12/07/2011 12:32:17",            "jobStartdate" : "13/07/2011 12:32:17",            "jobEnddate" : "14/07/2011 12:32:17",            "jobCompletedDate" : "15/07/2011 12:32:17"
        }    ],     "createVersion" : "1",    "submitVersion" : "1" }


available response representations:
  • 200 - application/json
{
  "result" : "success or fail",
  "result_msg" : "error message"
}


See the Workflow API matrix for the full list of endpoints in this category.