4.7 Object Modeling Case Lab

Case Lab: Modeling Customer Training Delivery

Scenario: a software company sells implementation services and customer training. Leadership wants Salesforce to track which customer accounts buy training, which courses are delivered, who attends, instructor assignments, and post-course satisfaction. Sales already uses Account, Contact, Opportunity, Product, and Case. The admin must decide what belongs on standard objects, what needs custom objects, and how users should work with the records.

Start by listing business nouns. Account and Contact already exist. Opportunity can track the sale of training packages. Product can represent sellable course offerings if the sales process uses products. A delivered class is not the same as a product; it has a date, capacity, instructor, delivery method, location, status, and attendance. An attendee's enrollment is also its own concept because it connects one contact to one delivered class and has status, attendance, and survey score.

A reasonable model could include a custom Course Delivery object and a custom Enrollment junction object. Course Delivery relates to Account when the class is private for a customer, and may relate to Product or a custom Course Catalog object if the company needs reusable curriculum records. Enrollment relates Contact to Course Delivery. Instructor Assignment could be a lookup to User from Course Delivery if there is one primary instructor, or a separate child object if multiple instructors need roles and hours.

Now choose relationships. Course Delivery to Account might be lookup if public courses can exist without a single customer account, or master-detail if every delivery must belong to one account and inherit access. Enrollment to Course Delivery is often master-detail because an enrollment should not exist without the delivery, and the delivery may need roll-ups such as number of enrollments. Enrollment to Contact could be lookup or master-detail depending on ownership and deletion needs; many orgs prefer lookup to Contact to avoid overly tight lifecycle behavior.

Fields should match reporting questions. Course Delivery needs Status, Start Date, End Date, Delivery Method, Capacity, Location, Primary Instructor, and maybe Course Level. Enrollment needs Enrollment Status, Attendance Status, Registration Date, Completion Date, Survey Score, and Certificate Sent. Use picklists for statuses and delivery method. Use date fields for dates. Use number for capacity and score when calculation or reporting is needed.

Requiredness should be staged. At creation, Course Delivery may require Start Date, Status, Delivery Method, and Course Name. Instructor might be required only when Status moves to Scheduled. Survey Score should be required only when Enrollment Status becomes Completed and the business truly requires it. Conditional validation rules are better than making every field universally required.

Record types may or may not be needed. If public, private, and virtual deliveries use different status values, fields, and pages, record types could help. If the differences are minor, one record type with Dynamic Forms sections based on Delivery Method may be simpler. The admin should avoid creating record types just to hide one field.

Lightning page design should reflect user work. Training coordinators need schedule, capacity, instructor, enrollments, and status actions. Sales users may need a compact view of delivery status from the Account or Opportunity. Managers may want report charts for upcoming deliveries and completion rates. A Course Delivery record page can use tabs for Details, Enrollments, Activity, and Insights, with Dynamic Actions that show Cancel only when the delivery is not completed.

Build the lab in a playground with a small data set:

1. Create Course Delivery as a custom object with a tab.
2. Add fields for dates, status, capacity, delivery method, location, and instructor.
3. Relate Course Delivery to Account and test whether lookup or master-detail matches the scenario.
4. Create Enrollment as a junction object between Contact and Course Delivery.
5. Add enrollment status, attendance, completion date, and survey score fields.
6. Add a roll-up summary on Course Delivery if the Enrollment relationship supports it.
7. Create validation rules for realistic conditional requirements.
8. Build a Lightning record page with focused sections and related lists.
9. Create reports for upcoming deliveries, enrollments by account, and completion rate.
10. Test as a coordinator, sales user, and manager.

This lab also shows why schema and UX cannot be separated. If Enrollment is a multi-select picklist on Contact, reporting by delivery becomes painful and attendance details have no proper home. If every class type becomes a different object, reporting across all deliveries becomes painful. If page visibility hides fields but field-level security is open, sensitive survey data may still be exposed elsewhere.

For Agentforce-aware administration, a clean model helps future AI and assistant use cases. A support or training agent should be grounded in reliable Course Delivery and Enrollment records, not scattered notes. However, the admin must verify permissions, data sensitivity, and testing boundaries before exposing actions or answers. AI should assist users within trusted data and access rules, not compensate for missing schema discipline.

The exam version of this lab would usually be shorter, but the logic is the same. Identify the business concept, select standard objects first, create custom objects only for distinct records, choose relationship type based on lifecycle and access, enforce data quality at the right layer, and shape the Lightning page around user tasks. When two answers look plausible, choose the one that preserves clean data and uses native platform behavior with the least unnecessary complexity.