Manage Transfer Windows
A transfer window is a date range during which players may be transferred into your organization's teams. This guide covers opening, editing, and closing windows, switching transfers off entirely, and how a child organization inherits its parent's windows. Setting transfer rules is an organizer / org-admin action on a PRO organization. For the wider context — the player pool, transfer requests, and the approval chain — see the Transfers & Windows section of the Organization Profile guide.
Only an organizer or organization admin of the organization can add, edit, delete a window, or toggle transfers off. The controls live on the organization's Transfer Windows screen, reached from the organization dashboard.
How a transfer window works
Each window is simply a label plus an open date and a close date. An organization can hold several windows (for example a summer window and a winter window). The rule the app enforces is straightforward:
- If your organization has no windows defined, transfers are allowed at any time.
- If your organization has one or more windows, a transfer into one of its teams is only accepted while "now" falls inside an open window (open date ≤ now ≤ close date).
- Outside every window, a transfer request is rejected, and the app surfaces the next window's opening date so the requester knows when they can try again.
The window check is applied to the destination team's organization — the one a player is moving into. Moving a player out of an organization is not blocked by that organization's windows. This means a restricted organization controls who joins its roster, without trapping players who want to leave.
Open or edit a window
Adding a window is how you "open" transfers for a period; the window becomes active automatically once its open date arrives.
Open the Transfer Windows screen
From your organization's dashboard, open Transfer Windows. You'll see the list of windows currently defined for the organization (if any).
Add a window
Tap to add a new window and enter a label (e.g. "Summer 2026"), an open date, and a close date. Save it.
Edit a window
Select an existing window to change its label or shift its open / close dates. Editing takes effect immediately — extending a close date keeps the window open longer; pulling it earlier closes it sooner.
Close a window
There are two ways a window closes:
- Automatically — once the close date passes, the window is no longer active and new transfers into the organization are refused until the next window opens.
- Manually — delete the window from the Transfer Windows screen, or pull its close date back to now. Deleting the last remaining window returns the organization to "no windows" — i.e. transfers allowed at any time. To stop transfers while keeping no windows defined, use the disable-transfers toggle instead.
Disable transfers entirely
Independent of windows, an organization has an enable-transfers toggle. Turning it off blocks all incoming transfers regardless of any window dates — useful for freezing the roster mid-season or while you reorganize teams. Turning it back on restores normal window behaviour.
When transfers are disabled, it does not matter whether a window is currently open — every new transfer request into the organization is rejected. The toggle is the hard switch; windows are the schedule.
In-flight requests survive a closing
This is the single most important thing to understand about how enforcement works, and it can surprise organizers.
The window / disabled check runs only at the moment a transfer is requested. Once a request has been submitted and is sitting as pending in an approval chain, it is not re-checked when an approver responds — approval goes straight to execution. So if a request was created while a window was open, it can still be approved and completed after that window closes, and likewise after you disable transfers. Closing a window or flipping transfers off stops new requests; it leaves in-flight ones untouched. This is intentional product behaviour, not a bug.
To prevent a specific pending transfer from completing after a window closes, reject it in the approval chain rather than relying on the window or the disable toggle. Rejecting at any step rejects the whole request.
A club submits a transfer request on the last day of the summer window. The window closes at midnight before the federation approver gets to it. The next morning the approver opens the request and approves it — and the transfer executes normally, because the eligibility check already passed at submission time and is not run again at approval. If the federation did not want that transfer to go through, the approver should have rejected it.
Inherited windows
Organizations form a hierarchy — a federation owns associations, which own clubs. Transfer windows flow down that chain. When the app needs an organization's effective windows, it walks up the parent chain (up to four levels) and uses the first organization that defines windows or has transfers disabled. The result is shared by everything below it.
For a child organization, this has two visible effects:
- The child's Transfer Windows screen shows the inherited windows as read-only, labelled with the name of the organization they come from (the parent that defined them).
- The child cannot add its own windows while it is inheriting — attempting to do so is refused because the parent already governs the schedule. To set its own windows, the child must no longer be inheriting from a parent that defines them.
Community groups are exempt from transfer windows and the disable toggle entirely — transfers into a community group are always allowed, regardless of any windows or settings on the chain above it.
A national federation defines a summer and a winter window. Every affiliated association and club below it opens its own Transfer Windows screen and sees those two windows, marked read-only and attributed to the federation. None of the clubs can add a window of their own — the federation owns the transfer calendar for the whole pyramid, and a club that wants a different schedule would need to not inherit from a parent that defines windows.
See Transfer Requests for how requests are raised and approved, the Organization Profile guide for the dashboard and player pool, and Create an Organization for the PRO subscription that org management requires.