Today Matador Jobs 3.8.4 is released to all our users. It primarily introduces new features to support Salary Ranges for users subject to new laws taking effect in the new year, but also includes several minor bug fixes.

Release Notes

While most “hotfix” release posts are often simply lists of changes, this one has a few items that need some detail and editorializing. Let’s dig in.

Salary Range Support

Matador Jobs 3.8.4, while a “hotfix” release that generally should not introduce new features, includes a wide range of support for “Salary Range”, as is required by new laws and regulations taking effect this year (or that have already taken effect). We wrote more about this in our blog post several weeks ago.

While we will list the change log below for the release, a complete how-to for these new features can be found on our new help doc on the topic. As this work was done with limited lead time, we may modify this behavior in the future, especially if we get feedback from users subject to the regulations that we may have missed the mark. Check out the Salary Range help doc page right away!

As a final update to the blog post on the topic, at this time, Bullhorn has not implemented default fields or UI for salary range, so our solution leveraged custom fields at this time. In the future, they may implement default fields for high and low salary ranges, and if so, we will adapt to and support that functionality.

Best Practice: Default to Common Bullhorn Workflows

This release contains a change that we’ve labeled as a bugfix but actually doesn’t fix a bug in our software, rather, prevents a failure when our users are doing something in their Bullhorn data that they shouldn’t.

Put simply, our users consistently surprise us with how easy it is, via the powerful field mappings tools at Bullhorn, to break their Matador import. While we’ve provided feedback to Bullhorn that some of the changes users are able to make shouldn’t be possible, they are.

This release fixes one of those things. It is possible that a user can manually set the value of the isPublic field, aka “Publishing Status” without going through the job publishing routine. The routine does more that just “publish” the job, it also sets the dateLastPublished timestamp, which Matador uses to determine whether to update or pass over an already imported job, as well as various “published” fields like the public job category and contact recruiter.

In the event you expose the isPublic field and manually set it, Matador will now continue to work, but not as intended. While preferred over the previous behavior of Matador not working at all, the best practice is to use the publishing workflow.

In general, for best results with not only Matador Jobs but all Bullhorn Marketplace Partners, consider using as standard of an implementation as you can.

  • Use default named fields instead of custom fields for common data when a default field exists, ie: don’t use customTextBlock1 for “description” when description and publicDescription exist.
  • Do not enable “use multiple values” settings in fields that shouldn’t accept multiple values. We’ve seen this commonly with jobs given multiple titles, which breaks the Matador Jobs importer.
  • Do not modify default workflows to avoid seemingly unnecessary steps, like the Job Publishing step, unless you know first the wider implications of that action.

While we do our best at Matador to make Matador work with all of your many implementations of Bullhorn, other Bullhorn Marketplace Partners may not be able to do this, and as a result, not only will customizations have an impact on Matador’s performance, but also make it so you can’t use other tools.

Best practice is: use as much default behavior as possible and leverage custom fields for custom data.

3.8.4 Changelog

