Skip to main content

SyncAllToHrWorksInput

Which residential park to synchronise with HR WORKS, which parts of it to run, and over what period.

input SyncAllToHrWorksInput {
  from: Date
  modules: [HrWorksSyncModule!]
  residentialParkId: ResidentialParkID!
  to: Date
}

Fields​

SyncAllToHrWorksInput.from ● Date scalar​

First day to reconcile, inclusive. Omit to let each module reach back as far as it is configured to, which is what every run without a period does.

Applies to absences and working times only. Working schedules and employee master data are reconciled in full every run and have no period to limit.

Running WORKING_TIMES over more than 31 days, or over more than two calendar months, fails the whole request: HR WORKS reads no more than that in one go. Absences have no such limit — ask for the longer period without the working times, and reconcile those a month at a time.

SyncAllToHrWorksInput.modules ● [HrWorksSyncModule!] list enum​

The modules to run, or omitted to run all of them.

Given several, they always run in dependency order regardless of the order listed, since employees have to exist before absences can be recorded against them.

SyncAllToHrWorksInput.residentialParkId ● ResidentialParkID! non-null scalar​

The residential park to synchronise.

Required, and the run is confined to it: people are imported only from the organisation unit this park is linked to, and only records belonging to this park's employees are reconciled — including the withdrawal of absences cancelled in HR WORKS, which is the one thing this synchronisation deletes.

Fails when the park is not linked to an organisation unit.

SyncAllToHrWorksInput.to ● Date scalar​

Last day to reconcile, inclusive. Omit to let each module reach forward as far as it is configured to, which is what every run without a period does.

Member Of​

syncAllToHrWorks mutation