Version 0183
Updated
by
Daniel Sjögren
- Release summary
- Important information
- Quinyx web app Version 0183
Release date April 3, 2024
Release summary
Short on time and want a high-level summary? Quinyx web app Version 0183 New functionality
Updates and performance improvements
Bug fixes
Important information
Frontline Portal Version 0183 New functionality
Updates and performance improvements
Bug fixes
SOAP API / Webservice updates
|
Important information
Last announcement! Notice of Interest functionality
In this version we are removing all notice of interest functionality in the web app and mobile app and urge all customers and users to switch to transition to using the Availability functionality. Availability is a more user-friendly feature that caters to a broader range of use cases compared to Notice of Interest. Some noteworthy capabilities of the Availability functionality include the ability to convert an availability item into a shift in the Schedule view of the Quinyx web app. Additionally, Quinyx supports sections with availability and multi-selection of both units and sections when creating availability as a user. Users can see, create, edit, and delete their own availability hours using our mobile apps.
If you have any questions or need further assistance, please do not hesitate to reach out to our support team.
End of life of the Classic and mobile SSO by March 31, 2024
Quinyx has decided that the support for the old SSO configuration (Classic and Mobile) will be removed during 2024.
New configurations are already available in the Manager Portal, and you'll now only need one configuration for all Quinyx applications. We recommend that customers still using the old configuration start planning to set up the new configuration.
The new configuration provider setup supports either SAML 2 or OPEN ID standards.
- General information: SSO basics
- Azure: SAML single sign on and OPEN ID single sign on
Quinyx web app Version 0183
Release date April 3, 2024
New functionality
Define full-time working hours equally distributed across the working days of the week
In Version 0183, we're releasing the second part of our bigger initiative that has the purpose of ensuring a more accurate reflection of employees' nominal hours distribution as stated in their employment agreement, better supporting the Quinyx overtime, additional time, or minus time methods, and duration of absence shifts created using absence schedules. This improvement will especially improve nominal hours distribution for the employees’ agreements defined for less or more than 5 working days per week.
How do I configure this new setup?
Agreement templates/personal agreements will get a new option inside the drop-down menu in the section "Working hours and periods". In this drop-down menu, you can define full-time working hours equally distributed across the working days of the week by selecting the drop-down option called “Full-time working hours equally distributed across the working days of the week”.
When you select this option, fields for defining full-time working hours and days will appear.
What is the “Full-time working hours equally distributed across the working days of the week (pre-Version 0183)” option in the drop-down?
This option represents the current agreement setup that existed until this release. We've decided to keep this configuration active until all customers are enabled and migrated to the new configuration we're releasing with Version 0183.
How is this configuration released with release 183 different from the one we have today (pre-183)?
Yes, you are right if you have noticed that the agreement configuration fields are identical. The difference comes with how those defined hours in Quinyx are reflected in employee metrics and when working with absence schedules using the nominal hours adjustment.
How is the employment rate affecting the hours I added on the working days?
The employee’s employment rate will work in the same way it works today. The percentage will be applied to the defined hours on working hours of the week.
Example:
If, in the image above, where the full-time working hours are defined as 24 hours, with the employment rate of 50%, the employee would have 12 expected nominal hours for that week.
How are my configured hours reflected in the employee metrics in the Schedule view?
Let’s assume that our example employee has defined 24 working hours per week in 3 working days.
Because the employee’s agreement does not state which 3 days during the week are working days, with our new logic, we're introducing a more flexible approach where the 3 working days can move during the week depending on the employee’s actual schedule.
The logic works in the following way:
- Nominal hours per working day are 8 hours which is the equal distribution of 24 hours in 3 working days.
- If the employee’s working week is still empty (i.e. the employee is not yet scheduled to work) 8 daily nominal hours will be allocated on the first three days of the week (Monday, Tuesday, and Wednesday). Other weekdays will have 0 allocated daily nominal hours.
- If during the scheduling process, the employee is scheduled to work any other 3 days of the week, the allocated 8 nominal hours per day will be moved to those 3 working days.
Example:
I've scheduled my employee to work 8 hours on Tuesday, Thursday, and Saturday. Daily nominal hours will be moved from the first allocated Monday, Tuesday, and Wednesday to the scheduled Tuesday, Thursday, and Saturday, making these days working days for the employee.
- With this logic, we're allowing managers to have flexibility in the scheduling process to assign shifts on any 3 days of the week for the employees with this agreement configuration adapting the employee metrics to the scheduling process.
- Once all 3 days defined per the agreement have been scheduled, all other days in the week will have 0 nominal hours allocated.
What happens if my employee is scheduled to work a shift that spans over the business daybreak?
In this case, daily nominal hours will be allocated to the day when the shift starts.
What happens if my employee doesn’t have a scheduled shift but has a punch?
If an employee only has a punch without a scheduled shift, we will consider this day as a “scheduled” day as well, and daily nominal hours will be allocated to it as per the agreement.
Can my employee actually work more than the contracted working days of the week?
Yes, Quinyx will not block the scheduling of employees on more days than defined in their agreements. Depending on the configured overtime method, employees will be compensated for those hours.
Example:
Let's say an employee is contracted to work 3 days for that week but actually works 4 days → if you're using daily overtime calculation, the 4th day will be fully considered as overtime. In this example, the 4th day is counted from the beginning of the week, starting from Monday.
If you are using weekly/monthly overtime calculation, then the system will look into weekly/monthly hours and employees will be compensated depending on those hours.
Are the employees getting the reduction of hours on bank holidays with this new logic?
Yes, with our new logic, we will be looking into the number of working days added in the agreement and where those hours are in the schedule for that week, following the same approach as defined above.
Example:
The employee has 3 working days and is scheduled to work all 3 days (Monday-Wednesday).
If a bank holiday falls on Tuesday and said bank holiday is set to reduce nominal hours, that employee will get a bank holiday reduction because Tuesday is considered as scheduled day for that employee.
If a bank holiday falls on Saturday, that employee will not receive a bank holiday reduction on Saturday because the contracted 3 working days are already scheduled during that week.
It's important to mention that we will be looking into the configuration of bank holidays that are based on the % of nominal hours. If the bank holidays are set to consider the fixed hours, this logic will not apply, and the hours will always be reduced on that day.
How are my configured hours reflected when I add absences with an absence schedule that has the nominal hours adjustment?
Absence schedules that have adjustments based on nominal hours will always consider the values of the employee’s working days and hours of the week configured in the employee’s agreement under the option of “Full-time working hours equally distributed across the working days of the week”.
When a manager adds an absence using an absence schedule, absence shifts will be added to the same number of working days as defined in the employee’s agreement. With our new and improved logic, Quinyx will now consider if the employee already worked shifts during that week, and absence shifts will be added on other days that are defined in the agreement.
The days configured in the absence schedule configuration will represent the range of the days on which Quinyx will add absence shifts when the absence is being created. We recommend that absence schedules are configured with all days of the week selected (Monday- Sunday) to allow maximum flexibility.
Absence schedule logic will follow the same approach as the employee metrics, assuming that the first three days of the week are working days for the employee.
Example:
Let’s use the same example employee that has defined 24 working hours per week in 3 working days with this absence schedule configuration.
- Assuming that the employee is not scheduled to work and the absence using the absence schedule is added for the whole week, absence shifts are generated on the first 3 days of the week (Monday, Tuesday, and Wednesday). Each day has 8 daily nominal hours allocated, adjusting the nominal hours for the week to be 24 hours.
- If the employee worked a shift on Monday but then got sick after they got home from work that day, as a result, an absence using an absence schedule is added for the rest of the week. Absence shifts are generated on Tuesday and Wednesday with respective hours of 8 and 8. In this example, Quinyx considered that the employee already worked 1 out of 3 working days defined in the employee’s agreement.
Audit log origin
As of this release, we’re introducing the concept of origin in our current audit logs. The purpose of this feature is to provide you with additional insight as to where the action reviewed took place. For example, when reviewing a shift that’s been created, you’d be able to understand whether it was created in the manager portal or rather in the mobile app.
The origin information is located in smaller text below the main value in the “Action made by” column of the view, as highlighted in the image below.
The table below contains an exhaustive list of the various origin values you may encounter as you browse your log search results, as well as the cases in which said 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, if the action has been triggered by a specific feature that has cascading effects on other parts of Quinyx, such as changing an employee’s home unit or ending their employment, then this will display as origin instead.
Action | Origin | Case(s) |
Creation | Via Manager portal | When a shift is created in Schedule in the manager portal. |
Creation | Via base schedule rollout | When a shift is created in Schedule as a result of a base schedule rollout. |
Creation | Due to absence |
|
Creation | Due to absence using absence schedule | When an absence is created using an absence schedule and, as a result, existing shift(s) in the Schedule are removed, and later the same absence is deleted, and the user chooses to reinstate the shifts, the shifts that were deleted when the absence was created are created anew, hence this origin. |
Creation | Via Mobile |
|
Creation | Via integration | When a shift is created using an integration, be it using our SOAP APIs or - in the future - REST APIs. Regarding auto-schedule and auto-assign: Refer to the description above this table. |
Update | Via Manager portal | When a shift is updated in Schedule in the manager portal. |
Update | Via base schedule rollout | When a shift is updated in Schedule upon a base schedule re-rollout. |
Update | Due to absence |
|
Update | Due to "Update shifts" feature | When a shift is updated as a result of the update shifts feature in Account settings or Group settings respectively |
Update | Due to employee deletion | When a shift is unassigned because an employee is deleted. Note that in this case, the State of salary type rules requiring approval property becomes null as a result of this. |
Update | Via Mobile |
|
Update | Due to agreement selection logic | When the agreement of the shift is updated as per any of the cases where Quinyx applies its agreement selection logic (as described here). |
Update | Due to end of employment | When a shift is unassigned as a result of the assignee's end of employment date being changed to before said shift’s start date. |
Update | Due to change of home unit | When the home unit of an employee is changed, which means the following changes are triggered as a result by the system:
|
Update | Due to agreement deletion | When the agreement used for a given shift is deleted. |
Update | Due to shift unassignment approval / Via Manager portal | When the shift property employee is changed as a result of a shift unassignment request being approved. Note that specifically for log actions prior to March 20, 2024, the copy “Via Manager portal” is used due to technical constraints. |
Update | Due to shift booking approval / Due to shift booking request | When the shift property employee is changed as a result of a shift booking being approved. Note that specifically for log actions prior to March 20, 2024, the copy “Due to shift booking request” is used due to technical constraints. |
Update | Due to shift assignment on away unit approval / Due to booking request | When the shift property employee is changed as a result of a home unit manager approving the request of an away unit manager to assign an employee. Note that specifically for log actions prior to March 20, 2024, the copy “Due to booking request” is used due to technical constraints. |
Update | Due to shift swap approval / Due to shift swap request | When the shift property employee is changed due to a shift swap being approved by the manager. Note that specifically for log actions prior to March 20, 2024, the copy “Due to shift swap request” is used due to technical constraints. |
Update | Due to re-calculated salary outcome | When a salary calculation is triggered by some actions in the schedule, leading to a shift’s "State of salary types requiring approval" being updated to Unapproved. One example of an action in Schedule that can trigger the salary re-calculation is opening the time card in Schedule. Note that this only triggers the calculation being run, the actual cause for the change will rather be due to a change in the factors configured in Quinyx to affect the employee’s salary output. |
Update | Via integration | When a shift is updated using an integration, be it using our SOAP APIs or - in the future - REST APIs. Regarding auto-schedule and auto-assign: Refer to the description above this table. |
Deletion | Via Manager portal | When a manager deletes a shift in the Schedule in the manager portal. |
Deletion | Via base schedule rollout | When a shift is deleted in the Schedule upon a base schedule re-rollout. |
Deletion | Via Mobile | When a manager deletes a shift in Mobile. |
Deletion | Due to absence | When a shift is deleted as a result of an absence having been added. Note that this happens in the following cases:
|
Deletion | Via integration | When a shift is deleted using an integration, be it using our SOAP APIs or - in the future - REST APIs. Regarding auto-schedule and auto-assign: Refer to the description above this table. |
Currently, origin will display for the actions relating to the “shift” item type. You can expect origin information to be released for the remaining item types during the coming months.
Updates and performance improvements
Update shifts - new and improved!
Due to needed maintenance and technical constraints, we’ve merged what has so far been known as the Update shifts and Apply rules features respectively. From this release onwards, the functionality related to these legacy features will be found by navigating to Account settings > Shift types > Update shifts and Group settings > Shift types > Update shifts respectively.
In Quinyx, when a shift type is edited in Account settings > Shift types and Group settings > Shift types respectively, the edits made will be reflected in any shifts (and tasks, if applicable) created from the point onwards in time. The purpose of the Update shifts feature is to propagate said edits - or part of said edits - to existing shifts in the Schedule and/or Base schedule. The Update shifts panel allows you to specify the exact subset of existing shifts - past or future - you want to update.
The following criteria are available for you to specify which shifts you want to update.
Field | Description |
Groups | This tree allows you to select which groups you want to propagate your shift type edits to. Use the checkboxes of the tree structure of groups to select this. You can use the free text field to more easily locate items in the tree structure. The tree structure is collapsed by default. Under the free text field, the number of districts, units, and sections selected respectively will be displayed.
If accessing this feature from account settings, you can select any group or groups across the account. If accessing it from group settings, you can select the group currently selected in the group selector of the nav bar, as well as any of its child groups*.
The default value for this field is the group currently selected in the navigation bar's group selector, as well as all of its child groups (if applicable).
Deselecting a parent group also deselects all of its child groups. Selecting a group automatically selects all of its child groups. Note that you're able to deselect all said child groups at your discretion. |
Shift type | Select the shift types you want to carry out the action for. Ticking the “Select all shift types” checkbox selects all shift types in one go. |
From | Applies to shifts in Schedule: Select - by typing or by clicking - the start date from which you want your shift type edits to be propagated in the schedule |
To | Applies to shifts in Schedule: Select - by typing or by clicking - the end date until which you want your shift type edits to be propagated in the schedule |
Select what to update | Select which specific shift properties you want to update. The shift properties available to update are:
|
Update salary type rules only on shifts that have no current rules applied to them | This checkbox only displays if you select the “Salary type rules” option in the “Select what to update” field above.
If you tick this checkbox and click Update, Quinyx will scan the shifts matching your selection criteria and identify any whose current state of salary type rules does not match that of its shift type. It will then add any missing salary type rules to said shifts.
This is a legacy feature, implemented with the intention of providing you with self-service capabilities to resolve (a now resolved) recurring bug in our system related to salary type rules. Until further notice, you may use this feature at your discretion. |
Select where to update | This part of the form allows you to select whether you want to only update shifts in Schedule, or also in Base schedule; and if yes, then which base schedules. Ticking the Base schedule “parent” checkbox will select all base schedules. Note that the base schedules that display in the list are only those that contain at least one shift matching the remainder of your selection criteria of the form in question. Note that base schedules with unresolved warnings can’t be updated, and will therefore appear with greyed-out text along with the text “Can’t be updated as base schedule warnings are unresolved.” |
Once you’re done selecting your update criteria, click “Update” in the bottom-most part of the panel. Once the update is complete, a toaster indicating its success will appear:
If your selection of shifts is large, the loading is likely to take some time and the Update shifts panel will remain open while a spinning wheel displays over top of the Update button. You may navigate away from this screen - or open another tab in your browser - and come back to the Update shifts. However, do note that if you do so, the above-mentioned toaster will not display upon update completion, nor will your selection per fields display. This is something we aim to improve over time.
If there are any kind of errors related to the update, the text in the toaster will read “Not all shifts were updated. Please try again”. The reasons for such an error could be, for instance, that another user in your organization attempts to roll out a base schedule that’s part of your update criteria while you’re filling out the Update shifts form. Please note that in such cases, you may update again as many times as you would like.
Permissions
In Quinyx, users need write access to the “Shift types” permission to make use of this feature. Since pre-Version 0183, the “Apply rules” didn’t control whether or not users could update salary type rules values but rather specifically whether they could make use of the “Update salary type rules only on shifts that have no current rules applied to them” feature, we’re currently collecting feedback as to how to best evolve said permission. Feel free to send us feedback using the “Send us feedback” button.
Summary of changes to functionality as a result of the Version 0183 update
- Before, Quinyx offered one feature called Update shifts and one called Apply rules. These have now been merged into one, still supporting the same cases as before - and more.
- Most notably: before, Update shifts requests would sometimes time-out. This would usually - but not solely - happen if you as a user had selected too large a selection of shifts for the system to cope with. Now, Quinyx uses asynchronous polling to ensure that your request be carried out. Note that this doesn’t mean that you might not get errors, but it will not be because the system isn’t able to handle the sheer quantity of shifts you’ve selected.
- Before, if you had selected a base schedule which had unresolved rollout warnings in “Select where to update” and clicked update, Quinyx would inform you something went wrong, meaning you could get stuck in an infinite loop of attempting to run the Update shifts command. Now, base schedules with unresolved rollout warnings are greyed out in the “Select what to update” part of the form, and are accompanied by explanatory text.
- As a result of your feedback, the shift type setting “Show breaks in mobile app” is now selectable in the “Select what to update”-field.
- Before, one was able to “Select all” for the “Select what to update” checkbox. We’ve now removed that option as a result of frequent reports of users accidentally selecting all values inadvertently, leading to massive overhead to correct said mistake, especially for the “shift times” value.
- Before, one was only able to update various shift types if updating salary type rules specifically (through the now obsolete feature “Apply rules”) - this is now possible also for remaining shift properties.
- Before, if accessing Update shifts through Account settings, there was no way to select only a subset of groups for which to update shifts. It is now possible to do so using the groups tree.
- Before, in the “Select where to update” part of the panel, the number of shifts that would be updated as per your current selection would display in brackets at the bottom of the panel for Schedule and for Base schedule respectively. Unfortunately, this had a very negative effect on performance, which is why we were constrained to remove said count.
- See the Permissions heading above the section you’re currently reading.
Compliance checker
Checking compliance for schedule
When checking schedule compliance, you now have the option to consider absence shifts. This is especially handy when you want to see if a user violated any rules before they were absent, i.e. called in sick.
As an example: a user should be scheduled no more than three shifts in a row. Initially, this user was scheduled for four shifts in a row, which should raise a violation. But on the third shift, the user called in sick. Using the new option, a violation will be raised, whereas previously it would not. Note that this option is disabled by default and must be enabled manually.
Checking compliance for worked hours
We've made some improvements in checking how an employee has been working during a shift. Before this release, we would check every punch individually, which could lead to false violations in certain situations. With the improvement, we now evaluate all punches belonging to the same shift, which should greatly increase the accuracy of checking violations.
Supporting local shift types in Optimal Headcount and Labor Standards
Quinyx is now able to also support local shift types, and not only global shift types, in optimal headcount and labor standards when selecting the shift type that the specific role/headcount relates to. This will unblock customers using both global and local shift types to schedule their staff to be able to accurately determine their labor needs.
When creating optimal headcount based on local shift types only the units and sections that the local shift type relates to will be returned in the group tree when configuring labor standards. This ensures that no units can be selected where the local shift types do not exist, and it’s clearer which specific units the local shift type belongs to.
Bug fixes
- Resolved an issue that caused the section field in the Edit shift type modal not to update.
- Resolved an issue where the "waiver signed" information message didn't appear and premium pay wasn't removed when punching out within specific waiver-active hours, despite meal break settings and one-time waivers being enabled.
- Resolved an issue that prevented a manager from attesting a punch on a shift on a specific date.
- Resolved an issue that caused rounding mismatches in the Detailed breaks and tasks report.
- Resolved an issue that caused the Detailed breaks and tasks report to fail if there were any punches without the shift in the filtered period.
New Quinyx HelpDocs content
HelpDocs articles
Interactive tutorials
Frontline Portal Version 0183
Release date April 3, 2024
New functionality
All-in-one login for Frontline Portal only users
For those users on the Quinyx All-in-one platform (AIO) who only use the Frontline Portal i.e. NOT Workforce Management (WFM), we have made some improvements to the login process.
- User logs into Quinyx here as usual:
- User will be directed straight to the Frontline Portal homepage:
- Those users granted User Management permissions can navigate to Quinyx WFM via the Settings Cog > User Management.
- The user will then be directed to the Quinyx WFM People tab.
- Here, they can update user details, i.e., a user’s name, email address, password etc. This is done by selecting the user whose details they wish to amend, updating their information, and then selecting Save.
- To navigate back to the Frontline Portal, the user must select Profile > Switch to Frontline Portal.
- Done!
Updates and performance improvements
None at this time.
Bug fixes
- Resolved an issue that prevented files from displaying correctly across the platform.
- Resolved an issue that prevented empty widgets from disappearing from the homepage.
New Frontline Portal HelpDocs content
HelpDocs articles
- None at this time.
Interactive tutorials
- None at this time.
SOAP API / Webservice updates
- None at this time.
- 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.
