Nếu Object Manager là nơi Admin quyết định Salesforce sẽ lưu dữ liệu như thế nào, thì Data & Analytics Management lại trả lời một câu hỏi thực tế hơn:

Làm sao đưa dữ liệu vào Org mà không biến nó thành “bãi rác”, đồng thời đảm bảo đúng người nhìn thấy đúng số liệu?

Đây chính là phần rất dễ bị xem nhẹ khi ôn Salesforce Platform Administrator, bởi các khái niệm như Data Loader, Duplicate Rules, Report Folder hay Dashboard Running User nghe khá đơn giản.

Nhưng đề thi thường không hỏi “định nghĩa là gì?”.

Nó hỏi:

“Trong tình huống này, Admin phải chọn cái nào và tại sao?”

Và đó mới là nơi bắt đầu phân loại một Admin biết thao tác Salesforce với một Admin thực sự hiểu Platform.

---

1. Quản trị dữ liệu hàng loạt: Data Import Wizard hay Data Loader?

Đây là một trong những cặp công cụ phải phân biệt bằng bản chất, không chỉ học thuộc giới hạn record.

Tiêu chí	Data Import Wizard	Data Loader
Cách sử dụng	Trình wizard trên trình duyệt	Ứng dụng client
Số lượng	Tối đa 50.000 records/lần	Tối đa 5 triệu records
Object	Một số standard objects + custom objects được hỗ trợ	Tất cả objects, bao gồm custom objects
Opportunity	Không hỗ trợ theo Data Import Wizard thông thường	Có
Export dữ liệu	Không	Có
Delete dữ liệu	Không	Có
Update dữ liệu hàng loạt	Có trong phạm vi hỗ trợ	Có
Automation	Hạn chế	Có khả năng batch/command-line
Độ phức tạp	Đơn giản, phù hợp Admin/business user	Mạnh hơn, phù hợp data operation

Vậy khi nào chọn công cụ nào?

Hãy tưởng tượng doanh nghiệp vừa migrate dữ liệu từ CRM cũ sang Salesforce.

Có:

• 20.000 Accounts
• 35.000 Contacts
• 80.000 Opportunities
• 200.000 Opportunity Products

Admin cần đưa toàn bộ dữ liệu vào Salesforce.

Nếu chỉ nhìn vào số lượng, có thể nghĩ:

“Data Import Wizard dễ dùng hơn, cứ chia file thành nhiều phần rồi import.”

Sai ở đây không phải vì số lượng. Sai ở object.

Data Import Wizard không phải công cụ tổng quát cho mọi Salesforce object. Trong khi đó, Data Loader hỗ trợ tất cả objects và xử lý các tác vụ như Insert, Update, Upsert, Delete, Export.

Với tình huống này, Data Loader là lựa chọn đúng.

Đặc biệt, khi dữ liệu đã vượt 50.000 records hoặc cần thao tác với Opportunity, Opportunity Product, các custom objects phức tạp..., Data Loader gần như trở thành lựa chọn mặc định.

Mẹo thi: Đừng chỉ nhìn vào câu hỏi “bao nhiêu records?”. Hãy nhìn tiếp “object nào?” và “operation nào?”. 50K + object được hỗ trợ + import đơn giản → nghĩ tới Data Import Wizard. >50K / mọi object / export / delete / upsert → nghĩ tới Data Loader.

---

2. Chống “rác dữ liệu”: Validation + Matching + Duplicate Rules

Một hệ thống CRM có thể hoạt động rất đẹp nhưng dữ liệu bên trong lại hoàn toàn vô dụng.

Đây chính là vấn đề:

Garbage In → Garbage Out.

Ví dụ doanh nghiệp có Object Customer, trong đó có các field:

• Email
• Phone
• Customer Type
• Tax Code
• Country

Business requirement:

Một khách hàng không được phép có Email sai format và không được tạo trùng Customer dựa trên Email.

Nếu chỉ dùng Validation Rule, Admin mới giải quyết được một nửa vấn đề.

Validation Rule: “Dữ liệu này có hợp lệ không?”

Ví dụ:

AND(
    NOT(ISBLANK(Email)),
    NOT(CONTAINS(Email, "@"))
)

