 <p>A few recommendations I would like to make (based on the app we've built which also uses Table Storage exclusively).</p> <ul> <li>Introduce a new entity called <code>Account</code> or <code>Subscription</code>. You can use a GUID to uniquely identify an account.</li> <li>Along with user information (user id, password etc.) in the user's table, store the account information as well. So at all times when you're authenticating a user, you're making point queries. Also store the user's role (Member or Owner) in the user's table. Doing this way, you would know if the user is an individual user or part of a team. If the user is part of a team, then what the role of that user in that team (Owner or Member).</li> <li>Store 2 copies of user data. First copy is what you're using now. Second copy essentially associate a user with an account where the PartitionKey of the second copy is the account id and row key is the PartitionKey of the first copy. This will help you find the users in a particular team.</li> </ul> <p><strong>Individual User Login Scenario</strong></p> <p>So an individual user logs in using their username/password. You retrieve the information about the user and there you find out that the user is an individual user based on the account type.</p> <p><strong>Team Owner Login Scenario</strong> So when a team owner logs in, based on the login you will find out that the user is a team owner. If the team owner needs to find the list of all the users in the team, you do another query (it will be the PartitionKey query only) which will give you information about all the users in the team.</p> <p><strong>Team User Login Scenario</strong></p> <p>So when a team user logs in, based on the login you will find out that the user is a team user. Since the user is a team user, he/she need not query the table to find out about other users in the team. Even if they do, you will do another query (same as team owner query) to get the list of users in a team.</p>