Published about 4 hours ago 23 min read

[Salesforce Agentforce Sales Consultant 2026] Phần 5 — Data Management (18%): Data Migration, Integration, Data Quality & Scalability

Ở Phần 4, chúng ta đã đi qua cách thiết kế một Sales Cloud Solution từ:

Lead → Opportunity → Products → Pricing → Quote → Close

Nhưng dù Sales Process được thiết kế tốt đến đâu, Solution vẫn có thể thất bại nếu dữ liệu bên dưới không đáng tin cậy.

Ví dụ Sales Manager mở Dashboard và thấy:

Pipeline = $10M

Nhưng nếu trong đó có:

Duplicate Opportunities.
Close Date đã quá hạn.
Amount không chính xác.
Accounts bị trùng.
Leads thiếu thông tin quan trọng.
Data từ ERP chưa được đồng bộ.

thì con số $10M gần như không còn nhiều ý nghĩa.

Đây là lý do Data Management chiếm 18% trong Salesforce Certified Agentforce Sales Consultant Exam.

Theo Exam Guide, domain này tập trung vào ba năng lực chính:

Data Migration và Integration.
Scalability.
Sales Data Quality.

Mental Model của Phần 5:

Clean Data → Reliable Sales Process → Reliable Pipeline → Better Forecast → Better Business Decisions

1. Data Management không chỉ là Import CSV

Khi nghe đến Data Management, nhiều người nghĩ ngay:

Data Import Wizard hay Data Loader?

Nhưng với một Salesforce Consultant, câu hỏi phải bắt đầu sớm hơn:

Data đến từ đâu?
Salesforce có phải System of Record không?
Data cần migrate một lần hay synchronize liên tục?
Data Volume bao nhiêu?
Data Quality hiện tại thế nào?
Records liên kết với nhau bằng gì?
Có External ID không?
Duplicate được xử lý thế nào?
Data có thực sự cần lưu trong Salesforce không?
Data sẽ tăng trưởng như thế nào trong vài năm tới?

Một Data Management Lifecycle có thể hình dung như sau:

Source → Profile → Clean → Map → Migrate / Integrate → Validate → Monitor

Trong đó:

Phase	Mục tiêu
Source	Xác định nguồn dữ liệu
Profile	Hiểu structure, volume và quality
Clean	Làm sạch dữ liệu
Map	Mapping sang Salesforce Data Model
Migrate / Integrate	Di chuyển hoặc đồng bộ dữ liệu
Validate	Kiểm tra kết quả
Monitor	Duy trì Data Quality

Điểm quan trọng:

Đừng bắt đầu Migration bằng việc Import Data. Hãy bắt đầu bằng việc hiểu Data.

2. Data Profiling — Hiểu dữ liệu trước khi di chuyển

Trước Migration hoặc Integration, Consultant cần hiểu Current State của Data.

Đó chính là Data Profiling.

Ví dụ Legacy CRM có:

2,000,000 Contacts

Nhưng sau khi phân tích:

600,000 Contacts đã không được sử dụng trong nhiều năm.
120,000 Records thiếu Email.
80,000 Records có khả năng Duplicate.
Nhiều Fields gần như không bao giờ được sử dụng.
Một số Fields không còn liên quan đến Business Process mới.

Nếu migrate toàn bộ chỉ vì:

“Data đang tồn tại.”

thì chúng ta có thể đang mang Technical Debt từ hệ thống cũ sang Salesforce.

Một cách tiếp cận tốt hơn:

Legacy Data
     |
     |------ Active & Valuable -----> Migrate
     |
     |------ Duplicate / Invalid ---> Clean
     |
     |------ Historical ------------> Evaluate / Archive
     |
     |------ Obsolete --------------> Exclude

Consultant phải đặt câu hỏi:

Business thực sự cần Data nào trong Salesforce?

Không phải:

Chúng ta có thể migrate bao nhiêu Data?

3. Data Migration ≠ Integration

Đây là distinction cực kỳ quan trọng.

Data Migration

Migration thường là việc di chuyển dữ liệu từ System hiện tại sang System đích.

Ví dụ:

Legacy CRM
     |
     |  One-time / Project-based Move
     |
     +------------------------> Salesforce

Use Cases:

Replace Legacy CRM.
Consolidate Salesforce Orgs.
Move Customer Data sang Salesforce.
Initial Salesforce Implementation.

