Within ROSTERkey:

  • multiple external codes are allowed to map to a single ROSTERkey leave code on inbound data.
  • a single external code cannot map to multiple internal codes for inbound data.
  • multiple ROSTERkey codes are allowed to map to a single external code on outbound data.
  • a single internal code cannot map to multiple external codes for outbound data.
  • ROSTERkey does not allow many-to-many code matching because it has no way to know which to apply without manual intervention.

ROSTERkey implements this by having an external code mapping Direction of "To Rosterkey", "From Rosterkey", or "Both".


However, there is a mechanism where a single external code can potentially map to multiple internal codes for inbound data, using the "Secondary" Direction setting.


There are several constraints when setting "Secondary" as the Direction:

  1. It can be the only External System mapping on that Absence Type.
  2. It cannot be set as a Secondary for that same External Code and External System on another Absence Type.


Processing of requests through the Leave Management API will follow these steps.

  1. If the inbound request matches a ROSTERkey leave record using the request's internal identifier then the inbound data is used to update the ROSTERkey leave record EXCEPT for the Absence Type code.  This allows for multiple codes to be utilised without being overwritten.
  2. If no matching ROSTERkey leave record is found by the internal identifier of the request
    1. A ROSTERkey Absence Type code is determined by looking for matching External Codes with either a "Both" or "To Rosterkey" Direction.  Then, other ROSTERkey leave for the same employee for a similar date range and the determined Absence Type code is checked.
    2. If a matching ROSTERkey leave record is found then it is assumed to match and is updated accordingly.
    3. If NO matching ROSTERkey leave record is found then the a new Absence Type code is determined by looking for a matching External Code with the "Secondary" Direction attribute.  This Absence Type code is then used to try and find a ROSTERkey leave record for the employee with a similar date range.
    4. If a ROSTERkey leave record is now found, then it is updated but its Absence Type code is not changed.
    5. If no ROSTERkey leave record was found with this last check, then the normal failure with no match occurs.


For example, Annual Leave from an external source ("AL_EX") that normally matches to ROSTERkey Annual Leave ("AL") but can sometimes match to ROSTERkey Special Leave ("SPL") would be set up like this:

  1. The ROSTERkey "AL" Absence Type would have an External Code of "AL_EX" and a Direction attribute of "To Rosterkey" (or "Both").
  2. The ROSTERkey Absence Type of "SPL" would also have an External Code of "AL_EX" but have a Direction attribute of "Secondary"

Then, an inbound leave request of "AL_EX" would, after failing to match on internal identifier, first try to find an "AL" record and then, if nothing found, look for an "SPL" ROSTERkey leave record.