Version 0159

Updated by Daniel Sjögren

Release date May 3, 2023

Release summary

Short on time and want a high-level summary?


Changes to aggregation calculation of Calculated Variables

  • We're currently planning to release this in Version 0160.

Web app

New functionality

  • Mobile apps provide notification support for availability connected to new unassigned shifts.
    • Reminder to use Availability instead of Notice of Interests.

Updates and performance improvements

  • Absence All-Day checkbox logic change.
  • Better scheduling experience with improved warning messages.
  • Increase in algorithm runtime before status Unknown result.

SOAP API / Webservice updates

  • No updates in this release.

Bug fixes

  • You might be interested in one of our bug fixes in this release. If you want more information, click here.


Changes to aggregation calculation of Calculated Variables - plan to release in Version 0160

We're currently working on removing inconsistencies in the way we aggregate data (hourly, daily, weekly, monthly) for Calculated Variables in Schedule Statistics and Forecast. So far, the aggregation in Calculated Variables has depended on whether the calculated variable has one or multiple operands aside from their primary input. With a single operand, the granular values are first summed and then used in the calculation afterward to get a daily total. With multiple operands, the calculation is performed on the lowest granular level and is summed only afterward. 

Why is this an issue?

Apart from the issue of inconsistencies in the calculation methods, it also results in calculated variables that represent, for example, percentage values dependent on multiple operands end up showing for example daily totals based on summation and not on average. 

How will it work in the future?

We're working on a change to solve this inconsistency by ensuring that the calculation in all cases is performed at every granularity level. 

Example 1

  • Variable A (aggregation type sum)
  • Variable B (aggregation type average)
  • Calculated variable C: A/B
  • Daily C = daily (sum) A / daily (average) B

The Daily C calculation is performed based on the daily values of the underlying variables.

Example 2

  • Variable A (aggregation type sum)Variable B (aggregation type sum)
  • Variable C (aggregation type sum)Calculated variable D: A+B-C
  • Daily D = daily (sum) A + daily (sum) B - daily (sum) C

The Daily D calculation is performed based on the daily values of the underlying variables.

Example 3

  • Variable A (aggregation type sum)Calculated variable B: A+100 (custom input)
  • Daily B = daily (sum) A + 100

The Daily B calculation adds the custom input as defined in the calculated variables, not as a sum of the addition of the custom input at the lowest granularity. 

Why is this important for you to know?

In some cases workarounds, for example, additional calculated variables, have been put in place in order to get the right daily calculated variable values. Once the change is made, the workarounds are no longer needed, and the values of the incorrectly calculated variables will be consistent. 

New functionality

Mobile app - Notification support for Availability connected to new unassigned shifts created

We've implemented support for receiving a notification when an unassigned shift is created that matches one of your availability entities. You can turn on this logic in the app's Settings page, and it follows the same setting as the notifications for unassigned shifts created that match your notices of interest.

Reminder - Start using Availability instead of Notice of Interests

We urge all our customers to start using our Availability functionality instead of Notice of Interests. The availability functionality is more user-friendly and supports more use cases than our current function Notice of Interest.

One function that availability supports is converting an availability item into a shift as a manager in the Schedule view of the web app. We also support sections with availability and multi-selection of both units & sections when creating availability as a user. We have implemented the possibility for our users to see, create, edit, and delete their own availability hours in our mobile apps. For the mobile apps, the permission for availability is turned off by default and needs to be turned on under Mobile and Staff portal permissions in You can find information about the availability functionality in mobile here and for managers here.

Updates and performance improvements

Absence All day checkbox logic change

As a result of feedback we received from many of you regarding the UX changes we made to the absence creation in Version 0151, many of you have given us feedback that while the change of default dates was appreciated, the default state of the All-day checkbox has led to many absences unintentionally being created for a single hour rather than for a full day as intended. Thanks to your feedback on this topic, we've been able to introduce an additional change with which we aim to address this usability problem.

Moving forward, the All day checkbox will be:

  1. Ticked when you enter the Add absence panel from clicking a cell in the schedule.
  2. Ticked when you enter the Add absence panel from clicking the + in the top right-hand corner in the schedule.
  3. Unticked when you enter the Add absence panel from the button at the bottom of the Edit shift panel.

