Ở Phần 3, chúng ta đã đi qua Configuration & Setup — nơi Salesforce Admin thiết lập nền móng về User, Security, Organization và các cấu hình cấp hệ thống.

Nhưng một Org tốt không chỉ cần bảo mật đúng. Nó còn phải có một kiến trúc dữ liệu hợp lý và một giao diện phù hợp với từng nhóm người dùng.

Đây chính là phạm vi của Object Manager & App Builder.

Trong bài này, chúng ta sẽ tập trung vào 4 nhóm kiến thức rất quan trọng trong kỳ thi Salesforce Platform Administrator 2026:

• Relationships
• Field Dependencies khi xóa Field
• Record Types & Page Layouts
• Lightning App Builder

---

1. Relationships: Master-Detail hay Lookup?

Khi thiết kế Data Model, một trong những quyết định quan trọng nhất là:

Object A và Object B thực sự phụ thuộc vào nhau đến mức nào?

Salesforce cung cấp hai loại Relationship phổ biến nhất:

• Lookup Relationship
• Master-Detail Relationship

Đừng chỉ học thuộc rằng "Master-Detail có Roll-Up Summary". Trong bài thi, điểm khác biệt thực sự nằm ở Security, Ownership, Record Lifecycle và Data Dependency.

Lookup Relationship

Lookup là mối quan hệ lỏng.

Ví dụ:

Account
   │
   └── Lookup
          │
          ▼
       Contact

Child record vẫn có thể tồn tại độc lập với Parent.

Điều này có nghĩa:

• Child có Owner riêng.
• Child có sharing/security riêng.
• Xóa Parent không nhất thiết xóa Child.
• Không có Roll-Up Summary thông thường dựa trên Lookup relationship.
• Phù hợp khi hai object có quan hệ nhưng không phụ thuộc hoàn toàn vào nhau.

Lookup thường được dùng khi chúng ta muốn nói:

"Record này có liên quan đến record kia."

chứ không phải:

"Record này là một phần không thể tách rời của record kia."

Master-Detail Relationship

Master-Detail là mối quan hệ chặt chẽ hơn rất nhiều.

Master
  │
  ├── Detail
  ├── Detail
  └── Detail

Detail record phụ thuộc vào Master.

Một số đặc điểm quan trọng:

Tiêu chí	Lookup	Master-Detail
Ownership	Child có Owner riêng	Child phụ thuộc Master
Security	Child có security riêng	Child kế thừa security từ Master
Xóa Parent	Có thể giữ Child tùy cấu hình	Xóa Master → xóa Detail
Roll-Up Summary	Không	Có
Child tồn tại độc lập	Có	Không
Mức độ phụ thuộc	Lỏng	Chặt

Tình huống doanh nghiệp thực tế

Hãy tưởng tượng chúng ta xây Salesforce cho một công ty bán thang máy.

Một Opportunity có thể có nhiều Elevator Configuration.

Ví dụ:

Opportunity: Vincom Tower Elevator Project
│
├── Configuration: 8 tầng - 1000kg
├── Configuration: 15 tầng - 1350kg
└── Configuration: 25 tầng - 1600kg

Nếu Configuration chỉ là thông tin tham khảo, có thể tồn tại độc lập và được tái sử dụng → Lookup hợp lý hơn.

Nhưng nếu mỗi Configuration chỉ có ý nghĩa khi thuộc về đúng Opportunity và khi Opportunity bị xóa thì toàn bộ Configuration cũng phải biến mất → Master-Detail phù hợp hơn.

Đặc biệt, nếu doanh nghiệp muốn tính:

Total Configuration Value = tổng giá trị của tất cả Configuration thuộc Opportunity

thì Master-Detail cho phép sử dụng Roll-Up Summary để tính tổng trực tiếp trên Parent.

Đây là tư duy mà Salesforce Admin cần có:

Đừng chọn Master-Detail chỉ vì "có Roll-Up Summary". Hãy chọn nó khi Child thực sự phụ thuộc vào Parent về mặt nghiệp vụ và vòng đời dữ liệu.

---

2. Cẩn thận với việc Delete Field

Đây là một trong những bẫy rất dễ gặp trong phòng thi Salesforce Admin.

Một Custom Field không đơn giản chỉ là "một cột dữ liệu".

Nó có thể đang được sử dụng bởi:

• Formula Field
• Roll-Up Summary
• Validation Rule
• Workflow
• Flow
• Reports
• List Views
• Apex
• Integration
• Page Layout
• Lightning Record Page
• Permission configuration

Vì vậy, khi xóa Field, Admin phải kiểm tra Dependency trước.

Đặc biệt quan trọng: Roll-Up Summary

Giả sử chúng ta có:

Opportunity
    │
    └── Master-Detail
            │
            ▼
      Opportunity Item

Opportunity có Roll-Up Summary:

Total Amount
= SUM(Opportunity Item.Amount)

Nếu Field Amount trên Detail bị xóa hoặc thay đổi theo cách làm mất dependency, Roll-Up Summary có thể bị ảnh hưởng.

Tương tự với Cross-Object Formula.

Ví dụ:

Opportunity.Account.Industry

Một Formula Field trên Opportunity có thể lấy dữ liệu từ Account.

Nếu Field mà Formula đang tham chiếu bị xóa, Formula sẽ mất dependency và có thể trở thành invalid/broken.

