We discussed all points during the brainstorming session with the client and his team and came up with below solutions:
Unique link based onboarding for each community, with this, there was a token that was given to the users to access the platform for the very first time. With this most of the users were able to access the system very easily.
DB schema was designed such that each Tower can be treated as a sub-community inside the community itself. With this each tower had its own admin, moderated by a new role ‘Community Admin’.
Separate rules were created for is-owner and is-tenant. Accordingly, group access was provided. This was handled by a Community Admin.
Users will have the option to make contact details private from residential directly. With this feature , users could avoid exposing details of female members.
Unique group allowing access only to Females was created. This group was accessible only if the gender was female. Changing gender was a right given solely to community admin and community moderators.
A separate panel was created on the web to onboard (sponser) local vendors. This page would reflect towards major part of the application at community level.
Gender and designation remains logically unchanged once a profile is created, thus the editing writes were given only to community admin once they were fed in system. With this, if a user named ‘Bryan’ is a male and a doctor, he will be reflected in the same way in all communities, or localities, in which he participates.