In cases 1 and 2 above, if one same date is selected as start and end date, for instance 2022-04-25, the start and end date will remain the same when you untick the checkbox, whereas the start and end times of the absence will be a one hour-interval. Said one-hour interval occurs 12 hours after your business daybreak, so if the business daybreak configured in your unit settings is 2am, then the default absence times would be 2 p.m. -3 p.m.

In cases 1 and 2 above, if multiple dates are selected as start and end dates, for instance, 2022-04-25 - 2022-04-30, those same dates will remain the same when you untick the checkbox, whereas the start and end times of the absence will be the business daybreak to business daybreak. By means of example, if the business daybreak configured in your unit settings is 2 am, then the default absence times would be 2 am - 2 am.

In case 3 above, nothing has changed from before; the default dates and times will reflect the shift you’re entering the absence from.

If you select various different dates prior to unticking the checkbox in question, the above behavior unfortunately will not apply due to technical limitations. This is something we aim to address in due time.

Better scheduling experience with improved warning messages 

We're releasing the first part of the initiative, which has the goal of improving warning messages that are presented to managers when scheduling shifts. We hope that with these improvements, managers will spend less time working in Schedule view because they will have more information about missing skills, exceeding hours, and other types of warnings. 

The first warning we improved with this release is one about missing employee skills.

As of this release, inside the warning message, Quinyx will provide information about which skill an employee is missing for that shift. This way the manager can immediately know which skill needs to be checked or corrected in the employee details before the shift is scheduled. 

There is one exception for this new warning message, and it applies to all cases where managers haven't resolved warnings when rolling out a base schedule. If warnings on the roll out weren't resolved prior to this release, Quinyx will show the old warning message "Employee missing skill(s)" when opening that base schedule.

As part of this initiative, we've also visually improved how we display all overridable and non-overridable warnings to the manager. We made this improvement because we wanted to make Quinyx more user-friendly and also to explain which steps need to be taken before the shift is scheduled. Currently, this new warning modal applies only in Schedule view; we do have plans to improve it in the Base schedule view also.

Increase in algorithm runtime before status "Unknown Result"

Within Auto Schedule and Auto Assign, we currently have a technical limit in place for how long the algorithm run tables request the status of algorithm runs to ensure that the run tables stay up-to-date. This technical limit is required for performance reasons. Algorithm runs longer than 30 minutes until now have displayed "Unknown Result" as the status even though the algorithm run has completed. We have now increased the limit to 90 minutes such that any algorithm run completed within 90 minutes displays the correct status and run time.

Meal break updates

Premium payments

With this release, we are introducing automatic compensation pay (i.e., penalty payment/premium payments) in the meal break functionality. What we want to enable is faster and less error-prone management of compensation when a meal break has not been provided or taken according to the meal break rules.

You can read all about how to add premium payments to your meal break rules here.
UX changes for meal break rules

After some feedback, we've updated the configuration flow in Quinyx when applying meal break rules to certain agreements. The main change is that instead of applying agreements to the rules in the meal break panel, you will now have to apply the rules in Agreement templates > (new panel) Meal break premiums in the corresponding drop-down.

Bug fixes

  • Resolved an issue that caused costs to be shown differently between weekly and monthly view selection. As a result of this bug fix, statistics display schedule items and employees regardless of whether or not a given employee has an active role.
  • Resolved an issue that caused the re-rollout of an edited base schedule to not reflect the edits in the rolled-out schedule.
  • Resolved an issue that produced a 500 error when running an API call for get shifts between 00.00 - 06.00.
  • Resolved an issue related to Daylight Saving Time where the time was displayed inconsistently in schedule statistics between the table and the pop-up whenever a specific data point was selected. This was only an issue on the day of DST and during daybreak.

New HelpDocs articles

Quinyx articles

Reminder! If you would like to receive bi-weekly email notifications about new Quinyx app releases, you can sign up here.

SOAP API / Webservice updates

  • No updates in this release.
  • 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 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?