Version 0157

Updated by Daniel Sjögren

Release date April 5, 2023

Release summary

Short on time and want a high-level summary?

Web app

New functionality

  • It is now possible to withdraw a pending schedule approval request. If the planner decides to withdraw the request, all assigned approvers will be notified about that action so that they can stop reviewing the schedule for that period.
  • Two new accrual drivers, allowing for accrual-based Time Trackers to be defined on absence type and not only for vacation.

Updates and performance improvements

  • Possibility to configure Opening hours on a 15-min granularity.
  • UI improvement for absence schedule configuration.

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.

New functionality

Possibility to withdraw pending schedule approval request 

With this release, we have added the possibility for planners to withdraw pending schedule approval requests. 

If the planner decides to withdraw the request, all assigned approvers will be notified about that action so that they can stop reviewing the schedule for that period. For the setup with two levels of approval, second-level approvers will receive this notification only if the request was pending for them to review (first-level approval is done). The option to withdraw the request will be available to every manager that has access to the schedule view.

When opening the Schedule approval and publishing modal, the manager will be presented with these options:

Clicking on Withdraw request, a new modal is opened where the action needs to be confirmed:

After clicking on Yes, the request is withdrawn and an automated Qmail is sent to approvers about this action:

New Time Tracker accrual drivers

Two new accrual drivers are added to the Time Tracker associations.

Each 'absence reason' leave day

The value of the time Tracker is calculated with the number of days when a specific absence reason is used. This allows for a more granular configuration of the accrual driver compared to the existing Each vacation leave day.

It is now possible to configure accrual-based time trackers to deduct 0.5 days from one absence type and 1 day from another absence type, even if both are of the type vacation.

Each 'absence reason' leave hours

The value of the time Tracker is calculated with the number of hours when a specific absence reason is used. This allows for a more granular configuration of the accrual driver compared to the existing Each vacation leave hours.

You can read more about how and where to configure Time Tracker on agreement templates here.

Updates and performance improvements

Possibility to configure Opening hours on a 15-min granularity

While it previously only was possible to configure Opening Hours (Standard and Special Hours) on an hourly level, it is now possible to set opening hours on a 15-min granularity. You can enter the required values either by typing directly in the field, or by selecting the clock and choosing the correct hours in the drop-down.

UI improvement for absence schedule configuration

Information about this improvement was added on 2023-04-03. We apologize for the inconvenience the late notice may have caused you.

Over the years, functionality related to absence schedules has been reported to us as bugs, whereas they were really by-design functionality. We've now taken some time to improve both our documentation and the user interface for the absence schedule configuration as a means of improving the understanding of the expected behavior of our absence schedules.

As you can see from the above screenshot, when you go to Account settings > Absence schedules > [calendar icon in the Actions column of any one absence schedule], the Day and time modal now has some new UI elements:

  1. The time fields have now been named "Start time" and "End time". This is so that they can be properly referenced in the improved documentation on this topic.
  2. Under the "Start time" and "End time" fields, there's an explanatory text. It reads: "This absence schedule uses the [name of adjustment option of the absence schedule in question] adjustment option. It will interact with the days and times you configure above."
  3. Below the explanatory text, we've included a link to the user manual article detailing how the day and time fields of this modal interact with the business logic related to each respective adjustment option. Please note that if the article in question doesn't exist in your local language, clicking the "More info here" link will take you to the English version article.

Bug fixes

  • Resolved an issue that caused an employee to not be visible in the monthly schedule report. 
  • Resolved an issue that made it possible to add Egenmelding for employees when they had used all occasions if the manager used a different absence type and then converted it to Egenmelding.
  • Resolved an issue with data sometimes being unreadable and not loading in the Forecast tab.
  • Resolved an issue with optimal hours not being correctly calculated whenever you had both static and dynamic rules.
  • Resolved an issue with Time Trackers and the combination of reduction of Saturdays, and Saturdays being defined as a bank holiday.
  • Resolved an issue where a Time Tracker transaction was removed after transferring to payroll.

New HelpDocs articles

Reminder! If you would like to receive bi-weekly email notifications about new 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?