Validation Rule kiểm tra record hiện tại có thỏa business condition hay không.

Nó rất phù hợp với những rule như:

• Close Date không được nằm trước ngày hiện tại.
• Discount không được vượt quá 30%.
• Nếu Customer Type = Corporate thì Tax Code bắt buộc phải có.

Nhưng Validation Rule không phải công cụ chuyên dụng để phát hiện:

“Record này có thể đã tồn tại rồi.”

Đây là lúc Matching Rules + Duplicate Rules xuất hiện.

Matching Rule: “Record này có giống record khác không?”

Ví dụ Matching Rule xác định:

Email = Email

hoặc phức tạp hơn:

Name + Phone

Matching Rule quyết định logic để xác định hai records có khả năng trùng nhau.

Duplicate Rule: “Nếu phát hiện trùng thì phải làm gì?”

Duplicate Rule sử dụng Matching Rule để quyết định hành vi:

• Allow
• Alert
• Block

Ví dụ:

Customer A

Email = john@abc.com

User chuẩn bị tạo:

Customer B

Email = john@abc.com

Matching Rule phát hiện hai records có cùng Email.

Duplicate Rule sau đó có thể:

Block → Không cho tạo record mới.

Đây là kiến trúc rất quan trọng:

Validation Rule → kiểm tra tính hợp lệ của dữ liệu.

Matching Rule → xác định khả năng trùng.

Duplicate Rule → quyết định xử lý khi phát hiện trùng.

Mẹo thi: Nếu đề nói “field phải đúng điều kiện” → nghĩ Validation Rule. Nếu đề nói “phát hiện records trùng nhau” → nghĩ Matching Rule. Nếu đề nói “cảnh báo/chặn việc tạo record trùng” → nghĩ Duplicate Rule.

---

3. Report & Dashboard: Bẫy lớn nhất nằm ở Folder Security

Đây là phần rất nhiều người làm sai trong phòng thi vì nhầm:

“Được xem Report” = “được xem dữ liệu trong Report”.

Hai chuyện này không hoàn toàn giống nhau.

Hãy tách thành hai lớp.

Lớp 1: Folder Security

Folder trả lời:

“Bạn có được phép mở Report/Dashboard này không?”

Ví dụ Report:

Sales Pipeline by Region

được lưu trong folder:

Sales Management Reports

Nếu Sales Rep không có quyền truy cập folder, họ có thể không mở được Report.

Folder Security liên quan tới việc chia sẻ Report/Dashboard thông qua folder, với các mức access như:

• Viewer
• Editor
• Manager

Lớp 2: Data Security

Sau khi user đã mở được Report, câu hỏi tiếp theo là:

“Report này sẽ cho user nhìn thấy bao nhiêu dữ liệu?”

Lúc này Salesforce quay lại các cơ chế bảo mật dữ liệu như:

• Object permissions
• Field-Level Security
• Record-level access
• Sharing Rules
• Role Hierarchy
• OWD

Ví dụ:

Sales Manager có thể xem:

Account A
Account B
Account C
Account D

Sales Rep chỉ được quyền xem:

Account A
Account B

Cả hai có thể cùng mở một Report.

Nhưng kết quả dữ liệu có thể khác nhau.

Folder Security quyết định “có được mở báo cáo hay không”. Data Security quyết định “mở rồi thì thấy dữ liệu nào”.

Đây là một trong những cách tư duy quan trọng nhất của Salesforce Admin.

---

4. Static Dashboard vs Dynamic Dashboard

Dashboard không chỉ là biểu đồ đẹp mắt.

Điểm quan trọng nhất là:

Dashboard đang chạy dưới quyền của ai?

Static Dashboard — Run as Specified User

Static Dashboard có một Running User được chỉ định.

Ví dụ:

Running User = VP of Sales

Dashboard hiển thị dữ liệu theo quyền truy cập của VP of Sales.

Sales Rep A mở Dashboard.

Sales Rep B mở Dashboard.

Sales Manager C mở Dashboard.

Nếu tất cả đều xem cùng một static dashboard, dữ liệu dashboard có thể vẫn được tính theo quyền của VP of Sales, thay vì quyền riêng của từng người.

