Version 0163

Updated by Leigh Hutchens

Release date June 28, 2023

Release summary

Short on time and want a high-level summary?

Quinyx web app Version 0163

New functionality

  • We've implemented the possibility to turn on a setting in the admin portal that prevents users in the mobile app and staff portal from seeing shifts they don't have the skills for to work.
  • We've added a new Rolling 7-day period minimum consecutive rest validation.
  • With this release, we are adding the support to calculate Overtime methods (Overtime, Additional time, and Minus time) even if your employee changes their agreement during the schedule period!

Updates and performance improvements

  • The Exceeding maximum number of days containing defined maximum amount of hours over defined time period schedule validation has been updated to now reflect the actual values causing the warning to be triggered.

Bug fixes

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

Frontline Portal Version 0163

New functionality

  • We've made some changes to the look and feel of the basic picking of people when you create an audience so that the people picker is now more intuitive and easier to use. 

Updates and performance improvements

  • None at this time.

Bug fixes

  • None at this time.

SOAP API / Webservice updates

  • No updates in this release.

Quinyx web app Version 0163

New functionality

Hide the shifts users don't have the right skills to book in the mobile apps and staff portal

We've implemented the possibility to turn on a setting in the admin portal that prevents users in the mobile app and staff portal from seeing shifts on which they don't have the skills to work. The reason for this feature is to prevent users from booking shifts they can't work and to prevent managers from getting invalid shift booking requests. This function needs to be turned on in Account settings > Advanced settings > Mobile account settings.

Rolling 7 Day period minimum consecutive rest validation

Some of our customers are bound by union agreements specifying their employees are entitled to a certain consecutive rest within any one 7 day period. To improve customers’ ability to schedule in a manner compliant with union agreement rules, we’re now releasing a new validation for this.

How do I configure this?

This warning is configurable both on the agreement template and on the agreement level:

  • Agreement templates: Agreement template > Rules for hours > Check minimum rest/week during any consecutive 7 day period
  • Agreements: Agreement > Rules for working time > Check minimum rest/week during any consecutive 7 day period

If the checkbox in question is ticked, the rest per week is carried out on a rolling basis. As an example, if you’re scheduling an 8 am-5 pm shift on a Wednesday for an employee who has 24 hours as the minimum consecutive rest, then:

  • Quinyx checks that between 8 am the previous Wednesday and 8 am the Wednesday you’re about to schedule, the employee has at least one occasion of 24 hours of uninterrupted, consecutive rest.
  • Quinyx also checks that between 5 pm on the Wednesday you’re about to schedule and 5 pm the Wednesday of the following week, the employee has at least one occasion of 24 hours of uninterrupted, consecutive rest.

When it comes to configuration options of schedule items, the following applies for the above validation: 

  • Absences (all types) are considered as rest (including the ones with calculate as working/scheduled time).
  • Shifts configured as “Free day” are considered as rest.
  • Shifts whose shift types are configured as “On call” are considered as rest.
  • Shifts whose shift types are configured as “Stand by” are not considered as rest.

OT Calculation for consecutive agreements

With this release, we're adding the support to calculate Overtime methods (Overtime, Additional time, and Minus time) even if your employee changes their agreement during the schedule period!

The calculation is encompassed by two checkboxes in the OT methods configuration (Account settings > Overtime methods) named Multiply quota by days ratio and OT total. These are separate from each other and can be used by themselves or in combination. You can: 

  • Multiply quota by days ratio is a calculation that considers the previous and/or the succeeding employee agreements when calculating OT for a period. The results here are shown in the same way as today (per agreement period). 
Note! Currently, this calculation only works if you have 7 work days per week; we're planning to extend this calculation to support 5 work days per week in Version164.
  • OT total is another component in the calculation of OT methods when you have consecutive agreements, where enabling this checkbox will enable a summary of OT method results by the end of the schedule period.
Read more about both calculations as well their limitations here.

Updates and performance improvements

