Audit logs - Absence requests

Updated by Leigh Hutchens

Audit logs are records of past actions within Quinyx. There are two types of absence related audit logs that can be extracted from Quinyx: 

  1. Absence request audit logs (this page)
  2. Absence audit logs

They provide a transparent history of who initiated an absence, who performed an action, what the action was, when it occurred and so on. This functionality helps managers:

  • Resolve disputes or questions related to absence requests.
  • Understand how absence requests are created, updated & processed.
  • Access historical activity data for self-service insights into team management.
  • Derive key information for workforce planning and unit-level analysis.
This page focuses only on the audit logs for absence requests. To see details about audit logs for absences, click here.

Absence request audit logs

For absence requests, audit logs provide a clear history of actions and can help answer questions such as (not limited to):

• Who created the absence request, and when?

• Who was the request sent to?

• Who approved or denied the request, and when?

• Who deleted the request, and when?

• What comments were added (by the employee and/or manager)?

To see the audit logs for absence requests, navigate to:

Audit logs > Adjust view > [Item type] Absence request.

The "Adjust view" panel allows you to refine your search for audit logs using the following filters. 

Filter

Description

Groups

This tree allows you to select groups for which Quinyx fetches audit logs. 

  • It contains a free text field that helps find groups. 
  • The tree is collapsed by default & can be expanded.
  • Selecting a group automatically includes its child groups, though these can be deselected.

Item Type

  • You can select the specific items for which Quinyx should fetch logs using this field. This is a mandatory field. 
  • Select Absence request in this field. 

Item start/ end date

  • These dates define the start and end of the period in which the items you are searching for begin.
  • They are optional fields.
  • The maximum period you’re able to specify is three months.
  • The search carried out considers the business daybreak of the group the item takes place on.

Type of action

  • Use this field to filter the logs by the possible actions associated with an item.
  • Currently, you're able to perform any, several, or all of the following action for absence requests:
    • Approved
    • Created
    • Deleted
    • Denied
    • Updated

The field will read "All" by default, meaning that logs for all of the above-listed actions will be fetched by Quinyx.

Action Start/end date

  • These date fields allow you to set the start and end date of the period within which the action on the item you're looking for was carried out in Quinyx.
  • This is a mandatory field and by default, the "Action start date" is set to three months prior to the current date, while the "Action end date" is set to today's date.
  • These are always in the same time zone as the group currently selected in the group selector of the top bar.

Action made by

  • This field can be used to filter out items to display based on which user has carried out an action. 
  • The default value of the field will be “All” text, meaning all managers/employees (as defined above) are included in the search by default. The dropdown values will be sorted alphanumerically.
  • The field is searchable via a text field. 
  • If an integration caused the action, the displayed data depends on the Quinyx API used:
    • REST Web Services: The integration credentials' name or UUID.
    • SOAP Web Services: "SOAP."

Action made for

  • This field can be used to filter out items to display based on which user has been impacted by an action in Quinyx. 
  • This field allows you to search for any user with an employee role in the group(s) selected. This means that editing your selections in the group's tree after populating the Action made for the field will reset the field.
  • Each employee in the field’s drop-down will display as per the following format: [first name] [last name] [badge number]
  • 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. The employees in the list are sorted alphabetically.
  • The default value is “All” meaning that if you leave this field blank when clicking “Apply” in the Adjust view panel, log results will show for all employees in that group. 

Interpreting absence request audit logs: A guide to understanding results

Once you have applied the filters, you will see the audit logs page displaying your results and you can see details such as who created the request and the date and time of the action. 

The table below details the information presented within the absence request audit logs.

Column Header

Explanation

Time Stamp

  • This column shows the date and time of actions in Quinyx. You can sort by timestamp (newest to oldest by default). 
  • Dates and times follow Quinyx language settings and are displayed in the time zone of the selected group.

Groups affected

Displays the units and sections affected by the item.

Item type

Displays the type of item affected by a given action.

Item

Displays information to help identify which absence request has been actioned and the actions made.

This will always show the latest state of that item   aligned with the schedule view i.e. the date and time, absence type of that item. 

Action

Identifies the type of action carried out.

Action made by

  • Identifies who performed the action. Shows their [first name] [last name] ([badge number]).
  • If the employee was deleted, it displays "Employee has been deleted from Quinyx."
  • If a Quinyx system administrator performed the action, it shows (Quinyx employee )([internal Quinyx employee database id]) to protect their privacy while allowing transparency and troubleshooting. 
    • However, if a Quinyx employee with a role in your company's Quinyx account performs the action, it uses the standard format.
  • If an integration caused the action, the data displayed depends on the Quinyx API used:
    • REST Web Services: The integration credentials' name or UUID.
    • SOAP Web Services: "SOAP."

Action made for

Identifies who was affected by the action. The person carrying out the action is indicated as: [first name] [last name] ([badge number]).

If the affected person has been deleted, it displays "Employee has been deleted from Quinyx." The reason for this is that the system no longer holds that information. 

Trail

(!) This feature is currently under development for absence request item types.

Property table

Most absence request items (based on the action) have more details inside a sub-table called the property table, accessed by clicking the chevron on the leftmost column of the main table.

Note: Items with a delete action do not have a property table. 

Below is a list of properties that are displayed in the property table depending on the action performed on the absence request. 

In the table, a checkmark (✅) next to a property for a specific action indicates that the property may be displayed if there are changes to it, unless it says (always).

For instance, the "Unit" property is always displayed when an absence request is "Created". However, during an "Update" action, it only appears if the unit field has been modified. It will not be shown for "Approve", "Deny", or "Delete" actions, regardless of changes. Therefore, if a property has a cross-mark ❌ for an action, it will not be displayed for that particular action.

Property

Value

Create

Update

Approve

Deny

Delete

Unit

The unit group the absence request belongs to

✅

(always)

✅

❌

❌

❌

Absence type

The absence type selected for the absence request

✅

(always)

✅

✅

❌

❌

Absence schedule

The linked absence schedule (if any)

✅

(always)

✅

✅

❌

❌

Date and time 

Describes the start and end time of the absence request

✅

(always)

✅

✅

❌

❌

Send to

Refers to the manager the absence request was sent to

✅

(always)

✅

✅

❌

❌

Employee comment

The ‘employee comment’ on absence request creation. If no comment was added, it will show as "N/A."

✅

(always)

✅

❌

❌

❌

Manager comment

Manager's comment for approved or denied absence requests. If no comment was added, it will show as "N/A."

❌

❌

✅

(always)

✅

(always)

❌

Search results

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

Coming soon

We are continuously improving this functionality, and here are some enhancements coming next: 

  1. Item trail
    Get a chronological view of everything that has happened to a given item. This helps provide the necessary context when resolving disputes or issues related to workforce planning and attendance.
  2. Origin
    See where an action originated. For example, when reviewing an absence request, you’ll be able to identify whether an action originated from the manager portal or via staff portal on the mobile app.
  3. PDF export
    Export the audit logs report as a PDF for easier sharing, record-keeping, and analysis.

FAQs

Q: I see ‘Quinyx employee [employee ID]’ in the ‘Action made by’ field - what does that mean?

A: Sometimes, an action on an item can be made by a System Administrator on behalf of a user. In such cases, the ‘Action made by’ field may contain ‘Quinyx [employee ID]’. This refers to a Quinyx system administrator who was active on at least one of the dates within the Action start date - Action end date range (displayed as ‘Quinyx employee [employee id]’).

Q: How can I get a full list of all actions made by a manager on absence requests?

A: You can do this by filtering the manager's name in the ‘Action made by’ field.

Q: How do I know what properties have changed since the creation of an absence request?

A: The property table for absence request typically displays changes (i.e. properties that have changed) for actions other than creation. 

The only exception is the "Manager comments" field, which is always visible during approve and deny actions, even if no changes have occurred. If there are changes, you'll see two columns: "old value" and "new value." The "Old value" column displays with a strikethrough, indicating that the old value is obsolete and replaced by new value. 

An example of how the changed properties are shown in the property table.

Q: Why does the audit log show “different” dates when an overlapping absence request is sent on top of an existing one that already had a decision (approved or denied)?

A: When an absence request is submitted and processed (approved or denied), and later another request is submitted with overlapping dates, Quinyx adjusts the original absence request to avoid duplication of dates. This means the original absence request is split or shortened so that overlapping days are removed.

This adjustment keeps absence records clean and prevents double-booking of absence days, but it can cause the dates shown in the audit log to look different from the dates in the original request.

Example:

  • Step 1: Employee Sam Whon requests absence for 24/11 – 29/11.
  • Step 2: Manager Triss Tworthie reviews and denies it, suggesting Sam takes absence starting Wednesday (26/11) instead.
  • Step 3: Sam submits a new absence request for 26/11 – 1/12.
  • Step 4: Triss approves this new request.

The audit logs now records these actions as follows:

  1. First absence request created.
  2. First request denied.
  3. Second absence request created.
  4. Second request approved.

To summarise, there are cases where a new absence request will overlap existing absence request or absences. In such cases, Quinyx adjusts the original request so it no longer includes the overlapping days. In the above example, the original request appears in the audit log as 24/11 – 26/11 (00:00) instead of the initially requested 24/11 – 29/11. The original dates are still accessible in the property table, but the audit log records the item with the adjusted dates.

This behavior is by design to ensure clarity in absence records and avoid overlapping absence days.

As a result, the audit log reflects the adjusted dates rather than the original ones, which may appear “incorrect” but is in fact by design to prevent overlapping absences.

How Did We Do?