Recurring Work in a Business App: What Does “Every Month” Actually Mean?

Before commissioning recurring maintenance visits, inspections or internal tasks, agree on the rule that creates each occurrence. “Monthly” is not enough: the same day number, the last day of the month and a fixed interval are different promises. Show the next actual dates before anyone activates the series, and decide separately what happens when one visit moves or the app misses a run.

This is a guide to defining a recurring work series, not selecting appointment display zones, sending reminders or arranging automatic billing. The business rules below are recommendations. The cited iCalendar standard supplies specific calendar semantics, not a guarantee about any particular app.

Start with dates your team can recognise

Ask the person responsible for the work to write the next few expected dates, including a short month. Then name the rule that produces them.

A hypothetical maintenance plan might mean “the final calendar day of each month.” Another might mean “the last weekday of each month.” Neither necessarily means the last working day: a weekday can still be a public holiday or a company closure. If holidays matter, specify the relevant calendar, who maintains it and whether work moves earlier, moves later or needs manual review.

Do not replace a calendar-based rule with a fixed elapsed duration just because it is easier to implement. Equally, if the work genuinely follows elapsed time since completion, say so. A task due a month after the last completed visit is not the same series as one due on an unchanged monthly schedule.

Decide what a missing day means

For a series anchored to the 31st, ask what February should contain. Options include skipping that month, using its final day or asking someone to choose a replacement. Pick one deliberately; they create different work obligations.

RFC 5545, section 3.3.10 says recurrence instances with invalid dates or nonexistent local times must be ignored and not counted in the recurrence set. That is important when exchanging iCalendar data. It does not mean your business must accept skipped maintenance: an app promising a visit every month needs a rule that actually supplies one and an export strategy that preserves the agreed dates.

Request a preview across short months and relevant clock changes. A timezone label is useful, but it does not explain whether an occurrence is omitted, shifted or flagged.

Separate the series from a particular visit

Moving one visit should not silently rewrite the whole plan. Ask for clearly different actions: change this occurrence, or change the schedule from an agreed point forward. Describe what each does to occurrences that have already been confirmed or completed.

The standard provides a useful model for identity. In section 3.8.4.4, a rescheduled recurrence is identified using its original scheduled time: moving a Friday meeting to Thursday does not change that original recurrence identifier to Thursday. Your app need not expose that technical field, but a moved visit should still be recognisable as the same occurrence rather than appearing as extra work.

For cancellations, keep an explicit exception instead of simply removing a visible row and hoping the generator never recreates it. Section 3.8.5.1 describes iCalendar exclusions taking precedence over included dates. Whether a cancelled visit requires a replacement is a separate business decision.

A scheduled date is not evidence of completed work

Agree when future work records are created and how far ahead people can see them. A long-running series does not require an endless list of records on screen. It does require a clear distinction between planned, created, cancelled and completed occurrences.

If generation stops while the service is unavailable, decide how recovery behaves. Should the app create overdue work, flag missed occurrences for review or resume only with future dates? Do not assume all overdue tasks should execute immediately. This article does not promise reliable external notifications or automatic side effects; those need their own delivery and reconciliation design.

Demonstrate the agreement before launch

Put these examples into your acceptance criteria:

• A short month produces exactly the agreed outcome, not an unexplained missing visit.
• One moved visit retains its identity and leaves the other dates unchanged.
• A cancelled occurrence remains cancelled after regeneration.
• A series change shows its effective point and does not rewrite completed work.
• A pause and resume show what happened to dates during the pause.
• A simulated interruption produces the agreed overdue-work review, without duplicate occurrences.

Ask for a human-readable summary beside the preview, such as “final calendar day, paused dates omitted, changes apply from the selected occurrence.” If nobody can explain that sentence, the recurrence feature is not ready to build. Bring a real schedule and its exceptions to a web-app project discussion, rather than asking only for a repeat button.