Stop a recurring appointment
Prevent future cycles while preserving the parent and all appointments already generated. The guide then takes you through the correct route, the checks to complete before making changes, the workflow in order, and the evidence to review afterwards.
What you’ll accomplish
Prevent future cycles while preserving the parent and all appointments already generated. It uses Britixo's permission-aware appointment, availability, status and integration flow rather than an unconnected diary entry.
How the module flow works
The stop action disables the parent's future recurrence processing.
Cron no longer creates new child appointments from that parent.
Existing appointments remain available for normal status, cancellation, calendar and history handling.
Follow these steps
- Go to the recurrence parent.
- Check future/generated appointments.
- Select Stop recurrence.
- Verify the action.
- Check the recurring state is disabled and existing children remain.
Fields and decisions to review
How to confirm it worked
After this workflow completes, Britixo keeps the appointment and its supported relationships connected. Reopen the appointment and verify the saved status, date, timezone, customer or lead, service, provider, attendees, reminder state, calendar or meeting reference, invoice reference and history that apply to this feature. External email, SMS, Google, Microsoft or payment outcomes must be checked separately from the Britixo database save.
- Open the saved appointment and confirm the final status and source.
- Check the participant, provider, timing and timezone from the full detail page.
- Review the relevant table filter, calendar, history, report or linked invoice instead of relying only on a success message.
Controls, checks and common mistakes
- Stopping recurrence does not cancel generated appointments.
- Do not delete history to end recurrence.
- Check participant commitments already communicated.
- Use the least destructive correction and retain the appointment history when the booking existed operationally.
- Never bypass a permission, availability, approval, client-access or verification control by changing an unrelated route or setting.
