Version 0166
Updated
by
Leigh Hutchens
Release date August 9, 2023
Release summaryShort on time and want a high-level summary? Quinyx web app Version 0166 New functionality
Updates and performance improvements
Bug fixes
Important information
Frontline Portal Version 0166 New functionality
Updates and performance improvements
Bug fixes
SOAP API / Webservice updates
|
Important information
End of life of the Notice of Interest functionality December 2023
We've decided that our legacy functionality called Notice of Interest will be discontinued at the end of December 2023. Therefore, we urge all our customers to use the Availability functionality instead of Notice of Interest as soon as possible. The availability functionality is more user-friendly and supports more use cases than the Notice of Interest functionality.
One function that availability supports is converting an availability item into a shift in the Schedule view of the Quinyx web app. Quinyx also supports sections with availability and multi-selection of both units and sections when creating availability as a user. We've implemented the possibility for users to see, create, edit, and delete their own availability hours in our mobile apps.
Quinyx web app Version 0166
New functionality
Base schedule rollout warning for absence accrual (as a manager)
In release 0161, we enabled a warning when attempting to create an absence or approve an absence request that exceeds the minimum or maximum Time Tracker values. However, said warning did not apply when base schedule shifts were rolled out on top of an existing absence, thereby generating absence shifts. This has now been resolved.
If you roll out a base schedule shift over an existing absence but any of the absence shifts created as a result of said rollout would lead to the maximum or minimum values configured on the Time Tracker to be exceeded, the behavior to expect is that Quinyx will trigger the following that reads “Employee’s [name of Time Tracker] Time Tracker balance is lower than that needed for generating absence shifts for the absence occasion in question.”
This requires that you have configured Time Trackers and accrual drivers accordingly (see the improvement further down in the release notes). See the below picture as an example:
The following applies to the above warning:
- As it’s a blocking warning, you have the option to either not roll out the shift at all, or to roll it out as an unassigned shift without creating a corresponding absence shift for the employee in question.
- Until further notice, if any one of the shifts you are attempting to roll out over a currently approved absence exceeds the minimum or maximum Time Tracker value, the warning will display for each of the shifts you are attempting to roll out over said absence. We will pay close attention to feedback on this topic, so feel free to give feedback to us using our Send us feedback button if you perceive this behavior as problematic.
Updates and performance improvements
- Please be aware that various Quinyx customers are currently experiencing issues when waiting for their (current) audit log results. With this note, we mainly aim to communicate that this is something we're working on resolving. We appreciate your patience and understanding.
Manual scheduling warning for absence accrual (as a manager)
In release 0161, we enabled a warning when attempting to create an absence or approve an absence request that exceeds the minimum or maximum Time Tracker values.
However, we pointed out that this warning was only available if using any of the accrual drivers called Each vacation leave day or Each vacation leave hour, but that we would soon enable said warning for the Each 'absence type' leave day and Each 'absence type' leave hours. This has now been resolved. The same configuration requirements and functionality apply as described in the above-linked release notes.
Bug fixes
- Resolved an issue where creating an absence through wsdlUpdateAbsence using an absence schedule that made use of the nominal hours adjustment logic would create an unexpected amount of absence hours.
New HelpDocs articles
Frontline Portal Version 0166
New functionality
Distribute by Role/Group Type
You can now add an audience to a resource by group type or role type.
- From the audience splash page select Create New.
- From the audience viewer page select By group type or By role type.
- Select the groups or roles you wish to choose to add to your audience and click Confirm.
- Select the location(s) you wish to add all of the selected group/role types from and click Confirm.
- Selected recipients are displayed on the summary page.
Bug fixes
- Resolved an issue where deleted chat messages on Mobile did not appear deleted until the page was reopened.
- Resolved an issue that sometimes caused the page to crash while tagging users in chat on a Form.
- Resolved an issue where cropped folder cover images were not showing the cropped version.
- Resolved an issue where editing a Forms name was not being saved.
- Resolved an issue where questions answered correctly on a task were sometimes being marked as incorrect.
- Resolved an issue that meant you were unable to delete saved lists belonging to an archived user.
- Resolved an issue that meant the number of stores in a group would sometimes not be listed in the distribution picker.
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 announcement that with Version 0164, we introduced new fields in SOAP Web Services. Affected SOAP Web Services were wsdlGetSchedulesV3 and wsdlGetAgreementsV2. Each affected Web Service got 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.
