Reference · built on requestOperator by FibricWorkforce & scheduling

Leave Conflict

Flags approved leave that overlaps a scheduled shift, and leave requests that would breach minimum staffing, and proposes the fix for each.

Request accessPricing ↗

About

Leave Conflict is an operator job that sits between your HRIS and your schedule. It reads approved leave and new requests from the HRIS, shifts for the same people and dates from the scheduling system, and the minimum staffing you set per site, role, and interval. Two things trip it: a shift still on the schedule for someone whose leave was approved, and a pending request whose dates would take a site below its floor.

For an overlap it proposes removing or reassigning the shift and offering it for cover. For a pending request it gives the manager the staffing picture for each day asked and, on their decision, proposes the approval or denial in the HRIS. The HRIS stays the record of leave; the schedule is corrected to match it.

This is a reference listing. It documents what Fibric would read from Leave Conflict and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • HRIS leave, approved and pending: BambooHR time_off/requests by status, HiBob timeoff.request events, Workday leaves of absence, Rippling leave requests, ADP Time Off Requests
  • Leave the scheduling system holds itself: Deputy Leave, When I Work /2/requests, Quinyx absence schedules, 7shifts time off, Connecteam time-off requests
  • Published and draft shifts for the same people and dates: Deputy rosters, When I Work /2/shifts, Quinyx /schedule/v3/shifts, Dayforce EmployeeSchedules
  • Minimum staffing per site, role, and interval: Quinyx optimal headcounts and labor standards, or the floor you set per site
  • Who else is out on the date: HiBob who is out today, BambooHR approved requests in the window, Workday balances and leaves of absence
  • Answers from managers on the proposals it posts in Slack or Microsoft Teams

Proposed actions

  • Target capability: propose removing or reassigning a shift that overlaps approved leave, as a Deputy roster update, When I Work shift update, or Quinyx absence
  • Target capability: propose a staffing view for a pending request: staffed against minimum for each day asked, and who else is already off
  • Target capability: propose approving or denying the request in the HRIS once the manager decides: BambooHR approvals, Connecteam time-off status, Workday requestTimeOff
  • Target capability: propose a cover offer for the shift the leave vacates, handed to the open-shift sequence
  • Target capability: propose a message to the employee explaining a denial with the staffing figures the manager relied on

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Clear Deputy shifts that overlap BambooHR leave

    Approved requests from time_off/requests are matched to rostered shifts by employee and date. Each overlap is proposed as a roster removal with a cover offer, sent to the manager in Slack.

    With BambooHR, Deputy, Slack

  • Check a HiBob request against Quinyx headcount

    timeoff.request.requested triggers a read of optimal headcounts for the days asked. The manager sees staffed against minimum in Microsoft Teams; on approval the absence is proposed at the Quinyx unit.

    With HiBob, Quinyx, Microsoft Teams

  • Keep When I Work and Workday in step

    A Workday leave of absence that spans published When I Work shifts is listed with each shift and a proposed update. A request Workday has denied never touches the schedule.

    With Workday, When I Work, Slack

Requirements

  • An HRIS or leave connector: BambooHR, HiBob, Workday, Rippling, or ADP Workforce Now; or a scheduling system that holds leave itself
  • A scheduling connector with shifts by employee and date: Deputy, When I Work, Quinyx, or Dayforce
  • A minimum staffing floor per site and role, from Quinyx labor standards or entered per site
  • Slack or Microsoft Teams for the manager's decision
  • For BambooHR and HiBob: a service user or API key permitted to see the time off policies in scope
Authentication
Leave, shifts, and staffing floors are read through the connectors you bind, with no credentials held by the operator, and each write goes through the connector that owns the record, under its scopes.

Limits

  • Leave it cannot see is not counted. BambooHR requests hidden by permissions and HiBob private policies stay invisible unless the service user is granted them
  • A staffing floor must exist per site and role. Without one the operator reports overlaps only and stays silent on pending requests
  • It does not decide leave. A pending request gets a staffing picture; the approve or deny is the manager's and is written on their answer
  • Where leave lives in two systems, the HRIS is the record and the schedule is corrected to match it, never the other way round

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Leave Conflict ↗

Questions and answers

What does the manager approve, and when?
For an overlap: the shift change, with the leave record beside it. For a pending request: the decision itself, shown with staffed and minimum for each day and the names already off. Nothing changes in either system before the answer.
What record is left?
The leave request or approval id, the shifts it touched, the staffing figures at review time, the manager's decision with its timestamp, and each write to the HRIS or the schedule with the system's response.
Does it approve leave on its own?
No. It never approves or denies a request, and never removes a shift, without a manager's answer. A request left unanswered stays pending in the HRIS and is listed again on the next pass.
Ask about Leave Conflict

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy