📊 Day 1: Scoping the Problem + Building the Core Data Model
I am a senior software developer with extensive experience in leading teams and building complex web platforms, including educational and healthcare-focused applications. I have demonstrated deep technical expertise in backend development, AI integration, and cloud technologies, which is further evidenced by my peer-reviewed publications in real-time object detection and AI. My work has earned recognition through citations and contributions to platforms indexed in Google Scholar and ResearchGate. Beyond my technical roles, I am actively involved in mentorship through ADPList and serve as an Alumni Advisory Board Member for the Generation Initiative, showcasing my commitment to advancing digital skills and cloud technology.
Series: Salesforce Admin + BA in 10 Days (Housing Ops)
Date: 9 October 2025
Time invested: 3.5 hours
GitHub: SALESFORCE ADMIN + BA
🎯 Today's Goal
Define the problem, identify users, and build the foundation data model for a Housing Operations system in Salesforce.
📋 What I Built Today
1. Problem Statement
Incommunities Limited manages 20,000+ properties. Current systems are fragmented (legacy CRM + spreadsheets + separate property database). Housing officers spend 40% of their time searching for information.
Solution: Centralize tenant, property, and case data in Salesforce.
Success metrics (90 days post-launch):
Response time: 48h → 24h (50% improvement)
Duplicate cases: 15% → 5%
CSAT score: 6.2 → 8.0
2. User Personas
I documented 4 personas:
Sarah Chen (Housing Officer)
Pain point: Searches 3 systems to find tenant + property + case history
How Salesforce helps: Single system with 360° view
James Okafor (Senior Housing Officer)
Pain point: No visibility into team workload or SLA compliance
How Salesforce helps: Real-time dashboard + automated alerts
Aisha Patel (Safeguarding Lead)
Pain point: Vulnerability data in locked Excel file, no audit trail
How Salesforce helps: Field-level security + audit trail
David Thompson (IT Admin)
Pain point: No documentation of customizations
How Salesforce helps: Data dictionary + change management via Cases
3. Use Cases
I defined 5 use cases:
Log a repair request (with duplicate detection)
Approve emergency repair (approval workflow)
Flag vulnerable tenant (with audit trail)
Generate weekly performance report
Bulk import properties (using External ID + upsert)
4. Entity Relationship Diagram (ERD)
I designed the data model with 4 objects:
Account (Household) ← Contact (Tenant)
Account ← HOA_Property__c (Property)
Contact ← Case (Repair/Complaint)
HOA_Property__c ← Case
Key design decision: Properties are separate from Accounts because one household can manage multiple properties.
5. Custom Property Object
I created HOA_Property__c with 7 custom fields:
| Field | Type | Why it matters |
| Property ID | Text (External ID) | Enables upsert during data imports (no duplicates) |
| Address | Text Area | Full property address |
| Postcode | Text | UK postcode |
| Property Type | Picklist | Flat, House, Bungalow, Maisonette |
| Bedrooms | Number | Number of bedrooms |
| Tenure Type | Picklist | Social Rent, Affordable Rent, Shared Ownership, Leasehold |
| Active | Checkbox | Is property currently active? |
Key learning: External ID is critical for data imports. It allows "upsert" (insert or update) — if Property ID already exists, Salesforce updates the record instead of creating a duplicate.
6. Vulnerability Fields on Contact
I added 2 fields to Contact:
Vulnerability Flag (Checkbox)
Vulnerability Reason (Text Area Long)
Why on Contact, not Account?
Vulnerability is person-specific. One tenant may be vulnerable; another in the same household may not be.
Security: These fields will be restricted with field-level security (Day 2).
7. Property Lookup on Case
I added a lookup field on Case → Property.
Why?
Cases are about properties (repairs, complaints). This lookup gives full context: which property, which tenant, which household.
8. Page Layouts
I organized page layouts:
Property Layout: Grouped all fields in "Property Details" section
Contact Layout: Added "Safeguarding" section for vulnerability fields
Case Layout: Added Property field to "Case Information" section
9. Data Dictionary
I created a data dictionary (Excel) with 11 fields:
- Object, Field Label, API Name, Data Type, Required?, Unique?, Default, Purpose, Security Notes
Why?
Documentation is critical for:
Onboarding new admins
Compliance audits
Change management
🧠 Key Learnings
1. External ID = Upsert Superpower
Marking Property_ID__c as External ID enables upsert during data imports. This prevents duplicates when importing 20,000 properties from legacy system.
2. Vulnerability Data Belongs on Contact (Not Account)
Vulnerability is person-specific. If I put it on Account, I'd lose granularity (e.g., one tenant in household is vulnerable, another isn't).
3. Page Layouts Matter for User Adoption
If fields are scattered randomly, users get frustrated. Grouping related fields (e.g., "Safeguarding" section) makes the UI intuitive.
4. Documentation = Future-Proofing
Data dictionary took 30 minutes but will save hours when:
Training new users
Responding to compliance audits
Onboarding new admin (if I leave the role)
🚧 Challenges
Challenge 1: Property Object Not Appearing in Lookup Dropdown
When creating the Case → Property lookup, HOA_Property__c didn't appear in the dropdown.
Solution: Logged out and logged back in (Salesforce caches metadata). After refresh, "Property" appeared in the dropdown.
Lesson: Always look for the Label (Property), not the API name (HOA_Property__c) in dropdowns.
Challenge 2: Deciding Where to Put Vulnerability Data
I debated: Should vulnerability fields go on Account or Contact?
Decision: Contact (person-specific).
Rationale:
One household may have 2 tenants: one vulnerable, one not
Safeguarding policies require person-level tracking
Audit trail needs to show who accessed which person's data
📊 Progress Check
✅ Problem statement finalized
✅ 4 personas documented
✅ 5 use cases defined
✅ ERD created and uploaded
✅ HOA_Property__c object created with 7 fields
✅ Vulnerability fields added to Contact
✅ Property lookup added to Case
✅ Page layouts updated
✅ Data dictionary uploaded
✅ Screenshots uploaded
Time: 3.5 hours (slightly over estimate, but worth it for documentation quality)
🎯 Next: Day 2 — Security by Design
Tomorrow I'll configure:
3 custom profiles (Housing Officer, Senior Officer, Admin)
Permission sets for vulnerability data
Field-level security (FLS) for Safeguarding fields
Sharing rules
RACI matrix
Why security on Day 2?
Security should be designed early, not bolted on later. Vulnerability data is sensitive (GDPR + safeguarding policies).
🔗 Resources
GitHub repo: [Salesforce Admin + BA]
Salesforce Trailhead: Data Modeling
💬 Reflections
What went well:
ERD design was clear (4 objects, 5 relationships)
External ID concept clicked immediately (thanks to Trailhead prep)
Documentation (data dictionary) felt tedious but I know it'll pay off
What I'd do differently:
- Should have taken screenshots during the build (not after). Had to recreate some steps for screenshots.
Confidence level: 8/10
I feel solid on data modeling. Excited to tackle security tomorrow.
Follow my journey:
💻 GitHub repo: [Salesforce Admin + BA]
📝 Hashnode: [Salesforce Admin + BA]
#Salesforce #SalesforceAdmin #10DayChallenge #HousingOps #DataModeling #LearningInPublic
