Feel Pro Club Docs

Appearance

0005. Team Workspace and Membership Governance ​

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

Overview ​

This PRD defines the core team workspace once a team exists. It covers team switching, team profile actions, roster visibility, ongoing invite tooling, known-substitute management, and the permission model that changes what different team roles can do.

Problem Statement ​

Feel Pro Club's value depends on turning a casual friend group into a manageable team workspace. Team administrators need to switch between teams, edit identity, invite members, manage substitutes, and inspect player cards, while non-admin members need a constrained but still useful team view. The workspace also needs a clear delegated-management model so organizers can offload operational work without giving away full control.

Goals ​

  • Provide a single team workspace where identity, roster, and key team actions live.
  • Keep permissions role-aware so organizers, managers, and players see the correct action set.
  • Support multi-team users without forcing them to leave the main shell.

Success Metrics ​

  • High rate of successful team switching for multi-team users.
  • Frequent use of team management tools by organizers and managers without accidental destructive actions.
  • Low confusion about what each user can and cannot do inside a team.

Scope ​

In Scope ​

  • Team profile header, roster, and action grid.
  • Team switching sidebar and multi-team organization.
  • Editing team identity after creation.
  • Ongoing invite tools for full team members and known substitutes.
  • Per-user team ordering across all teams the user belongs to.
  • Team role transfer from organizer to manager.

Out of Scope ​

  • Match creation details and summoned-player management beyond entry points from the team workspace.
  • Final join flow for invitation recipients.
  • Financial, league, venue, or season management.

Personas and Roles ​

  • Organizer: The single top-level administrator of the team. Can create matches, edit team data, invite players, invite known substitutes, manage team roles, transfer organizer ownership, and delete the team.
  • Manager: A delegated team operator with a reduced permission set. Can organize matches, invite players, and invite known substitutes, but cannot edit team details or delete the team.
  • Starter or substitute player: Can view the team and match context but cannot perform admin-only actions.
  • Known substitute: Uses the same team workspace as starter and substitute players, but only sees convocation actions when explicitly invited into a match.
  • Multi-team user: Needs a per-user way to order all teams they are part of, regardless of role.

User Journey ​

  1. The user opens My Team(s) and lands on the current team's profile.
  2. The user either manages the current team, inspects players, or switches into another team through the sidebar.
  3. Organizers and managers invite more fixed players or known substitutes and organize matches.
  4. Organizers edit branding, manage team roles, and can transfer organizer ownership to an existing manager.
  5. Multi-team users reorder teams based on personal preference, with newly created or joined teams appended at the end by default.
  6. Players and known substitutes use the same team page to understand their team context and leave if needed.

Functional Requirements ​

Team Profile ​

  1. The team profile shall display team branding, founded date, and a persistent affordance for switching teams.
  2. The workspace shall support a no-current-team empty state with a clear "create team" call to action.
  3. The action grid shall change based on role and current match state.
  4. Organizers shall see actions for inviting players, inviting known substitutes, editing the team, managing team roles, and leaving the team.
  5. Managers shall see actions for organizing matches, inviting players, inviting known substitutes, and leaving the team, but shall not see actions for editing team details or deleting the team.
  6. Players and known substitutes shall see the same base team workspace layout.
  7. Convocation-related actions shall be visible to a known substitute only when the team has explicitly extended an invitation to that user.

Team Switching and Multi-Team Management ​

  1. The team switcher sidebar shall present teams in a single ordered list rather than grouping them by role or relationship type.
  2. Selecting a team from the sidebar shall make it the current active team and load the correct team state.
  3. The sidebar shall offer a direct action to create a new team.
  4. Any user shall be able to reorder the teams they are part of according to personal preference.
  5. Team ordering shall be stored per user and shall not affect how other users see their own team lists.
  6. Newly created or newly joined teams shall be appended at the end of the user's current team order by default.
  7. Team deletion shall remain restricted to the organizer and follow the deletion rules defined elsewhere.

Team Editing ​

  1. Organizers shall be able to edit team name, abbreviation, colors, and logo after creation.
  2. Edit-team shall warn users before discarding unsaved changes.
  3. Edit-team shall validate that name and abbreviation still exist before save.
  4. Managers shall not be allowed to edit team identity details.

