Nếu Object Manager trả lời câu hỏi “Dữ liệu của chúng ta được xây như thế nào?”, thì Configuration & Setup trả lời một câu hỏi còn quan trọng hơn: “Ai được phép làm gì, được nhìn thấy dữ liệu nào và Org được bảo vệ ra sao?”

Trong hành trình chinh phục Salesforce Platform Administrator 2026, Configuration & Setup chiếm 15% trọng số bài thi.

Nhưng đừng học 15% này theo kiểu thuộc lòng từng menu trong Setup.

Hãy tư duy như một Salesforce Administrator đang vận hành một Production Org thực tế.

Giả sử chúng ta có một công ty với:

• 300 Sales Representatives
• 30 Sales Managers
• 5 Regional Managers
• Nhóm Sales Operations
• Nhóm Security/IT

Business đưa ra một loạt yêu cầu:

Sales Rep không được xem dữ liệu của Sales Rep khác. Sales Manager phải xem được dữ liệu của team. Regional Manager phải xem được toàn region. Một số Sales Ops cần thêm quyền đặc biệt. User ngoài mạng công ty phải được xác minh. Security Admin cần biết ai vừa thay đổi cấu hình.

Đây chính là lúc Configuration & Setup phát huy sức mạnh.

---

1. Profiles vs Permission Sets: User được phép LÀM GÌ?

Đây là lớp quyền đầu tiên cần xác định.

Một cách nhớ rất thực dụng:

Profile = baseline access Permission Set = additional access

Business Scenario

100 Sales Rep đều có quyền:

• Đăng nhập Salesforce
• Read/Edit Account
• Create/Edit Opportunity
• Chạy Report

Nhưng:

• 5 Sales Ops cần thêm quyền export dữ liệu.
• 3 Integration Users cần API access.
• 2 Contract Specialists cần thêm quyền liên quan đến Contract.

Cách làm “non-scalable” là tạo hàng loạt Profile:

Sales Profile
Sales + Export Profile
Sales + API Profile
Sales + Contract Profile
Sales + API + Contract Profile
...

Chỉ vài năm sau, Admin sẽ phải quản lý một rừng Profiles.

Thiết kế tốt hơn:

Sales Profile
      │
      ├── Export Permission Set
      ├── API Permission Set
      └── Contract Permission Set

Mỗi user có một Profile, nhưng có thể được cấp nhiều Permission Sets.

🎯 Exam Traps

Bẫy 1: User không thể có nhiều Profiles. Nhưng một user có thể có nhiều Permission Sets.

Bẫy 2: Permission Set chủ yếu dùng để grant thêm quyền, không phải để revoke permission mà user đã có từ Profile.

Bẫy 3: Đề nói “chỉ một nhóm nhỏ user cần thêm quyền” → nghĩ ngay đến Permission Set, đừng vội tạo Profile mới.

---

2. OWD: User được thấy RECORD nào?

Đây là nơi rất nhiều người nhầm với Profile.

Hãy tách hai câu hỏi:

Câu hỏi	Công cụ chính
User có quyền Read/Edit Object không?	Profile / Permission Set
User được xem record nào?	OWD / Role / Sharing

Business Scenario

Salesforce có 300 Sales Rep.

Business yêu cầu:

Sales Rep A không được xem Opportunity của Sales Rep B.

Nếu đặt:

Opportunity OWD = Public Read/Write

thì thiết kế đã sai ngay từ baseline.

Một lựa chọn hợp lý:

Opportunity OWD = Private

Sau đó Salesforce mới sử dụng các cơ chế khác để mở rộng access khi cần.

Đây là nguyên tắc cực kỳ quan trọng:

Start restrictive, then open access.

Đừng bắt đầu bằng việc mở toàn bộ dữ liệu rồi tìm cách “đóng” từng trường hợp.

🎯 Exam Traps

Bẫy 1: OWD không quyết định user có quyền Edit Object hay không.

Bẫy 2: OWD = Private không có nghĩa Manager không thể xem dữ liệu của nhân viên cấp dưới.

Role Hierarchy hoặc các cơ chế sharing khác có thể mở rộng record access.

Bẫy 3: Nếu đề hỏi “default record access”, hãy nghĩ đến OWD, không phải Profile.

---

