Match Custom Filters

Match Custom Filters

It is possible to filter custom values imported as part of the resumes through Match. To do so, a field and corresponding filter must first be defined in Talemetry.

Custom Field and Filter

A custom field is defined by its name, HRXML node, and value type/values. It encapsulates the metadata that defines the operands when the filter is applied.

A custom filter is defined by its name and the custom field to use, and is what is visible through Match. Through a filter, one may also define default values to be applied.

Filter Operation

The custom field HRXML node defines the location within the HRXML UserArea where value comparison would be performed against. This is essentially the source operand.

The custom field value type describes if the field can accept free-form string value, or a predefined list of values. In case of LOV, each entry is defined by a display value and an actual value for comparison. The value is the target operand.

When a filter is applied, value comparison is done a normalized string match, which performs case insensitive comparison, ignoring any non-alphanumeric character (such as -, _, space).

Multiple values may be specified for a filter, in which case these comparison are OR'ed together. Multiple filters may be defined, in which case these filters are AND'ed together.

Creating Custom Field

The custom field is generally created through Talemetry UI, not API. The HRXML node and value types can only be specified upon creation through the UI in the current release (2012 Q2).

It is possible to create or overwrite a List type custom field through the Match List API (see SOAP API). Note the HRXML node cannot be defined/updated through the API.

Deleting Custom Field

Deleting a custom field only really archives its list of values, if any. The field is not actually deleted.

Match List API

Please see SOAP API for more information. The API currently accepts multiple display values for different locales, but it is indeed not implemented within Talemetry. Only the first display value specified would be relevant, regardless of its locale.

List specified through the List API would either create a new list if it does not already exist, or overwrite entirely an existing list. It does not perform incremental update. Any existing value missing from a call to the List API would be archived. Note while the display value could be changed, the actual value cannot be changed. Changing it means archiving the old value and creating a new one.

It is not possible to have 2 entries with the same actual value, though duplicates in display values are possible - resulting in UI duplicates.

HRXML UserArea

The source operand to be filtered are indexed from the HRXML UserArea:

<?xml version="1.0" encoding="UTF-8"?>
<Candidate xmlns="http://ns.hr-xml.org/2007-04-15" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:rm="http://resumemirror.com" xsi:schemaLocation="http://ns.hr-xml.org/2007-04-15 Candidate.xsd">
    <CandidateRecordInfo>
        <Id>
            <IdValue name="Applid">SOME_REMOTE_ID</IdValue>
        </Id>
    </CandidateRecordInfo>
    <RelatedPositionPostings/>
    <Resume>
        <StructuredXMLResume>
            ...
        </StructuredXMLResume>
        <NonXMLResume>
            ...
        </NonXMLResume>
    </Resume>
    <UserArea>
        <rm:SomeNode1>SomeValue1</rm:SomeNode1>
        <rm:SomeNode2>SomeValue2</rm:SomeNode2>
    </UserArea>
</Candidate>

The HRXML namespace must be exactly as above, such that the HRXML would be accepted by Match. However, the rm namespace would be stripped off by Match during scraping (in some example, it is rm, some it is rms. It does not really matter as long as it matches the namespace defined in the XML so the XML is valid).

HRXML Scraping

The entire HRXML UserArea would be scraped and indexed, such that custom filter could later be applied. There are different ways the custom field data is scraped, depending on the node name in the HRXML. The following nodes are specially handled (as of 2012Q2):

RelatedPositionPostings, Citizenships, Referrals, Qualifications, Screenings, Attachments, TestData, Comments, JobFamily, Lists, SUIT.

The writer of this document has no idea how many of these are intended to be used... So he will describe only a few.

Generic Field

Any node whose name is not one of those specified in above will be processed as follow:

  <UserArea>
      <rm:SomeNode1>SomeValue1</rm:SomeNode1>
      <rm:SomeNode2>SomeValue2</rm:SomeNode2>
  </UserArea>
  • The node name would correspond to the HRXML Node entry when defining the custom field.
  • Only one value per unique node name extracted. Latter occurrence overwrites previous values.

