A weekly schedule app is mostly one grid and one button.
Strip a weekly schedule app down and two things are left: a grid of seven days that somebody edits, and a button that copies last week into this one. Almost every complaint about scheduling software is really a complaint about one of those two, and almost every rota mistake comes out of the copy button carrying something it should not have.
The rules a schedule has to obey are a separate subject, covered in work shift app. This page is about the week itself: how the grid should behave, what duplication should carry forward, what a recurring pattern actually is, and what has to happen at the moment you publish.
See what the copy button should carryThe short version
Copy the pattern and the gaps, never the one-off decisions.
The useful distinction is between a pattern and a decision. Shift times, roles needed, and the shifts you failed to cover are patterns: copying them forward saves an hour a week and surfaces a problem early. Approved leave, swaps and last-minute cover are decisions about one specific week, and carrying them forward books people off who are back at work.
Publishing is the other half. The moment a schedule goes out it stops being a draft and becomes a record, and in some places it becomes a record with legal weight. Once published, changes need to be visible rather than silent, both to the team and in the history.
The copy forward button, and what it gets wrong
Nobody builds a rota from scratch every week. They open last week, duplicate it, and change what moved. That is the correct workflow and it is why this button deserves more design attention than the grid does.
Copy people as a suggestion, not a result
Carrying names forward is genuinely useful, because most weeks most people work the same shifts. It becomes dangerous when the copy is treated as complete. Every carried name has to be rechecked against next week's availability and leave, and the ones that now conflict should be visible immediately rather than at publish.
Copy the holes
The shift nobody covered last week is the most valuable thing in the copy, and most apps drop it. Bring it forward as an open shift. A gap that recurs is a staffing problem, and seeing it three weeks running is how anyone finds out.
Try it
What should copy forward when you duplicate a week
Copy last week is the most used button in any weekly schedule app, and the one that quietly creates most of the mistakes. Choose what it carries.
3 choices worth reconsidering
- Last week's holiday is not next week's. Carrying it forward books people off who are back.
- A swap was a change to one week. Copying it makes a one-off into a pattern nobody agreed to.
- Copy them as open, not as filled. A gap you had last week is a gap you are about to have again.
Recurring patterns are a standard, not an invention
Sooner or later someone wants every other Tuesday, or the last Friday of the month, or weekdays except bank holidays. It is tempting to invent a small format for this, and it is a mistake, because the problem is old and solved.
The iCalendar specification, RFC 5545, defines a recurrence rule with a frequency, an interval, a count or an end date, and by-day, by-month-day and by-set-position parts that express every one of those cases. Following it means your patterns can be exported to a calendar, and more importantly it means somebody has already thought through what the last Friday of a month means in February.
The part worth knowing in advance is that a recurrence generates occurrences, and occurrences get edited individually. Somebody will change one Tuesday in a fortnightly pattern. If the data model cannot hold an exception to a rule, that single edit rewrites the pattern for everyone, which is a bug people find in week three.
RFC 5545, Internet Calendaring and Scheduling Core Object Specification
Building a week view without a calendar library
A practical note, since this comes up on every build. A week view looks like a calendar component and mostly is not one. A calendar library earns its place when you need arbitrary overlapping events positioned by time, drag to resize, and a month view. A rota usually needs none of that.
Seven columns, a row per person or per role, and a block per shift is a grid, not a calendar. It can be built from ordinary layout components, which keeps the bundle small and, more usefully, keeps the behaviour yours. Once a library owns the grid, every unusual thing your rota does becomes an argument with the library.
The one case that genuinely wants a time-positioned calendar is a schedule where shifts overlap heavily within a day and the overlap matters visually, such as a hospital floor or a crew scheduling app covering shifts that hand over mid-task. If that is not you, a grid is less work and ages better.
Publishing is an event, not a save
A draft rota and a published rota are different objects and the app should treat them that way. Editing a draft is free. Editing a published week is a change that someone has to be told about, and that the history has to keep.
In some jurisdictions that is not just good practice. Oregon requires covered large employers in retail, hospitality and food services to give workers a written work schedule at least 14 calendar days in advance, and to pay additional compensation when it changes: one hour at the regular rate for adding a shift or more than 30 minutes to one, and one half the regular rate per scheduled hour for hours removed or a shift cancelled.
Whether or not that applies to you, it describes the data you want: the schedule exactly as published, the timestamp, and every subsequent change with a name against it. Build that from the start and the legal question becomes a reporting question rather than a rebuild. These rules differ by city and state, so check the one where you operate rather than assuming Oregon's numbers, and treat the whole thing as part of wider employee management apps rather than a scheduling feature.
Oregon Bureau of Labor and Industries, predictive scheduling
What each way of running a week gives you
| Option | Copy last week | Recurring patterns | Change history | Team sees it immediately |
|---|---|---|---|---|
| Printed rota on the wall | photocopier | No | No | only in that room |
| Spreadsheet | duplicate the tab | by hand | if nobody overwrites it | No |
| Group chat | No | No | buried in messages | Yes |
| Off-the-shelf scheduling platform | Yes | Yes | Yes | Yes |
| A weekly schedule app you build | Yes | Yes | Yes | Yes |
Building one around your own week
Scheduling products are usually good and usually assume a shape: a week that starts Monday, shifts that belong to one person, a manager who approves everything. Plenty of teams do not fit. A week that starts Thursday because that is when the rota runs. A shift two people share. An approval that depends on which department the cover came from.
Newly is an AI app builder. You describe the app you want, including the shape of your week, and it builds and ships a real mobile app you own. Plans start at $25 a month, there is no free plan, and iOS builds ship through App Store Connect. It is not a scheduling product. It is what you use when the one you tried cannot express something ordinary about how your week runs.
Design the publish step before the grid, because it is the part that affects people. A rota published into a system nobody opens has not been published, which is why it is worth reading about publishing next week to the team before deciding what the button does.
Questions people ask about weekly schedule apps
It is the tool a team uses to build, publish and change a rota one week at a time. In practice it is a seven day grid that somebody edits, a way of copying the previous week forward, and a publish step that tells the team what changed and keeps a record of it.
Describe the week as your team actually runs it
Write down when your week starts, what copies forward and who has to approve a change, and build the schedule around that instead of a template.
Start building