Skip to content

0010. Team Exit, Ownership Transfer, and Deletion

Status: Draft Author: Codex Created: 2026-03-09

Overview

This PRD defines how users leave a team, how organizers transfer team ownership before exiting, and how an organizer can delete a team instead of handing it over.

Problem Statement

Teams need safe exit paths that do not orphan the group or accidentally destroy it. The MVP will treat organizer exit differently from member exit: members can leave directly, while organizers must either pass leadership to someone else or explicitly delete the team.

Goals

  • Let non-organizers leave a team cleanly with clear consequences.
  • Force organizer exits through either ownership transfer or explicit deletion.
  • Protect destructive team deletion with strong confirmation.

Success Metrics

  • Low rate of accidental team deletion or accidental self-removal.
  • High clarity for who becomes the next owner when an organizer leaves.
  • Reliable cleanup of team access after a leave or delete action.

Scope

In Scope

  • Non-organizer leave confirmation from the team workspace.
  • Organizer-only ownership-transfer flow.
  • Organizer-only team deletion flow.
  • Post-leave notification that adapts to whether the user has remaining teams.
  • Notification to the newly assigned president on ownership transfer.
  • Automatic attendance revocation for future matches on team leave.
  • Soft-delete data retention for all team and member history.

Out of Scope

  • Rejoining a team after leaving.
  • Ownership transfer approval by the successor.

Personas and Roles

  • Organizer: Must either hand off leadership or delete the team.
  • Regular member: Can leave with a simple confirm path.
  • Known substitute: Can also leave through the lightweight leave confirmation path.
  • Successor candidate: A current manager who receives team leadership during an organizer exit.

User Journey

  1. A non-organizer taps "leave team" from the team workspace and confirms the action.
  2. An organizer taps "leave team" and is routed into a dedicated handoff flow.
  3. The organizer either selects a manager as the new president and confirms the transfer, or starts the team-deletion path.
  4. After leaving, the user is removed from the team context and returned to Home. If they still belong to other teams, the notification acknowledges the departure. If they have no remaining teams, the notification frames them as a free player.

Functional Requirements

Non-Organizer Leave Flow

  1. Non-organizers shall be able to leave a team directly from the team workspace.
  2. Leaving shall require a confirmation dialog that explains the user will no longer see team matches or convocations.
  3. Successful leave shall remove the team membership, automatically revoke confirmed attendance and pending match invitations for any of that team's future matches, and return the user to Home.

Organizer Ownership Transfer

  1. Organizers shall not be allowed to leave a team without either assigning a successor or deleting the team.
  2. The organizer leave flow shall explain why a successor is required.
  3. The organizer shall choose the next president from the list of current managers only. If no managers exist, the system shall display a message explaining that a manager is needed and provide a CTA that redirects the organizer back to the team section to designate one or more managers.
  4. The organizer shall see a final confirmation screen that names the selected successor before completing the exit.
  5. Completing the transfer flow shall remove the current organizer from the team and return them to Home.
  6. The newly assigned president shall receive a push and in-app notification confirming they have been assigned team ownership.

Team Deletion

  1. Organizers shall be able to delete the team instead of transferring ownership. Team deletion is implemented as a soft-delete: the team is removed from all members' workspaces but all team data, current and past member records, and match history are retained in the database.
  2. Team deletion shall require at least two confirmation steps.
  3. The final destructive step shall require the organizer to retype the team name before deletion becomes available.
  4. Deleting the team shall automatically terminate all associated matches (pending or in-progress). A push and in-app notification shall be sent to all starter players, substitute players, known substitutes, and summoned free players informing them the team has been deleted.
  5. Deleting the team shall remove the team from the user's accessible teams and return the user to Home.

Post-Exit Feedback

  1. Leaving a team shall create a push and in-app notification confirming the user is no longer part of that team.
  2. If the departing user is still a member of at least one other team, the notification shall acknowledge the departure and direct them to their remaining teams.
  3. If the departing user has no remaining teams, the notification shall frame them as a free player, prompt them to explore the market or create a new team, and inform them to enable market visibility if it is currently off.
  4. Organizer deletion and organizer transfer outcomes should both leave the user outside the team workspace afterward.

Business Rules and Permissions

  • Only organizers can delete an entire team or assign the next president.
  • Non-organizers may leave their membership but may not delete the team for everyone else.
  • A leave action must revoke the user's access to future team matches and convocations, and automatically remove any confirmed attendance and pending match invitations for that team's future matches.
  • Only current managers are eligible to become the next president. A team member must be promoted to manager before they can be selected as a successor.
  • Ownership transfer is automatic and requires no confirmation from the successor.
  • Team deletion is a soft-delete. All team data, match history, and current and past member records are retained in the database and not exposed in any product surface for MVP.
  • Leaving a team does not automatically enable market visibility. The player's visibility state remains unchanged; they must enable it explicitly from the Market tab if they want to become discoverable.
  • Account deletion triggers the same organizer-exit guardrail as voluntary team leave: a user who is the last organizer of an active team must transfer ownership or delete the team before account deletion is permitted.
  • Once a team is soft-deleted, all associated invite links become immediately invalid. Users attempting to use such links shall see an error indicating the team no longer exists.
  • Team deletion terminates all associated matches (pending or in-progress) and notifies all affected players.

UX Considerations

  • Exit messaging should make the consequence of leaving unmistakable before the user confirms.
  • Ownership transfer should feel like a deliberate handoff, not a hidden admin edge case.
  • Team deletion should use stronger destructive styling than team leave because the blast radius is much larger.

Error States

  • Non-organizer leave, ownership transfer, and team deletion flows shall use an in-progress state through the full backend cleanup and shall not report success until team access and match cleanup are committed.
  • If ownership-transfer submission fails, the current organizer shall remain in the team, the selected successor shall stay visible on the confirmation screen, and the UI shall explain that ownership did not change.
  • If the selected successor becomes ineligible before confirmation because they left, were demoted, or the team changed, the product shall block completion, explain why, and return the organizer to a refreshed eligible-manager list.
  • If the organizer is the sole remaining member and there is no eligible successor, the handoff flow shall state that transfer is impossible and present the option to designate a manager or delete the team instead.
  • If a stale invite link is opened after a team has been deleted, the invite surface shall show a terminal "team no longer exists" message with a route back to Home instead of a generic invalid-link error.
  • If post-exit redirect to Home fails, the user shall see a neutral confirmation screen outside the former team context with retry and a safe route into the authenticated shell.