🔒 Day 5: Security & Access Control
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.
What I Built Today
Today I implemented a complete security model for my Housing Operations system in Salesforce. Security is critical in a housing association context because we're dealing with sensitive tenant data, financial information, and safeguarding records.
I learned how Salesforce's multi-layered security model works and applied it to ensure the right people have the right access to the right data.
The 6 Layers of Salesforce Security
Salesforce security works in layers, from most restrictive to least restrictive:
1. Organization-Wide Defaults (OWD)
What it controls: Baseline access to records
I set:
Property: Public Read/Write (shared resource)
Tenancy, Repair Request, Vulnerability: Private (sensitive data)
2. Role Hierarchy
What it controls: Access to records owned by users below you
I created a 7-role hierarchy:
CEO
├── Head of Housing
│ ├── Housing Manager
│ │ └── Housing Officer
│ └── Repairs Manager
└── Finance Manager
└── Finance Officer
Managers can see their team's records automatically.
3. Sharing Rules
What it controls: Extends access to specific groups
I created 2 sharing rules:
High Risk Arrears Visibility: Finance Officers can see tenancies with arrears ≥ £1500
Urgent Repairs Visibility: Repairs Managers can see all urgent repair requests
4. Manual Sharing
What it controls: Individual record sharing by owners
Users can share specific records with colleagues as needed.
5. Profiles
What it controls: Object and field permissions
I created 3 custom profiles:
Housing Officer: Full access to properties, tenancies, repairs, vulnerabilities
Repairs Manager: View All/Modify All on repairs, read-only on others
Finance Officer: View All on tenancies, read-only on others
6. Permission Sets
What it controls: Additional permissions on top of profiles
I created 2 permission sets:
Vulnerability Data Steward: Grants delete permission on vulnerabilities
Financial Data Viewer: Grants read access to financial fields for specific Repairs Managers
Key Learnings
1. Profiles vs. Permission Sets
When to use Profiles:
Define baseline permissions for a job role
One profile per user
Example: All Housing Officers get the same base permissions
When to use Permission Sets:
Grant additional permissions to specific users
Users can have multiple permission sets
Example: Only some Housing Officers need delete access to vulnerabilities
Best Practice: Keep profiles broad and use permission sets for exceptions.
2. Field-Level Security (FLS)
Field-level security restricts access to specific fields, even if a user has object-level access.
Example: I restricted the Rent Arrears field on Tenancy:
Visible to: System Administrator, Finance Officer
Hidden from: Housing Officer, Repairs Manager
Why this matters:
Protects sensitive financial data
Ensures compliance with data protection regulations
Prevents unauthorized access to personal information
How to set FLS:
Go to the field
Click Set Field-Level Security
Configure visibility for each profile
3. Role Hierarchy and Record Access
The role hierarchy is powerful but often misunderstood.
Key Rule: Users can see records owned by users below them in the hierarchy.
Example:
Housing Officer creates a tenancy (they own it)
Housing Manager (their boss) can automatically see it
Head of Housing (their boss's boss) can also see it
Finance Officer (different branch) CANNOT see it (unless shared via sharing rule)
Important: Role hierarchy only works if OWD is set to Private or Public Read Only. If OWD is Public Read/Write, everyone can see everything anyway!
4. Organization-Wide Defaults (OWD)
OWD sets the baseline access for records you don't own.
Options:
Private: You can only see records you own (most restrictive)
Public Read Only: You can see all records but only edit your own
Public Read/Write: You can see and edit all records (least restrictive)
My choices:
Property: Public Read/Write (properties are shared resources, everyone needs access)
Tenancy, Repair Request, Vulnerability: Private (sensitive data, need to control access)
Why Private for sensitive objects?
Protects tenant privacy
Ensures compliance with GDPR
Allows granular control via role hierarchy and sharing rules
5. Sharing Rules
Sharing rules extend access beyond OWD and role hierarchy.
Two types:
Criteria-Based Sharing Rules:
Share records that meet specific criteria
Example: Share tenancies with arrears ≥ £1500 with Finance Officers
Ownership-Based Sharing Rules:
Share records owned by specific users/roles with other users/roles
Example: Share all records owned by Housing Officers in Region A with Housing Officers in Region B
I used criteria-based sharing rules because I wanted to share based on data values (arrears amount, repair priority), not ownership.
6. Testing is Non-Negotiable
You must test your security model with real users (or test users).
Why?
Security bugs can expose sensitive data
Incorrect permissions can block users from doing their jobs
Compliance violations can result in fines
My testing approach:
Create test users for each profile
Log in as each test user (use incognito/private browsing)
Try to access records you should and shouldn't see
Try to perform actions you should and shouldn't be able to do
Document the results
Pro tip: Use the "Login As" feature (Setup → Users → Login) to quickly test as different users without logging out.
Real-World Impact for Incommunities
This security model ensures:
Data Protection & Compliance
GDPR compliance: Sensitive tenant data is only visible to authorized users
Safeguarding compliance: Vulnerability data is highly restricted
Audit trail: Field history tracking shows who accessed what and when
Operational Efficiency
Right access, right people: Users see the data they need, nothing more
Reduced admin overhead: Permission sets allow exceptions without profile changes
Clear accountability: Record ownership and role hierarchy make responsibilities clear
Risk Management
Prevents data breaches: Field-level security protects financial data
Prevents accidental deletion: Only admins and specific users can delete records
Escalation paths: Role hierarchy ensures managers can see their team's work
What I Learned About the Salesforce Admin Role
Today's work directly aligns with the Salesforce Administrator role at Incommunities:
From the Job Spec:
"Manage user access, profiles, and permissions"
How today's work delivers this:
Created custom profiles for different job roles
Configured object and field-level permissions
Used permission sets for exceptions
Built role hierarchy to reflect organizational structure
From the Job Spec:
"Ensure data security and compliance"
How today's work delivers this:
Implemented field-level security for sensitive data
Set organization-wide defaults to Private for sensitive objects
Created sharing rules to extend access only where needed
Tested security model thoroughly
From the Job Spec:
"Support users and troubleshoot issues"
How today's work delivers this:
Understanding security helps troubleshoot "I can't see this record" issues
Knowing when to use profiles vs. permission sets helps solve access problems efficiently
Testing as different users builds empathy for user experience
Challenges I Faced
1. Understanding the Security Layers
At first, the 6 layers felt overwhelming. Which layer should I configure first?
Solution: I learned to think bottom-up:
Start with OWD (most restrictive baseline)
Add role hierarchy (extends access to managers)
Add sharing rules (extends access to specific groups)
Configure profiles (object/field permissions)
Add permission sets (exceptions)
2. Profiles vs. Permission Sets
I initially tried to create a different profile for every possible combination of permissions.
Solution: Keep profiles broad (one per job role) and use permission sets for exceptions. This is more maintainable and scalable.
3. Testing Security
Testing security is tedious because you need to log in as different users repeatedly.
Solution: Use the "Login As" feature and keep a spreadsheet of test scenarios to ensure thorough coverage.
Tomorrow: Day 6
I'll dive into Automation with Flow – building flows to automate business processes like auto-assigning repair requests, sending email alerts, and updating records automatically! 🤖
This is where Salesforce really starts to feel like magic!
Resources
GitHub: [https://github.com/chidoziemanagwu/sfdc-housing-ops-admin-ba]
Hashnode: [](https://github.com/chidoziemanagwu/sfdc-housing-ops-admin-ba)https://doxzy.hashnode.dev/series/project-based-learning-with-daily-lessons-templates-and-assets[]
Progress Tracker
✅ Day 1: Data Modeling & ERD ✅ Day 2: Custom Objects & Fields ✅ Day 3: Data Quality & Validation Rules ✅ Day 4: Formula Fields & Calculations ✅ Day 5: Security & Access Control ⬜ Day 6: Automation (Flow) ⬜ Day 7: Reports & Dashboards ⬜ Day 8: Data Management ⬜ Day 9: Integration Basics ⬜ Day 10: Final Project & Review
Follow my journey:
GitHub: [https://github.com/chidoziemanagwu/sfdc-housing-ops-admin-ba]
Hashnode: [](https://github.com/chidoziemanagwu/sfdc-housing-ops-admin-ba)https://doxzy.hashnode.dev/series/project-based-learning-with-daily-lessons-templates-and-assets[]
#Salesforce #SalesforceAdmin #LearningInPublic #Day5 #Security #DataProtection #GDPR #HousingAssociation #Incommunities