3. Role Hierarchy: Ai được nhìn thấy dữ liệu theo chiều dọc?

Đừng hiểu Role Hierarchy đơn giản là:

Role = Job Title

Trong Security Model, Role Hierarchy đặc biệt quan trọng đối với record visibility theo hierarchy.

Ví dụ:

Regional Manager
       │
   Sales Manager
       │
    Sales Rep

Nếu Opportunity có OWD = Private, một Sales Rep không mặc nhiên thấy Opportunity của đồng nghiệp.

Nhưng Manager có thể được mở quyền truy cập đối với records của cấp dưới theo hierarchy.

Business Scenario

Regional Manager Bắc quản lý:

Manager A
 ├── Rep 1
 ├── Rep 2
 └── Rep 3

Manager B
 ├── Rep 4
 └── Rep 5

Business yêu cầu:

Manager A xem dữ liệu team A. Manager B xem dữ liệu team B. Regional Manager xem toàn bộ dữ liệu phía dưới.

Đây là một scenario rất tự nhiên cho Role Hierarchy.

Nhưng nếu requirement lại là:

Manager A cần xem một số record của Manager B dù hai người không nằm cùng nhánh.

Thì đừng cố nhét requirement đó vào Role Hierarchy.

Hãy nghĩ đến Sharing.

🎯 Exam Traps

Bẫy 1: Role Hierarchy không cấp Object Permission.

Bẫy 2: Không phải cứ thấy từ “Manager” trong đề là chọn Role Hierarchy.

Phải có requirement về record access theo cấp bậc.

Bẫy 3: Role Hierarchy giải quyết tốt access theo chiều dọc, còn access giữa các nhóm ngang nhau thường cần cơ chế sharing khác.

---

4. Sharing Rules: Mở cửa có kiểm soát

Đây chính là mảnh ghép nối giữa OWD và business requirement.

Hãy tưởng tượng:

OWD = Private
       ↓
Baseline rất chặt
       ↓
Sharing Rule
       ↓
Mở access cho đúng nhóm cần thiết

Business Scenario

Một công ty có:

• Sales
• Marketing
• Customer Success
• Finance

Account đang:

OWD = Private

Nhưng Marketing cần Read một nhóm Account để thực hiện campaign.

Thay vì đổi Account thành Public Read Only và vô tình mở dữ liệu cho toàn bộ Org, Admin có thể tạo một Sharing Rule để chia sẻ dữ liệu cho đúng nhóm.

Đây chính là tư duy:

OWD đóng cửa trước. Sharing mở cửa có chủ đích.

🎯 Exam Traps

Bẫy 1: Sharing Rule thường dùng để mở rộng record access, không phải thu hẹp access.

Bẫy 2: Permission Set và Sharing Rule nằm ở hai tầng khác nhau:

Permission Set
→ User được LÀM GÌ?

Sharing Rule
→ User được THẤY RECORD NÀO?

Bẫy 3: Nếu đề nói “User A cần truy cập records thuộc User/Group B”, đừng chọn Permission Set chỉ vì thấy chữ “access”.

---

5. Login & Security Settings: User có được phép VÀO Org không?

Đến đây chúng ta mới đi ra ngoài record access.

Một user có permission đầy đủ vẫn có thể bị hạn chế bởi security configuration.

Một số khu vực Admin cần đặc biệt nhớ:

• Login Hours
• Login IP Ranges
• Trusted IP Ranges
• Password Policies
• Session Settings
• Identity Verification

Business Scenario

Một công ty tài chính yêu cầu:

Nhân viên chỉ được đăng nhập Salesforce trong giờ làm việc và từ corporate network.

Đây không còn là câu hỏi:

“User có quyền Read Account không?”

Mà là:

“User có được phép establish session với Salesforce trong điều kiện này không?”

Đây là bài toán của Security Settings.

⚠️ Trusted IP vs Login IP — Bẫy cực kinh điển

Hai khái niệm rất dễ nhầm:

Login IP Range

→ Giới hạn nơi user được phép login.

Trusted IP Range

→ Xác định các IP được Salesforce tin cậy cho mục đích identity verification; đăng nhập từ ngoài vùng trusted có thể dẫn đến yêu cầu xác minh bổ sung.