Bẫy phòng thi

Nếu câu hỏi nói:

"An administrator wants to delete a custom field that is referenced by a Roll-Up Summary or Formula."

Đừng nghĩ:

"Field không còn dùng thì cứ Delete."

Hãy nghĩ ngay đến:

Dependency!

Trước khi xóa một Field quan trọng, Admin cần xác định Field đang được sử dụng ở đâu và xử lý các dependency liên quan.

Đây là một trong những điểm phân biệt giữa một Admin chỉ biết thao tác Setup và một Admin thực sự hiểu kiến trúc Salesforce.

---

3. Record Types & Page Layouts: Đừng nhầm vai trò

Một Object có thể phục vụ nhiều quy trình nghiệp vụ khác nhau.

Ví dụ cùng là Opportunity, nhưng:

• Sales trực tiếp có quy trình bán hàng A.
• Partner Sales có quy trình bán hàng B.

Chúng ta không nhất thiết phải tạo hai Object khác nhau.

Thay vào đó, Record Type cho phép Salesforce hiểu:

"Record này thuộc loại nghiệp vụ nào?"

Record Type có thể điều khiển ba thứ cực kỳ quan trọng:

1. Page Layout

Record Type có thể được gán với Page Layout khác nhau.

Ví dụ:

Retail Opportunity
    → Retail Page Layout

Enterprise Opportunity
    → Enterprise Page Layout

2. Picklist Values

Cùng một Picklist nhưng mỗi Record Type có thể có tập giá trị khác nhau.

Ví dụ Lead Source hoặc một custom Picklist có thể được giới hạn value tùy Record Type.

3. Business Processes

Record Type có thể được kết hợp với Business Process tương ứng trên các Object hỗ trợ Business Process như:

• Opportunity → Sales Process
• Case → Support Process
• Lead → Lead Process

Ví dụ:

Partner Opportunity Record Type
        ↓
Partner Sales Process
        ↓
Stage values phù hợp với Partner

Vì vậy, hãy nhớ:

Record Type không chỉ đơn giản là "phân loại Record". Nó là cơ chế để Salesforce áp dụng một bộ hành vi nghiệp vụ khác nhau cho cùng một Object.

---

4. Lightning App Builder: Biến Record Page thành giao diện thông minh

Nếu Object Manager giúp chúng ta xây dựng cấu trúc dữ liệu, thì Lightning App Builder giúp chúng ta quyết định:

"Người dùng sẽ nhìn thấy và tương tác với dữ liệu đó như thế nào?"

Thay vì tất cả User đều nhìn thấy một giao diện giống nhau, Lightning App Builder cho phép tạo Lightning Record Page và điều chỉnh component theo ngữ cảnh.

Ví dụ một Opportunity có thể có:

Sales User
    → Opportunity Information
    → Products
    → Activities
    → Sales Guidance

Manager
    → Opportunity Information
    → Products
    → Forecast
    → Approval Information

Một trong những tính năng mạnh nhất là Component Visibility.

Admin có thể thiết lập điều kiện để component:

• Hiện hoặc ẩn theo giá trị Field.
• Hiện hoặc ẩn theo Record Type.
• Hiện hoặc ẩn dựa trên User/permission context phù hợp.

Ví dụ:

Record Type = Enterprise
        ↓
Hiển thị Enterprise Configuration component

Hoặc:

User/Permission Context
        ↓
Có quyền quản lý
        ↓
Hiển thị Management Dashboard

Điều này giúp chúng ta xây dựng một UI mang tính context-aware — người dùng chỉ nhìn thấy những gì thực sự cần thiết.

Đây là một nguyên tắc UX rất quan trọng:

Không phải cứ đưa tất cả dữ liệu lên màn hình là tốt. Một giao diện tốt là giao diện đưa đúng thông tin đến đúng người, đúng thời điểm và đúng ngữ cảnh.

---

Kết luận: Từ Data Model đến Automation

Đến đây, chúng ta đã đi qua một chuỗi kiến thức rất quan trọng:

Relationship
     ↓
Data Dependency
     ↓
Record Type
     ↓
Page Layout
     ↓
Lightning App Builder
     ↓
User Experience

Master-Detail hay Lookup quyết định mức độ phụ thuộc giữa các dữ liệu.

Field Dependency quyết định một thay đổi tưởng như đơn giản có thể ảnh hưởng đến toàn bộ hệ thống như thế nào.

Record Type & Page Layout giúp một Object phục vụ nhiều quy trình nghiệp vụ.

Và Lightning App Builder biến dữ liệu đó thành một giao diện linh hoạt, phù hợp với từng người dùng và từng ngữ cảnh.

Nhưng chúng ta mới chỉ trả lời được:

"Dữ liệu được tổ chức như thế nào và người dùng nhìn thấy nó ra sao?"

Câu hỏi tiếp theo còn thú vị hơn:

"Khi dữ liệu thay đổi, Salesforce sẽ tự động làm gì?"

Một Case mới được tạo thì có tự động gửi Email không?

Một Opportunity đạt đến Stage nhất định thì có tự động cập nhật Field không?

Một Record được tạo thì có cần Approval không?

Đó chính là lúc chúng ta bước vào thế giới của Automation.

Hẹn gặp bạn ở Phần 5 — nơi chúng ta sẽ bắt đầu "ra lệnh" cho Salesforce tự làm công việc thay cho Admin.