Opportunity = Sale
Reservation → Agreement → Deed → After Sales becomes the Opportunity lifecycle. One stage is tracked once for the entire bundle.
Core model
Salesforce data model
The design separates physical inventory from the commercial transaction and lets Salesforce own the standard CRM behaviour.
CustomBuilding__cDevelopment / building metadata
→
StandardProduct2Apartment, parking, basement, shop, office
→
StandardOpportunityThe commercial sale / bundle
StandardPricebookEntryList / asking price
→
StandardOpportunityLineItemNegotiated unit price in this sale
→
StandardOpportunity Contact RoleBuyer participation and ownership %
Product2 = Unit
Every apartment, parking bay, basement, office or shop is an independently sellable product with unit-specific metadata.
OLI = Bundle membership
Opportunity Products replace a custom SaleUnit junction and preserve Salesforce pricing, reporting and forecasting behaviour.
Design choice
Where custom objects still earn their place
Custom objects should represent concepts Salesforce does not already model rather than duplicate standard CRM structures.
Building__c
1
Why custom?A building/project has its own lifecycle and metadata but is not naturally an Account or Product Family.
2
Relationship
Product2.Building__c as Lookup. Keep standard Product even though that means giving up master-detail here.3
OWDPublic Read Only is a sensible starting point for shared inventory metadata.
Flatten lifecycle onto Opportunity
1
Use standard Stage
Opportunity.StageName holds Reservation → Agreement → Deed → After Sales.2
Use Salesforce PathSurface the relevant signature, deposit, buyer and notary fields at the point users need them.
3
No Sale_Stage__cThe stated requirements do not justify another child object. Keep the model simpler unless stage-level records become materially more complex.
Standard UX
Opportunity Stage + Salesforce Path
The lifecycle is flattened onto Opportunity. Path gives the sales team a clear guided journey while validation rules and automation enforce the actual business requirements.
✓
ReservationDeposit + signatures2
AgreementOwnership + notary3
DeedFinal signatures4
After SalesHandover / follow-upReservation key fields
- Buyer signature date
- Developer signature date
- Deposit amount
- Deposit paid date
Agreement key fields
- Buyer signature date
- Developer signature date
- Agreement deposit
- Ownership totals 100%
- Notary assigned per buyer
Deed / After Sales
- Deed buyer signature
- Deed developer signature
- Valid bundle confirmed
- Inventory moved to Sold
- After-sales follow-up starts
Important distinction: Path is the guided user experience. Validation Rules, Flow and Apex provide enforcement. Users should never be able to bypass the underlying bundle, deposit, ownership or reservation rules simply by changing Stage.
Bundle enforcement
The Opportunity is the bundle
There is no separate Bundle object. Opportunity groups the individually selected physical units; automation determines whether that collection is legally and commercially valid.
Physical inventory
A101Apartment • deed required
P14Parking • supporting unit
P15Parking • supporting unit
B07Basement • supporting unit
→
Opportunity Products
Each selected Product becomes one Opportunity Product with Quantity = 1 and its negotiated sales price.
A101€410,000
P14€25,000
P15€25,000
B07€10,000
→
Opportunity
SALE-000123
Stage: Agreement
Amount: €470,000
Bundle rule: maximum one Product where
Requires_Separate_Deed__c = TRUE.Declarative enforcement
Flow / validation handles Quantity = 1, deed-required unit count, ownership = 100%, stage prerequisites, inventory status changes and required deposits/signatures.
Reservation concurrency
For the actual “claim this apartment” transaction, consider Apex with row locking so two users cannot reserve the same physical Product at nearly the same time.
Security
OWD & relationship strategy
OWD answers “which records can I see?” Object permissions answer “what can I do with them?” Start restrictive for customer transactions, broad for shared inventory.
| Object | Purpose | Baseline access | Relationship / rationale |
|---|---|---|---|
| Opportunity | Sale / bundle | Private | Sensitive pricing, buyers, deposits and legal data. |
| Opportunity Product | Units in sale | Controlled by Opportunity | Commercial line should follow transaction access. |
| Product2 | Physical unit inventory | Public Read Only | Sales users need visibility of availability across all buildings. |
| Building__c | Development metadata | Public Read Only | Shared catalogue, with editing reserved by permissions. |
| Account | Customer / notary organisation | Private | Open access only where process requires it. |
| Contact | Buyer / notary person | Controlled by Parent | Where this fits the broader CRM contact-sharing model. |
Interview nuance: present these OWDs as a proposed baseline, then say you would validate personas, legal/data boundaries, sales territories, finance and after-sales access during discovery.
Automation
Rules worth calling out
These are the places where the model becomes a working Salesforce solution rather than just an ERD.
Prevent double-selling a physical unit
Maintain Product2.Availability_Status__c and an active Opportunity reference. A Product representing a physical unit can only participate in one active sale at a time.
Flow is sufficient for most orchestration, but the reservation operation is where I would evaluate Apex row locking to prevent two concurrent users claiming the same apartment.
Enforce a legally valid bundle
The Opportunity is the bundle. Every Opportunity Product must have Quantity = 1, the same Product cannot appear twice, and the Opportunity may contain a maximum of one Product where Requires_Separate_Deed__c = TRUE.
Buyer ownership must total 100%
Use Opportunity Contact Roles for the buyer relationship and add transaction-specific metadata such as Ownership_Percentage__c and Notary_Contact__c. Validate the total before allowing later stages.
Control Path progression
Reservation → Agreement → Deed → After Sales is stored on Opportunity.StageName and visualised with Salesforce Path. Validation rules and Flow check the required signatures, deposits, ownership, notaries and bundle validity before allowing progression.
Interview
The 60-second architecture answer
A concise explanation you could give before drilling into the diagram.
I would stay standard-first. The Opportunity itself represents the legal sale or bundle, and each physical apartment, parking space or basement is a Product. Price Book Entries hold list prices, while Opportunity Products represent the units selected into that transaction and their negotiated prices. The bundle is enforced rather than modelled as another object: every physical Product has quantity one, the same unit cannot participate in two active sales, and an Opportunity can contain a maximum of one Product requiring its own deed. Buyers are Contacts or Person Accounts associated through Opportunity Contact Roles, carrying ownership percentage and the notary for that buyer in that transaction. I would flatten Reservation, Agreement, Deed and After Sales onto Opportunity Stage and use Salesforce Path to guide users through the relevant signature and deposit fields. Flow handles most orchestration and validation, while I would consider Apex row locking for the actual unit reservation to protect against concurrent double-selling.
Interactive ERD
Salesforce implementation data model
Standard Salesforce labels are shown first, with API names beneath. The lifecycle is flattened onto Opportunity, while relationship types, bundle membership and OWD are visible directly in the diagram.