Đề hỏi “restrict login location” → nghĩ Login IP Range. Đề hỏi “outside trusted network → verification” → nghĩ Trusted IP Range.

---

6. Setup Audit Trail: Ai vừa thay đổi Org?

Trong Development, một thay đổi sai có thể là một bug.

Trong Production, một thay đổi sai có thể trở thành incident.

Ví dụ:

Sáng thứ Hai, 20 Sales Rep đột nhiên không còn quyền truy cập một tính năng.

Admin kiểm tra:

• User vẫn Active.
• Profile vẫn đúng.
• Permission Set vẫn đúng.

Câu hỏi tiếp theo:

“Ai đã thay đổi Setup?”

Đó là lúc Setup Audit Trail trở nên cực kỳ hữu ích.

Nó giúp Admin theo dõi các thay đổi quan trọng trong Setup, từ đó hỗ trợ:

• Troubleshooting
• Security investigation
• Governance
• Change management

Tư duy Enterprise ở đây là:

Configuration cũng phải được kiểm soát và audit, không chỉ code.

---

🧠 Framework phá đảo câu hỏi Configuration & Setup

Khi gặp một scenario trong đề thi, đừng nhìn keyword rồi chọn đáp án.

Hãy tự hỏi theo thứ tự:

                    BUSINESS REQUIREMENT
                            │
                            ▼
                 USER CÓ LÀM ĐƯỢC KHÔNG?
                            │
                   Profile / Permission Set
                            │
                            ▼
                USER CÓ THẤY RECORD KHÔNG?
                            │
                 OWD / Role / Sharing
                            │
                            ▼
                 USER CÓ ĐƯỢC LOGIN KHÔNG?
                            │
                    Security Settings
                            │
                            ▼
                 AI ĐÃ THAY ĐỔI CẤU HÌNH?
                            │
                     Audit Trail

Hoặc nhớ bằng 4 câu hỏi:

WHAT CAN I DO? → Profile / Permission Set

WHAT CAN I SEE? → OWD / Role Hierarchy / Sharing

CAN I LOG IN? → Login & Security Settings

WHO CHANGED IT? → Setup Audit Trail

Nếu nắm được framework này, rất nhiều câu hỏi Configuration & Setup sẽ chuyển từ “học thuộc” thành “suy luận”.

---

🔥 Một bài toán, nhiều công cụ — đó mới là thứ đề thi muốn kiểm tra

Điểm khó nhất của Salesforce Admin không phải là biết OWD là gì.

Mà là biết khi nào không nên dùng OWD.

Không phải là biết Permission Set là gì.

Mà là biết khi nào Permission Set tốt hơn việc tạo Profile mới.

Không phải là biết Role Hierarchy.

Mà là nhận ra:

“Requirement này là record access theo hierarchy hay sharing ngang giữa các nhóm?”

Đó chính là sự khác biệt giữa:

“Tôi đã học Salesforce Admin.”

và

“Tôi có thể thiết kế Salesforce Security Model.”

---

🚀 Kết bài

Nếu nhìn toàn bộ Salesforce Platform như một ngôi nhà, thì Configuration & Setup chính là hệ thống kiểm soát ra vào.

Nó quyết định:

Ai được bước vào → Ai được làm gì → Ai được nhìn thấy khu vực nào → Khi nào được truy cập → Và ai đã thay đổi hệ thống.

Nhưng chúng ta mới chỉ giải quyết được một câu hỏi:

“User được phép làm gì với dữ liệu?”

Còn một câu hỏi lớn hơn đang chờ phía trước:

“Dữ liệu đó thực sự được tổ chức như thế nào trong Salesforce?”

Đó chính là lúc chúng ta bước sang Phần 4: Object Manager & App Builder.

Chúng ta sẽ bắt đầu xây bộ khung của Salesforce Org: từ Object, Field, Relationship cho đến Record Type, Page Layout và Lightning App Builder.

Nói cách khác:

Phần 3 xây SECURITY. Phần 4 xây DATA MODEL & USER EXPERIENCE. Phần 5 mới khiến mọi thứ bắt đầu TỰ ĐỘNG.

🔥 Và từ đó, Salesforce mới thực sự bắt đầu trở thành một Business Platform, thay vì chỉ là một nơi lưu trữ dữ liệu.