Version 0180
Updated
by
Daniel Sjögren
- Release summary
- Important information
- Quinyx web app Version 0180
Release date February 22, 2024
Release summaryShort on time and want a high-level summary? Quinyx web app Version 0180 New functionality
Updates and performance improvements
Bug fixes
Important information
Frontline Portal Version 0180 New functionality
Updates and performance improvements
Bug fixes
SOAP API / Webservice updates
|
Important information
Update! Notice of Interest functionality
After careful consideration and recognizing that the approaching end of the year and holiday season posed challenges for our customers to meet the initial timeline, we have chosen not to proceed with the previously communicated plan to end the Notice of Interest (NOI) functionality in December 2023.
Instead, we have decided to extend the end-of-life date for NOI to the end of Q1 2024, specifically until March 31, 2024.
During this extended period, we encourage all our customers 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.
We appreciate your understanding and cooperation during this transition period. 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 0180
February 22, 2024
New functionality
Early employee access
Early employee access for new employees
You can give your employees(s) early access in People > People details > Status when logged into web.quinyx.com. The setting makes it possible for you to give your soon-to-be-starting employees an early employee access date for the mobile apps and staff portal before the actual role start date.
During the early employee access period, the user can log in to the app and use it just like other users to see their coming schedule, see their colleagues, and more.
However, the users can only perform certain actions like applying for open shifts, swapping shifts, creating shifts, applying for absences, and more (based on what permissions they have) if those items are dated on the actual role start date or later. If the user tries to perform an action on entities on a date before their actual role start date, they will get an error message stating, “You don’t have an active role on that date”.
Early employee access for already existing employees starting work in a new unit/section in the future
You can also give early access to an already existing employee who is going to start working in a new unit or section in the future. You can do this from Add role and Share employee.
Early access to a future unit/section for an already existing employee works the same way as early employee access for a "new employee" but for a different use case. During the early access period, the user can log in to the app and see their upcoming schedule, see their colleagues, and more in the unit/section where they have early access.
However, the users can only perform certain actions like applying for open shifts, swapping shifts, creating shifts, applying for absences, and more (based on what permissions they have) if those items are dated on the actual role start date or later in the unit/section where the user has early access. If the user tries to perform an action on entities on a date before their actual role start date in the unit where they have early access, they will get an error message stating “You don’t have an active role on that date”.
Enabling Early employee access for your organization
By default, Early employee access is disabled for you and your organization.
To enable early employee access so that you can set and configure the early employee access for your employees in the touchpoints listed above, you can do so in the web application under Account Settings.
To do so, navigate to Advanced Settings > Global Account Settings > Early employee access to enable it.
- If enabled, the "Early employee access" setting will be available in the touchpoints listed above.
- If disabled, the "Early employee access" setting will be hidden, and users will be unable to configure this for future. employees.
Organization REST API
The Organization REST API presents Create, Read, Update and Delete (CRUD) functionality for the basic data about an organization entity (District, Unit or Section). Please refer to the Rest API for organization documentation for further details.
Mapping REST API
This API lets you look up the integration key and can both look up the internal ID or vice versa. Read more about REST Mapping API.
Updates and performance improvements
Messenger
We now support 24-hour format for Messenger.
Update to remove ‘canceled’ tasks from the global calendar
We’d had feedback to say that ‘canceled’ items appearing on the global calendar was confusing. We have now removed canceled tasks from the global calendar, so now only ‘active’ items appear.
Labor rule deletion when the underlying forecast configuration is removed
We have made a small update to the labor rules within the optimal headcount configuration. If a labor rule is configured based on a forecast configuration (e.g. transactions) and the forecast configuration is deleted, then the labor rules based on that deleted forecast configuration will be removed as well. Labor rules based on other forecast configurations that have not been deleted will not be removed.
Minimum and maximum rules can be used in Auto Schedule
We have now enabled the usage of minimum and maximum rules configured as labor rules on optimal headcount variables to be used in Auto Schedule when creating schedules. Minimum and maximum rules are constraints that can be configured for your Optimal Headcount to indicate the minimum or maximum headcount needed for that specific role/shift type.
Minimum and maximum rules can be used for informative purposes when doing manual scheduling, or to constrain the Auto Schedule to ensure that the resulting schedule does not exceed the set minimum or maximum requirements.
Bug fixes
- Resolved an issue that caused the nominal hour metric not to reflect the actual nominal hours of the selected period and continue not to change from the incorrect number irrespective of the selected period.
- Resolved an issue that prevented the clock/time options from displaying when adjusting the time for a shift (Safari).
- Resolved an issue that displayed incorrect nominal hours according to an employee’s agreement when adjusting the schedule view.
- Resolved an issue that caused deleted absences to show an overlapping shift still present in the Schedule view.
- Resolved an issue in the mobile apps where employees that only had a role on a section could select their home unit when, for example, creating availability. Now, if an employee only has a role on a section, adding availability is only possible for that section.
- Resolved an issue when triggering forecasts through Quinyx causing the start time of the forecasting period to be generated on the incorrect time slot depending on unit timezone.
- Resolved an issue that caused calculated variables to be shown as 0 in the Schedule view.
New Quinyx HelpDocs content
HelpDocs articles
Interactive tutorials
Frontline Portal Version 0180
Release date February 22, 2024
New functionality
None at this time.
Updates and performance improvements
Updates to confirmation messages when deleting a resource from the homepage
We’d had feedback from users saying that it wasn’t clear when deleting a resource (e.g., file, folder, form) from the homepage whether the resource would be permanently deleted across the platform. As a result, we've made some updates to the confirmation message displayed when deleting a resource from within a widget on the homepage. The message now reads: ”This action will permanently delete this file from all locations for all users. This action cannot be undone.”
Update to remove "canceled" tasks from the global calendar
We’d had feedback to say that "canceled" items appearing on the global calendar was confusing. We've removed canceled tasks from the global calendar, so only "active" items appear now.
Bug fixes
- Resolved an issue that caused you to be unable to update an audience if it contained an archived group.
- Resolved an issue causing tasks to move to drafts rather than the task overview.
- Resolved an issue causing the audience selection on subfolders to loop between HQ and district levels.
- Resolved an issue within widgets that caused a delete button on items added by tags to appear.
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.