New Features:

  • Support for importing and displaying a Salary or Pay Range. This is in response to upcoming laws and regulations in various jurisdictions that will require hiring agencies that meet certain qualifications to publish “pay ranges” for each position. A full help document will be written to explain how to use this feature, but the cliffs’ notes are:
    • New Settings Section “Salary Options” Under the Job Listings Tab
      • Formerly Job Structured Setting “Show ‘Pay Rate’ Data” was moved and renamed “Display Salary/Pay Rate”. This will now add a Salary Transparency string to the Job Information Bar under the title automatically.
      • New Settings “Salary Range Low Field” and “Salary Range High Field” allow users to select which fields, from a list of two default and 8 custom number fields, to use for the two parts.
    • A formatted text string of constructed salary parts, if available and setting is set to on, will be added to the default Job Info Bar if included in the front-end.
      • If the Job Info Bar is not included, users will need to leverage WordPress templating and/or Matador functions to include it in their layouts.
    • Salary Range or static Salary will be included in Structured Data, if available and setting is set to on.
    • When imported, the following existing or new post meta fields will be made on the job object if supporting data was found on the remote job record:
      • salary_currency: the value of the Bullhorn setting or a custom text field with the salary’s currency
      • salary, salary_low & salary_high: The raw number(s) from the imported data. salary_low can be 0 while salary and salary_high cannot be 0 and will be omitted and not set if 0.
      • salary_formatted, salary_low_formatted, salary_high_formatted: a localized formatted string of text containing the value with currency symbols and number/decimal separators. salary_formatted is formatted value of the Bullhorn salary field, unless it was blank and a high or low value was present, which would be used instead in that order.
      • salaryUnit: The text string that represents the unit, ie: Annually, Per Hour, etc.
      • salary_string: This is a string of text that dynamically combines the pieces we imported into a succinct summary of the salary or salary range, eg: “$100,000 USD per year” or $97,500 – $105,000 USD per year”, etc.
    • The following WordPress filters were added to customize the behavior of the above features:
      • matador_bullhorn_import_bullhorn_salary_currency_field will allow you to assign a custom text field to your job import that will designate the currency of the pay rate. This is optional, but helpful for users offering roles paid in separate currencies. Default is the value of the default currency in Bullhorn settings.
      • matador_bullhorn_import_salary_range_separator filter will allow you to change the characters or text that separate two numbers in a range. Default is an skinny dash, also known as an n-dash, or -.
      • matador_bullhorn_import_salary_unit_separator filter will allow you to change the characters or text that separate the last pay rate with the pay unit. Default is a single non-breaking space character. For example, the space between “USD” and “per year” in the string “$100,000 USD per year” can be changed to a slash character to result in “$100,000 USD/year”.
      • matador_bullhorn_import_salary_string filter will allow you to further customize the text string that makes up a salary statement. Default is the string we construct and it is passed an array of arguments with all the imported salary parts.
      • matador_structured_data_include_salary filter can be passed true or false to hide salary fields from the external structured data (used by Google, others to aggregate job data). It defaults to the settings option “Display Salary/Pay Rate”. If you are required by local law or regulation to show pay rate, Google may not present your jobs if this is not provided.
      • matador_template_job_info_show_pay filter can be passed true or false to show or hide the Salary/Salary Range text in the Job Info Bar. The Job Info Bar is getting a little crowded, we’ll admit, but it is the most consistent way we can include this by default without breaking users’ layouts. It defaults to the settings option “Display Salary/Pay Rate”.
  • Bullhorn’s newly implemented isWorkFromHome field will now be used to flag “Remote” or “Work From Home Jobs”. This will override legacy behavior based on the Bullhorn onSite field if found, otherwise we will default to the former behavior of matching certain values from the onSite field as we developed for users in summer 2020.
  • New “Information” form field was introduced to simplify passing instructions via settings fields and forms.

Bugfixes:

  • Fixed issue that could cause the job importer to crash if the user has modified their Bullhorn field mappings to expose and then manually set or manipulate the publishing status, resulting in some expected fields set as part of the Publishing Action to not be set.
  • Fixed an issue preventing the assumed behavior of the “Sync This Job” button to not work as intended. The intent of this function was that a manual per-job sync would always fully download and overwrite the job data, but it was honoring dateLastPublished/dateLastModified rules intended for only the bulk sync. The button will now work as expected.
  • Fixed issue introduced in 3.8.0 that impacted certain sites using Persistent Object Caching with Load Balancers. Not all systems were impacted, but certain configurations of some systems were, including the setup used on WPEngine hosting.
  • The 3.8.2 bugfix “when a certain of combination of settings were selected, the recommended value for careerPortalDomainRoot was incorrect” fixed only 3 of the 4 instances of that bug, and this release fixes the one we missed.

Update Now!

Matador Jobs 3.8.4 is released for automatic update to all subscribers as of today, Wednesday, December 21, 2022. If your subscription has expired, renew it on your account page. If you find any issues, please send a support request.