> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flowpayroll.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Working patterns

> Record the days an employee works, set organisation and pay-run defaults, and control the qualifying days that statutory sick pay is based on.

A working pattern records which days of the week an employee actually works. Flow Payroll uses it to work out statutory sick pay: SSP is paid for qualifying days, and how much a single day is worth depends on how many days that employee works in the week. Get the pattern wrong and the daily rate is wrong.

Everyone has a pattern, whether or not anybody set one. If an employee has none of their own, Flow Payroll falls back through the pay run, then the organisation, then a built-in Monday to Friday week.

## The three kinds of pattern

Pick the one that describes how the person actually works. They are alternatives, so only one applies at a time.

<CardGroup cols={3}>
  <Card title="Same days every week" icon="repeat">
    A fixed week. Tick the days worked and they repeat indefinitely. This covers most salaried staff.
  </Card>

  <Card title="Repeating rota" icon="arrows-rotate">
    A rotation that repeats on a cycle, starting from a date you choose. Either a named rota, or a custom one you set week by week.
  </Card>

  <Card title="Set week by week" icon="calendar">
    A genuinely irregular schedule with no repeat, where each week is listed individually. For shift workers whose hours change constantly.
  </Card>
</CardGroup>

### Same days every week

The simplest case: seven true/false flags, one per weekday. Someone working Monday to Thursday has four working days a week, and SSP divides by four.

### Repeating rota

A rota starts on a **rotation start date** and repeats from there forever. You choose a rota type:

| Rota | What it means |
| - | - |
| 5 days on, 2 off | Monday to Friday |
| 4 days on, 4 off | Four worked, four off, rolling — so the days drift through the week |
| 3 days on, 3 off | Three worked, three off, rolling |
| 2 days on, 2 off | Two worked, two off, rolling |
| 4-4-5 rota | A six-week cycle: four weeks Monday to Friday, then two weeks Monday to Saturday |
| Custom | You set the worked days for each week of the cycle yourself |

The five named rotas have their shape built in — you only supply the start date. **Custom** is the one you spell out.

<Note>
  A custom rota is an **ordered list**. Starting from the rotation start date, each entry applies for its number of days, then the next one takes over, and when the list runs out it starts again from the top. The cycle length is simply the durations added together — so two entries of seven days each give you a fortnightly rota.

  Because the order is what defines the rotation, reordering the list changes the pattern. There is no separate week number to set.
</Note>

### Set week by week

Each week is listed with its own start date and its own worked days. Weeks you do not list count as not worked, which is deliberate: a week with no shifts is a real state, not missing data.

Weeks must be at least seven days apart so they cannot overlap, and a week can start on any weekday — shift and pay weeks are often not Monday-based. A schedule holds at most 53 weeks at a time; feed later weeks as they get scheduled.

This is the pattern to use when an external rota system pushes shifts into Flow Payroll.

## Which pattern applies to whom

Flow Payroll resolves a pattern most-specific-first, and stops at the first one it finds:

<Steps>
  <Step title="The employee's own pattern">
    Set on their record, or through the API. Always wins.
  </Step>

  <Step title="The pay run default">
    Set in **Pay run settings**. Applies to everyone in that pay run without their own pattern.
  </Step>

  <Step title="The organisation default">
    Set in **Settings → Working patterns**. Applies to everyone else.
  </Step>

  <Step title="Monday to Friday">
    The built-in fallback when nothing else is set.
  </Step>
</Steps>

On an employee's record, a note above the pattern tells you which of these is currently in force, so you can see at a glance whether the pattern shown is theirs or inherited.

<Warning>
  An employee record always shows a working pattern, even when nobody has chosen one for that person. Seeing Monday to Friday on screen does not mean it was set deliberately. Check the note above the pattern to see where it came from.
</Warning>

## Patterns change over time

Working patterns are **effective-dated**. Saving a pattern does not overwrite the old one — it adds a new version that applies from a date you choose, and the previous versions stay on record.

This matters because statutory sick pay for a past date has to use the pattern that was in force *then*, not the one in force today. Someone who moved from three days a week to five in July should have a June sickness paid on the three-day pattern.

Set the same effective date twice and the second save replaces the first, so correcting a mistake does not leave a stray version behind.

