Audit log origin

Updated by Leigh Hutchens

Introduction

The audit log origin feature helps you understand where and how an action took place in Quinyx. It shows the source of each change—whether it happened in the manager portal, mobile app, staff portal, or through an integration—so you can trace actions with confidence.

Origins appear in smaller text beneath the name in the Action made by column and provide essential insight for reviewing activity, troubleshooting scheduling issues, and resolving disputes around workforce planning or attendance.

Each section below outlines the possible origin values you may see in your audit log and explains the context in which they appear. In most cases, the origin reflects the Quinyx platform where the action was triggered. When a change results from a system-driven process—such as ending employment, changing a home unit, or creating an absence—the origin identifies that feature instead.

Auto-Assign and Auto-Schedule origins aren’t currently available due to technical limitations, but improvements are in progress.

Origin for shifts

This section explains how Quinyx records where a shift action happened — whether it was created, updated, or deleted.

Use this table when:

  • A shift has changed unexpectedly and you need to confirm who or what caused it
  • You’re troubleshooting actions related to absences, integrations, or schedule rollouts
  • You want to understand the relationship between shift updates and employment changes

Common origins include:

  • Via Manager portal — manual actions by a manager in Schedule
  • Via Mobile — employee or manager actions through the Quinyx mobile app
  • Via base schedule rollout — automated creation or updates from a base schedule rollout
  • Via integration — API-driven actions
  • Due to absence / employment / home unit change — system-triggered updates based on HR or scheduling events

💡 Tip: Origins like Due to absence or Due to end of employment indicate that Quinyx made the change automatically based on business logic — not user input.

Action

Origin

Item

Cases

Creation

Via Manager portal

Shift

When a shift is created in Schedule within the manager portal.

Creation

Via base schedule rollout

Shift

When a shift is created in the schedule due to a base schedule rollout.

Creation

Due to absence

Shift

  1. When a shift is converted into an absence shift as a result of an absence being created on top of a shift. Note: This also applies to when an absence is added on top of part of a shift.
  2. When an absence is deleted and an absence shift is reinstated as a result. This applies regardless of which shift action out of delete/unassign/reassign was selected at absence creation.

Creation

Due to absence using absence schedule

Shift

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

Shift

  1. Employee adding shift in Mobile
  2. Manager adding shift in Mobile

Creation

Via integration

Shift

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

Shift

When a shift is updated in the schedule within the manager portal.

Update

Via base schedule rollout

Shift

When a shift is updated in the schedule upon a base schedule re-rollout.

Update

Due to absence

Shift

  1. When an absence is created, and the selected shift action is unassigned or reassigned, Quinyx unassigns/reassigns the original shift. (Under the hood, Quinyx simultaneously creates a new shift for the absence shift.)
  2. When a part-time absence is created for an existing shift, and as a result, either then start or end time of said shift is updated.
  3. When a part-time absence is deleted and, as a result, the first part of the existing absence is extended to reflect the time of the initial shift. Example: 
    1. Initial shift 8 am-4 pm
    2. Absence is added 10 am-2 pm
    3. The absence is removed
    4. As a result, the end time of the 8 am-10am changes to 4 pm
  4. When the employee punches out early or late and selects an absence reason, which in turn converts the corresponding part of the shift to an absence and thereby changes the shift start or shift end time accordingly.

Update

Due to "Update shifts" feature

Shift

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

Shift

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 due to this.

Update

Via Mobile

Shift

  1. When an employee updates a shift in Mobile
  2. When a manager updates shift in Mobile

Update

Due to agreement selection logic

Shift

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

Shift

When a shift is unassigned due to the assignee's end of employment date being changed to before said shift’s start date. 

Update

Due to change of home unit

Shift

When the home unit of an employee is changed, which means the following changes are triggered as a result by the system:

  1. The employee's future scheduled shifts are unassigned (but remain on the same unit)

Update

Due to agreement deletion

Shift

When the agreement used for a given shift is deleted.

Update

Due to shift unassignment approval / Via Manager portal

Shift

When the shift property employee is changed due to 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

Shift

When the shift property employee is changed due to 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

Shift

When the shift property employee is changed due to 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

Shift

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

Shift

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

Shift

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

Shift

When a manager deletes a shift in the Schedule in the manager portal.

Deletion

Via base schedule rollout

Shift

When a shift is deleted in the Schedule upon a base schedule re-rollout.

Deletion

Via Mobile

Shift

When a manager deletes a shift in Mobile.

Deletion

Due to absence

Shift

When a shift is deleted due to an absence being added. Note that this happens in the following cases:

  1. When an absence is created and shift action is deleted.
  2. When an absence is created using an absence schedule where the absence schedule is configured to replace "scheduled days" or "all days", meaning some of the existing shifts in the schedule are deleted as a result of said absence creation.
  3. When a part-time absence is deleted, and the absence shift (that was created by Quinyx in the background specifically to ensure that said part-time absence contained an absence shift) is removed from the system as a result.

Deletion

Via integration

Shift

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.

 

Origin for shift requests

Shift requests include shift swaps, unassignment requests, and assignments on away units. This section helps you identify how and where those requests originated or were handled.