The Exceeding maximum number of days containing defined maximum amount of hours over defined time period schedule validation has been updated to now reflect the actual values causing the warning to be triggered.

For instance, if the agreement fields are populated as in the image below, and the employee you’re attempting to add a shift to already has >10 hours of shifts on 2 days across a given 5-day period, then when you attempt to add it for the third day, you will get the following warning: Exceeding 2 days containing the maximum amount of 10 hours during 5 days.

When processing your employees’ shift swap requests, the warnings displayed in Quinyx so far haven’t indicated which one of the two employees swapping the warning(s) relate to. We've improved this by grouping the warnings by the employee using as displayed in the image below.

When editing a shift, the Time punch exists for this shift warning was displayed in the Edit shift panel for all shifts with a time punch up until this release. However, various parts of our customers using the deviation reporting mode for some employees and agreements pointed out the redundancy of this warning in such cases. Therefore, we have now removed the warning for the specific cases when the shift uses an agreement that uses deviation reporting if the punch is the same as the shift. Do note, however, that if the punch is different from the shift, the warning will still display.

Bug fixes

  • Resolved an issue that caused availability for an employee no longer on a unit to still be displayed even though the availability was deleted. 
  • Resolved an issue that caused attested punches on overlapping shifts to be deleted when an absence was created using wsdlUpdateAbsence even if the attested punches were outside of the timeframe of the absence.
  • Resolved an issue that produced a Something's wrong error message for some users when attempting to define the day and time modal on an absence schedule. 
  • Resolved an issue that erroneously allowed creating and/or approving absence requests in the specific case they were located between two existing absences, despite the corresponding warning having been configured. This issue only occurred when the accrual driver Each vacation leave day was used.
  • Resolved an issue that allowed an absence to be added when an employee didn’t have any vacation days left.
  • Resolved an issue that caused requests in the current audit logs to fail if the user switched languages in the manager portal.
  • Resolved an issue relating to absence shifts not being created as expected on the first day of the absence specifically when said absence was created using wsdlUpdateAbsence.

New HelpDocs articles

Frontline Portal Version 0163

Release and release date update

Frontline Portal distribution

Unfortunately, we have encountered some unforeseen challenges during the final phase of quality assurance (QA) testing, which has necessitated us to postpone the release date to the 12th of July. Our QA team has been diligently examining the product to ensure its robustness, reliability, and seamless user experience. During this rigorous testing process, they discovered several complex bugs that require immediate attention and resolution.

Although this delay is regrettable, we firmly believe that it is crucial to deliver a product that meets the high standards of quality and performance. We understand that this news may be disappointing, and we sincerely apologize for any inconvenience caused by the revised timeline. We value the trust and confidence you have placed in us, and we assure you that every effort is being made to rectify the issues promptly. Transparency and accountability are at the core of our company’s values, and we want to assure you that we are taking this delay seriously.

Our team is committed to delivering a reliable and superior product that will empower you in your day-to-day operations. Our development team is working diligently to address the identified bugs and implement the necessary fixes. We are conducting thorough testing and quality checks to ensure that the product meets your expectations upon release. While we are actively working towards resolving these issues, we believe it is vital to communicate this update to you.

We greatly appreciate your patience and understanding as we work through these challenges. Once again, we sincerely apologize for the delay and any inconvenience it may cause. We deeply value your partnership and look forward to delivering a superior product.

Thank you for your continued support.

Bug fixes

  • None at this time.

New Frontline Portal HelpDocs articles

  • None at this time.

SOAP API / Webservice updates

  • No updates in this release.
  • No endpoints are currently deprecated and planned for removal.
    Update of SOAP Web Services in the Version 0164 
    • This is an early announcement that with Version 0164, we will introduce new fields in SOAP Web Services. Affected SOAP Web Services will be wsdlGetSchedulesV3 and wsdlGetAgreementsV2. Each affected Web Service will get 1 new field.
    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?