Điều này cực kỳ hữu ích cho các dashboard quản trị:

Executive Sales Dashboard
CEO Dashboard
Company Revenue Dashboard

Nhưng nó cũng tạo ra một rủi ro:

Người xem có thể nhìn thấy dữ liệu mà bản thân họ không được quyền truy cập trực tiếp.

Vì vậy, chọn Running User phải cực kỳ cẩn thận.

---

Dynamic Dashboard — Run as Logged-in User

Dynamic Dashboard hoạt động theo cách ngược lại.

User đăng nhập là ai?

→ Dashboard chạy theo quyền của chính user đó.

Ví dụ:

Sales Rep A
→ thấy pipeline của mình

Sales Rep B
→ thấy pipeline của mình

Sales Manager
→ thấy dữ liệu mà Manager được quyền xem

Một dashboard có thể phục vụ nhiều user mà không cần tạo hàng loạt dashboard riêng cho từng người.

Đây chính là lý do Dynamic Dashboard cực kỳ phù hợp cho:

• Sales team
• Regional team
• Management hierarchy
• User-specific performance dashboard

Nhưng Dynamic Dashboard có một cái bẫy rất nổi tiếng:

Dynamic Dashboard không thể Schedule Refresh để tự động gửi email như static dashboard.

Lý do nằm ở chính bản chất của nó.

Nếu dashboard phải chạy theo:

Current Logged-in User

thì hệ thống phải biết ai là người đang đăng nhập.

Còn Scheduled Refresh lại chạy tự động tại một thời điểm định trước, không có một người dùng cụ thể đang mở dashboard để làm “logged-in user”.

Vì vậy:

Static Dashboard
→ Specified Running User
→ Có thể Schedule Refresh

Dynamic Dashboard
→ Logged-in User
→ Không thể Schedule Refresh

Mẹo thi cực quan trọng: Đề cho keyword “scheduled email”, “automatic refresh”, “send dashboard results by email” → nghĩ ngay đến Static Dashboard. Đề cho keyword “each user sees their own data”, “based on logged-in user” → nghĩ ngay đến Dynamic Dashboard.

---

Kết luận: Data & Analytics không phải chuyện “import và làm report”

Nếu nhìn toàn bộ phần này từ góc độ Solution Architect, ta sẽ thấy một chuỗi logic rất rõ:

DATA IN
   ↓
Validation Rules
   ↓
Matching Rules
   ↓
Duplicate Rules
   ↓
Data Security
   ↓
Reports
   ↓
Folder Security
   ↓
Dashboard
   ↓
Running User

Mỗi lớp giải quyết một vấn đề khác nhau.

Một Admin giỏi không chỉ biết:

“Data Loader import được 5 triệu records.”

Mà phải biết:

“Tại sao trường hợp này phải dùng Data Loader?”

Không chỉ biết:

“Duplicate Rule dùng để chống duplicate.”

Mà phải hiểu:

“Matching Rule xác định duplicate như thế nào, còn Duplicate Rule quyết định hệ thống phải phản ứng ra sao?”

Và đặc biệt, không được nhầm:

Folder Security bảo vệ Report/Dashboard. Data Security bảo vệ dữ liệu phía sau Report/Dashboard.

Đó chính là tư duy Salesforce Admin mà đề thi 2026 đang muốn kiểm tra.

---

🚀 Bài tiếp theo: Khi Admin bắt đầu “đụng vào hệ thống”

Data đã sạch. Report đã đúng. Dashboard đã phân quyền.

Nhưng Salesforce vẫn còn một câu hỏi lớn hơn:

Ai được làm gì trong Org? Field nào xuất hiện? User nào có quyền nào? Org được cấu hình ra sao?

Lúc này chúng ta sẽ bước sang một vùng kiến thức cực kỳ quan trọng:

Configuration & Setup

Nơi Admin bắt đầu thực sự “cầm lái” Salesforce Org — từ User, Profile, Permission, Security Settings cho đến cách cấu hình nền tảng phía sau toàn bộ hệ thống.

Và đây cũng là phần mà rất nhiều câu hỏi thi bắt đầu trở nên “đánh lừa” hơn hẳn.

Hẹn gặp ở Phần 3.