This requires a Master-Detail relationship between the child and parent objects, because Roll-Up Summary Fields — the native, no-code mechanism for aggregating child values like SUM, COUNT, MIN, or MAX onto a parent — are only supported on Master-Detail relationships, not Lookup relationships. A Lookup relationship intentionally creates a much looser connection between two objects, where the child can exist independently, can have its own OWD, and does not inherit ownership or security from the parent the way Master-Detail does — Salesforce's platform does not extend native Roll-Up Summary support to this looser relationship type. If a Roll-Up-style aggregation is genuinely needed across a Lookup relationship, the workaround requires either an Apex trigger, a Flow that recalculates and writes the aggregate value, or Declarative Lookup Rollup Summary (DLRS), an open-source AppExchange tool built specifically to fill this gap.

Under a Master-Detail relationship, deleting the parent record automatically cascades the deletion to all of its child records as well — this is a defining, intentional characteristic of Master-Detail, reflecting that the child genuinely cannot exist without its parent. Under a Lookup relationship, the child record's behavior on parent deletion is different and generally less destructive: depending on configuration, the child typically survives with its Lookup field simply becoming blank, or in some cases the deletion of the parent can be blocked entirely if a "prevent deletion if related records exist" style constraint is configured, but true automatic cascading deletion of the child is not the Lookup relationship's native, default behavior. This cascading-delete characteristic of Master-Detail is one of the most consequential practical differences an Admin must consider before choosing this relationship type.

The most likely cause is that the specific Record Type has not been made available to that user's Profile. Record Type availability is controlled at the Profile level, meaning even a fully and correctly configured Record Type, with its own picklist values and Page Layout assignment, will simply not appear as an option for a user whose Profile does not have that Record Type explicitly added to its available Record Types list. This is a very common real-world troubleshooting scenario precisely because the Record Type configuration itself can look completely correct when viewed in isolation, and the actual missing piece is a separate Profile-level setting that is easy to overlook. The fix is to go to the user's Profile, locate the Record Type Settings section for that object, and add the specific Record Type to the list of available types for that Profile, optionally also setting it as the default if appropriate.

This is modeled using two Record Types on the existing Opportunity object — for example, "Product Sale" and "Service Sale" — each with its own Sales Process defining a distinct set of Stages appropriate to that specific type of deal, and each optionally assigned its own Page Layout emphasizing the fields relevant to that process. Building two entirely separate custom objects instead of using Record Types would be the wrong approach here, because Product and Service deals are still fundamentally the same kind of thing — Opportunities representing potential revenue — and splitting them into separate objects would fragment pipeline reporting, forecasting, and dashboards across two disconnected data sources, requiring significantly more effort to produce any unified view of total company pipeline. Record Types preserve unified reporting on the same underlying object while still allowing each business process to have its own distinct behavior, which is exactly the scenario Record Types are designed to solve.

The design process starts by checking whether this fits an existing standard object — no standard Vendor or Certification object exists by default, so both are genuinely new entities requiring custom objects. Next, the relationship: a Vendor Certification record cannot meaningfully exist without being tied to a specific Vendor, and the requirement to see a count of current certifications at a glance on the Vendor itself specifically calls for a Roll-Up Summary Field, which is only available on Master-Detail relationships — this means Vendor Certification should be Master-Detail to Vendor, not Lookup. For fields, Vendor Certification would need an Issuing Body text field, an Issue Date, an Expiry Date, and likely a Formula field determining whether the certification is currently valid based on today's date versus Expiry Date. Finally, evaluate whether Record Types are needed — if all certification types follow the same basic process, Record Types may not be necessary here, though if different certifying bodies have meaningfully different tracked attributes, Record Types could organize that variation cleanly.

The decision is high-stakes because Lookup and Master-Detail differ across multiple dimensions simultaneously — mandatory versus optional parent reference, cascading versus non-cascading deletion, independent OWD versus Controlled by Parent security, native Roll-Up Summary support versus none, and independent ownership versus inherited ownership — meaning a wrong choice does not just affect one small setting but ripples across data integrity, security configuration, and available automation all at once. It is difficult to reverse once real data exists specifically because converting Lookup to Master-Detail requires every single existing child record to already have a non-blank value in that relationship field, since Master-Detail cannot tolerate an empty parent reference, and any existing records violating this requirement will block the conversion entirely until manually corrected. This combination of wide-reaching impact and conversion friction is exactly why this decision deserves careful upfront design thinking rather than being treated as a minor technical detail.