Site Transfer lets an administrator propose moving a user from one site to another. Instead of silently reassigning the user, the initiating admin sends a request to the administrators of the receiving site, who can accept, decline, or re-route it.
A site transfer is a proposal, not an immediate move. In most cases the user is only added to the destination site once a receiving admin accepts. While a request is pending, the user does not yet appear on the destination site.
Everyone involved stays informed through in-app notifications, a dashboard card, a profile banner, and a routing history that travels with the request.
Site Transfer is an administrator-facing feature. The user being transferred takes no action; their site membership changes as a result of admin decisions.
An admin can start a request from three places:
Expanded user profile – the top actions menu includes Request site transfer (next to actions such as Archive). This targets the single profile being viewed.
Database (user list) – after selecting one or more users, the bulk action bar includes Request site transfer. This targets all selected users at once.
Site membership history report – each row’s actions menu includes Request site transfer for that row’s user.
When you start a transfer, a Request site transfer popup opens. You set the following options:
The list contains only the sites you manage.
If you manage exactly one site, it is preselected and locked.
The user must already be a member of the site you choose.
The list contains all sites in the organization, except the source site you selected.
This control becomes available once a source site is chosen.
This controls what happens to the user’s membership on the source site. There are three options:
When the new site accepts (recommended) – the user is removed from the source site at the moment a receiving admin accepts. This is the default.
Immediately – the user is removed from the source site as soon as the request is sent. They are still only added to the destination site upon acceptance.
Do not remove from current site – the user is never removed from the source. On acceptance they are added to the destination and remain on the source as well, keeping a record in both.
A free-text note for the receiving admins, visible in the request’s routing history.
When you are ready, select Send request. For a single user, the popup closes on success.
Yes. When you start a transfer for multiple users, the same popup is used and shows how many users are selected. The source site, destination site, removal option, and note apply to everyone selected.
On submission, each user is processed individually:
A request is created for each eligible user.
A user who is not a member of the chosen source site is skipped.
A user who already has a pending request to the same destination site is skipped.
If every user is processed with no skips, the popup closes. If any users are skipped, the popup stays open and shows a summary of how many requests were created and how many were skipped.
Admins of the destination site see the pending request in three places: the dashboard card, the request detail view, and a banner on the user’s profile.
From the request detail view, a receiving admin can take one of three actions:
Accept – the user is added to the destination site. Depending on the removal option, the user is also removed from the source site on acceptance, was already removed (immediate), or remains on the source site (do not remove). The initiating admin is notified, and the request status becomes Accepted.
Decline – no membership change occurs. The initiating admin is notified, and the status becomes Declined.
Re-route – the request stays pending and its destination changes to a different site that the responding admin manages. The admins of the new destination are notified, and the routing history records the change. A request cannot be re-routed to the source site or to the current destination site.
A receiving admin can add a response note when accepting, declining, or re-routing.
💡 Note:
A destination site can have multiple admins, and they all receive the request. The first admin to respond determines the outcome. After that, other admins who open the request see a banner showing the action already taken and that nothing further is required.
The detail view shows the subject user, the requesting admin, the source-to-destination route, and the full routing history. The request note appears within the routing history rather than as a separate field.
The routing history lists each event in order: Created, Re-routed, Accepted, Declined, and Cancelled. Each entry shows the acting admin, an optional note, and a timestamp.
The view adapts to who is looking at it:
The initiating admin can edit the note and cancel the request while it is pending.
A receiving admin sees the response note field and the Accept, Decline, and Re-route actions.
An admin who is neither the initiator nor an admin of the current destination sees a message that the request is awaiting a response from the receiving site’s admins.
When the request is no longer pending, an informational banner states the outcome and the admin who took the action, indicating that no further action is needed.
Yes. While a request is pending, the initiating admin can cancel it from the request detail view. After cancellation, the status becomes Cancelled, no membership change occurs, and the request is removed from the receiving admins’ pending items. Editing the note and cancelling are available only to the initiating admin, and only while the request is pending.
This card appears at the top of the main column of the admin dashboard, above the forms area. It is shown to admins of a destination site when there are requests awaiting their action, and it is hidden when there are none. Each entry shows the user’s name, who requested the transfer, the source and destination sites, and a Review action that opens the request. A count of pending requests appears in the card header.
💡 Note:
Requests you initiated do not appear in your own dashboard card, because the card lists requests awaiting your action. You track your own requests through the profile banner, the request detail view, and the accept or decline notification.
On the user’s expanded profile, a banner appears at the top when that user has a pending transfer (similar to the time-off banner). It shows who initiated the transfer and the source and destination sites. The initiating admin sees a Manage transfer action; other involved admins see a Review transfer action. Both open the request detail view.
Notifications are delivered as in-app and push notifications. Email is off by default for site transfer notifications.
Transfer requested – sent to the destination site’s admins when a request is created.
Transfer re-routed – sent to the new destination site’s admins when a pending request is re-routed to them.
Transfer accepted – sent to the initiating admin when a request is accepted.
Transfer declined – sent to the initiating admin when a request is declined.
If your organization’s handoff notifications are enabled, the standard “user added to your site” notification is also sent to the destination admins when the request is accepted.
On the mobile app, tapping a transfer push notification opens the request’s detail screen. If the request has already been handled by then, the screen shows the handled state rather than action controls.
Pending – awaiting a decision from the destination site’s admins.
Accepted – the user has been added to the destination site.
Declined – the request was rejected; no membership change.
Cancelled – the initiating admin withdrew the request; no membership change.
Pending vs. completed membership: while a request is pending, the user does not appear on the destination site and (unless you chose the immediate removal option) still appears on the source site. Membership reflects the transfer only after acceptance.
Immediate removal: if you choose to remove the user immediately, there is an interval between sending and acceptance during which the user is on neither the source site (through this membership) nor the destination site.
Keeping the user on both sites: with the do-not-remove option, acceptance adds the user to the destination while leaving the source membership intact, so the user is recorded on both.
Who can respond: only admins of the request’s current destination site can accept, decline, or re-route it. Re-routing is limited to sites the responding admin manages.
Duplicate requests: a new request cannot be created for the same user to the same destination while an earlier request to that destination is still pending. In a bulk request, those users are skipped and counted in the result summary.
If you need help managing Site Transfers, feel free to contact support@vomevolunteer.zohodesk.com.