Handling requests¶
The requests that reach the staff are of three kinds, and they live in three different places.
Requests to join the organization¶
Whoever looks for your organization from the app and asks to join ends up in Registry → People, in the Access requests box.
They are approved by linking the person to the right registry record: the full procedure, with the warning about duplicates, is in Registry.
Availability requests¶
These are the ones you send: you ask a person to cover a shift.
They are created from the shift, by inviting the person (see Availability and attendance). Whoever you invited you see on the shift itself: in the organizer card that person already shows as invited and is not offered again for a second invitation.
The person invited receives a notification taking them to the shift, where they find the invitation at the top and the Accept and Reject buttons: they answer from there, looking at the time, the tasks and the colleagues already signed up.
You additionally have the Availability requests list, which collects all those still pending for the organization: Shift (with day and time), Task, Recipient, Expires on and the Status. It is the place from which to see at a glance how many invitations are outstanding and to whom; tapping a row reopens the form the invitation was sent with, and the answer buttons appear only to whoever received the invitation.
The list is not in the menu
You reach the page by a direct link — from the notification, or from the address — not from a menu entry. If you need to keep an eye on it, save it in your browser bookmarks: the everyday work on invitations is done from the shift anyway.
Only pending requests
The list shows the requests still open. Those accepted, rejected or expired do not stay in view: you read the outcome on the shift, where the person either is or is not.
How an availability request behaves¶
A request does not hang around forever. It lapses by itself when one of these happens:
- the deadline you set has passed;
- the shift has started — at that point it is of no further use;
- the shift has become full, if you left active the option that makes the request lapse once coverage is reached. It is the default behaviour and it is what you want almost always: if you invite three people for one place, the first answer closes the matter for the other two.
If instead you turn that option off, the request stays valid even with the shift full: accepting it, the person is added anyway. Use it only when you really want more people than the minimum.
There can be only one request per person on each shift: to renew it, the one in progress has to be closed first.
On accepting, the person is signed up on the shift already approved, without going through the calendar's possible confirmation: you invited them, you have already given the confirmation. On rejecting, they stay recorded as unavailable on that shift — which is useful information: you know you asked them.
If the shift is close, a phone call is better: the notification arrives, but there is no second reminder.
Shift swap requests¶
These are the ones between volunteers: one hands a shift to another. You find them in Shift swaps.
If the calendar has Shift swap requires approval active, the swap is not concluded when the colleague accepts: it moves to Awaiting approval and appears in your To approve tab. Until then the shift is still on whoever handed it over.
In the tab you see Gives, Takes, Role and the Status, and you can Approve or Reject. The requests already closed end up in the History tab.
What AppToMe checks on your behalf¶
The shift swap is designed not to require work from you: the checking part is automatic and cannot be bypassed.
- Tasks are not chosen. Whoever takes the shift takes it with the same task as whoever gives it; in a mutual swap, whoever gives inherits the task the other had on the shift taken in return. Nobody changes role this way.
- The candidate must have the task. The list of proposed recipients contains only those who can really cover that place: if a volunteer tells you they "cannot find them among the names", check their tasks in Registry.
- Coverage is untouchable. The swap is applied and then verified: if a shift involved has gone from covered to uncovered, everything is undone and the two people receive the notification. There are no half-applied swaps.
- Everything is checked again at the moment of the answer, not at the moment of sending: whoever gives may have removed themselves from the shift, whoever takes may have signed up there by themselves, a task may have been revoked. In that case the swap stops and touches nothing.
- The deadline is 24 hours, but never beyond the start of the shift.
If a swap "does not arrive", the cause is almost always one of these — not a fault.
When approval is skipped¶
Approval kicks in if even one of the calendars involved requires it. There are however two cases where AppToMe skips it, so as not to leave the request sitting until its deadline:
- whoever proposes the swap is already the manager of that shift — they could approve it themselves, the double signature adds nothing;
- there is nobody else who could approve that shift.
Those involved in the swap — whoever gives and whoever takes — never appear among the approvers, even if they would have the permission.
In To approve you see only the shifts you really have power over: the permission to manage availabilities can be limited to certain calendars, shift types, days and time slots (see Roles and permissions).
Vehicle bookings¶
Vehicle bookings can require approval too: see Vehicles.