Apex Property Operations is a fictional but realistic property management company responsible for overseeing residential and commercial properties on behalf of landlords. The business coordinates maintenance requests from tenants, assigns work to external contractors, and provides property owners with visibility into property issues and resolution timelines.
The aim of this project was to design and build a simple, scalable Salesforce solution that centralises property data, streamlines maintenance workflows, and improves operational visibility — without over-engineering the system.
This project was built in a Salesforce Developer Org and reflects how I would approach a real Salesforce Admin engagement from discovery through to delivery.
Some Projects in this solution:
- Automating Property Assignment on Work Order Creation
Flow-based automation to reliably assign the correct Property at creation time, reducing manual input and data errors.
→ View project - Why One Flow Wasn’t Enough
Evolving the automation design by separating responsibilities across multiple flows to improve clarity, maintenance, and scale.
→ View project - Why Platform Users See a Blank App
Diagnosing profile, permission, and app visibility issues to ensure Platform Users see the correct navigation and records.
→ View project
You can see the all the Apex projects here.
Business Problem
Before Salesforce, Apex Property Operations relied on emails and spreadsheets to manage properties and maintenance issues. This led to:
- No single source of truth for properties and tenants
- Maintenance requests being missed or delayed
- Limited visibility for managers into open and overdue jobs
- Difficulty tracking contractor workload and performance
The business needed a CRM that was:
- Easy for staff to use
- Flexible as the company grows
- Capable of supporting automation and reporting
Solution Design
I’m designing and building a Salesforce data model and operations workflow for end-to-end property maintenance management. This page summarises the solution direction and links to deeper implementation notes.
Core Objects
Standard Objects
- Accounts – Property Owners / Landlords
- Contacts – Tenants, Property Managers, Contractors
Custom Objects (
- Property__c – Individual properties managed by the business
- Maintenance_Request__c – Issues reported by tenants or staff
- Work_Order__c – Maintenance jobs assigned to contractors
- Seervice_Task_c- operational field work items (Platform User Friendly)
This structure ensures clear ownership, traceability, and reporting across properties and maintenance activity.
Object Relationships
- One Account can own multiple Properties
- One Property can have multiple Maintenance Requests
- Each Maintenance Request can generate one or more Work Orders
- Contacts are linked to records based on role (Tenant, Contractor, Manager)
Lookup relationships were deliberately chosen to allow flexibility and avoid unintended record deletion in operational scenarios.
Automation and Flow
To reduce manual work and improve consistency, I implemented the following automations using Record-Triggered Flows:
- Maintenance Request Intake
- Automatically sets priority based on issue type (e.g. electrical vs cosmetic)
- Defaults status and assigns ownership
- Work Order Progression
- Updates Maintenance Request status when a related Work Order is completed
- Ensures no request is left open unintentionally
- Notifications
- Email alerts to tenants when work is scheduled
- Notifications to property managers when high-priority issues are logged
All automation was built declaratively using Flow, with a focus on maintainability and clear logic paths.
Security & Access Model
To reflect real-world access requirements, I designed a simple but realistic security model:
- License-aware design: non-admin users were Salesforce Platform (no Case access)
- Property Manager
- Operations Staff
- Read-Only (future state for property owners)
- Operational work separated into Service Tasks to support Platform users
- Least privilege via Permission Sets: grant only required object + field access
- UI control with Custom Permissions: show different Lightning record pages by role
- App access validated using “Login As” and end-user navigation testing
See the following:
- Using Custom Permissions
- Why Platform Users See a Blank App
- Permission checks during Case ownership transfer
Reporting and Dashboards
I created reports and dashboards to give management immediate insight into operations, including:
- Open maintenance requests by priority
- Average resolution time
- Work orders by contractor
- Properties with repeat maintenance issues
These dashboards are designed to support daily operational decisions rather than just historical reporting.
Outcome and Learnings
This project demonstrates my ability to:
- Licensing impacts architecture: Platform users changed the object strategy
- A blank app is usually access + navigation, not a broken build
- Custom Permissions bridge security and UI for scalable role-based experiences
- Record ownership changes require related-record read access (Case transfer lesson)
It also reinforced the importance of keeping solutions simple, user-focused, and scalable, particularly in operational environments where adoption is critical.
Skills Demonstrated
- Data modelling (custom object design)
- Permission sets, FLS, and least-privilege access
- Role hierarchy + OWD concepts
- Lightning App Builder (record pages + visibility rules)
- Troubleshooting access (license vs permission vs navigation)
- Documentation + STAR storytelling
