The Account-to-Contact relationship is a standard Lookup relationship, not Master-Detail, even though the two objects feel conceptually tightly bound. The practical consequence is twofold: first, a Contact CAN exist without being linked to any Account at all, which would be impossible under Master-Detail, where the child record cannot exist without its parent. Second, deleting an Account does not cascade-delete its related Contacts in the same forceful, immediate way true Master-Detail deletion would — Salesforce instead moves the Account and its related Contacts to the Recycle Bin together through a related but distinct mechanism, and Contacts can potentially be restored independently. This distinction is frequently tested in interviews specifically because the conceptual closeness of Account and Contact leads many people to assume Master-Detail incorrectly.

During Lead Conversion, a single Lead record is transformed into an Account, a Contact, and optionally an Opportunity, all created or matched simultaneously based on the choices made on the conversion screen, and the original Lead's Status changes to Converted, after which it becomes effectively read-only and disappears from standard Lead list views while still technically existing in the system. This is considered high-stakes and one-way because Salesforce provides no native "unconvert" function — reversing a mistaken or premature conversion requires manual cleanup, potentially deleting or merging the newly created Account, Contact, and Opportunity records and attempting to manually recreate the original Lead state, which is messy, error-prone, and rarely produces a perfectly clean result. This is exactly why many orgs invest in Validation Rules or user training to ensure Lead data quality BEFORE conversion is attempted, rather than relying on the ability to correct mistakes afterward.

Person Accounts directly address this scenario, since they merge Account and Contact fields into a single record representing one individual person while still technically residing in the Account table, eliminating the need for a meaningless placeholder company record for every individual consumer. The key risk is that enabling Person Accounts is a permanent, irreversible decision — it must be activated through Salesforce Support and cannot be disabled afterward under any circumstances, even by Salesforce itself, making it comparable in stakes to enabling Multiple Currencies from Module 1, but with even less flexibility to reverse course. Given this permanence, the recommendation is always to validate the decision thoroughly in a full sandbox environment and confirm genuine, long-term business alignment with a B2C data model before ever enabling it in production.

Using Opportunity Products and Price Books instead of a single manually-entered Amount enables itemized, product-level reporting that a flat deal value cannot provide — a business can then report specifically on which individual products or services are driving revenue, track quantity sold per product, and analyze deal composition rather than just total deal size. This structure follows Product2 as the master catalog, PricebookEntry defining that Product's price within a specific Price Book, and OpportunityLineItem representing one specific Product, quantity, and price actually added to one Opportunity, with the Opportunity's Amount typically calculated as the sum of all its Line Items rather than manually typed. Any business selling multiple distinct products or services, rather than a single undifferentiated offering, benefits significantly from this structure for accurate, granular revenue and pipeline analysis that a flat Amount field simply cannot support.

The flow begins with a Lead, representing an unqualified prospect who has shown interest but has no Account or Contact record yet. Once qualified, the Lead undergoes Lead Conversion, simultaneously creating an Account, a Contact, and typically an Opportunity representing the potential deal now being actively pursued. That Opportunity can have Products added to it, drawn from a Price Book via PricebookEntry records, with each specific Product and quantity captured as an OpportunityLineItem, giving the deal an itemized structure rather than a single flat value. Once the Opportunity reaches Closed Won, the prospect has become a genuine customer, and any subsequent support interactions are tracked as Case records, linked back to the same Account and Contact that were created at the very beginning of this flow during Lead Conversion — meaning every object in this entire journey ultimately traces back to that one originating Account.

Business Hours from Module 1 directly power Case-related SLA and escalation timing: Escalation Rules and Entitlement Processes reference a Business Hours record to correctly calculate deadlines like "respond within 4 business hours," ensuring that non-working time like evenings, weekends, and configured holidays does not count against the SLA clock, exactly as demonstrated in Module 1's escalation timing example. Sharing Rules from Module 5 apply directly through the Criteria-Based Sharing Rule pattern, where a rule such as "share any Case where Priority equals Critical, regardless of owner" ensures the right group of users, like all Support Agents, automatically gains visibility into urgent Cases the moment they are created, without needing manual reassignment or ownership changes. Together, these two mechanisms mean the Case object in Concept 4 is not really introducing new security or timing concepts — it is applying two mechanisms from earlier modules to a concrete, realistic, service-oriented use case.