Version 0109

Updated by Leigh Hutchens

Release date June 2, 2021

Quinyx works relentlessly to strengthen information security and continuously improve measures to protect data. As part of this work, we have updated our Information Security Overview to reflect policies, mechanisms, steering processes, and organizational structure that form our commitment to protecting your data. The updated version can be found side-by side with the current version in the Information Security section on our website and will be valid through agreements 2 months from today.
In regards of the above message Quinyx will change the current password policy in the release of 111 planned for 30/6. The current policy can be found here. The current standard password policy will be removed and the new standard will be replaced with a modified high version.

New password policy level 30/6 will require that all passwords will need to:

  • Contain a minimum of 12 characters long (128 maximum)
  • Contain at least 2 numeric characters
  • Contain at least 2 letters

If a manager resets an employee's password, or if the employee chooses to reset the password, the system will require that you choose a new password when logging in.

The user account will be locked after 6 unsuccessful login attempts. A manager must then reactivate the account.

The password must be updated the next time the user resets the password or the manager sets a password for the user.

New functionality

Schedule

Unsocial time (UT) on punch

As of this release, we're showing UT (unsocial time) in the Time card on the punch. See below:

It’s also possible to manually override the UT by clicking on edit and punch and selecting either “Paid” or ”Save as time in lieu”. The default option is fetched from the agreement template:

  • The behavior of which forecasts are shown when multiple predictions are sent has changed. Those with the latest 'runIdentifer' will now be shown in the GUI instead of those with the latest initial 'runIdentifer.'

Base Schedule

Improved nominal hour warning

Up until this release, when rolling out a base schedule, the “Nominal hours exceeded” warning occurred on all shifts of that employee across the schedule period in question. This made for a suboptimal user experience. 

Due to popular demand, we’ve addressed this issue in this release. The warning will now be given for the shift at which the nominal hour limit is exceeded, as well as at all subsequent shifts in that same schedule period.

Example: Gregory Payne’s main agreement has a one-week schedule period. We roll out this base schedule over October 2021:

Before, this would result in one warning appearing for each shift rolled out in the rollout period, in this case October, as you can see in the warnings below:

As of this release, the warning will only appear on Fridays of fully rolled out weeks, since it's on that weekday of the recurring schedule that the nominal hours are being exceeded, which you can see in the warnings below:

Note that in the above specific example Friday October 1 won't trigger a warning since Monday-Thursday of that same week are in September, and therefore Gregory becomes scheduled only 8.5 hours out of his 40 nominal hours that week as a result of this rollout.

Updates and performance improvements

During the last weeks, we have made several UI improvements to reflect better our brand, and to improve the overall accessibility of our product. We have changed the font, improved color contrast, and corrected some inconsistencies. This is ongoing work to constantly improve the visual imagery of our applications.

Bug fixes

  • Correction to Time Tracker first to expire deduction logic when using consecutive agreements during a year.
  • Correction to Time Tracker first to expire logic and calculated balances when using consecutive agreements during a year.
  • Fixed an issue that prevented users from entering Time Tracker accrual drivers.
  • Fixed an issue where entering .0x as a value on social costs would not be accepted.
  • Fixed an issue where the 'last updated' timestamp on agreements may have been shown incorrectly.
  • Fixed an issue that caused a 500 error when an external config ID was not defined on all forecast configurations.
  • Fixed an issue where clicking 'Next Badge No' upon adding a new employee would remove the Unit and Group Integration Keys from the Unit.
  • Resolved an issue that covered shift information in Schedule and Base schedule on pick and delete hover.
  • Resolved a schedule issue that prevented adding a task in a shift.
  • Resolved a custom report filter issue that displayed expired employees if the date range selected was within their active period.
  • Resolved a custom report issue that did not display inactive employees when the report was configured to do so.
  • Resolved an issue that caused Absence type to not display in filters in the schedule view.
  • Resolved a schedule issue that prevented the calendar from opening on first click.
  • Resolved an issue in People that caused an overlapping email address.
  • Resolved a schedule issue that displayed a horizontal scroll in employee metrics.
  • Resolved a  visualization issue causing the dynamic and static rule shift name to overlap with the comment field.

New HelpDocs articles

REST API / Web service updates

None at this time.

SOAP API / Web service updates

  • Correction to wsdlGetAgreementsV2 returning 0000-00-00 in a xsd:date type field. It will now return 1970-01-01

Endpoints being deprecated and removed

The following SOAP API endpoints will be discontinued and removed from Quinyx WFM August 2021.They are already now replaced with REST API endpoints for Quinyx Forecast or obsolete. Read more about Quinyx Forecast and the improved functionality here and about the new REST APIs here.

6.2 wsdlGetForecasts

6.3 wsdlUpdateForecasts

6.5 wsdlGetMonthlyView

6.6 wsdlUpdateForecastV2

6.8 wsdlUpdateForecastsV3

6.4 wsdlGetSalesData

6.9 wsdlGetSalesDataV2

6.7 wsdlGetOptimalStaffing

4.6 wsdlUpdateAdminGroupRelationships <- not applicable for Quinyx WFM

Click here to view the new Quinyx WFM Web Service documentation. You can find even more web services info here.
We encourage all our customers to make use of our APIs to maintain data and make sure that information is up to date. To ensure scalability of our APIs while growing our customer and user base, we have decided to add restrictions on usage of our SOAP APIs. These restrictions will be enforced programmatically and 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 following 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?