@Addy_619
I agree to @jeevith that is related to combinations and that is recommendable to focus on team member combinations without taking the team positions into account.
For this my demo uses a stack approach
Havin a set of members:
List(12) { “A1”, “A2”, “A3”, “A4”, “B1”, “B2”, “B3”, “B4”, “C1”, “C2”, “C3”, “C4” }
Starting with 12 teams (Team stack with level 1):
List(12) { “A1”, “A2”, “A3”, “A4”, “B1”, “B2”, “B3”, “B4”, “C1”, “C2”, “C3”, “C4” }
now in the first iteration:

look for each team member in members for all members not present in the particular team

create new combinations (team stack size: 2) of team member and 1 free member:
Result for A1:
List(66) { “A1,A2”, “A1,A3”, “A1,A4”, “A1,B1”, “A1,B2”, “A1,B3”, “A1,B4”, “A1,C1”, “A1,C2”, “A1,C3”, “A1,C4”

order all teams by its members and remove duplicates: So A1,B1 and B1,A1 are the same and the duplicates are removed (As we said, member positions in the team is to ignore)
do the same for the next level (3):
List(220) { “A1,A2,A3”, “A1,A2,A4”, “A1,A2,B1”, “A1,A2,B2”, “A1,A2,B3”, “A1,A2,B4”, “A1,A2,C1”, “A1,A2,C2”, “A1,A2,C3”, “A1,A2,C4”, “A1,A3,A4”, “A1,A3,B1”, “A1,A3,B2”, “A1,A3,B3”, “A1,A3,B4”, “A1,A3,C1”, “A1,A3,C2”, “A1,A3,C3”, “A1,A3,C4”, “A1,A4,B1”, “A1,A4,B2”, “A1,A4,B3”, “A1,A4,B4”, “A1,A4,C1”, “A1,A4,C2”, “A1,A4,C3”, “A1,A4,C4”, “A1,B1,B2”, “A1,B1,B3”, “A1,B1,B4”, “A1,B1,C1”, “A1,B1,C2”, “A1,B1,C3”, “A1,B1,C4”, “A1,B2,B3”, “A1,B2,B4”, “A1,B2,C1”, “A1,B2,C2”, “A1,B2,C3”, “A1,B2,C4”, “A1,B3,B4”, “A1,B3,C1”, “A1,B3,C2”, “A1,B3,C3”, “A1,B3,C4”, “A1,B4,C1”, “A1,B4,C2”, “A1,B4,C3”, “A1,B4,C4”, “A1,C1,C2”, “A1,C1,C3”, “A1,C1,C4”, “A1,C2,C3”, “A1,C2,C4”, “A1,C3,C4”
and so on.
the main building part looks like this:
the implementation was based on strings (thats why it is using split and join), due the duplicates identification need and there was no List to List is equal content comparer in place.
find relinked demo XAMl here:
NTeamCombinations_StackApproach.xaml (12.2 KB)