Version 0145

Updated by Daniel Sjögren

Release date October 19, 2022

New functionality

Mobile app

SAML SSO provider - added support for Mobile SSO

In this release, we've updated the SAML provider to support Mobile SSO as well. This means that the provider can be used for login via the mobile app. Read more about the configuration here.

Updates and performance improvements

None at this time.

Bug fixes

  • Resolved an issue that caused the nominal hours delta value to display more than two decimal places. 
  • Resolved an issue that caused punches connected to shifts to disappear when filtering in task grouping.
  • Resolved an issue that when moving an employee to a new unit, existing shifts assigned to the employee on the old unit on the day of the move no longer had an agreement attached.
  • Resolved a visual issue that caused data to be misaligned in statistics on daylight saving.
  • Resolved an issue when punching out in Webpunch that set the original punch-out time to the shift's end time.
  • Resolved an issue where the salary type rule Replace completely even replaced the break time when punch type was defined as Punch in/out no breaks.
  • Resolved an issue where filtering on an employee section didn't show employees that lost role on the section, but still calculated hours in statistics.

New HelpDocs articles

SOAP API / Webservice updates

The following endpoints will be updated in the next upcoming sprints. This is necessary for us to do in order to add new functionality for compensation rules. These are configuration endpoints, and our data shows no active integrations running towards them.

New input parameters will be added as well as new response objects.

3.36 wsdlGetSalaryCompensations

3.37 wsdlUpdateSalaryCompensations

3.38 wsdlDeleteSalaryCompensations

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?