Version 0186

Updated by Leigh Hutchens

Release date May 15, 2024

Release summary

Short on time and want a high-level summary?

Quinyx web app Version 0186

New functionality

  • With this release, email addresses are no longer a unique identifier for users.
  • For our Audit logs, we're releasing the Audit log "Action made for" search field.
  • Audit logs for additional Schedule actions:
    • Audit logs for Lock Schedule action.
    • Audit logs Publish Schedule action.
  • We're excited to release the first open BETA version for the ability to print the schedule.

Updates and performance improvements

  • None at this time.

Bug fixes

  • You might be interested in one of our bug fixes in this release. For more information, click here.

Frontline Portal Version 0186

New functionality

  • None at this time.

Updates and performance improvements

  • None at this time.

Bug fixes

  • You might be interested in one of our bug fixes in this release. For more information, click here.

SOAP API / Webservice updates

  • Check out the updates and new documentation here.

Quinyx web app Version 0186

Release date May 15, 2024

New functionality

Email addresses are no longer a unique identifier for users

With the release of version 186, we have removed the requirement that emails need to be unique across customers. The effect is that several user accounts can have the same email address. Within a customer, we still enforce uniqueness.

All different login options/providers support the new change, which means that customers using SSO via configuration in their Identity provider can give access to multiple customer accounts in Quinyx.

Users with only one account connected to the email will not notice any changes.

If a user logs in with an email that is connected to more than one user account, a verification message will be presented, and an email with a verification link will be sent to the user.

When the email address is verified, a list of the customer accounts will be presented. The user can only select one customer account at a time. 

From here, the login process will be the same as usual.

Audit log "Action made for" search field

We’re excited to allow you to specify (when using the (current) audit logs) which user has been impacted by a given action in Quinyx.

This enables you to get a full list of actions for a specific employee, which is typically useful when attempting to verify claims by specific employees of unfair treatment.

The field used to do so can be found at the bottom of the Adjust view panel in the (current) audit logs:

The following can be expected from this field:

  1. This field allows you to search for any user with an employee role on the group(s) selected in the Adjust view panel group tree as of today, any time in the past, or the future.
    This means that editing your selections in the group's tree after populating the Action made for field will reset the field.
  2. Each employee in the field’s dropdown will display as per the following format: [first name] [last name] [badge number]
  3. You may search for a specific employee by typing their name(s) or badge number and/or by scrolling the list that adapts to what you’ve typed. You may also search for various employees simultaneously by selecting various employees in this field. The employees in the list are sorted alphabetically.
  4. The default value is “All”, meaning that if you leave this field blank when clicking “Apply” in the Adjust view panel, log results will not be fetched for one specific employee.
Audit logs for additional Schedule actions

With this release, we are adding two new items to our Audit logs framework. In addition to audit logs of schedule items, now you will be able to search for the audit logs that reflect the publishing and locking respectively of the schedule.

The purpose of this is to provide you as a manager with a more complete picture of the changes taking place in your unit(s).

Audit logs for Lock Schedule action

Searching and navigating the lock schedule audit logs inside the Adjust view panel, the table follows the same logic as described in Audit logs (current) with the following adjustments:

  • “Schedule lock” is a new item with its own separate row inside the audit logs table.
  • Inside the “Item type” column, we display a new item type named “Schedule lock”.
  • Inside the “Item” column we are showing the current value of the lock date.
  • Inside the “Action” column, we display actions taken on this item, and due to the very nature of these items, it is always the same action: update.
  • The “Action made by” column displays who has carried out the action in question. In addition to the information about who has carried out the action, information about the origin of the action is also displayed. For this item, there are two possible origins:
    • Via Manager portal - when the schedule is locked from the Schedule tab.
    • Due to transfer to payroll - when the schedule is locked from the Time tab during the transfer to payroll process.
  • Inside the “Action made for”, we will display N/A since, no specific employees are affected by the action in this case.  

