before you think in terms of buttons and layouts, think in terms of records in tables. With the correct data model, a single button in a list view of many records can serve to perform the script that "checks in" the user and then checks to see if all group members are no present in order to change layouts if that proves to be the case.
Group membership could be a one to many relationship, one group to many members. Or it could be a many to many relationship where a user can be a member of more than one group even as a group lists many members.
For now, I will assume the simpler one group to many users relationship. If this should be a many to many relationship, we can add in the needed changes later.
Start with two tables:
Groups::__pkGroupID = Users::_fkGroupID
A portal to users on the groups layout can be used to list all users that are members of a given group. On a users layout, the _fkGroupID field can be formatted with a value list for selecting the group to which you want to assign that member.
This will allow you to set up either a list view layout based on Groups with portals listing the users assigned to each group or a list view layout based on Users with sub summary layout parts including fields from groups to show the names or IDs of each group. A button in the portal row or a button if using portals or a button in the body if you use the second options can perform a script to "check in" a group member:
Set Field [Users::checkIn ; 1 ]
If [Groups::MemberCount = Groups::CheckIN ]
Go to Layout [
Groups::MemberCount would be a calculation field defined as:
Count ( Users::_fkGroupID )
Groups::CheckIn would be a calculation field defined as:;
Sum ( Users::CheckIn )