Audit logs (current)

Updated 5 days ago by Daniel Sjögren

Before the logs described in this article were released, Quinyx offered logging data for some functionality in the Account settings. From now on, those will be referred to as the old audit logs, whereas the ones described in this article will be referred to as the current audit logs.

What's the purpose of the audit logs?

Logs, by definition, are a reflection of past activity in a certain context. In Quinyx, we've enabled logs in order for manager portal users to be able to resolve points of contention or conflicts relating to planning and/or attendance of their workforce through self-service access to historical activity data in Quinyx.

How do I navigate to the audit logs?

When you're logged into the manager portal, you access the audit logs by clicking the chevron in the right top-hand corner of your screen. From there, any manager portal user is able to click the Audit logs option.

How do I search for log data I'm after?

Once you've navigated to the audit logs, you'll be met by the following page.

Click Adjust view to enter your search parameters for the logs you're looking for. For now, you have the following search parameters at your disposal.

  1. Groups
    1. This tree allows you to select which groups you want Quinyx to fetch logs for. 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.
      1. Under the free text field, the number of districts, units, and sections selected respectively will display.
    2. You're able to select any group or groups on which you have at least one non-Employee role which has at least read access on any of the permissions.
    3. 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).
    4. Deselecting a parent group also deselects all of its child groups.
    5. Selecting a group automatically selects all of its child groups. Note that you're able to deselect all said child groups at your discretion. Example: In the first picture below, Quinyx will search for all items taking place on both unit Drottninggatan as well as on its sections Back office, and Sales. In the second image, we're searching for items that take place on Drottninggatan, but not items that take place directly on the sections, meaning that shifts with shift section Drottninggatan > Backoffice or Drottninggatan > Sales will not be included in that search.

  1. Item type
    1. This field allows you to select which items you want Quinyx to fetch logs for.
    2. This field requires you to select a value. At the time being, the only item available for selection here is shifts, but we're working hard to add more (see FAQ for more information).
    3. Assuming you have at least read access on the relevant permission - for shifts, that would be the Scheduling permission - on non-Employee role any of the groups you've selected in the Groups tree, that item would be available for selection in the Item type field.
    4. The item type field is mandatory.
  2. Type of action
    1. This field allows you to select which types of actions - taken by a given user - you want Quinyx to fetch logs for.
    2. Currently, you're able to perform any, several, or all of the following actions:
      1. Create
      2. Update
      3. Delete
    3. If you make no selection in this field, the field will read "All", meaning that logs for all of the above-listed actions will be fetched by Quinyx.
  3. Action start and end date
    1. These date fields allow you to set the start and end date of the period within which the action you're looking for was carried out in Quinyx.
    2. The default values for these fields are three months back in time from today's date for the "Action start date" field and today's date for the "Action end date" field. If you're uncertain of when a given action took place, use the maximum 3-month span and work yourself backward.
    3. Action start and end date are always in the same time zone as the group currently selected in the group selector of the top bar.
      1. Example: Drottninggatan is selected in the group selector, but let's say that I'm searching logs for my entire Quinyx account and some of my company's units are in the United Kingdom. In Account settings > Group management > Drottninggatan > Settings > Time zone, Europe/Stockholm is selected. If my action start date is 2023-02-21 and my action end date is 2023-05-21, then, for instance, actions taking place between 11 pm and 12 am on 2023-02-20 (UK time) in United Kingdom units will be included in my search, but actions taking place between 11 pm and 12 am on 2023-05-21 (UK time) in United Kingdom units won't.
    4. The action start and end date fields are mandatory for performance reasons.
    Once you're done adjusting the above search parameters, click Apply, and Quinyx will fetch the log data in question. A spinning wheel will display on top of the Apply button until the results of your search display.

    How do I navigate the log search results?

When Quinyx has retrieved the log items matching your search criteria, they're presented to you in a table of search results as can be seen below.

