Position signals

Position status updates fill gaps in tracking the progression of SEEK candidates through the recruitment process. Feeding these back to SEEK helps to improve our search & recommendation capabilities, and ultimately match candidates with the optimal positions on offer.If a hirer does not move a SEEK candidate to a final application status, SEEK may fall back to the final position status to infer why they were not placed (e.g. because the position was withdrawn, because a different candidate was more suitable, or some other reason). This is accomplished without requiring your software to reveal specifics about candidates that did not use SEEK to apply for the position.Signal capture is only required if the position has been advertised on SEEK.
SEEK hirer
Advertised on SEEK
Send position status updates?
Yes
Yes
Yes
No
No
No
Your software may have configurable automation that allows a position status like Closed to move all candidates to a final application status like Talent pool. In this scenario, send the position status update and the automated application status updates for candidates that used SEEK to apply for the position. Send the signals in batches for efficiency.

Position status update

In a Selection Signals context and as previously discussed in key concepts, a position is synonymous with an employment opportunity, job order, job requisition, job vacancy, or position opening. Position status updates reflect changes at this conceptual level, not changes to individual job ads.
Pass the positionProfileIds of the SEEK job ads that correspond to the relevant position as correlating identifiers.An array is accepted as the position may have been advertised on SEEK more than once. These identifiers are available in either:
MutationVariables
{
  "input": {
    "typeCode": "PositionStatusUpdate",

    // The identifiers to correlate the signal back to the SEEK job ads.
    "positionProfileIds": "seekAnzPublicTest:positionProfile:jobAd:27cuZeA47",

    "current": {
      // Omit `phase` if your software does not support hierarchies.
      "phase": {
        "label": "Closed",
        "index": 4,
        "total": 4
      },
      "status": {
        "label": "Withdrawn",
        "index": 6,
        "total": 6
      },
      // Whether placement(s) were made for the position.
      // Set to `null` for non-final statuses like `Review`.
      "success": false,
      "timestamp": "2020-01-02T00:00:00.000Z"
    },
    // Omit `previous` if your software does not track prior states.
    "previous": {
      "phase": {
        "label": "Open",
        "index": 3,
        "total": 4
      },
      "status": {
        "label": "Review",
        "index": 4,
        "total": 6
      },
      "success": null,
      "timestamp": "2020-01-01T00:00:00.000Z"
    }
  }
}