Approve a client reschedule request
Apply a valid requested date and time after checking provider availability, reminders, calendar events and participant communication.
What this feature does
Apply a valid requested date and time after checking provider availability, reminders, calendar events and participant communication. It uses Britixo's permission-aware appointment, availability, status and integration flow rather than an unconnected diary entry.
How the module flow works
The approval action requires the module Approve permission and a pending reschedule request.
It updates appointment timing and request state after validation.
Calendar events, meeting details, reminders and notifications may require update through configured integrations.
Step-by-step workflow
- Open the appointment with the pending request.
- Review the proposed time, provider schedule and conflicts.
- Approve the request.
- Confirm updated date, time, timezone and history.
- Verify notifications and remote calendar updates.
Important fields and decisions
What happens after completion
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
- Do not approve without rechecking availability.
- Review service buffers.
- Confirm the customer received the revised schedule.
- 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.
