Version 0139

Updated by Leigh Hutchens

Release date July 28, 2022

New functionality

New filters feature in base schedule

With this release, we’re adding the same sort of filter functionality to Base schedule as exists today in Schedule. There are, however, a few differences between how the filters work in base schedule versus in the schedule. We're working on the articles that will describe more in-depth how the filters work in base schedule, and we'll publish these articles no later than Monday, July 25th.

Read more about filters in base schedule in the Base schedule filter groupings and their fields and How to find and use base schedule filters articles.

Updates and performance improvements

  • With this release, we've added a new permission to disable the Add button in the People tab for those of you who prefer their employee creation to be restricted to their integration setups. To disable the Add button in the user interface, navigate to Account Settings > Access Rights > Integrations > Employee Details > Add employee.
  • Under Account Settings > Access Rights > Integrations > Employee Agreements, we've added one additional permission to better manage the employment rate. Under Employment rate > Add employment rate, you can disable adding of employment rate, even when no template is used. This field is unlocked by default.

Bug fixes

  • Resolved an issue that allowed an employee’s rate to be changed despite the integration field being locked.
  • Resolved an issue that caused the start date of an absence in the schedule to not match the absence request’s start date.
  • Resolved an issue that prevented a punch time from being saved due to a daylight saving issue.
  • Resolved an issue that prevented saving a punch end time to the employee’s actual punch end time due to a daylight saving issue. 
  • Resolved an issue that prevented a specific punch time from being saved due to a daylight saving issue.
  • Resolved an issue that prevented editing punch times to match shift times due to a daylight saving issue.
  • Resolved an issue that prevented a Qmail from being sent without displaying an error message if the header length had reached maximum character length.
  • Resolved an issue that produced the error “Something happened, please try again” when clicking on Agreements in the employee card. 
  • Resolved an issue that produced the error message “Absence schedule is not changeable” when trying to change an absence schedule at the time of absence approval. 
  • Resolved an issue that caused a shift to not display when using an absence schedule.
  • Resolved an issue that did not display metrics when Expected hours/Nominal hours was selected in display options.
  • Resolved an issue that caused approved absences to appear multiple times on the schedule.
  • Resolved an issue that prevented opening a time card in the schedule view. 
  • Resolved an issue that prevented adding more than 100% bank holiday reduction for an agreement-specific bank holiday. 

Training material

Don't forget to watch the training videos that are available in HelpDocs! The videos cover:

  • Configuration & Settings
  • Schedule & Time Management
Click here to view Quinyx WFM training videos.

New HelpDocs articles

SOAP API / Webservice updates

New validations for wsdlUpdateEmployees

When creating or updating an employee through the SOAP API, validation is added for non supported characters in the following places : givenName, familyName, staffCat, address1, address2, zip, city, country, locale, loginId, cardNo, info, legalGuardianName.

If you try to update one or more of these settings including characters   [(\|\]\/~+@!%^&*={};:?><')] you will receive a validation error.

For the phoneNo, cellPhone, nextPhone only possible characters are space numbers 0-9, dot ., plus +, dashes - and /

Endpoints being deprecated and removed

No endpoints are currently deprecated and planned for removal.

Click here to view the new Quinyx WFM Web Service documentation. You can find even more web services info here.
We encourage all of our customers to make use of our APIs to maintain data and to make sure that information is up-to-date. To ensure the scalability of our APIs while growing our customer and user base, we've decided to add restrictions on the usage of our SOAP APIs. These restrictions will be enforced programmatically, which means that we will enforce a limit on concurrent calls per customer to 10. You should expect response code 429 if you happen to exceed this limit, and you are recommended to implement a backoff retry mechanism to handle the limit. Note that the limit applies to SOAP only. When moving from SOAP to Rest over the coming years, any limits will be built into the API. 

Please make sure to forward this information to the party within your company responsible for integrations.

How Did We Do?