Version 0200
Updated
by
Leigh Hutchens
- Release summary
- Important announcements
- Quinyx web app Version 0200
Release date December 2, 2024
Release summary
Short on time and want a high-level summary? Quinyx web app Version 0200 New functionality
New functionality requiring configuration updates
Updates and performance improvements
Bug fixes
Frontline Portal Version 0200 New functionality
Updates and performance improvements
Bug fixes
SOAP API / Webservice updates
|
Important announcements
Release moved from November 27th to December 2nd, 2024
To ensure a smooth experience for our customers during the Black Friday sales period, we are rescheduling our upcoming release from November 27th to December 2nd, 2024. Although not all of our customers operate in retail, we recognize the importance of this peak season and aim to minimize any potential disruptions. Some scheduled payroll files will still be released as planned on November 27th.
Please note:
- Final 2024 release: December 11th, 2024
- First 2025 release: January 8th, 2025
Release highlight videos
Coming soon!
Quinyx web app Version 0200
Release date December 2, 2024
New functionality
Advanced Analytics - Forecast data dashboards
With this release, we’re introducing advanced insights around Forecast Data usage within Quinyx, expanding the scope of analysis from unit-level insights to district and global analysis via two new dashboards in Advanced Analytics.
- Upcoming Forecast Demand: Provides a forward-looking view of projected demand over the next defined period based on historical sales data. The dashboard visualizes total forecasted items with potential variances and highlights outliers, enabling quick action for more precise demand planning.
- Historical Forecast Accuracy: Offers insights into forecasting accuracy by comparing past forecasts with actual demand and identifying significant discrepancies and trends. This dashboard helps improve forecast precision over time, making demand planning more reliable and actionable.
These dashboards will empower you to make informed decisions based on comprehensive forecast data over different groups and extended periods rather than focusing on only individual units. In doing so, we’re enabling new actionable insights to allow users to identify underperforming units, spot peaks in demand, and analyze trends over time to supercharge your forecasting.
In the meantime, for more information on how to work best work with these dashboards, you can find more information here!
Reminders 2.1 - Consecutive absence reminders
In Version 0197, we released our first absence-based reminder recurring absence of non-consecutive days where you could configure reminders to notify affected users when an individual has been absent regularly within a certain time window.
And now, with this release, we are adding more control here with consecutive absence reminders, which allows you to track when users have been absent for extended periods within a certain time period to help you action different types of absences in the best way possible.
License overview
With this release, we’re adding a simple license overview to the Account Settings where account owners can view the license information for their organization, enabling users to optimize their setup better.
Remaining audit logs origin for Shift requests
With this release, we're adding origin information for remaining shift requests inside our Audit logs.
Shift requests in question are: Shift swaps, Shift unassignment requests, and Shift assignments on away unit that already exist as separate “Item types” inside Audit logs framework.
Origin provides additional insight into where the action reviewed took place. As highlighted in the image below, the origin information is located in smaller text below the main value in the Action made by column of the view.
The table below contains an exhaustive list of the various origin values you may encounter as you browse your log search results and the cases in which the values will display. The logic in the origin naming aims to support you in resolving disputes or issues concerning workforce planning and attendance and is as follows:
- In most cases, it reflects the Quinyx “platform” where the action got triggered, such as the Manager portal, Mobile, Webpunch, or Integration.
- However, suppose the action has been triggered by a specific feature that has cascading effects on other parts of Quinyx, such as deleting or reassigning the shift; this will display as the origin instead.
Action | Origin | Item | Cases |
Creation | Via Mobile | Shift swap Shift unassignment request | When an employee creates a request in Mobile. |
Creation | Via Staff portal | Shift unassignment request | When an employee creates a request in the Staff portal. |
Creation | Via Manager portal | Shift assignment on away unit | When manager creates a request scheduling the employee on away unit. |
Deletion | Via Mobile | Shift swap Shift unassignment request | When an employee deletes a request in Mobile. |
Deletion | Via Staff portal | Shift unassignment request | When an employee deletes a request in the Staff portal. |
Deletion | Due to shift deletion | Shift swap Shift unassignment request Shift assignment on away unit | When the requests are deleted because the shift itself has been deleted. |
Deletion | Due to ended employment | Shift swap Shift unassignment request Shift assignment on away unit | When the requests are deleted because the employee’s employment has ended. |
Deletion | Due to employee deletion | Shift swap Shift unassignment request Shift assignment on away unit | When the requests are deleted because the employee itself has been deleted. |
Approve | Via Manager portal | Shift swap Shift unassignment request Shift assignment on away unit | When the manager approves the request in the Manager portal using the Notifications panel section. |
Approve | Via Mobile | Shift swap | When the employee approves shift swap in Mobile. |
Deny | Via Manager portal | Shift swap Shift unassignment request Shift assignment on away unit | When the manager denies the request in the Manager portal using the Notifications panel section. |
Deny | Via Mobile | Shift swap | When the employee denies shift swap in Mobile. |
Deny | Due to shift reassign | Shift swap | When the shift swap is denied because a shift is reassigned to an employee who was in the list of employees but didn't apply for that shift. |
Auto Schedule and Auto Assign warnings
In this release, we have introduced Auto Schedule and Auto Assign warnings. The aim of this functionality is to provide AI users with more insights into scenarios where the algorithm runs have been successfully completed but might, for some reason, not have optimally created or assigned shifts to certain employees due to one or multiple reasons.
How do I know whether there are relevant warnings in my latest algorithm run?
If an algorithm run has finished but with some potentially relevant warnings, there will be a mention in the notification when the algorithm run has completed that there might be one or more warnings for one or more units.
To view the warning details, go to the algorithm run tables. You can find the warnings of specific algorithm runs by selecting the run in the run table and viewing the warnings in the run details side panel.
What type of warnings can I get notified about?
There are different types of warnings for Auto Schedule and for Auto Assign. Each warning also comes with a suggestion of what you can do to resolve the warning.
You can get the following type of warnings for Auto Schedule:
- No active agreements: This warning is shown whenever you don’t have any active agreements for your employees. In this case, the algorithm run will be complete without creating any shifts.
- Supply/demand gap: This warning is shown whenever the number of hours required is higher than the number of hours available for one or multiple shift types. This means that you might need to schedule 400 hours within a specific week, but you only have 300 hours available employee hours.
- Missing requirements: This warning is shown whenever some of the shift types have no required headcount and shifts and, therefore, can't be created.
- Faulty shift type configuration: This warning is shown whenever there are shift type templates with conflicting shift rules. Currently, these rules are configured outside of Quinyx, so you should, therefore reach out to Quinyx if you get this warning on your algorithm run.
- Faulty break configuration: This warning is shown whenever there are break rules with conflicting rules. Currently, these rules are configured outside of Quinyx, and you should, therefore reach out to Quinyx if you get this warning on your algorithm run.
The following type of warnings you can get for Auto Assign:
- No employees are eligible: This warning is shown whenever you don’t have any employees qualified or available to work specific shifts. To resolve this warning, you should review employees' availabilities and available hours or skills.
- No shifts eligible: This warning is shown whenever you have certain employees who are not eligible to work any of the shifts available to be assigned. This could be due to the qualifications of the employee or their availabilities not matching the available shifts.
- No shifts to be assigned: This warning is shown whenever there are no shifts to be assigned within the period you have selected to run the algorithm for.
- Shifts fixed for non-eligible employees: This warning is shown whenever employees who were previously assigned shifts within the schedule period that the algorithm is run for are non-eligible.
- Misalignment between agreement and scheduling period: This warning is shown whenever some employees don’t have an active agreement for part of the days within the scheduling period.
New functionality requiring configuration updates
Coming soon: New design in the mobile apps and new side menu logo option
Our mobile team is excited to announce a brand-new design for our Android and iOS apps, launching with Version 3.41, planned for release in December.
With this new design, the side menu in the mobile app will have two different colors depending on the mode the user's phone is set to. This is different from the current version, where the side menu always has a dark color, no matter if the user is in light or dark mode. This means that the users, from when the new design is implemented, will have:
- A light color if they have light mode
- A dark color if they have dark mode
To support this change, we’ve added a new setting under Account settings > Appearance > Navigation Bar, enabling you to upload two logos for the side menu. This is the logic:
- The current logo upload function for mobile was previously called “Company logo URL for mobile” and is now called “Company logo URL for mobile in Dark mode.” This logo upload is the current function that will work for the older mobile versions. There is no need to change this logo since it will be automatically applied for users with dark mode once they’ve installed the coming mobile version 3.41 of the app. The optimal logo size is at least 796px wide, and we recommend a logo with a white or light color if possible, the same recommendation as before for this option.
- We’ve implemented a new logo upload function called “Company logo URL for mobile with light mode.” We recommend that you upload this logo as soon as possible since it will be shown to users with light mode selected on their phones and displayed to them once they install the coming mobile version 3.41. The optimal logo size is at least 796px wide, and we recommend a logo with a black or dark color if possible.
Adding Email Address to wsdlFindEmployees
With this release, we are enhancing the wsdlFindEmployees SOAP API to include the email address in the response. This update allows you to better identify which email addresses are present in Quinyx and to associate them with the corresponding users, allowing you more flexibility in your setup.
Example request
<wsdlFindEmployeesRequest>
<apiKey>{{apiKeyDomain}}</apiKey>
<emailList xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="tns:email[]">
<email xsi:type="xsd:string">firstname.lastname@company.com</email>
<email xsi:type="xsd:string">another.name@company.com</email>
<email xsi:type="xsd:string">someone@company.com</email>
<email xsi:type="xsd:string">one.more@company.com</email>
</emailList>
</wsdlFindEmployeesRequest>
Example response
<wsdlFindEmployeesResponse>
<return xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="tns:UnitEmployee[2]">
<item xsi:type="tns:UnitEmployee">
<api_key xsi:type="xsd:string">e121ererwrw121r2ewr12ew1r2e1wr2we1r21</api_key>
<unitName xsi:type="xsd:string">Restaurant Foodie</unitName>
<employeeId xsi:type="xsd:int">123456</employeeId>
<email xsi:type="xsd:string">firstname.lastname@company.com</email>
</item>
<item xsi:type="tns:UnitEmployee">
<api_key xsi:type="xsd:string">5r46ew4r564ewr5e4wr54ew65r4f5ds4f6</api_key>
<unitName xsi:type="xsd:string">Restaurant The Best Food</unitName>
<employeeId xsi:type="xsd:int">123457</employeeId>
<email xsi:type="xsd:string">another.name@company.com</email>
</item>
</return>
</wsdlFindEmployeesResponse>
Additional possibilities to how hours for overnight shifts, absences and availabilities are calculated within employee metrics
Until now, the hours from overnight shifts and absences within Employee metrics were always added to the starting day of the shift or the absence. That means that if a shift is scheduled on the 1st of January from 22:00-06:00, then all 8 hours of that shift are added to the 1st of January, even if some of those hours are scheduled on the 2nd of January. This works as expected in the majority of industries and regions. However, in some regions there is a desire for those hours to be added to the day where the work actually is scheduled.
With this release, we are adding the possibility to select, for your entire tenant, whether the hours of that shift, absence, or availability should be added to the starting day of that item, or to the day where the hours actually are planned/ or worked. This can be configured through Account settings > Advanced settings > Global account settings > Overnight hour calculations.
When selecting the Overnight hour calculation, you can see that by default Starting day of the item is selected. By selecting the edit icon, you are able to select Day when the hours are planned.
⚠️Some things to consider when selecting Day when the hours are planned ⚠️
- The selection for overnight shifts, absences, and availabilities only impacts employee metrics. That means that any payroll calculations, warnings, visualization of overnight shifts, absences, and availability are NOT impacted, and if the new configuration option is selected, you might notice a difference between what you see in the schedule and e.g. payroll calculations. Do not worry, if you do not consciously make any changes based on this new configuration you will see no mismatch between what you see in the schedule and e.g. payroll calculations.
- The selection for overnight shifts, absences, and availabilities impacts scheduled hours, worked hours, expected hours, and available hours in the Employee metrics.
- The default for overnight availabilities until now has been to add the hours to the day where the availability is planned. This was a mismatch in how absences and shifts were treated. Through this new functionality there is now alignment, however, if you had previous overnight availabilities and you frequently use the available hours employee metric, you might see a difference in how the values are calculated.
Updates and performance improvements
End of open BETA for Schedule and Base schedule printout
This release marks the end of the open BETAs for the Schedule and Base schedule printout respectively. As a result, the “BETA” icon that used to display next to the respective printout buttons has been removed.
This doesn’t mean we won’t keep improving these printouts in the future, but rather that we won’t discontinue the printout functionality altogether. A big thank you to all of those of you who have taken the time to submit feedback to us regarding the BETA versions in question! 🚀
Integration keys
In the process of building an improved management of these keys, we've now introduced the following changes:
- The source of the integration keys used for Agreements and Agreement tables is switched to the Mapping Service. No change should affect the usage of these keys in SOAP, Manager Portal, or Mapping REST API.
- For integration keys of the types District, Unit, Group, Roles, Agreement templates, Agreements validation for uniqueness within a tenant has been improved.
- Section uniqueness is enforced within the same unit.
Role management
We've made improvements to role management stability and efficiency.
Bug fixes
- Resolved an issue with the SOAP call GetSchedulesV3 where the ts of an object with an
absenceScheduleIdwouldn't update when updating the length of the absence. - Resolved an issue that caused two-step schedule approval Qmails not to be copied to email.
New Quinyx HelpDocs content
- Advanced Analytics - Forecast data dashboards
- Advanced Analytics - Historical forecast accuracy dashboard
- Advanced Analytics - Upcoming forecast demand dashboard
- Auto Schedule and Auto Assign Warnings
- How to maximize the shift planning process
- License overview
- Warnings FAQ
Frontline Portal Version 0200
Release date December 2, 2024
New functionality
- None at this time.
Updates and performance improvements
- None at this time.
Bug fixes
- None at this time.
New Frontline Portal HelpDocs content
- None at this time.
SOAP API / Web service updates
wsdlFindEmployees SOAP API
In Version 0200 release, we are enhancing the wsdlFindEmployees SOAP API to include the email address in the response. This update allows you to better identify which email addresses are present in Quinyx and to associate them with the corresponding users, allowing you more flexibility in your setup.
Example request
<wsdlFindEmployeesRequest>
<apiKey>{{apiKeyDomain}}</apiKey>
<emailList xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="tns:email[]">
<email xsi:type="xsd:string">firstname.lastname@company.com</email>
<email xsi:type="xsd:string">another.name@company.com</email>
<email xsi:type="xsd:string">someone@company.com</email>
<email xsi:type="xsd:string">one.more@company.com</email>
</emailList>
</wsdlFindEmployeesRequest>
Example response
<wsdlFindEmployeesResponse>
<return xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="tns:UnitEmployee[2]">
<item xsi:type="tns:UnitEmployee">
<api_key xsi:type="xsd:string">e121ererwrw121r2ewr12ew1r2e1wr2we1r21</api_key>
<unitName xsi:type="xsd:string">Restaurant Foodie</unitName>
<employeeId xsi:type="xsd:int">123456</employeeId>
<email xsi:type="xsd:string">firstname.lastname@company.com</email>
</item>
<item xsi:type="tns:UnitEmployee">
<api_key xsi:type="xsd:string">5r46ew4r564ewr5e4wr54ew65r4f5ds4f6</api_key>
<unitName xsi:type="xsd:string">Restaurant The Best Food</unitName>
<employeeId xsi:type="xsd:int">123457</employeeId>
<email xsi:type="xsd:string">another.name@company.com</email>
</item>
</return>
</wsdlFindEmployeesResponse>
Please make sure to forward this information to the party within your company responsible for integrations.
