In the coming days, we’ll be releasing Matador Jobs 3.6, our next major release of the Bullhorn Marketplace Partner solution for connecting your Bullhorn data to your WordPress website.

We acknowledge the time between releases has been a little more than ideal, especially as we’ve shared privately with many of you that we intended to see a release much sooner. The time however, we promise, was well spent making sure each change was made carefully. In the case of some of the most seemingly simple features, like sorting jobs by date last published, the underlying adjustments to our core system were major.

This release will be final, we expect, by the time this post is a week old. If you’d like to download a preview version of it, let us know, and we’ll provide you a pre-release you can demo on your site.

What’s New?

Unlike release 3.5.0, which had one major new feature and a handful of more minor enhancements, 3.6.0 has six–yes six–major new features! Let’s break them down!

Integration with Bullhorn’s “Consent” Custom Object to Track Candidate Acceptance/Consent

Two years ago, with the implementation of the General Data Protection Regulation (GDPR) in the European Union, a worldwide tsunami of new rules for handling and protecting user data was ushered in. While tracking user consent is critical in EU, it is now critical in a number of US states and other countries around the world.

At our 3.0 release, with improvements in releases 3.1, 3.4, and 3.5, we’ve regularly added improvements to how Matador can help you keep up with this ever-changing landscape of laws, regulations, and best practices, most importantly documenting user actions of acceptance or consent during the application process.

Our progress in this area continues with our biggest step forward yet with full integration with Bullhorn’s Consent custom object. Here is how it works:

  • Turn on “Require Applicant to Agree to Privacy Policy” setting in the Matador Settings, under the “Applications” tab, if you haven’t already.
  • Optionally write a “Privacy Policy” page, and in the WordPress Privacy settings, set that page to as your Privacy Policy Page. Matador does not require a linked page, but will include a link to the page if enabled.
  • In your Bullhorn account, check the Candidate screen and see if there is a “Consent” tab. If not, contact support to have it added.
  • Matador will automatically check your account for the consent object, and if it finds it, will create an entry for each application you receive. If it doesn’t find it, it will re-check once per day.
  • The entries include important data about the consent the applicant agreed to with their application.
A consent record created from a Matador Application.

With this release, solutions previously available from releases 3.1.0 and 3.4.0 that used candidate custom fields are officially deprecated. This means, moving forward, we won’t update the older features and eventually remove them. We encourage you to update to this method, and it’s super easy to do so!

Few other notes about this feature:

  • Matador will check for the existence of the Consent custom object once per day until its found. If you have Bullhorn install the object and don’t want to wait for the next refresh, use the Transients Manager plugin (free) to remove the matador_bullhorn_candidate_consent_object transient.
  • Once set up on Bullhorn, the consent object should never change. Matador will assume it doesn’t.
  • Instead of automatically detecting the Consent object, a developer can manually set the API object name with the matador_applicant_candidate_consent_object_name filter. It expects a value from customObject1scustomObject10s.

At this time, only the “Privacy Policy” form field form will add a record to the Consent object. In a future release, we’ll add a way for our users to create a separate “Terms of Service” consent field. In the meanwhile, developers can create their own “Terms of Service” or other custom consents in the form and then process them and create consent records using the matador_applicant_candidate_consents_data filter. An example of a custom consent may be “I give permission to receive communication about this role in the form of SMS messages.”

“Work From Home” Jobs Optimizations for Job Schema (Google for Jobs Search)

Prior to this past March, “Work From Home” aka “telecommute” aka “remote work” was not quite in the forefront of our minds, especially during a job search. Now, however recruitment agencies are wanting to highlight jobs that are “Work From Home”.

The Job Postings schema, used by Google for Jobs Search and others to deliver accurate, relevant job search results, always had structure to highlight WFH jobs. Matador was previously unable to fully support this, but with the drastic changes to the industry in the last year, we put extra effort into extending our support moving forward.

Now Matador Jobs can determine, from your job data, if a job is WFH and broadcast this information in the Job Schema. Here is how it works:

  • In Bullhorn, modify your Job Posting field mappings to show the “On Site” option.
  • Matador expects the following default values of “On Site”, “Off Site”, and “Telecommute”. If there are more options and/or these are not your options, see below. Save your field mappings.
  • In your jobs, denote jobs that are WFH as either “No Preference” or “Off-Site”.
  • On the next sync, Matador will import these jobs and modify with the Job Schema to highlight WFH, which will be updated by Google for Jobs on their next visit.

In Google for Jobs search, these jobs will be shown to users seeking WFH positions explicitly as well as location-based searches in the same state (if USA) or country.

If your options for ‘On Site’ are different than ‘On Site’, ‘Off Site’, and ‘Telecommute’ (Bullhorn defaults), your developer will need to use the matador_bullhorn_import_telecommute_types to map your values to the scheme expected values. See the documentation for that filter in the source code.