Fixed-Roster Invites ​

  1. Organizers and managers shall have an ongoing invite surface from the team workspace, separate from the onboarding share screen.
  2. The invite surface shall support WhatsApp, Telegram, copy-to-clipboard, and email share actions.
  3. The invite surface shall generate or copy a link used to add players directly into the fixed roster.
  4. Invite links shall embed a token tied to the team and valid for 24 hours. Generating a new invite link shall immediately invalidate any previously active link for that team.
  5. The invite surface shall communicate that invite links expire after 24 hours and may need regeneration.
  6. When a new member joins the team via an invite link, all organizers and managers of that team shall receive a push and in-app notification.

Known Substitutes ​

  1. Teams shall support a "known substitutes" pool that represents friends or nearby players who can be called when the roster is short.
  2. The known-substitutes area shall provide a prewritten invitation message that can be edited and copied.
  3. Registered known substitutes shall appear in a list with inspectable player-card details.
  4. Organizers and managers shall be able to invite known substitutes.
  5. Organizers shall see actions to promote a known substitute into an official player and to remove them from the team.
  6. Promoting a known substitute into an official player shall convert that user into a persistent team player.
  7. Once promoted, the player shall receive a push and in-app notification confirming the promotion, receive immediate notifications for new matches, and appear in the main team workspace as part of the standard roster. Promotion does not auto-add the player to an already-active match's convocation; the organizer must explicitly invite them if desired.
  8. Removing a known substitute shall remove that user from the team. If the known substitute has been summoned into an active match, their pending or confirmed spot in the convocation shall also be removed.

Player Detail Within Team Context ​

  1. Team members listed in the roster shall open a detailed player card modal.
  2. The player card shall show at least role, positions, preferred foot, play style, and play zone when available.
  3. When the selected card belongs to the current user and required profile data is missing, the card shall prompt profile completion.
  4. Organizers shall be able to grant or remove manager permissions and dismiss a player from the team roster. Dismissing a player shall automatically revoke their confirmed attendance for all of that team's future matches, consistent with the leave behavior defined in PRD 0006 and PRD 0010. The dismissed player shall receive a push and in-app notification.
  5. When a user is promoted to manager, they shall receive a push and in-app notification.
  6. When a user is demoted from manager, they shall receive a push and in-app notification.
  7. Only the organizer shall be able to transfer organizer ownership, and the transfer target must already be a manager.
  8. A team shall have exactly one organizer at a time, may have multiple managers, and may have multiple players.

Business Rules and Permissions ​

  • The organizer is the single President of the team.
  • Manager is a true team role with delegated permissions, not just a label.
  • Organizer-only permissions include editing team details, deleting the team, granting or removing manager role, and transferring organizer ownership.
  • Organizer and manager permissions both include organizing matches, inviting players, and inviting known substitutes.
  • Team membership and global intent are separate concepts; a user may own one team, belong to another, and be a substitute in a third.
  • Team ordering is personal to each user and shall not create a shared team priority for other members.
  • Known substitutes are not treated as team members, and their convocation actions exist only when they have actually been invited.
  • A team may have a maximum of 30 main and substitute players. There is no limit on the number of known substitutes.
  • Organizers cannot be removed or dismissed by any other team member. Only voluntary leave (with ownership transfer or team deletion) applies to organizers.
  • Generating a new invite link for a team immediately invalidates any previously active link for that team.

UX Considerations ​

  • The team workspace should feel branded and team-specific, not like a neutral CRUD page.
  • Team switching should remain one gesture away because multi-team usage is a core product behavior.
  • Destructive actions such as deleting a team, dismissing a player, or leaving a team should always require confirmation.
  • Team ordering should feel personal and easily adjustable, without implying any shared ranking across the team.
  • The invite surface inside the team workspace should feel consistent with the invite surface used during team creation.

Error States ​

  • If switching teams fails, the app shall keep the previously rendered team visible, show that the new team could not be loaded, and offer retry instead of dropping to a blank workspace.
  • Changing teams while a destructive modal is open shall cancel the pending action and require the user to reopen that action in the newly selected team context.
  • Team reordering and roster-management mutations may update optimistically only if failure restores the previous order or role state and informs the user that the change did not persist.
  • If a join attempt or promotion would exceed the 30-player roster cap because of a concurrent action, the server response shall win and the UI shall explain that the roster is full.
  • If push permissions are denied or notification delivery fails, the same membership changes shall remain visible through in-app notifications and updated team state; critical role changes cannot rely on push alone.
  • If share targets are unavailable from the invite surface, copy-to-clipboard remains available and the current invite link stays visible.