Use this table when:

  • You’re verifying whether a request was made by an employee or manager
  • You need to trace who approved or denied a swap or unassignment
  • You’re troubleshooting requests that disappeared after a shift change

Common origins:

  • Via Mobile — employee actions in the app
  • Via Staff portal — employee actions on desktop
  • Via Manager portal — manager approvals or scheduling actions
  • Due to shift deletion / employment changes — system cleanup of requests tied to deleted shifts or ended employment

💡 Tip: If a shift is deleted or an employee’s employment ends, related requests are automatically removed. You’ll see these marked as Due to shift deletion or Due to ended employment.

Action

Origin

Item

Cases

Creation

Via Mobile

Shift swap

Shift unassignment request

When an employee creates a request in Mobile.

Creation

Via Staff portal

Shift unassignment request

When an employee creates a request in the Staff portal.

Creation

Via Manager portal

Shift assignment on away unit

When manager creates a request scheduling the employee on away unit.

Deletion

Via Mobile

Shift swap

Shift unassignment request

When an employee deletes a request in Mobile.

Deletion

Via Staff portal

Shift unassignment request

When an employee deletes a request in the Staff portal.

Deletion

Due to shift deletion

Shift swap

Shift unassignment request

Shift assignment on away unit

When the requests are deleted because the shift itself has been deleted.

Deletion

Due to ended employment

Shift swap

Shift unassignment request

Shift assignment on away unit

When the requests are deleted because the employee’s employment has ended.

Deletion

Due to employee deletion

Shift swap

Shift unassignment request

Shift assignment on away unit

When the requests are deleted because the employee itself has been deleted.

Approve

Via Manager portal

Shift swap

Shift unassignment request

Shift assignment on away unit

When the manager approves the request in the Manager portal using the Notifications panel section.

Approve

Via Mobile

Shift swap

When the employee approves shift swap in Mobile.

Deny

Via Manager portal

Shift swap

Shift unassignment request

Shift assignment on away unit

When the manager denies the request in the Manager portal using the Notifications panel section.

Deny

Via Mobile

Shift swap

When the employee denies shift swap in Mobile.

Deny

Due to shift reassign

Shift swap

When the shift swap is denied because a shift is reassigned to an employee who was in the list of employees but didn't apply for that shift.

Origin for shift offers

Similar to other audit log items, you can also see the origin associated with the shift offer item. 

Origin provides additional insight into where the action reviewed took place. As highlighted in the image below, the origin information is located in smaller text below the main value in the Action made by column of the view.

The table below contains an exhaustive list of the various origin values you may encounter as you browse your log search results and the cases in which the 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, suppose the action has been triggered by a specific feature that has cascading effects on other parts of Quinyx, such as deleting or reassigning the shift; this will display as the origin instead.

Action

Origin

Cases

Creation

Via Manager portal

When a manager creates a shift offer in the Manager portal.

Deletion

Via Manager portal

When a manager deletes a shift offer in the Manager portal.

Deletion

Due to automatic deletion

When Quinyx as a system deletes automatically an offer that hasn’t been handled by an employee and the shift has already started.

Deletion

Due to shift offer approval

When the shift is offered to multiple employees and it's approved by one, all other offers made to other employees will be deleted. 

Approve

Via Mobile

When an employee approves a shift offer in Mobile.

Deny

Via Mobile

When an employee denies a shift offer in Mobile.

Y

Origin for shift bookings

Similar to the shift item, you can see the origin associated with the shift booking item. 

Origin provides additional insight into where the action reviewed took place. As highlighted in the image below, the origin information is located in smaller text below the main value in the Action made by column of the view.

The table below contains an exhaustive list of the various origin values you may encounter as you browse your log search results and the cases in which the 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, suppose the action has been triggered by a specific feature that has cascading effects on other parts of Quinyx, such as deleting or reassigning the shift; this will display as the origin instead.

Action

Origin

Cases

Creation

Via Mobile

When an employee creates a shift booking request in Mobile.

Creation

Via staff portal

When an employee creates a shift booking request in the Staff portal.

Deletion

Via Mobile

When an employee deletes a shift booking request in Mobile.

Deletion

Via staff portal

When an employee deletes a shift booking request in the Staff portal.

Deletion

Due to shift deletion

When shift booking requests are deleted because of the shift itself has been deleted.

Approve

Via Manager portal

When the manager approves shift bookings in the Manager portal using the Notifications panel section.

Approve

Via Mobile

When the manager approves shift bookings in Mobile.

Approve

Due to shift reassign

When the manager approves shift bookings in the Manager portal by approving it using the list of applied employees.

Deny

Via Manager portal

When the manager denies shift bookings in the Manager portal using the Notifications panel section.

Deny

Via Mobile

When the manager denies shift bookings in Mobile.

Deny

Due to shift reassign

When the shift booking is denied because a shift is reassigned to an employee who was in the list of employees but didn't apply for that shift.

Note that we’re currently working on adding “Via Webpunch” for updates of shifts that occur as a result of an employee adding an unplanned task using Webpunch.

How Did We Do?