Check Settings: Validity & Scheduling

When setting up a check in Zipline, three configuration areas work together to define when a check is first due, how compliance is maintained over time, and whether workers get any buffer before becoming non-compliant. Understanding how each setting works — and how they interact — helps you set up checks that behave exactly as intended.

These settings can be used independently or in combination, depending on the requirements of the check.

The Validity setting determines how Zipline handles compliance after a check has been completed and approved. There are three approaches: the check is not renewed, it is renewed on a defined cycle, or it is actively monitored by Zipline over time.

Choose Not renewed when the check is a one-off requirement that does not need to be repeated.

Once a check record is finalised and approved, it is treated as permanently compliant. Zipline will not generate a renewal cycle from the issue date or expiry date, and no future due date is created.

When to use this This option suits checks that are completed once per worker, such as a declaration, an acknowledgement of a policy, or a one-time verification that does not have a time-limited validity.

📌 Example: A worker completes a one-off declaration for a specific check. Once approved, that record is treated as complete with no ongoing renewal expected.

Choose Renewed when the check needs to stay current over time. Zipline calculates a new due date after each approved record, based on one of three renewal methods.

The next due date is driven by the expiry date recorded on the check.

This is appropriate when the underlying document or credential has its own expiry date that determines when renewal is required. For example, a licence, certification, or credential with a fixed end date.

When to use this Use when workers submit documents or credentials that carry their own expiry dates, and those dates should drive the renewal schedule.

📌 Example: A worker uploads a document with an expiry date of 30 June 2027. Because the check is configured as Renewed → Based on expiry date, the next due date is set from that expiry date.

The next due date is calculated by adding a configured period to the check's issue date.

If no issue date is available on the record, Zipline uses the reviewed date as a fallback.

When to use this Use when renewal should be tied to how long ago the check was issued. For example, renewing every two or three years from the date the credential was originally issued.

📌 Example: A check is configured to renew every 3 years based on issue date.

If no issue date is available, Zipline uses the reviewed date instead.

The check renews on a defined calendar date at a set interval. For example, 1 November every year rather than being tied to each worker's individual issue or expiry date.

When configuring this option, you set:

Zipline uses the issue date first to determine the renewal date. If no issue date is available, it falls back to the reviewed date.

⚠️ 90-day proximity rule: If a worker completes a check within 90 days either side of the configured recurring date, Zipline automatically moves their next due date to the following recurrence. This prevents workers from completing a check just before the shared date and being immediately due again.

When to use this Use when all workers should align to a common renewal date regardless of when they individually completed the check. This is common for organisation-wide annual requirements.

📌 Example: A check is configured to recur on 1 November every 12 months.

Choose Monitored when the check does not follow a standard renewal cycle but instead requires active, ongoing monitoring by Zipline.

Rather than calculating a due date from an issue or expiry date, Zipline continuously monitors the latest approved record. The compliance card displays the last checked date and the next auto-check date where supported.

When to use this Use for checks where compliance status is determined by external sources that Zipline re-checks automatically, such as registrations, licences, or orders that can change status at any time.

Checks currently using the Monitored configuration include:

📌 Example: A worker has a check that requires ongoing monitoring. Instead of a manual renewal period, Zipline continues checking the latest approved record and surfaces the most recent monitoring activity and next scheduled check date.

The Grace period setting adds a buffer after the due date before a worker's status becomes non-compliant. This gives workers and administrators a defined window to complete a renewal without immediately triggering a non-compliant status.

The grace period is configured as a duration. For example, 1 month or 2 weeks, and applies after the primary due date has passed.

When to use this Use when you want to allow a short window for renewals without making the worker immediately non-compliant on the exact due date. This is particularly useful when processing or submission delays are expected.

📌 Example: A check is configured with:

The Scheduling setting controls when collection for the check is first required. This is separate from validity. It determines the first due date rather than ongoing renewal dates.

Choose Static when all relevant workers should complete the check by a specific fixed calendar date, regardless of when they started work.

When to use this Use for organisation-wide or cohort-wide requirements where a deadline applies to everyone at the same time. For example, a new compliance requirement being rolled out with a specific collection deadline.

📌 Example: A customer wants a declaration collected by 1 June 2026 for all relevant workers. Static scheduling sets that specific date as the first due date for everyone.

Choose Dynamic when the first due date should be calculated from each worker's first day of work, after a configured period.

This means the first due date differs from worker to worker, based on their individual start date.

When to use this Use when timing should depend on when each worker joins. For example, requiring a check to be completed within the first 3 months of starting.

📌 Example: A check is configured to be due 3 months from first day of work.

When a check has more than one due date rule in effect at the same time — for example, both a validity-based due date and a scheduling-based due date — Zipline always uses the due date with the longest validity.

This means the later due date takes precedence over the earlier one for compliance purposes.

📌 Example: A check is configured with:

Because the scheduling-based due date is later, the worker is treated as compliant until 10 May 2026. The longer-validity due date always wins.