To begin taking advantage of this new feature, all you need to do is update your job data with the on site values!

Advanced “Work From Home” Jobs Optimizations for Job Schema

The updates to the Schema explained so far, as we said, require no configuration to begin using, in fact it’ll happen automatically. That said, let’s talk a little more about how this works.

In Google for Jobs search, these jobs will be shown to users seeking WFH positions in a given state (in the US) or country (elsewhere).

What happens if the job is available to people in more states or countries? What if the position in New York can be worked by a WFH worker in Los Angeles? Schema allows you to set places your WFH job can work with a little extra leg work.

  • Open your Bullhorn field mappings for the Job Listing.
  • Set up a new customText field with a label like “WFH Location Type” and give it picker values of “COUNTRY”, “STATE”, and “PROVINCE”.
  • Set up a second new customText field with a label like “WFH Location Value(s)”. Allow free-form text input.
  • Make sure these new customText fields are visible and located near your onSite field.
  • Using the matador_bullhorn_import_location_requirements_fields filter, pass the names of the customText fields you’re using for Type and Value(s). See the documentation in the source for information on how to do this.

From this point forward, if Matador identifies an imported job as WFH, it will check if it has values set in those custom fields. If so, it will add extra data to the Job Posting Schema so that the job will show up in more relevant search results.

Let’s say you have a job located in France and workers from Belgium are also welcome to apply. If the WFH extra inputs are not set, the search will only return results for searches in France, but by using extra inputs, searchers in Belgium will also see the job. To set this job up like this, you’ll:

  • Set “On Site” to “Telecommute”, “No Preference”, or “Off Site”.
  • Set “WFH Location Type” to “Country”
  • Set “WFH Location Value(s)” to “France, Belgium”

Job ID based URLs

Website addresses should be human readable (for humans, but also to highlight keywords for search engines), so when Matador creates the URLs for your imported jobs, it creates something based on the job title. In this release, we added alternate URL schemes to support other integrations alongside default, human-readable functionality.

Jobs can now be found by appending the remote job id (ie: Bullhorn ID) to the jobs base URL. If yours jobs exist at https://your-site.com/gigs/ and you have a job ID on Bullhorn of 1234, then https://your-site.com/gigs/1234 will work as a link for that job. In fact, you will redirect to its human-friendly URL like https://your-site.com/gigs/job-name-1234 automatically.

Jobs can now also be found by appending a query string to the jobs base URL with the argument of ‘xid’. For example, if jobs exist on https://your-site.com/gigs/  and you have a job ID on Bullhorn of 1234, then https://your-site.com/gigs/?xid=1234 will redirect to its human-friendly URL also.

For forward compatibility with future support of additional ATS services, you further use the query string method and include an additional argument of ‘xsource’ to verify the external source, for example https://your-site.com/gigs/?xid=1234&xsource=bullhorn will ensure that xid of 1234 is a Bullhorn job.

This feature was added specifically to support Bullhorn’s publish to Indeed feature, but we see potential for it in many applications. For example, if a recruiter wants to email a job to a candidate, they could look up the job ID and hand-write the URL without needing to look up the human-readable URL generated by Matador.

This feature is automatically enabled on all Matador Jobs 3.6.0 sites with no setup required.

Job Date Source Option

We are excited to release what is likely one of the most requested features in the history of Matador: Job Date Source settings.

Let’s say you hired for a position at a company one year ago and the placement didn’t work out. The client contacted you to repost the role with the same description, salary, and job title. It makes sense to re-open the old record, right?

Well, since its release, Matador has set the job date from the dateAdded field, aka the date the job was created in Bullhorn.

When a job is reopened, it technically represents a new opportunity, but to a visitor of your site, it might appear it is old opportunity thats never been filled. With jobs sorted by date in both your Matador powered job board and on aggregators like Google for Jobs Search, this meant new opportunities were being listed at a lower priority just because they were created a long time ago.

With this release, you can select from multiple options for the job date. The options are ‘Date Added’, ‘Date Last Published’, and ‘Date Last Updated’. Our recommendation moving forward is to use the ‘Date Last Published’, which is changed every time you explicitly Publish (or Republish) a job in Bullhorn.

To use this feature, go to the new “Job Date Field” setting in the Matador Settings, Job Listings tab. Select your desired option. On the next sync, the jobs’ dates will be updated.

Major Sync Performance Improvements

The data Matador fetches from Bullhorn during a job sync is a lot, especially if you have a lot of open jobs. Once all the data is fetched and stored on your webserver’s RAM memory, Matador then must process it.

On some of our larger sites, including those with 300-1000 active jobs, there are occasional issues where their webhost would time out the syncs due to it taking too long. This is of course a huge problem!