Mental Model:

Migration = Move

Integration

Integration xảy ra khi các Systems cần tiếp tục trao đổi dữ liệu sau khi Solution đi vào hoạt động.

Ví dụ:

Salesforce <--------------------> ERP
                Ongoing

Use Cases:

Salesforce gửi dữ liệu sang ERP.
ERP gửi Invoice Status về Salesforce.
Website tạo Lead trong Salesforce.
External System cung cấp Pricing hoặc Inventory.

Mental Model:

Integration = Connect

Exam Trap

Nếu Scenario nói:

“Move historical customer data from the legacy CRM before go-live.”

Think:

Migration

Nếu Scenario nói:

“Salesforce must continuously receive inventory information from ERP.”

Think:

Integration

4. Xác định System of Record và Data Ownership

Trong Integration Design, một câu hỏi rất quan trọng là:

System nào sở hữu dữ liệu?

Ví dụ:

Salesforce
   |
   |------ Lead / Opportunity --------> Salesforce owns
   |
   |------ Customer Billing ----------> ERP owns
   |
   |------ Inventory -----------------> ERP owns
   |
   |------ Marketing Engagement ------> Marketing Platform owns

Không phải mọi Data đều nên được Salesforce quản lý như Master Data.

Ví dụ:

Sales Rep cần xem Inventory.

Điều đó không tự động nghĩa là:

Copy toàn bộ Inventory Database vào Salesforce.

Consultant cần hỏi:

Salesforce chỉ cần View Data?
Data có cần stored trong Salesforce?
Data có cần Real-time không?
Salesforce có cần update Data đó không?
System nào là Source of Truth?

Một Integration Architecture tốt cần có:

Clear Data Ownership

5. Data Mapping — Legacy Field không tự biến thành Salesforce Field

Giả sử Legacy CRM có:

Legacy Field	Salesforce
Company_Name	Account.Name
Customer_Code	Account.External_ID__c
Sales_Region	Account.Region__c
Contact_Email	Contact.Email
Deal_Value	Opportunity.Amount

Đây là Data Mapping.

Nhưng Mapping không chỉ đơn giản là:

Field A → Field B

Consultant phải xem xét:

Data Type.
Required Fields.
Picklist Values.
Record Types.
Relationships.
Field Length.
Date Format.
Currency.
Validation Rules.
Transformation Logic.

Ví dụ Legacy System lưu:

Region = VN

nhưng Salesforce sử dụng:

Region = Vietnam

Migration có thể cần Transformation:

VN ------> Vietnam
JP ------> Japan
US ------> United States

Nếu không chuẩn hóa Data:

Reports có thể sai.
Automation có thể hoạt động không đúng.
Integration trở nên khó maintain.
Users khó tìm kiếm và phân tích Data.

6. External ID — Cầu nối với External Systems

Giả sử ERP có Customer:

Customer ID = ERP-10025

Trong Salesforce:

Account
|
|------ Name = ABC Corporation
|
|------ ERP Customer ID = ERP-10025

ERP Customer ID có thể được thiết kế thành External ID.

Mental Model:

ERP
|
| ERP-10025
|
+----------------------> Salesforce Account
                          ERP ID = ERP-10025

External ID rất hữu ích cho:

Matching Records giữa Salesforce và External Systems.
Data Migration.
Integration.
Upsert.
Maintaining relationships giữa Records.

Lưu ý: External ID và Unique là hai concept khác nhau. Nếu Business Identifier bắt buộc phải duy nhất, Consultant cần xem xét yêu cầu uniqueness thay vì mặc định rằng External ID tự giải quyết toàn bộ Duplicate Management.

7. Upsert — Insert hay Update?

Upsert là một pattern cực kỳ hữu ích trong Migration và Integration.

Mental Model:

Incoming Record
      |
      |
  Match found?
   /       \
 YES       NO
  |         |
UPDATE    INSERT

Ví dụ ERP gửi:

ERP Customer ID = ERP-10025

Nếu Salesforce đã có Account tương ứng:

Update Account.

Nếu chưa có:

Insert Account.

Exam Trap

Đừng nhớ:

Upsert = External ID.

Hãy nhớ:

Upsert = Update hoặc Insert dựa trên Matching Key phù hợp.