The table in question contains the following columns:

  • Timestamp
    • This column displays the date and time when a given action in Quinyx was carried out.
    • You're able to sort your table's values on timestamps. The default sorting of the table is from the newest to the oldest search results.
    • The date and time displayed follow the time/date formats dictated by the Quinyx language settings.
    • The timestamp of a given action displays in the time zone of the group currently selected in the top bar's group selector.
  • Groups affected
    • The purpose of this column is to help improve your ability to locate the item you're looking for, as there might be items with identical information (such as shift type name, shift times, etc.) on various groups.
    • This column displays the units and sections that were affected by the action in question.
      • Example: If a shift's shift section value is added, edited, or removed, Quinyx displays both the section(s) affected by that as well as the parent unit.
    • The group name will display followed by an indication of whether or not the group in question is a unit or section.
    • If more than one group is affected, "[number] groups" will display. Hovering that text will then display the list of units and sections affected. We will soon change this so that this behavior only occurs if more than two groups are affected.
  • Item type
    • This column displays the item type affected by a given action. This column will mainly prove valuable when more item types are available in these logs (see FAQ).
  • Item
    • The purpose of this column is to display information allowing you to identify which item has de facto been actioned.
    • Shifts are displayed as follows for shifts that start and end on the same calendar date: [Start date] [Start time] [End time] [Shift type name].
    • Shifts are displayed as follows for shifts that start and end on different calendar dates: [Start date] [Start time] [End date] [End time] [Shift type name].
    • If a shift type has been deleted in Quinyx, "[Shift type has been deleted from Quinyx]" will display instead of the shift type name. The reason for this is that the system no longer holds that information in those cases.
    • The shift type color displays as a vertical bar in front of the above-mentioned information.
  • Action
    • The purpose of this field is to allow you to identify which type of action has been carried out.
    • The actions taken on a shift all fall into the following types: create, update, and delete.
  • Action made by
    • The purpose of this column is to allow you to identify who has carried out the action in question.
    • If a person has carried out the action in question, this is indicated using the following format: [first name] [last name] ([badge number])
      • If the person an action was carried out for has since been deleted from Quinyx, "[Employee has been deleted from Quinyx]" will display instead of the employee's first name, last name, and badge number respectively. The reason for this is that the system no longer holds that information in those cases.
      • In the special case, an employee at Quinyx with system administrator permissions was to have carried out the action in question, this will display as follows: "Quinyx employee" [internal Quinyx employee database id]. Our intention is for this to safeguard Quinyx employees' personal information while enabling transparency to you, as well as troubleshooting by our internal departments if needed.
      • Note, however, that if an employee at Quinyx with an actual role in your company's Quinyx account carries out the action in question, this will display using the standard format used for this column, i.e. [first name] [last name] ([badge number]).
    • If the action in question was generated as a result of an integration with another system, we are technically constrained to display different data depending on what type of external Quinyx API said integration makes use of.
    • Regarding the "State of salary types requiring approval" property, see the "How do I know what properties were updated?" heading below.
  • Action made for
    • The purpose of this column is to allow you to identify who was affected by the action in question.
    • The person carrying out the action is indicated using the following format: [first name] [last name] ([badge number])
    • If the person an action was carried out for has since been deleted from Quinyx, "[Employee has been deleted from Quinyx]" will display instead of the employee's first name, last name, and badge number respectively. The reason for this is that the system no longer holds that information in those cases.
    • If the action you're viewing in your list of search results pertains to a re-assignment, then both employees will display in this column for that action - the new assignee on top, the old one below - as the action affects both of them.

The table will display 20 search results per page. In this example, our search results populate 21 pages, and we're viewing the first one out of those:

To browse your search results, use the outermost arrows to navigate to the first and last page of your search results respectively, and the innermost ones to step through each individual page.

Note that you will only be able to access log data starting from the date the logging was released. For instance, since shift logs were released in release 0161 which was on May 31, 2023, the current logs do not hold log data for any dates prior to May 31, 2023.

Permissions and audit log search results

Your search results as a user will reflect your Quinyx permissions. When it comes to shifts, you will only get log data for shifts actioned on groups on which you have at least read access on the Scheduling permission.

How do I know what an item looked like at creation?

For items in your audit log search results that are of type Create, you're able to see more details about the properties that applied to said item at the time of creation by clicking the chevron in the left-most column of the table of search results.

As a result, an item sub-table for shift create actions expands, listing all possible item properties and their corresponding values. The below illustrates what said sub-table for a shift can look like:

The table below clarifies the values to be expected by property for the item sub-table for shift create actions:

Property

Value

Employee

This property describes the employee assigned to the shift at shift creation.

The information displays as [First name] [Last name] [badge number]. If the employee has been deleted in Quinyx, then "[Employee has been deleted from Quinyx]" displays instead. N/A displays if no employee was selected at creation.

Shift type

This property describes the shift type selected for the shift at shift creation.

If the employee has been deleted in Quinyx, then "[Shift type has been deleted from Quinyx]" displays instead.

Date and time

This property describes the start and end time of the shift.