In your audit log search results for these items, you can see more details about the properties that applied to the item by clicking the chevron in the leftmost column of the table of search results. Clicking there brings up a sub-table with properties that are connected to the action update. Inside the sub-table, the Schedule lock item will have the following property: 

  • Locked date: This property will show the old and new value of the updated date for the Schedule lock.

The below illustrates what said sub-table for a schedule approval can look like:

Audit logs for Publish Schedule action

Searching and navigating the schedule publish audit logs inside the Adjust view panel and table follows the same logic as described in Audit logs (current) with the following adjustments:

  • “Schedule publish" is a new item with a separate row inside the audit logs table.
  • Inside the “Groups affected” column, we display the units and sections that were affected by the action in question. 
    • If your publishing action is performed on the unit level, this column will display the unit name and all sections that have the same publishing date as the unit.
    • If your publishing is done on a section level, this column displays the name of that one section and that of its parent unit.
    • One visual improvement with this addition is that, as of this release, you will always be able to see the unit name. If there is more than one section affected, then only the number of sections affected will be displayed; you may hover that piece of information in order to see section names:
  • The “Item type” column displays a new item type named “Schedule publish”.
  • The “Item” column shows the current value of the publish date.
  • The “Action” column displays actions taken concerning this item, and due to the very nature of these items, it is always the same action: update.
  • The “Action made by” column displays who has carried out the action in question. In addition to the information about who has carried out the action, this column provides information about the origin of the action. For this item, there are four possible origins:
    • Due to automatic unit publishing - When the new date is set due to automatic publishing activated on the unit level.
    • Due to manual unit publishing - When the new date is set due to manual publishing from the Schedule tab.
    • Due to manual section publishing - When the new date is set due to manual publishing on the section level from the Schedule tab.
    • Due to unit schedule approval - When the new date is set due to the schedule being approved as a result of the Schedule approval flow process.
  • The “Action made for” displays as N/A since, in this case, no specific employees are affected by the action. 

In your audit log search results for these items, you can see more details about the properties that applied to the item by clicking the chevron in the leftmost column of the table of search results. Clicking there will bring up a sub-table with properties that are connected to the action update. Inside the sub-table, these items will have the following property: 

  • Published date - This property will show the old and new values of the updated date for the Schedule publish.

The below illustrates how the sub-table for a schedule approval can look like:

Note: For these two new items we will not provide the “Item trail” since the whole history of the Schedule actions is already visualized in the table view for them.
Note that you can only access log data starting from the date the logging was released. For instance, since audit logs for the publish and lock schedule are released in release 0186, which is on May 15th, 2024, the current logs do not hold log data for the publish and lock schedule on any dates prior to May 15th, 2024.
Schedule printout (Open BETA version)

We’re excited to announce that we’re releasing something many of you have requested for quite some time: the ability to print the schedule. The purpose of printing the schedule can be many, but our aim is first and foremost to enable communicating the schedule to employees in paper format, typically but not exclusively because said employees can’t or won’t use their personal digital devices to access their schedule.

How to

In order to print the schedule, navigate to Schedule and click the ellipsis in the top right corner of the view, then click “Print schedule [BETA]”. If you prefer, you may also click your keyboard’s ctrl and p buttons if you’re using a PC, command and p if you’re using a Mac.

Performing the above keyboard shortcut will bring up your browser’s print dialog, where you can make use of the various options this dialog offers, including whether to print a paper format of the pre-view or rather save it as PDF:

Whether you save it as a PDF or print it on paper - the printout will differ slightly from the graphical user interface to ensure the information is readable. A reason for this is, for instance, that some information is only available on hover in Quinyx. Another reason is that the printout is - as mentioned above - intended for employees to view their work schedule, whereas the users of the manager portal are managers rather than employees by definition.

As a whole, the printout reflects your Schedule selections, such as those made in display options and filters, as a means of allowing you to include only the information most relevant to you and your team in the printout.

The following lists graphical elements that are different in the printout compared to when you’re viewing the Schedule in Quinyx:

  1. View mode: if you’re displaying a calendar month in Quinyx when printing, the printout will be one calendar week per sheet. In cases where the information in the Schedule doesn’t fit - vertically - on one sheet, then the printout will print all sheets for the first calendar week of said month prior to doing the same for the remaining calendar weeks of said calendar month.
    Note that you can control which information is displayed in the printout - and thereby, possibly, “save” vertical height by making use of the Schedule filters. If you print a custom view, the same logic applies. Due to technical constraints, if you print the daily view, it will print to reflect how a custom view displays when one single calendar date has been selected.
  2. Breaks: These are indicated using a coffee cup on the shift, followed by the break start and end times for shift types where the “Show break in mobile app” is enabled. For shift types where the setting is disabled, the break duration is displayed instead of the break start and end times.
  3. Shift comments: The full comment is displayed in the printout, even if it entails a line break.
  4. Availability comments: The full comment is displayed in the printout, even if it entails one or various line breaks.
  5. Shift type name: In cases where the shift type name is too long to fit one same line, these will display using line breaks. In an attempt to save vertical space, we’re working on enabling the ability to configure abbreviations for shift types with long names.
  6. Absences:
    1. In cases where the absence type name is too long to fit one same line, the printout will hold the abbreviation as defined when creating/editing the absence type in question. Said abbreviation supports a maximum of 10 characters. This is done in an attempt to save vertical height - and thereby save trees! If there’s no abbreviation and the name doesn’t fit in one same line, no name displays at the moment; this is not intended and will be addressed as soon as possible so that the full absence type name displays with line break in such cases.
    2. Absence shift information is not reflected in the printout to be consistent with what information is available to employees using Quinyx' mobile app.
  7. Statistics: These are currently not reflected in the printout in order to be consistent with what information is available to employees using Quinyx' mobile app.
  8. Unavailability: Due to technical constraints, the printout currently doesn’t reflect unavailability information. This is something we aim to enable - subject to Schedule filter configuration - in the medium term.
  9. Various interactive elements - such as the envelope button for Qmail, entry point to Display options, entry point to filters, entry point to statistics, the “waving hand” indicating shift bookings and so on - aren’t reflected in the printout in an attempt to only include information valuable to the employees.
This feature is currently in open BETA mode: this means that you’re very welcome to provide us with feedback regarding problems or shortcomings you experience when using this feature.
Please note that the readability and quality of the printout may vary depending on your printer.

New functionality requiring configuration updates

We are adding a new section to the release notes called "New functionality requiring configuration updates." This section is designed to keep customers well-informed about new features that may require adjustments to existing settings or additional configurations. It's important to note that this section won't always contain content, but it will be used as needed to ensure clarity and readiness for any required changes.

No updates at this time.

Updates and performance improvements

None at this time.

Bug fixes

  • Resolved an issue in the Schedule view that caused the greyed-out fields that indicate that a shift is scheduled on another unit not to be displayed properly.
  • Resolved an issue where an error message occurred when a manager attested shifts before ticking the employee box

New Quinyx HelpDocs content

HelpDocs articles
  • None at this time

Frontline Portal Version 0186

Release date May 15, 2024

New functionality

None at this time.

Updates and performance improvements

None at this time.

Bug fixes

  • Resolved an issue that caused the Frontline portal to crash when uploading files to tasks.
  • Resolved an issue that caused tasks to be sent out one hour after the set send-out time.
  • Resolved an issue that caused the recently opened folders widget to go missing from the Homepage.
  • Resolved an issue causing HQ users to be unable to view folders.

New Frontline Portal HelpDocs content

HelpDocs articles
  • None at this time

SOAP API / Webservice updates

  • As part of our long-term attempt to move away from SOAP APIs to REST APIs, we released the following absence-related REST APIs as of the Version 0185 release:
  • Our tentative plan is to release additional absence-related APIs - POST Part-Time Absence, PUT Absence, Delete Absence - in the coming months.
  • Various absence-related SOAP APIs will be deprecated with time as a result of the above-mentioned REST APIs. In due time, we'll communicate a deprecation timeline to affected parties.
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.


How Did We Do?