External ID đặc biệt hữu ích khi matching identifier đến từ một External System.

8. Data Load Order — Relationships quyết định thứ tự Migration

Giả sử chúng ta cần migrate:

Accounts.
Contacts.
Opportunities.
Products.
Price Books.
Opportunity Products.

Không nên import theo thứ tự ngẫu nhiên.

Data Model có dependencies:

Account
   |
   |--------- Contact
   |
   +--------- Opportunity
                   |
                   +--------- Opportunity Product
                                  ^
                                  |
                         Product / Pricing
                           Dependencies

Ví dụ Opportunity cần liên kết với Account, vì vậy Account phải tồn tại trước khi relationship đó có thể được thiết lập đúng.

Nguyên tắc cần nhớ:

Load Parent và Dependencies trước những Records phụ thuộc vào chúng.

Không có một Load Order duy nhất cho mọi Project.

Thứ tự Migration phải dựa trên:

Data Model.
Required Relationships.
Record Dependencies.
Business Scope.

Nếu không:

Lookup có thể bị mất.
Relationships có thể sai.
Records có thể fail khi import.

9. Data Migration Strategy

Một Migration Project tốt không nên chỉ là:

Export
   |
Import
   |
 Done

Một Strategy hoàn chỉnh hơn:

Source Data
     |
Data Profiling
     |
Data Cleansing
     |
Data Mapping
     |
Transformation
     |
Test Migration
     |
Validation
     |
Production Migration
     |
Post-Migration Validation

Một trong những sai lầm nguy hiểm nhất là:

Migration lần đầu tiên trực tiếp vào Production.

Một Project thực tế nên cân nhắc:

Test Migration.
Reconciliation.
Business Validation.
Performance Testing khi Volume lớn.
Cutover Plan.
Backup / Recovery Strategy.

10. Import Success ≠ Migration Success

Giả sử Data Loader báo:

500,000 Records Successfully Imported

Migration đã thành công chưa?

Chưa chắc.

Chúng ta còn phải kiểm tra:

Technical Validation

Record Count.
Import Errors.
Required Fields.
Data Types.

Business Validation

Relationships có đúng không?
Owners có đúng không?
Record Types có đúng không?
Currency có đúng không?
Picklist Values có đúng không?
Reports có phản ánh đúng Business không?

Mental Model:

MIGRATION SUCCESS
       |
       |--------- Technical Validation
       |
       +--------- Business Validation

Một Migration chỉ thực sự thành công khi:

Data đúng về cả Technical Structure lẫn Business Meaning.

11. Data Quality — Có Data không đồng nghĩa có Data tốt

Khi đánh giá Data Quality trong một Project, Consultant có thể xem xét các khía cạnh như:

Completeness

Data có đầy đủ không?

Ví dụ:

Opportunity thiếu Close Date.

Accuracy

Data có đúng không?

Ví dụ:

Customer Phone Number đã không còn sử dụng.

Consistency

Data có cùng format và meaning không?

Ví dụ:

Vietnam
Viet Nam
VN
VNM

Uniqueness

Có Duplicate không?

Ví dụ:

ABC Corporation
ABC Corp.
ABC Corporation Ltd.

Timeliness

Data có được cập nhật kịp thời không?

Ví dụ:

Opportunity Close Date đã quá hạn 60 ngày.

Một CRM có thể chứa hàng triệu Records nhưng vẫn tạo ra rất ít Business Value nếu Data Quality thấp.

12. Data Quality ảnh hưởng trực tiếp đến Sales

Hãy nhìn chuỗi sau:

Poor Data Quality
       |
Poor Opportunity Data
       |
Unreliable Pipeline
       |
   Bad Forecast
       |
Bad Business Decisions

Ví dụ Sales Manager thấy:

$5M Pipeline sẽ Close trong tháng này.

Nhưng:

$1M đã stale.
$500K duplicate.
$800K có Close Date sai.
$700K đã Lost nhưng Stage chưa được update.

Pipeline thực tế có thể hoàn toàn khác.

Do đó:

Data Quality không chỉ là vấn đề của Admin. Nó là Business Problem.

13. Preventive vs Corrective Data Quality

Có hai hướng xử lý quan trọng.

Preventive

Ngăn Bad Data được tạo ra.

Ví dụ:

Required Fields.
Validation Rules.
Controlled Picklist Values.
Lookup Filters.
Duplicate Management.
Automation.

User Input | Data Controls | Clean Data

Corrective

Xử lý Bad Data đã tồn tại.

Ví dụ:

Data Cleansing.
Duplicate Cleanup.
Data Standardization.
Mass Update.
Merge.
Data Enrichment.

Existing Bad Data | Clean / Standardize | Trusted Data

Một Solution tốt thường cần cả hai:

Fix existing Data + Prevent future Bad Data

Nếu chỉ Cleanup mà không sửa Process:

Bad Data sẽ quay trở lại.

14. Duplicate Management

Duplicate Data là vấn đề rất phổ biến.

Ví dụ:

ABC Corporation
ABC Corp.
ABC Corporation Ltd.

Salesforce cung cấp Duplicate Management với hai concept quan trọng:

Matching Rule

Xác định criteria để Salesforce tìm:

Potential Duplicate Records

Duplicate Rule

Xác định Salesforce sẽ làm gì khi Matching Rule phát hiện Potential Duplicate.

Ví dụ:

Allow.
Alert.
Block.

Mental Model:

New / Updated Record
        |
  Matching Rule
        |
Potential Duplicate?
        |
  Duplicate Rule
        |
 Allow / Alert / Block

Exam Trap

Đừng nhầm:

Matching Rule = xử lý Duplicate.

Matching Rule chủ yếu xác định:

Records nào được xem là potential match.

Duplicate Rule xác định:

Action nào được thực hiện khi match xảy ra.

15. Validation Rules — Bảo vệ Data Quality tại thời điểm nhập

Ví dụ Business Requirement:

Closed Won Opportunity phải có Contract Number.

Logic có thể là:

Stage = Closed Won
       +
Contract Number Blank
       |
       |
    BLOCK SAVE

Nhưng Consultant phải cẩn thận.

Quá nhiều Validation Rules có thể tạo ra:

Poor User Experience

Ví dụ Opportunity mới ở Prospecting nhưng Sales Rep đã bị bắt nhập:

Contract Number.
Competitor.
Final Discount.
Implementation Date.

Điều đó không hợp lý.

Principle:

Collect Data when it becomes relevant to the Business Process.

Không phải:

Make everything required immediately.

16. Data Quality và User Adoption

Một vòng lặp xấu thường xảy ra:

Poor UX
   |
Users avoid Salesforce
   |
Incomplete Data
   |
Users don't trust Salesforce
   |
More Excel / External Tracking
   |
Salesforce Data gets worse

Ngược lại:

Simple Process
   |
Users maintain Data
   |
Better Data Quality
   |
Better Reports
   |
Managers use Salesforce
   |
Higher Adoption

Do đó Data Quality không chỉ được giải quyết bằng Technical Controls.

Nó còn liên quan đến:

Process Design.
Training.
User Experience.
Governance.
Management Behavior.

17. Integration — Đừng bắt đầu bằng API

Business nói:

“Salesforce cần Integration với ERP.”

Consultant không nên lập tức hỏi:

REST hay SOAP?

Trước tiên cần hiểu:

What?

Data nào cần trao đổi?

Ownership?

System nào sở hữu Data?

Direction?

Salesforce ---------> ERP

hoặc:

ERP ---------> Salesforce

hoặc:

Salesforce <--------> ERP

When?

Real-time?
Near Real-time?
Scheduled Batch?
On Demand?

Volume?

10 Records/ngày?

Hay hàng triệu Records?

Error Handling?

Nếu Integration fail thì sao?

Mental Model:

What → Ownership → Direction → Frequency → Volume → Error Handling → Technology

Technology nên đến sau Requirement.

18. Real-Time vs Batch Integration

Không phải Data nào cũng cần Real-time.

Real-Time / Near Real-Time

Phù hợp khi Business cần Data nhanh để tiếp tục Process.

Ví dụ:

Sales Rep cần biết Credit Status trước khi hoàn tất một bước quan trọng của Deal.

Salesforce
    |
  Request
    |
External System
    |
  Response
    |
 Sales Rep

Batch

Phù hợp khi Data có thể synchronize theo lịch.

Ví dụ:

ERP gửi Product Inventory Summary mỗi đêm.

ERP
 |
 | Nightly
 |
Salesforce

Batch có thể phù hợp khi:

Volume lớn.
Không cần immediate response.
Scheduled Processing đáp ứng Business Requirement.

Exam Mindset

Đừng chọn Real-time chỉ vì nó nghe hiện đại hơn.

Chọn Integration Pattern dựa trên:

Business Requirement

19. Scalability — Solution hôm nay có hoạt động khi Business lớn lên?

Scalability không chỉ là:

Salesforce có lưu được nhiều Records không?

Consultant cần xem xét:

Data Volume.
Record Growth.
Storage.
Automation Volume.
Integration Volume.
API Usage.
Reporting.
Record Locking.
Query Performance.
Sharing Model.

Ví dụ hôm nay:

100 Sales Reps
50,000 Opportunities

Ba năm sau:

5,000 Sales Reps
20,000,000 Opportunities

Solution ban đầu có còn phù hợp không?

Đây là:

Scalability Thinking

20. Data Volume ảnh hưởng Architecture

So sánh hai Requirement:

Import 10,000 historical Contacts.

và:

Process hàng chục triệu transaction records.

Hai Scenario không nên được thiết kế giống nhau.

Khi Data Volume tăng, Consultant cần cân nhắc:

Storage Strategy.
Archiving.
Batch Processing.
Integration Pattern.
Query Performance.
Reporting Requirements.
Data Retention.
Automation Impact.

Một câu hỏi quan trọng:

Data này có thực sự cần nằm trong Salesforce Operational CRM không?

Có những Data:

cần cho Daily Operations;
cần cho Analytics;
chỉ cần Historical Reference;
có thể Archive.

Không phải:

Keep everything forever in the same operational model.

21. Archiving — Historical Data không nhất thiết phải ở Operational Layer

Giả sử Salesforce có:

30 triệu Opportunities từ 15 năm trước.

Nhưng Sales Team chủ yếu làm việc với:

Opportunities trong vài năm gần nhất.

Consultant nên đặt câu hỏi:

Historical Data có thực sự cần nằm trong Operational Salesforce Org không?

Một Strategy có thể là:

Active Data
    |
    +--------> Salesforce Operational CRM


Historical Data
    |
    +--------> Archive / Appropriate Storage

Archiving có thể giúp quản lý:

Storage.
Operational Performance.
Data Lifecycle.
Reporting Strategy.

Nhưng Archiving phải xem xét:

Compliance.
Reporting.
Accessibility.
Retention Policy.
Business Requirements.

22. Data Governance — Ai chịu trách nhiệm cho Data?

Nếu mọi người đều chịu trách nhiệm:

thường cuối cùng không ai thực sự chịu trách nhiệm.

Một Data Governance Model có thể xác định:

Data Owner

Ai chịu trách nhiệm Business cho Data?

Data Steward

Ai theo dõi và cải thiện Data Quality?

Salesforce / Platform Team

Ai implement Technical Controls?

Users

Ai tạo và maintain Data trong Daily Process?

Ví dụ:

Sales Leadership
       |
Business Ownership
       |
Sales Operations
       |
Data Stewardship
       |
Salesforce Team
       |
Technical Controls
       |
  Sales Users
       |
Daily Data Maintenance

Data Quality cần:

People + Process + Technology

không chỉ Technology.

23. Data Quality Metrics

Nếu Business nói:

“Chúng ta muốn Data tốt hơn.”

thì Requirement vẫn chưa đủ rõ.

Cần Metrics.

Ví dụ:

Completeness

% Opportunities có đầy đủ các Fields cần thiết tại Stage tương ứng.

Duplicate Rate

% Accounts được xác định là Potential Duplicates.

Freshness

% Open Opportunities được update trong 30 ngày gần nhất.

Process Compliance

% Closed Lost Opportunities có Lost Reason.

Mental Model:

Data Quality Goal
       |
     Metric
       |
    Baseline
       |
  Improvement
       |
    Monitor

Điều này biến Data Quality từ:

“IT Cleanup Project”

thành:

Measurable Business Capability

24. Data Quality và AI

Khi Sales Organization sử dụng AI hoặc Agentforce, Data Quality càng trở nên quan trọng.

Mental Model:

CRM / Business Data
        |
        |
    AI / Agent
        |
        |
Prediction / Generation / Action

Nếu Data đầu vào:

Incomplete.
Incorrect.
Duplicate.
Outdated.