## Going back to an inherited pattern

Giving somebody their own pattern takes them out of the defaults, and sometimes that was not what you wanted. Removing a version puts them back: once an employee has no versions of their own left, they fall through the cascade again to the pay run default, then the organisation default, then Monday to Friday. The same applies to the qualifying-day policy.

On the employee's record, when the pattern shown is their own, the note above it carries a **Use the default** button. Confirming removes every pattern they had of their own, so the cascade applies again. The qualifying-day section has the same control when they have their own policy.

<Note>
  Through the API there are two ways to do this. `DELETE /employees/{employeeId}/working-pattern` clears the whole history in one call, which is what the button does. `DELETE /employees/{employeeId}/working-pattern/{effectiveFrom}` removes a single version by its effective date, for correcting one dated entry — bear in mind that only reveals the version before it. Both have a qualifying-day-policy equivalent.
</Note>

## Qualifying days and SSP

Qualifying days are the days SSP can be paid for. They are usually the days worked, but HMRC treats them as **agreed** between employer and employee rather than simply derived from the rota, so Flow Payroll keeps them separate from the working pattern. You choose how they are decided:

| Setting | What it does |
| - | - |
| Derive from pattern | Qualifying days are the working days. The right answer for most people. |
| Agreed fixed days | You pick the qualifying days explicitly, regardless of which days are worked. |
| Wednesday default | The statutory fallback where no agreement exists. |

<Note>
  Every week must have at least one qualifying day — that is a statutory floor, not a Flow Payroll rule (SSP (General) Regulations 1982, regulation 5). If a pattern would otherwise leave a week with none, the Wednesday default covers it.
</Note>

Like working patterns, qualifying-day policies are effective-dated and can be set per employee, per pay run, or organisation-wide.

## Setting a pattern

<Steps>
  <Step title="Open the employee's record">
    Go to **People** and click the employee's name.
  </Step>

  <Step title="Edit employment information">
    Find the **Employment information** card and click edit.
  </Step>

  <Step title="Choose the kind of pattern">
    Pick **Same days every week**, **Repeating rota**, or **Set week by week**. Switching between them keeps what you had entered in the others, so you can compare before deciding — only the one you have selected is saved.
  </Step>

  <Step title="Fill in the days">
    Tick the days, choose the rota and its start date, or click the days worked on the calendar. The calendar preview below always shows how the pattern actually falls, so you can check it before saving. For the week-by-week calendar, hold **Shift** and click to fill a run of days at once.
  </Step>

  <Step title="Save">
    The pattern is recorded from today. The card returns to view mode showing the saved pattern.
  </Step>
</Steps>

To set defaults instead of an individual pattern, go to **Settings → Working patterns** for the organisation, or the **Working patterns** section of **Pay run settings** for a single pay run.

## Setting patterns through the API

| What | Endpoint |
| - | - |
| Read an employee's pattern history | `GET /employees/{employeeId}/working-pattern` |
| Set an employee's pattern from a date | `PUT /employees/{employeeId}/working-pattern` |
| Push a batch of scheduled weeks | `PUT /employees/{employeeId}/working-schedule` |
| Remove the whole pattern history | `DELETE /employees/{employeeId}/working-pattern` |
| Remove one pattern version | `DELETE /employees/{employeeId}/working-pattern/{effectiveFrom}` |
| Read or set qualifying days | `GET` / `PUT /employees/{employeeId}/qualifying-day-policy` |
| Remove the whole qualifying-day history | `DELETE /employees/{employeeId}/qualifying-day-policy` |
| Remove one qualifying-day version | `DELETE /employees/{employeeId}/qualifying-day-policy/{effectiveFrom}` |
| Organisation defaults | `GET` / `POST /organisation/working-pattern-defaults` |
| Pay run defaults | `GET` / `POST /payrollconfig/{payrollConfigId}/working-pattern-defaults` |

`PUT /working-schedule` is the one to use from a rota or scheduling system. It merges the weeks you send into the employee's existing schedule by week-commencing date, so pushing the same week twice updates it rather than duplicating it, and you can send one week or many.

See the [Pay API reference](/api-reference/pay-api/overview) for full request and response shapes.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.