Shifts are displayed as follows for shifts that start and end on the same calendar date: [Start date] [Start time] [End time].

Shifts are displayed as follows for shifts that start and end on different calendar dates: [Start date] [Start time] [End date] [End time].

Breaks

All breaks of a shift are contained within a separate table within the table, as breaks are sub-items to shifts. The separate table is expanded by default but can be collapsed by clicking the two chevrons next to the Breaks property name. Doing so will display the breaks of the shift in question.

Each break displays as "Break [break start time] - [break end time]". In addition, breaks contain the "Break time" sub-property, for which the value column holds the [break start time] - [break end time].

Tasks

Similar to breaks, all tasks of a shift are contained within a separate table within the table, as tasks are sub-items to shifts. The separate table is expanded by default but can be collapsed by clicking the two chevrons next to the Tasks property name.

Each task displays as [task start time] - [task end time] [task type name]. The task type color displays as a vertical bar in front of that.

Tasks contain the Task time as well as the Comment sub-properties. The first displays as [task start time] - [task end time] in the Value column. The latter displays with the text of the comment in question in the Value column, or as N/A if there the task in question has no task.

Section

The section property describes the shift section of a given shift.

If a shift has a shift section, its full name displays in the Value column. If there's no shift section, N/A displays instead.

Cost center

The cost center property describes the shift's cost center.

If a shift has a cost center, its full name displays in the Value column. If there's no cost center, N/A displays instead.

Project

The project property describes the shift's project.

If a shift has a project, its full name displays in the Value column. If there's no project, N/A displays instead.

Agreement

The agreement property describes the shift's agreement.

If a shift has an agreement, its full name displays in the Value column. If there's no agreement - which only applies to unassigned shifts -, N/A displays instead.

Comment

The comment property describes the shift's comment.

If a shift has a comment, its full text displays in the Value column. If there's no comment, N/A displays instead.

Salary type rules

Similar to tasks, all salary type rules of a shift are contained within a separate table within the table, as salary type rules are sub-items to shifts. The separate table is expanded by default but can be collapsed by clicking the two chevrons next to the Salary type rules property name.

Each salary type rule displays as "Rule [number reflecting the order with which the rule displays in the shift panel in Schedule]".

In order to reflect the salary type rules UI from Schedule, this audit log property contains the following sub-properties:

  • Outcome salary type
  • Functions
  • Multiply by value
    • Note that this sub-property only displays if the salary type rule in question de facto has a multiply by-value, see the above picture for reference.
    • This figure supports up to 2 decimals in Schedule; the value in the audit logs' Value field will reflect that.
  • Salary type
  • Time interval
  • Amount
    • This figure supports up to 4 decimals in Schedule; the value in the audit logs' Value field will reflect that.

Productive hours

The productive hours property describes the state of the productive hours setting.

The option selected for this setting will display in the Value column.

Count as scheduled hours

The count as scheduled hours property describes the state of the count as scheduled hours setting.

"Yes" will display in the Value column if the setting is set to true, "No" will display if it's set to false.

Count as worked hours

The count as worked hours property describes the state of the count as worked hours setting.

"Yes" will display in the Value column if the setting is set to true, "No" will display if it's set to false.

Free day

The Free day property describes the state of the Free day setting.

"Yes" will display in the Value column if the setting is set to true, "No" will display if it's set to false.

Transferred to payroll

This property describes whether or not the shift has been transferred to payroll or no.

When the shift is transferred to payroll, this property's value will be "Yes".

When the shift isn't transferred to payroll, this property's value will be "No".

Note that if a payroll run is reverted, that will be reflected in this property.

By definition, the value of this property will always be "No" at shift creation.

State of salary types requiring approval

This property is a special case. When a bank holiday has a day-rule using the "Shift without matching punch" option, and the salary type generated as a result of that requires approval, then the approval of said salary type will be logged on this specific property. Similar to salary type rules, all of the above-mentioned salary types requiring approval will be contained within a separate table within the table. The separate table is expanded by default, but can be collapsed by clicking the two chevrons next to the property name.

Each salary type requiring approval in this separate table displays using the following format: [name of salary type] [custom salary code].

The sub-properties for each salary type requiring approval in this separate table display with the following sub-property:

  • State: possible values are "approved" and "unapproved"

By definition, the separate table will always be empty at shift creation.

Note that for all other occasions of salary types requiring approval, they will be logged as a property on the punch log items.

How do I know what properties were updated?