thì AI cũng có thể đưa ra Output kém hữu ích hoặc không đáng tin cậy.

Một Principle dễ nhớ:

AI không thay thế Data Governance.

Trước khi hỏi:

“Chúng ta nên dùng AI thế nào?”

Consultant cũng cần hỏi:

Data có đủ tốt để hỗ trợ Use Case này không?

25. Scenario — Legacy CRM Migration

Business:

Công ty muốn thay Legacy CRM bằng Salesforce.

Legacy CRM có:

2M Accounts.
5M Contacts.
10M Opportunities.
Duplicate Records.
Fields không còn sử dụng.
Historical Data 15 năm.

Một cách làm tệ:

Export Everything
       |
Import Everything
       |
     Go Live

Consultant Approach:

Profile Data
     |
Define Scope
     |
Clean Data
     |
 Map Data
     |
Archive Strategy
     |
Test Migration
     |
  Validate
     |
Production Migration

Questions:

Historical Data nào cần migrate?
Data nào có thể archive?
Duplicate được xử lý thế nào?
Relationships được preserve như thế nào?
External IDs / Legacy IDs nào được sử dụng?
Load Sequence ra sao?
Business sẽ validate bằng cách nào?

Đây mới là:

Data Migration Strategy

26. Scenario — Salesforce ↔ ERP Integration

Requirement:

Salesforce quản lý Sales Process nhưng ERP quản lý Orders, Inventory và Billing.

Data Ownership:

Salesforce
   |
   |------ Leads
   |------ Opportunities
   +------ Sales Activities


ERP
   |
   |------ Orders
   |------ Inventory
   +------ Invoices

Business Process có thể yêu cầu:

Salesforce
    |
Closed Won
    |
    |
   ERP
    |
Create Order
    |
Order / Invoice Status
    |
    |
Salesforce

Consultant cần xác định:

Trigger nào bắt đầu Integration?
Data nào được gửi?
Records được match bằng gì?
Sync Direction?
Frequency?
Error Handling?
Retry Strategy?
Data Ownership?

Chỉ sau đó mới chọn:

Integration Technology

27. Scenario — Data Quality đang phá Forecast

Sales Director nói:

“Forecast của Salesforce không đáng tin.”

Investigation phát hiện:

25% Opportunities có Close Date quá hạn.
Sales Reps không update Stage.
Duplicate Opportunities tồn tại.
Amount thường chỉ được nhập ngay trước khi Close.
Closed Lost Reasons thường để trống.

Root Cause:

Poor Opportunity Data
         |
         |
   Poor Pipeline
         |
         |
   Poor Forecast

Solution không chỉ là:

Configure Forecasting.

Nó có thể cần:

Better Sales Process.
Appropriate Validation.
Required Data tại đúng Stage.
Duplicate Prevention.
Pipeline Review.
Data Quality Reports.
User Training.
Governance.

Một lần nữa:

Fix Root Cause trước khi Fix Dashboard.

28. Exam Trap — Migration Tool không phải câu hỏi đầu tiên

Scenario nói:

“Company is migrating from a legacy CRM.”

Đừng lập tức nghĩ:

Data Loader.

Trước tiên hãy nghĩ:

What Data?
    |
How Much?
    |
Data Quality?
    |
Relationships?
    |
Transformation?
    |
Migration Window?
    |
Validation?
    |
   Tool

Tool là:

Implementation Detail

Migration Strategy mới là:

Consultant Decision

29. Exam Trap — Real-Time không tự động tốt hơn Batch

Nếu Business cần:

Daily Inventory Summary.

Real-time Integration có thể tạo Complexity không cần thiết.

Nếu Business cần:

Credit Status ngay trong Sales Process.

Nightly Batch có thể quá chậm.

Do đó:

Frequency phải đến từ Business Requirement.

30. Exam Trap — More Data ≠ Better Data

Migration toàn bộ Historical Data không tự động tốt hơn.

Hãy hỏi:

Business Value?
Operational Need?
Compliance?
Reporting?
Storage?
Performance?

Một số Data có thể phù hợp hơn với:

Archive / Alternative Storage Strategy

31. Exam Trap — Required Fields ≠ Data Quality Strategy

Make everything required nghe có vẻ đơn giản.

Nhưng nó có thể dẫn tới:

