Goal: keep a schedule running, but submit only when it should — pause on a status, stop while a case is closed, submit only while a flag is set.
The schedule keeps ticking; individual occurrences are skipped.
Three Different Conditional Checks #
The feed offers three, at three different moments. They are easy to mix up.
| Check | When it runs | What it decides |
|---|---|---|
| Enable Condition | Once, when the form is submitted | Whether this entry starts a series at all |
| Conditional Logic (Current Parent Entry) | Before every occurrence | Whether the parent as saved right now still qualifies |
| Conditional Logic (Child Entry) | Before every occurrence | Whether the submission about to be created qualifies |
The two per-occurrence checks appear only while feed conditional logic is enabled.
Setting It Up #
- Enable the feed’s Enable Condition and define the rule.
- Tick Evaluate feed conditional logic against the Current Parent Entry before every resubmission, or …against the Potential Child Entry, or both.
- Save.
Which One Do You Want? #
Parent check #
Evaluated against the parent entry’s current database values.
Use it when something about the record decides eligibility: a status field an administrator updates, a membership flag, a case that gets closed.
Edit the parent entry’s status to
On holdand the series quietly stops submitting — without pausing, without failing, and it resumes on its own when the status changes back.
Child check #
Evaluated against the final hydrated submission, including any date updates and Dynamic-mode lookups.
Use it when something about this particular occurrence decides eligibility: a looked-up value that came back empty, a date that landed in a blackout period, a calculated amount of zero.
What a Skip Does #
| Effect | Skip |
|---|---|
| Child entry created | No |
| Successful count raised | No |
| Consecutive failures raised | No |
| Recorded in attempt history | Yes |
| Schedule continues | Yes |
A skip is not a failure. A series whose conditions never pass keeps running quietly and never trips the failure threshold.
The same is true of a skipped missed run — both kinds of skip behave identically.
Worked Examples #
Only while a case is open #
- Parent entry has a Case status field.
- Feed condition: Case status is Open.
- Enable the Current Parent Entry check.
- Result: closing the case stops the submissions; reopening it resumes them, with no operator action either way.
Only when a lookup returned something #
- Dynamic input mode with a Populate Anything field.
- Feed condition: Assigned inspector is not empty.
- Enable the Child Entry check.
- Result: occurrences where nobody is assigned are skipped instead of creating a useless entry — or failing validation.
Only for premium members #
- Parent entry has a Plan field, editable by staff.
- Feed condition: Plan is Premium.
- Enable the Current Parent Entry check.
- Result: a downgrade stops the schedule without cancelling it, so an upgrade restores it.
Skipping Specific Dates #
Conditional logic works on entry values, not on the calendar. For date-based exclusions:
| Need | Approach |
|---|---|
| Skip weekends | Use the Monday–Sunday allowed-weekday checkboxes — a disallowed slot moves forward to the next allowed day. |
| Skip a specific holiday once | Use Change next submission to move that occurrence. |
| Skip a recurring blackout window | Add a field carrying the relevant date state and condition on it, or handle it in rfsfgf_next_occurrence. |
Built-in blackout dates and business-day offsets are on the roadmap.
Seeing Skips #
Every skip is recorded in View attempt history with its target, actual time and outcome. If a schedule looks idle, history will tell you whether it is skipping or simply not running at all.
