Admin: Set Up the Resident Directory

Admin: set up the resident directory

The directory tells the society who lives where. Done carelessly — as a spreadsheet circulated to a WhatsApp group — it is a data breach with a helpful format. Done properly it is a controlled record with per-field visibility.

Before you start

• You are a society admin or committee member
• Flats are imported (Admin → Members → Import)
• The committee has agreed the directory rules below

Separate the two things first

Societies conflate these, and it causes most of the trouble:

• The register of members is a statutory record the society must maintain — member name, flat, share details, nomination. It is not consent-based; the state act requires it.
• The resident directory is a convenience: contact details residents share so neighbours can reach neighbours. It is optional and consent-based, and a resident may decline entirely.

Do not treat a resident declining to publish their mobile number as a refusal to be on the members' register. They are different things.

Step 1: Link residents to flats

Go to /directory.

For each flat, add the people who live there with their role:

Mark one person as primary for the flat — this is who the gate calls and who billing addresses.

Include tenants. Excluding them is common, unkind, and operationally foolish: the gate and the committee need to know who actually lives in a flat, and an invisible tenant is a problem in an emergency.

Record the owner separately for billing and governance, and the occupant for operations. Both, not one.

Step 2: Set visibility defaults

Not everything should be visible to everyone:

Two defaults do most of the work. Phone numbers are opt-in, not opt-out — a resident who has not chosen should not be published. And residents can reach each other in-app without the number being revealed, which removes most of the reason to publish it.

Collect the minimum. A directory does not need dates of birth, blood groups, occupations or photographs. Every extra field is one more thing to protect and one more reason a resident declines.

Step 3: Assign committee roles

Add committee members with their position — chairman, secretary, treasurer, and portfolio roles. This drives who can see restricted data and who appears as the point of contact.

Deactivate a role rather than deleting it when someone leaves the committee, so historical records stay readable.

Step 4: Adopt the rules

Write these into a short data policy and tell residents:

• No bulk export. No PDF or Excel of the directory, ever, to anyone. This is the single most important rule. If someone needs to reach all residents, they use the notice system.
• No directory data for commercial use. Residents will ask for the list to promote a business. The answer is no.
• No sharing outside the society — including with vendors, brokers and the security agency beyond what the gate genuinely needs.
• Deactivate on move-out, as part of the move-out checklist rather than a later cleanup.
• Annual refresh — ask residents to confirm their details once a year. It fixes accuracy and refreshes consent at the same time.
• Name someone accountable, usually the secretary.

Step 5: Keep it current

Residents can correct their own details. When a flat changes hands, the move-out process should deactivate the outgoing residents along with their gate access and registered household help.

What the law expects

India's Digital Personal Data Protection Act applies to a society processing residents' personal data: collect for a stated purpose, collect the minimum, obtain consent with a genuine ability to withdraw it, secure it, and remove it when the purpose ends. Children's data needs verifiable parental consent and should generally not be in a society-wide directory at all.

Frequently asked questions

Can a society publish every resident's phone number? Not without consent. Make phone numbers opt-in, and prefer an in-app contact path that connects residents without revealing the number.

Can a resident refuse to be in the directory? They can decline to share contact details. They cannot be left out of the statutory register of members, which serves a different purpose.

Should tenants be listed? Yes. Record the owner separately for billing and governance.

Can we share the directory with our security agency? Only what the gate genuinely needs to do its job. Not the full contact list.

Can we export the directory to a spreadsheet? Do not. Bulk export is how a controlled record becomes a file on two hundred phones, permanently and beyond recall.

How long should we keep a former resident's details? Remove them at move-out. Retain only what the statutory register requires.

Related: Resident: manage your directory privacy · Resident directory and privacy · Admin: review move requests