How should the device store save the groupId if you have a new device and an account?

App users are stored in collection users and groups in collection groups. At a high level a user is part of one group. When you log in you are asked to either join or create a group.

I store the groupId with SharedPreferences when you register.

How should the device store save the groupId if you have a new device and already have an account?

My initial thought is to stick groupId into the user model so that when I retrieve the account details on login I can point to a specific group. But you might want to be part of two or more groups in the future.

Coming from a SQL world I am tempted to have a homeUsers collection but that defeats the purpose of NoSQL.

I have a user collection inside the groups; i.e. groups -> groupId -> users. This allows me to display users without unnecessary querying.

My initial thought is to stick groupId as part of the user model so that when I retrieve the account details on login I can point to a specific group.

Yes, that is a common approach but it will work only if the user belongs to a single group.

I slightly don't like this because what if you want to be part of 2 or more groups in the future?

In that case, instead of saving the groupId as a separate field inside the document, you can save it as a value within an array-type field. In this way, you'll be able to add as many group IDs as you need. You'll also be able to use restrict the access in your security rules based on the group ID.

Coming from a SQL world I am tempted to have a homeUsers collection but that defeats the purpose of NoSQL no?

That's also a solution, but it will be some kind of expensive because when you read the entire sub-collection you'll need to pay a read operation for each document you download. With the previous solution, you'll only have to pay for a single read.

I do in fact have a "users" collection inside the groups i.e. groups -> groupId -> users. This simply allows me to display users without doing unnecessary querying.

As said, this approach will also work, but you have to do your math to see which solution is more affordable for the queries you will perform.