For items in your audit log search results that are of type Update, you're able to see more details about which properties were de facto modified at the time of the update by clicking the chevron in the left-most column of the table of search results.

As a result, an item sub-table for shift update actions expands, listing all item properties that were affected by the update in question as well as their corresponding values. The below illustrates what said sub-table for a shift can look like.

The following applies to the item sub-table for shift update actions:

  • It has one column for "Old value" and one column for "New value", which are used to indicate how the value of a given property has evolved.
  • "Old value" column values display with strikethrough, in an attempt to highlight that the value in question was made obsolete as of the update in question.
  • Just as in the item sub-table for shift create actions, the properties containing sub-properties display within separate tables, which are expanded by default, but can be collapsed at your discretion by clicking the two chevrons next to the property name.
    • This separate table has sub-headings indicating what action has been taken on the list of items (breaks, tasks, salary type rules etc). Possible actions are create, update, delete.
      • When breaks have been updated specifically, this will display as the break with the obsolete values being deleted and then created a break being created with the new values (refer to the above picture). The reason for this is strictly that of technical limitations.
      • The same goes for tasks that originate from a base schedule if they're updated in the base schedule and then re-rolled out, as well as if tasks are updated using an integration that makes use of our SOAP Web Services. This limitation regarding tasks is something we plan to resolve in the medium-term.
    • When a sub-item (such as a break, task, etc.) has been created, we will display N/A with strikethrough as value in the Old value column. When a sub-item has been deleted in Quinyx, we will display N/A as value in the New value column.
    • The "State of salary types requiring approval" property will display as updated when a salary type requiring approval is generated as a result of a bank holiday with the "Shift without matching punch" option is approved and unapproved respectively.
    Note that when one of these salary types are unapproved due to Quinyx re-calculating the correct salary - which happens depending on internal calls, for instance, when a user enters the manager portal's time card for the day the salary type is generated -, the "Action made by value" will be "Quinyx". Also, when a salary type as described above is configured to be automatically approved, the "Action made by" value will be "Quinyx" as well.

Bug and improvements history

The Quinyx logs are immutable. That means that if for some reason a bug occurs and the data that is logged by the system and displayed to you as a user is incorrect, and you report it, and we fix that bug, then that bug will be fixed for future occasions, but the data that was logged while the bug was in existence will, unfortunately, remain incorrect. The same goes for improvements. For that reason, the below table lists bugs and improvements pertaining to or somehow affecting log data along with relevant information, so that you know that it's unfortunate yet expected behaviour that should not be reported as a bug.

Bug description

Calendar dates applicable

Account specific

FAQ

What's the plan for the old audit logs?

We'll monitor usage of the old audit logs as we keep improving the current audit logs. We will perform very limited maintenance of the old audit logs during this time. With time, we'll remove the old audit logs completely, but will communicate this well in advance and abundantly in our bi-weekly release notes.

Do deleted items have sub-tables?

No, there are no sub-tables for delete actions in Quinyx' audit logs. The reason is that at a later point in time, you'll be able to see the full trail of an item and how it's evolved from the time of creation through its (potentially) many updates until the date it's (potentially) deleted.

It feels like some things are missing, and it's really frustrating to me. Why?!

We look at various data points when building a product. We also release the first version as soon as we can, but not before we're certain that it creates at least some value for many of our users. But it of course doesn't mean we stop there! We have a plan to continue to improve the audit logs for some time. We monitor usage as well as feedback sent to us when doing so. When submitting feedback to us, please note that:

  1. Submitting feedback to us in a language other than English is likely going to take longer for us to process.
  2. We look for trends in needs and preferences across customers when determining which feedback to act on.

What improvements can I expect to the audit logs?

In addition to the above, we plan for a number of improvements, for example:

  • Providing the ability to export the search results to Excel.
  • Enabling users to gain more insight into where a given action originated from, for instance, whether a shift was created in the Schedule view, through a Base schedule rollout through an integration.
  • Providing the ability to access a schedule item's full history from A to Z, including from the Schedule view.

Most importantly, our plan is to continue releasing logs for various parts of Quinyx, such as:

  • Shift bookings
  • Shift swaps
  • Shift unassignments
  • Absences and absence requests
  • Punches
  • Publishing and locking of schedule
  • Availability
  • Base schedule

We also plan to log changes made to configuration-related data such as roles, agreements, and agreement templates.

Stay tuned to our release notes and, as always, do feel free to feedback to us using the manager portal's Send us feedback form.

How Did We Do?