Overview
The meeting confirmation flow governs how a pending meeting request becomes a confirmed meeting.
-
The recipient must click Accept to confirm, with no implicit confirmation via other actions.
-
A clear Decline control sits alongside Accept on every pending request, both in the list view and on the request detail view.
-
A confirmation dialog appears before Decline is finalised, preventing accidental declines from a mis-click.
-
Once a request is confirmed, both parties receive an immediate notification (in-app, push and email per the user's preferences).
Status transitions
-
Pending — request has been sent and is awaiting recipient action.
-
Accepted — recipient has confirmed; the meeting is on both schedules.
-
Declined — recipient has refused; the requester is notified and the slot is released.
-
Expired — pending request reached the configured expiry without action; treated as declined for reporting.
-
Cancelled — either party cancels a previously accepted meeting before it starts.
Notifications
Each transition triggers a notification to the relevant party. Notification content includes the counterpart name, meeting time, table or location and a deep link to the meeting detail view.
Edge cases
-
If the recipient's schedule becomes incompatible (overlapping confirmed meeting) between request and accept, the system blocks the accept with an explanatory message and offers to propose a new slot.
-
Concurrent accept attempts on the last available slot are resolved server-side; only the first request to land is confirmed and the others are returned with a friendly conflict message.