Now let’s be clear, Matador is not your local Mom-and-Pop website app. While we’ve done our best to ensure Matador will work on as many web hosts as possible, some have configurations that make it hard for Matador to do its job. Some web hosts have “long process killers” that stop Matador at 10 seconds of run time. A site with 100 jobs may need over 10 seconds to complete, and a site with 1000 jobs may need a lot more! For this reason, we strongly encourage you use premium hosting when running Matador! You need a powerful webhost to ensure Matador has the power it needs.

That said, with this release, we found several ways to optimization sync, and we’ve seen subsequent syncs run up to 70% faster than the initial sync. There may still be some timeouts, but the number of the sites seeing these timeout issues are reporting an almost total disappearance of timeouts!

These improvements won’t matter to everyone, but to those who needed it, we know its welcome! To take advantage of this, simply update to Matador Jobs 3.6.0, with no configuration necessary.

Reworked Email

When we first built Matador, we build it for a handful of early-adopter clients. What mattered to them were priorities to us. Since these Bullhorn users had automations and routines set up for email, none of them needed Matador to send recruiter and candidate related emails. We knew some of our users would need email, but we didn’t have a client to help us battle test it, and for this reason, Matador’s email was simple out of the gate.

Though it worked, we soon found many users were constantly pushing the limits of our email system. We knew early on that a more robust Email implementation and rework would be necessary, but over time, we were able to patch in new features and added onto our original processing to add much-requested features. But each update propped up something that wasn’t built for how we were using it.

With this release, Matador email handling is completely rewritten. This solved several annoying bugs and added many paths for us build toward a future. Here are some highlights:

  • New settings added to set the default from “name” and from “email address” for Matador generated emails. This was previously the site admin unless changed via a filter by a developer.
  • When a site chose to use multiple recruiter emails sources, ie: “job owner” and “assigned user(s)”, sometimes the same email could be sent multiple times to the same recruiter while other times to no recruiter if the job had no owner or assigner user. Now the Email will send only one email per person and an additional setting is added for a “backup email” for when a recruiter email isn’t attached to a job.
  • The Mustache Templating Engine was added to Emails. This opens the door for a soon-to-be-released All Access Extension allowing our users to change emails from a settings screen, but also simplifies editing email templates.
  • Applicant & Recruiter Confirmation emails can now be sent either before or after the application syncs to Bullhorn. Emails sent after the sync can include a direct link to the new Candidate profile inside Bullhorn.

Easier Button Styling

Theme developers creating rich, unique Matador Jobs-powered sites have found one pain point when developing customizations: buttons.

Many websites use utility classes–like Bootstrap’s btn class–to style buttons. Matador’s default templates cannot guess the name of your button class, so if a user wanted to match button styles they previously had two options:

  1. Update the Matador templates via overrides to add the utility classes to the buttons, or,
  2. Modify their CSS to apply button styles to the Matador button style names.

With this update, we offer theme developers a much easier way. By using the new filter matador_template_button_classes filter, developers can apply global button classes to all buttons created by Matador and/or specific classes for primary, secondary, and tertiary (currently unused) styles. Here is an example:

Bug Fixes & More

Are you done yet? Actually no! We also were able to do the following as well:

  • Matador now plays more nicely with Yoast SEO by injecting our Job Posting Schema into the overall Yoast SEO Schema object. This will happen automatically with no configuration required when Yoast SEO is installed. This change may improve organic search traffic as well as fix missing company logos on Google for Jobs listings.
  • In WordPress on an “edit” job screen, you can now request a refresh of that job by clicking the new “Sync Job” button. Since, for some sites, a full sync is time consuming, this is an easier way to get that one update live on your site right away.
  • We found and fixed a handful of PHP 7.3 compatibility issues. The Matador team is keeping a keen eye out for PHP 7.4 and 8.0 issues. Whenever possible, use the most recent version of PHP for best speed and security.
  • We fixed an issue where an edge-case implementation of the Matador application shortcode on custom pages did not read query string values or connect applications to jobs.
  • We fixed an issue the hidden resume/cover letter file inputs weren’t completely hidden. They actually were, but if a theme developer applied certain rules to it, they could appear. Then, when said developer wanted to re-hide that field, they would display:none it. According to our form validator, a display:none form field is not validated, allowing forms without the required resume to be submitted. This wasn’t a bug, but we found an opportunity to “hide” the field better so such a silly thing may not happen again. Thanks Heidi, by the way, for your patience as we figured this out! It was a doozy!
  • Some fixes for PHP 7.3, 7.4, & 8.0 compatibility.
  • Several more minor features and bug fixes, including several to support developers for new extensions and themes, are also included, but not as noteworthy.

What Now?

Matador Jobs 3.6.0 is available in its release candidate today. Contact us by email if you’d like to deploy it at the risk of finding one more bug we need to fix.

We expect to release it to automatic updates via logged in users with active license keys next week.

To all our users who have been patiently waiting for this release: THANK YOU. We worked hard and we know you’ve been waiting for months for this. We didn’t want to give you something half-baked. We appreciate your understanding!