RelatedPositionPosting

  <UserArea>
      <rm:RelatedPositionPostings>
          <rm:NODENAME>
              <rm:Id>TST_AAAA_202</rm:Id>
              <rm:Disposition>
                  <rm:StatusCode>ZZZZ_202</rm:StatusCode>
              </rm:Disposition>
          </rm:NODENAME>
          <rm:NODENAME>
              <rm:Id>TST_AAAA_203</rm:Id>
              <rm:Disposition>
                  <rm:StatusCode>ZZZZ_203</rm:StatusCode>
              </rm:Disposition>
          </rm:NODENAME>
      </rm:RelatedPositionPostings>
  </UserArea>
  • The format must be exactly as above, with the parent node named "RelatedPositionPostings". Multiple child nodes may appear within.
  • Within each child node, only the node "Id" and the node "Disposition/StatusCode" would be extracted. Nodes with other names would be ignored. This is CASE SENSITIVE.
  • Within each child node, the first occurrence of "Id" and "Disposition/StatusCode" would be extracted. Subsequence occurrences would be ignored.
  • Within each child node, both "Id" and "Disposition/StatusCode" must be present, or the child node would not be extracted.
  • The "Id" and "Disposition/StatusCode" correspond to the HRXML Node entry "RelatedPositionPostings:ID" and "RelatedPositionPostings:StatusCode" respectively. Custom field with these nodes should already be created by default.
  • When there are multiple child nodes, matching any one of the values is considered a match.

Citizenships

  <UserArea>
      <rm:Citizenships>
          <rm:NODENAME>
              <rm:countryCode>HKG</rm:countryCode>
              <rm:CitizenshipCode>2</rm:CitizenshipCode>
          </rm:NODENAME>
          <rm:NODENAME>
              <rm:countryCode>GBR</rm:countryCode>
              <rm:CitizenshipCode>2</rm:CitizenshipCode>
          </rm:NODENAME>
      </rm:Citizenships>
  </UserArea>
  • The format must be exactly as above, with the parent node named "Citizenships". Multiple child nodes may appear within.
  • Within each child node, only the node "countryCode" and the node "CitizenshipCode" would be extracted. Nodes with other names would be ignored. This is CASE SENSITIVE.
  • Within each child node, the last occurrence of "countryCode" and "CitizenshipCode" would be extracted. Earlier occurrences would be overwritten.
  • Within each child node, both "countryCode" and "CitizenshipCode" must be present, or the child node would not be extracted.
  • The value of "countryCode" and "CitizenshipCode" would be combined. For example, it would be HKG2 and GBR2 in the above example. This correspond to custom field HRXML Node entry "Citizenship" (NOTE, no trailing "s").
  • When there are multiple child nodes, matching any one of the combined values is considered a match.

List Struct Field (Referrals, Qualifications, Screenings, Attachments, TestData, Comments)

  <UserArea>
      <rm:ANYFIELDABOVE>
          <rm:NODENAME>
              <rm:Value1>1</rm:Value1>
              <rm:Value2>2</rm:Value2>
          </rm:NODENAME>
          <rm:NODENAME>
              <rm:Value1>3</rm:Value1>
              <rm:Value2>4</rm:Value2>
          </rm:NODENAME>
      </rm:ANYFIELDABOVE>
  </UserArea>
  • The format must be exactly as above, with the parent node named per one of the fields (Referrals, Qualifications, etc). Multiple child nodes may appear within.
  • Within each child node, any node would be extracted.
  • Within each child node, the last occurrence of each unique node would be extracted. Earlier occurrences would be overwritten.
  • Each of the value node would correspond to a custom field with HRXML Node entry as ANYFIELDABOVE:Value1, per the example above.
  • When applying the filter, matching any one of the value is considered a match.

List and Struct Field (JobFamily, Lists, SUIT)

  <UserArea>
      <rm:ANYFIELDABOVE>
          <rm:Value1>1</rm:Value1>
          <rm:Value2>2</rm:Value2>
      </rm:ANYFIELDABOVE>
  </UserArea>
  • The format must be exactly as above, with the parent node named per one of the fields (JobFamily, Lists, etc). Multiple value nodes may appear within.
  • The last occurrence of a unique value node would be extracted. Earlier occurrences would be overwritten.
  • Each of the value node would correspond to a custom field with HRXML Node entry as ANYFIELDABOVE:Value1, per the example above.
  • When applying the filter, matching any one of the value is considered a match.

Feedback and Knowledge Base