Fake Data

Nếu User chưa biết giá trị nhưng System bắt nhập, họ có thể nhập:

N/A
Unknown
123
-

Kết quả:

Field technically complete nhưng Business Data vẫn vô dụng.

Data Quality phải cân bằng:

Control + User Experience + Process Timing

32. Exam Trap — Integration ≠ Copy Everything into Salesforce

Nếu Salesforce cần sử dụng External Data, không phải lúc nào cũng cần replicate toàn bộ Data vào CRM.

Consultant phải đánh giá:

Data Ownership.
Volume.
Freshness.
Access Pattern.
Storage.
Business Use Case.
Integration Capabilities.

Question đúng là:

Salesforce cần làm gì với Data?

không phải:

Làm sao đưa toàn bộ Data vào Salesforce?

33. Exam Trap — Data Quality không phải One-Time Project

Cleanup trước Go-Live là cần thiết.

Nhưng nếu sau đó không có:

Validation.
Duplicate Prevention.
Governance.
Monitoring.
User Process.

thì Data Quality sẽ xuống cấp trở lại.

Data Quality là:

Continuous Process

34. Consultant Data Decision Framework

Khi gặp một Data Scenario trong Exam, hãy đi theo Framework sau:

Technology chỉ nên được chọn sau khi những câu hỏi trên được trả lời.

Mental Model:

Requirement → Data → Architecture → Technology

Không phải:

Technology → rồi mới tìm Requirement phù hợp

35. Data Management Architecture

Nếu ghép toàn bộ Phần 5 lại:

Bao quanh Architecture này là:

Data Quality + Governance + Security + Scalability

Đó mới là một Data Strategy hoàn chỉnh.

36. Migration vs Integration — Nhớ nhanh

Đây là distinction rất đơn giản nhưng cực kỳ hữu ích khi đọc Scenario.

37. Những điều cần nhớ cho Exam

Migration

Move Data từ Source sang Target System.

Integration

Systems tiếp tục trao đổi Data.

External ID

Identifier giúp Salesforce liên hệ Record với identifier từ External System.

External ID ≠ Unique

Đừng mặc định External ID tự động giải quyết uniqueness.

Upsert

Match → Update
No Match → Insert

Data Mapping

Source Data → Salesforce Data Model.

Data Profiling

Hiểu Structure, Usage, Quality và Volume trước khi thiết kế Migration.

Data Load Order

Follow Record Dependencies.

Duplicate Management

Matching Rule tìm Potential Matches.
Duplicate Rule quyết định Action.

Data Quality

Không chỉ Cleanup — phải Prevent + Monitor + Improve.

Scalability

Solution phải tiếp tục hoạt động khi Users, Records và Transactions tăng.

Archiving

Không phải mọi Historical Data đều cần nằm trong Operational CRM.

Governance

Data cần Ownership, Stewardship và Monitoring.

Tổng kết

Data Management (18%) không phải domain để chỉ học thuộc:

Data Loader, Import Wizard hay API.

Điều Salesforce muốn kiểm tra ở một Consultant là khả năng nhìn Data như một phần của Solution Architecture.

Khi gặp một Scenario, hãy bắt đầu bằng:

Business Requirement

sau đó hỏi:

What Data? → Where? → Owner? → Quality? → Volume? → Migration or Integration? → Frequency? → Matching? → Scalability? → Validation?

Một Salesforce Solution tốt cần:

Clean & Trusted Data
        |
Reliable Sales Process
        |
  Reliable Pipeline
        |
  Reliable Forecast
        |
  Analytics / AI
        |
Better Business Decisions

Và Principle quan trọng nhất của Phần 5:

Don't migrate bad data faster. Understand it, clean it, govern it, and design for growth.

Ở Phần 6, chúng ta sẽ đến domain cuối cùng của Exam Guide:

Predictive & Generative AI (13%) — Agentforce, Predictive AI, Generative AI và Trusted AI trong Sales.

Đây cũng là nơi Data Management của Phần 5 trở thành nền tảng để AI tạo ra Business Value.

Tài liệu tham khảo chính thức

Exam Tip: Nếu một Data Scenario đưa ra rất nhiều Technical Options, hãy quay lại Business Requirement trước. Consultant không chọn Tool mạnh nhất — Consultant chọn Architecture phù hợp nhất.