Custom Fields for Units & Users
Giving every community a home for the data it used to keep in a spreadsheet.
BEFORE
AFTER
A community ERP with a blind spot.
ADDA is a community-management ERP used by residential associations. Admins (Syndics) run units, owners, tenants, dues and reports in it. But every community also tracks things ADDA never asked for, a swimming pool, roller shutters, parking slots, a resident’s blood group. This project gave that data a home.
MY RESPONSIBILITIES
- →Discovery with PM: PRD review, ARM parity audit, spreadsheet analysis
- →User stories, business rules and edge cases
- →Flows, wireframes and hi-fi UI in the ADDA system
- →Prototype reviews, dev handoff and design QA
Communities have no way to capture community-specific data against a unit or a user inside ADDA.
“A Syndic who needs to know which units have a swimming pool, a roller shutter or an assigned parking slot has to keep that list outside ADDA and reconcile it by hand.”
The data exists either way, it just lives in a private spreadsheet nobody else can see, search or trust. That costs admin time every day, and in an emergency it can cost far more.
Five frustrations, one root cause.
P1Data lives outside ADDAUnit and resident attributes sit in spreadsheets, so they can’t be referenced from the unit while the admin works.
P2Not searchable or reportableThese attributes can’t be reported, searched or filtered anywhere in the product.
P3A known parity gapACM has no Setup area under Units & Users, ARM already does.
P4Data drifts and disappearsHand-kept records are lost when an admin changes; re-typed data drifts from the truth.
P5Missing in an emergencyResident data like blood group isn’t available when it’s urgently needed.
What success looks like.
USER GOALS
- →Record data on the unit or resident it belongs to
- →See it while working, no switching to a sheet
- →Pull the whole community’s data in one report
BUSINESS GOALS
- →Close the ACM-vs-ARM capability gap
- →Lay the first tab of a Setup area that can grow
- →Cut manual, error-prone admin work
5 + 5
custom fields per community: five for units, five for residents
4
field types: single choice, multiple choice, dropdown and date
0
required fields, so nothing ever blocks creating a unit or user
Written from the admin’s chair.
STORY 01
As an Admin, I want to define up to 5 custom unit fields under Setup, so that I can track what my community needs without an external sheet.
STORY 02
As an Admin, I want to define up to 5 custom user fields, so that I hold resident attributes like blood group inside ADDA.
STORY 03
As an Admin, I want to see custom information on the unit I’m viewing, so that I can answer questions without leaving ADDA.
STORY 04
As a Moderator, I want to pull custom fields in reports, so that I can share a community-wide list in one click.
STORY 05
As an Admin, I want to be warned before deleting a field, so that I never lose captured data by accident.
What we learned.
PRD & stakeholder sessions
Scope, rules and priorities with PM
ARM parity audit
What the sister product already supports
Spreadsheet analysis
Real admin sheets, and which columns they actually track
Admin interviews
Syndics and admins on how they track units today
INSIGHT 1
Every community tracks different things
Pools here, shutters there: a fixed list of fields would fit nobody.
INSIGHT 2
The spreadsheet is the real source of truth
Admins weren’t missing data. They were missing a place for it.
INSIGHT 3
Data is needed where work happens
Questions come up while viewing a unit, not in a separate module.
INSIGHT 4
Resident data is sensitive
Blood group must help in an emergency without being visible to everyone.
Who it’s for.
RRoochita
Syndic · Admin
Syndic · Admin
Runs the community in ADDA and answers every question about units.
- →Wants answers in one place
- →Hates re-checking spreadsheets
- →Needs to hand over cleanly
OOwner / Tenant
Resident
Resident
The person whose unit and personal data get recorded.
- →Expects their data kept safe
- →Owner and tenant keep their own values
BBoard member
Moderator
Moderator
Pulls community-wide lists for decisions and emergencies.
- →Needs exportable reports
- →Can see sensitive user fields
Where it fits in ADDA.
WHERE IT LIVES
Units & Users › Setup
Approved Users › View/Edit Unit Details
Approved Users › Edit Profile
Reports › Unit Information
Reports › Moderator Only › All Owners, Tenants
BUSINESS RULES
- →5 unit + 5 user fields per community
- →Configured per community, nothing inherited
- →Never mandatory, never blocks creation
- →Only Admin / Syndic can reach Setup
- →User fields stored per person (owner ≠ tenant)
- →Reports show only configured columns
The hard parts.
01
Flexible, not chaotic
Let every community define fields without turning the unit form into a mess.
02
Protect captured data
Editing or deleting a field must never silently destroy values.
03
Sensitive by default
Resident fields need to be useful but restricted.
04
Fit a legacy ERP
New patterns had to feel native next to years of ADDA screens.
05
Zero-state communities
A community that configures nothing should see no change.
How I got there.
01
Discover
PRD, ARM audit, real admin sheets
02
Define
Stories, rules, edge cases
03
Ideate
Field types, where data shows
04
Flow
Configure → capture → report
05
Wireframe
Setup, modals, unit & profile
06
Design
Hi-fi in the ADDA system
07
Test
Prototype walkthroughs
08
Ship
Handoff & design QA
Six decisions, mapped to the pains.
FEATURE 01Setup › Custom FieldsUnit Fields and Users Fields, each with “2 of 5 added”, reorder, edit and delete.fixes P1fixes P3
FEATURE 02Add a field in one formName, type (single choice, multiple choice, dropdown, date) and comma-separated options.fixes P1fixes P2
Add unit field✕
Separate each option with a comma.
CancelAdd Field
FEATURE 03Custom Information on the unitA green block right on the unit panel, editable in View/Edit.fixes P1fixes P2
FEATURE 04Custom Information on the residentBlood group, birthday and more; owner and tenant keep their own.fixes P5
FEATURE 05Reports that include itUnit fields become columns; user fields stay moderator-only.fixes P2fixes P5
FEATURE 06An honest deleteSays it removes values from every unit, before you confirm.fixes P4
!Delete “Swimming Pool”?
This removes the field from every unit, along with the values already recorded against it. This cannot be undone.
CancelDelete Field
Edge cases, handled.
✓A 6th field
Add is disabled at 5 of 5, with a tooltip.
Add is disabled at 5 of 5, with a tooltip.
✓Duplicate name
Inline error; unique per section, case-insensitive.
Inline error; unique per section, case-insensitive.
✓Dropdown with 1 option
Rejected, at least two needed.
Rejected, at least two needed.
✓Change type after data
Type locks; renaming keeps every value.
Type locks; renaming keeps every value.
✓Field added later
Shows blank on existing units, no errors.
Shows blank on existing units, no errors.
✓Owner vs tenant
Each keeps their own user-field values.
Each keeps their own user-field values.
✓Non-moderator in reports
Never sees user custom-field columns.
Never sees user custom-field columns.
✓Unconfigured community
Empty states in Setup; reports unchanged.
Empty states in Setup; reports unchanged.
Impact and what’s next.
1 place
for community data: the unit or resident it belongs to
3
surfaces kept in sync: Setup, unit & profile, and reports
0
separate spreadsheets needed to answer “which units have a pool?”
WHAT I LEARNED
- →Follow the spreadsheet, it’s the real roadmap
- →Flexibility needs guardrails to stay trustworthy
- →Put data where the work already happens
NEXT STEPS
- →Search and filter units by custom field
- →More Setup tabs for Units & Users config
- →Bulk import from existing spreadsheets