Ở Phần 2, chúng ta đã hiểu Sales Lifecycle.

Ở Phần 3, chúng ta tiếp tục với tư duy:

Business Problem → Discovery → Requirement → Solution → Implementation → Adoption

Sang Phần 4, chúng ta bắt đầu áp dụng hai nền tảng đó để giải những bài toán Sales Cloud thực tế.

Đây chính là trọng tâm của domain:

Practical Application of Agentforce Sales Expertise — 24%

Theo Exam Guide, domain này tập trung vào khả năng:

• Thiết kế End-to-End Sales Process từ Lead → Opportunity → Quote → Close.
• Xác định khi nào Standard / Declarative Salesforce không đủ và cần Custom Development, Third-party Applications, Salesforce Products hoặc Productivity Tools.
• Thiết kế Security Model phù hợp.
• Hiểu Products, Opportunity Products, Price Books, Quotes và Multi-Currency.
• Hỗ trợ nhiều Business Process khác nhau cho Campaigns, Leads và Opportunities.

Nếu Phần 3 trả lời:

“Consultant nên suy nghĩ như thế nào?”

thì Phần 4 trả lời:

“Với Requirement này, chúng ta thực sự nên thiết kế Salesforce Solution như thế nào?”

---

1. Bắt đầu bằng End-to-End Sales Process

Một lỗi rất phổ biến khi thiết kế Salesforce là nhìn từng Object riêng lẻ.

Ví dụ:

Configure Lead.

Configure Opportunity.

Configure Quote.

Nhưng Business không vận hành theo từng Object riêng biệt.

Business vận hành theo một Process xuyên suốt.

Mental Model:

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

Data được tạo ở đâu?

Ai chịu trách nhiệm ở từng Stage?

Record nào cần được tạo?

Khi nào cần Automation?

Khi nào cần Human Decision?

Ai được phép xem và sửa dữ liệu?

Pricing được xác định như thế nào?

Business Outcome cuối cùng được đo bằng KPI nào?

Đó mới là End-to-End Solution Design.

---

2. Đừng thiết kế Object — hãy thiết kế Business Process

Giả sử một công ty có quy trình:

Website Lead → Qualification → Demo → Proposal → Negotiation → Contract.

Một cách tiếp cận không tốt là lập tức hỏi:

Cần bao nhiêu Custom Fields?

Consultant nên hỏi trước:

• Khi nào một Prospect trở thành Qualified Lead?
• Điều kiện nào cho phép tạo Opportunity?
• Stage nào đại diện cho Demo?
• Khi nào Products được xác định?
• Khi nào Pricing được xác nhận?
• Khi nào Quote được tạo?
• Ai có quyền approve Discount?
• Điều kiện nào khiến Opportunity trở thành Closed Won?

Sau đó mới map vào Salesforce.

Ví dụ:

Business Concept	Salesforce Concept
Prospect	Lead
Company	Account
Buyer	Contact
Potential Deal	Opportunity
Deal Progress	Opportunity Stage
Items being sold	Opportunity Products
Pricing Catalog	Price Book
Customer Proposal	Quote
Sales Interaction	Activity

Nguyên tắc:

Business Process trước → Salesforce Data Model sau.

---

3. Campaign — Marketing bắt đầu Sales Process như thế nào?

Campaign giúp doanh nghiệp theo dõi các Marketing Initiatives.

Ví dụ:

Agentforce Webinar 2026

Marketing muốn biết:

• Ai được Target?
• Ai phản hồi?
• Lead nào được tạo?
• Campaign có ảnh hưởng đến Opportunities không?
• Campaign có đóng góp Revenue không?

Campaign không chỉ là:

“Một danh sách người tham gia Webinar.”

Nó giúp kết nối Marketing Activity với Sales Outcome.

Ví dụ:

Marketing Campaign

↓

Lead Generation

↓

Lead Qualification

↓

Opportunity

↓

Revenue

Khi gặp Scenario liên quan đến Marketing, Consultant cần xác định Business muốn đo:

• Engagement?
• Lead Generation?
• Conversion?
• Pipeline?
• Revenue Influence?

Đừng chỉ thấy từ Marketing rồi mặc định Solution là Campaign.

---

4. Lead Process — Không phải mọi Prospect đều giống nhau

Một doanh nghiệp có thể có nhiều loại Lead:

• Website Lead.
• Partner Lead.
• Event Lead.
• Referral Lead.
• Outbound Prospect.

Và mỗi loại có thể có Qualification Process khác nhau.

Ví dụ:

Enterprise Lead

Sales cần xác nhận:

• Company Size.
• Budget.
• Decision Maker.
• Business Need.
• Timeline.

SMB Lead

Qualification có thể đơn giản hơn:

• Product Interest.
• Budget.
• Purchase Timeline.

Do đó Consultant cần xác định:

Business có thực sự cần nhiều Process khác nhau không?

Salesforce có thể sử dụng những capability như:

• Lead Status.
• Record Types.
• Page Layouts.
• Validation.
• Assignment.
• Automation.

Nhưng đừng tạo Record Type chỉ vì:

“Có hai nhóm User.”

Record Type nên xuất hiện khi Business cần những khác biệt thực sự về:

• Business Process.
• Picklist Values.
• Page Experience.

---

5. Lead Assignment — Ai nên nhận Lead?

Một Requirement phổ biến:

“New Leads phải được gửi đến Sales Rep phù hợp.”

Nhưng “phù hợp” nghĩa là gì?

Có thể dựa trên:

• Country.
• Region.
• Product Interest.
• Customer Segment.
• Industry.
• Lead Source.

Ví dụ:

Vietnam

→ APAC Sales Team

Japan

→ Japan Sales Team

Enterprise

→ Enterprise Sales

SMB

→ SMB Sales

Salesforce có Lead Assignment Rules dành cho việc tự động assign Lead dựa trên criteria.

Nhưng nếu Requirement có orchestration phức tạp hơn:

• Update nhiều Records.
• Call External System.
• Complex Decision Logic.
• Multi-step Automation.

thì Consultant có thể cần đánh giá thêm Flow hoặc Custom Solution.

Exam Mindset:

Dùng capability chuyên biệt khi nó giải quyết Requirement trực tiếp.

Không phải:

“Flow làm được mọi thứ nên chọn Flow cho mọi bài toán.”

---

6. Lead Conversion — Thiết kế Transition đúng

Khi Lead đủ điều kiện, nó có thể được Convert.

Mental Model:

Lead ↓ Convert ↓ Account + Contact ↓ Opportunity (Optional during Conversion)

Điểm cần nhớ:

Opportunity không bắt buộc phải được tạo trong mọi Lead Conversion.

Điều này phụ thuộc vào Business Process.

Ví dụ:

Scenario A — Sales-qualified Lead

Lead đã có một Deal cụ thể.

→ Tạo Opportunity trong quá trình Conversion có thể phù hợp.

Scenario B — Contact chưa có Deal

Business chỉ muốn đưa Prospect đã xác minh vào Account / Contact Data Model.

→ Có thể Convert mà chưa tạo Opportunity.

Consultant phải thiết kế dựa trên:

Business Meaning của Conversion

không phải chỉ dựa trên Technical Capability.

---

7. Opportunity — Deal phải phản ánh Sales Process thật

Opportunity đại diện cho một Potential Revenue Deal.

Những thông tin quan trọng thường bao gồm:

• Stage.
• Amount.
• Close Date.
• Probability.
• Forecast Category.
• Products.
• Activities.

Nhưng phần quan trọng nhất là:

Opportunity Stages phải phản ánh Business Milestones.

Ví dụ:

Prospecting

↓

Qualification

↓

Needs Analysis

↓

Proposal

↓

Negotiation

↓

Closed Won / Closed Lost

Không nên thiết kế Stage chỉ để:

“Salesforce nhìn đẹp hơn.”

Stage Data ảnh hưởng đến:

• Pipeline.
• Forecast.
• Reports.
• Dashboards.
• Automation.
• Management Decisions.

Nếu Stage Data sai:

Bad Stage Data

↓

Bad Pipeline

↓

Bad Forecast

↓

Bad Business Decision

---

8. Nhiều Sales Process — Khi nào cần Record Types?

Giả sử công ty bán hai loại Deal.

New Business

Process:

Prospecting

↓

Qualification

↓

Demo

↓

Proposal

↓

Negotiation

↓

Closed Won

Renewal

Process:

Renewal Identified

↓

Customer Review

↓

Renewal Proposal

↓

Negotiation

↓

Renewed / Lost

Hai loại Deal có:

• Stages khác nhau.
• Picklist Values khác nhau.
• Có thể cần Page Experience khác nhau.

Đây là Scenario phù hợp để cân nhắc:

Sales Process + Record Type + Page Layout

Mental Model:

Business Process A ↓ Sales Process A ↓ Record Type A ↓ Relevant Page Experience

Business Process B ↓ Sales Process B ↓ Record Type B ↓ Relevant Page Experience

Exam Trap:

Record Type không phải Security Model.

Record Type giúp điều khiển Business Process, Picklist Values và Page Layout assignment.

Nó không được thiết kế để thay thế Object Permission hoặc Record-level Sharing.

---

9. Products — Doanh nghiệp đang bán cái gì?

Một Product đại diện cho Item hoặc Service doanh nghiệp bán.

Ví dụ:

• CRM Enterprise License.
• Implementation Service.
• Training Package.
• Premium Support.

Product là Catalog Item.

Nó không phải:

Product cụ thể đã được bán trong Deal X.

Khi Product được thêm vào Opportunity, chúng ta làm việc với Opportunity Product.

Mental Model:

Product

→ “Chúng ta bán cái gì?”

Opportunity Product

→ “Trong Deal này, chúng ta đang bán Product nào, bao nhiêu và với giá nào?”

Đây là distinction rất quan trọng.

---

10. Price Book — Một Product có thể có nhiều mức giá

Giả sử Product:

CRM Enterprise License

có Standard Price:

$1,000

Nhưng Business có nhiều Market Segment.

Ví dụ:

Standard Price Book

→ $1,000

Partner Price Book

→ $850

Enterprise Price Book

→ $900

APAC Price Book

→ $950

Salesforce cho phép Product tồn tại trong nhiều Price Books với mức giá khác nhau.

Mental Model:

Product

Item / Service doanh nghiệp bán.

Price Book

Collection của Products và Prices cho một mục đích kinh doanh.

Price Book Entry

Liên kết:

Product + Price Book + Price

Opportunity Product

Product được đưa vào một Opportunity cụ thể.

---

11. Standard Price Book và Custom Price Books

Salesforce có Standard Price Book.

Ngoài ra doanh nghiệp có thể tạo Custom Price Books.

Ví dụ:

• Partner Pricing.
• Enterprise Pricing.
• Domestic Pricing.
• International Pricing.

Custom Price Book phù hợp khi Business cần:

Cùng Product nhưng Pricing khác nhau cho Market Segment hoặc Sales Context khác nhau.

Một điểm cần nhớ:

Product cần có Standard Price đang active trước khi có thể được thêm vào Custom Price Book.

Do đó Product & Pricing Design không đơn giản là:

“Tạo Product rồi nhập Price.”

Consultant cần hiểu:

• Pricing Strategy.
• Customer Segments.
• Currency.
• Discount Model.
• Product Availability.
• Price Book Selection.

---

12. Opportunity Product — Deal thực sự bán gì?

Giả sử Opportunity:

ABC Digital Transformation — $150,000

Opportunity Products có thể là:

Product	Quantity	Sales Price
Enterprise License	100	$1,000
Implementation	1	$40,000
Training	1	$10,000

Opportunity Product cho phép Deal chứa Pricing ở Line-item Level.

Điều này giúp Business phân tích:

• Product Revenue.
• Product Mix.
• Quantity.
• Pricing.
• Deal Composition.

Đây là lý do một Requirement như:

“Management muốn biết Product nào tạo nhiều Revenue nhất.”

có thể yêu cầu Business sử dụng Products trên Opportunities thay vì chỉ nhập một con số vào Opportunity Amount.

---

13. Quote — Proposal gửi cho Customer

Quote đại diện cho:

Proposed prices của Products và Services dành cho Customer.

Quote được tạo từ Opportunity và Products của Opportunity.

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

Ví dụ:

Opportunity │ ├── Quote V1 — $150K │ ├── Quote V2 — $140K │ └── Quote V3 — $135K

Điều này rất hợp với Negotiation Process.

Nhưng:

Chỉ một Quote có thể được Sync với Opportunity tại một thời điểm.

Khi Quote được Sync với Opportunity:

Quote Line Items

⇄

Opportunity Products

được đồng bộ.

Exam Trap:

Opportunity ≠ Quote

Opportunity:

Deal chúng ta đang cố Close.

Quote:

Pricing Proposal cụ thể cho Deal đó.

---

14. Multi-Currency — Khi Business bán hàng toàn cầu

Giả sử công ty hoạt động ở:

• United States.
• Japan.
• Vietnam.
• Europe.

Các Deals có thể sử dụng:

• USD.
• JPY.
• VND.
• EUR.

Đây là lúc Multi-Currency trở thành một Design Consideration.

Một Salesforce Org có:

Corporate Currency

và khi Multi-Currency được enable, Records có thể sử dụng các active currencies khác.

Consultant cần cân nhắc:

• Currency nào Business sử dụng?
• Exchange Rates được quản lý như thế nào?
• Pricing được định nghĩa theo Currency nào?
• Reports cần hiển thị Currency ra sao?
• Opportunities và Quotes xử lý Currency như thế nào?
• Business có cần historical exchange-rate behavior không?

Điểm quan trọng:

Multi-Currency không chỉ là hiển thị ký hiệu tiền tệ khác nhau.

Đối với domain này, Exam Guide đặc biệt yêu cầu hiểu:

• Sharing Rules.
• Role Hierarchy.
• Account Teams.
• Opportunity Teams.
• Permission Sets.
• Permission Set Groups.

Điều quan trọng là:

Các mechanism này không giải quyết cùng một vấn đề.

---

16. Permission Sets — User được phép làm gì?

Permission Sets giúp cấp thêm Permissions cho Users mà không cần tạo thêm Profile chỉ để đáp ứng từng variation nhỏ.

Ví dụ:

Sales Rep cơ bản có quyền:

• Read Account.
• Create/Edit Opportunity.

Một số Senior Reps cần thêm:

• Special Application Permission.
• Additional Object Access.

Thay vì tạo:

Senior Sales Profile

chỉ vì vài quyền bổ sung, Consultant có thể cân nhắc Permission Set.

Mental Model:

Profile / Base Access + Permission Sets = Additional Access

Permission Set không phải mechanism chính để chia sẻ một Opportunity cụ thể cho một User.

Nó giải quyết Permission, không thay thế Record Sharing.

---

17. Permission Set Groups — Gom quyền theo Job Function

Trong Org lớn, một User có thể cần nhiều Permission Sets.

Ví dụ:

Sales Rep cần:

• Core Sales Permissions.
• Quote Permissions.
• Reporting Permissions.
• Mobile Permissions.

Thay vì assign từng Permission Set riêng lẻ, Consultant có thể sử dụng:

Permission Set Group

Mental Model:

Business Value:

• Easier Administration.
• Job-based Permission Management.
• Better Maintainability.

---

18. Role Hierarchy — Access theo Organizational Hierarchy

Role Hierarchy thường phù hợp khi Business Requirement phản ánh Organizational Reporting Structure.

Ví dụ:

Users phía trên Role Hierarchy có thể nhận Record Access từ Users phía dưới theo Salesforce Sharing Model.

Mental Model:

Role Hierarchy = Organizational / Management Visibility

Nhưng Role Hierarchy không phải:

Team Selling.

Nếu nhiều người ngang cấp cần cùng làm một Deal, cần xem xét mechanism khác.

---

19. Sharing Rules — Mở rộng Access theo Rule

Giả sử Opportunity OWD là Private.

Business Requirement:

Finance Team cần Read Access đối với tất cả Closed Won Opportunities.

Đây là Scenario phù hợp để cân nhắc Sharing Rule.

Mental Model:

Điểm cực kỳ quan trọng:

Sharing Rules mở rộng Access.

Chúng không được dùng để làm Access restrictive hơn OWD.

Nếu OWD đã Public Read/Write, Sharing Rule không thể biến một nhóm Records thành Private.

---

20. Account Teams — Collaboration quanh Customer

Một Account có thể được phục vụ bởi:

• Account Executive.
• Sales Engineer.
• Customer Success.
• Support.
• Specialist.

Những người này có thể cần collaboration lâu dài quanh Customer.

Đây là Scenario phù hợp với Account Teams.

Account Team Members có thể có:

• Team Roles.
• Account Access.
• Opportunity Access.
• Case Access.

Mental Model:

Account Team thường phù hợp khi:

Nhiều người có relationship lâu dài với cùng một Customer Account.

---

21. Opportunity Teams — Collaboration quanh một Deal

Opportunity Team có Purpose khác.

Ví dụ Deal:

Global CRM Transformation — $5M

cần:

• Account Executive.
• Solution Engineer.
• Product Specialist.
• Legal Specialist.

Những người này cùng tham gia Deal cụ thể.

Mental Model:

Distinction rất đáng nhớ:

Account Team

Long-term collaboration quanh Customer / Account.

Opportunity Team

Team tập trung vào một Deal cụ thể.

Đây là một Exam Trap rất dễ gặp.

---

22. Security Scenario — Chọn đúng Mechanism

Hãy thử một số Requirement.

Scenario A

Managers cần thấy Records của Reps bên dưới họ.

Think:

Role Hierarchy

---

Scenario B

Finance cần Read Access vào tất cả Closed Won Opportunities.

Think:

Sharing Rule

---

Scenario C

Một Sales Engineer cần cùng làm một Deal cụ thể với Account Executive.

Think:

Opportunity Team

---

Scenario D

Customer Success và Support thường xuyên cùng làm việc với một Customer Account.

Think:

Account Team

---

Scenario E

Một nhóm Users cần thêm Object / Feature Permissions.

Think:

Permission Set

---

Scenario F

Một Job Function cần combination của nhiều Permission Sets.

Think:

Permission Set Group

Exam Mindset:

Đừng chỉ hỏi “User cần Access không?”

Hãy hỏi:

Access gì? Ở Layer nào? Cho Record nào? Theo Organizational Structure, Rule, Team hay Job Function?

---

23. Declarative hay Custom?

Salesforce cung cấp rất nhiều Declarative Capabilities.

Ví dụ:

• Flow.
• Validation Rules.
• Assignment Rules.
• Approval-related capabilities.
• Record Types.
• Sharing Rules.
• Lightning App Builder.

Do đó Consultant thường nên đánh giá Standard / Declarative Solution trước.

Nhưng không phải mọi Requirement đều nên ép vào Declarative.

Mental Model:

Nhưng từ khóa quan trọng là:

solve it well

Không chỉ:

“Technically possible.”

Một Flow 500 Elements có thể technically hoạt động.

Nhưng Consultant còn phải hỏi:

• Maintainable?
• Scalable?
• Testable?
• Secure?
• Performant?
• Understandable?

---

24. Khi nào Custom Development hợp lý?

Custom Development có thể phù hợp khi:

• Requirement quá phức tạp cho Declarative.
• Cần sophisticated UI.
• Complex Transaction Logic.
• Performance Requirements.
• Advanced Integration.
• Reusable Technical Component.

Ví dụ:

Sales Rep cần một interactive pricing interface có logic phức tạp mà Standard UI không đáp ứng.

Có thể cân nhắc:

Lightning Web Component

Hoặc:

Complex server-side logic → Apex.

Nhưng Custom Development có Trade-off:

• Development Cost.
• Testing.
• Maintenance.
• Technical Skills.
• Deployment Complexity.
• Technical Debt.

Do đó:

Code vì Requirement cần Code, không phải vì Developer thích Code.

---

25. Khi nào Third-party Application hợp lý?

Giả sử Requirement:

Sales Team cần Electronic Signature.

Thay vì tự Build toàn bộ E-signature System, Consultant có thể đánh giá một AppExchange / Third-party Solution.

Factors:

• Product Fit.
• Cost.
• Security.
• Vendor Reliability.
• Integration.
• Support.
• Scalability.
• User Experience.
• Maintenance.

Mental Model:

Build vs Buy vs Integrate

Consultant phải đánh giá Total Solution, không chỉ Initial Development Cost.

---

26. Khi nào dùng Salesforce Product khác?

Một Requirement có thể vượt khỏi capability của Core Sales Cloud.

Ví dụ Business cần:

• Advanced Sales Engagement.
• Collaboration.
• Advanced Revenue capabilities.
• Experience for Partners.
• Additional AI capabilities.

Consultant cần biết khi nào:

Extend bằng một Salesforce Product phù hợp

tốt hơn việc:

Custom Build functionality tương tự.

Một lần nữa:

Requirement → Capability → Product

không phải:

Product → tìm Requirement để sử dụng.

---

27. Productivity Tools — Solution không chỉ nằm trong Salesforce Tab

Exam Guide nhắc trực tiếp đến Productivity Tools như:

• Email Integrations.
• Slack.
• Salesforce Mobile.

Điều này phản ánh một Principle quan trọng:

Solution tốt phải phù hợp với nơi User thực sự làm việc.

Ví dụ:

Sales Rep thường xuyên làm việc ngoài văn phòng.

Requirement:

Update Opportunity và Customer Information khi đang di chuyển.

Think:

Salesforce Mobile

Sales Team collaboration chủ yếu trên Slack.

Requirement:

Improve collaboration around Deals.

Think:

Slack Integration / Salesforce collaboration capability

Sales Rep dành phần lớn thời gian trong Email.

Requirement:

Reduce context switching giữa Email và CRM.

Think:

Email Integration / Salesforce Inbox-related capabilities

Đừng ép User phải mở thêm nhiều Screen nếu Salesforce có thể được đưa gần hơn vào Workflow của họ.

---

28. Thiết kế Solution phải cân nhắc Trade-off

Giả sử có Requirement:

Automatically assign Leads based on Country, Industry, Product Interest và Sales Rep Capacity.

Có nhiều Solution possible.

Option A — Assignment Rules

Ưu:

• Standard.
• Easy to understand.
• Maintainable.

Nhược:

• Có thể không đáp ứng sophisticated dynamic capacity logic.

Option B — Flow

Ưu:

• Flexible.
• Declarative.
• Có thể orchestration nhiều bước.

Nhược:

• Complexity tăng khi Logic lớn.

Option C — Custom Apex

Ưu:

• Maximum flexibility.
• Có thể xử lý Complex Logic.

Nhược:

• Development.
• Testing.
• Maintenance.

Consultant không hỏi:

“Cái nào mạnh nhất?”

Consultant hỏi:

Cái nào đáp ứng Requirement với Complexity thấp nhất nhưng vẫn Maintainable và Scalable?

---

29. Exam Trap — Standard trước, nhưng đừng tuyệt đối hóa

Một heuristic hữu ích:

Standard → Declarative → Extend → Custom

Nhưng đây không phải luật tuyệt đối.

Nếu Requirement rõ ràng cần capability từ Third-party Product hoặc Custom Solution, không cần cố tạo một Declarative Architecture phức tạp chỉ để tránh Code.

Exam thường muốn bạn chọn:

Most appropriate solution

không phải:

Least-code solution at any cost.

---

30. Scenario tổng hợp — Thiết kế một Sales Solution

Hãy ghép toàn bộ domain vào một Scenario.

Business Requirement

Một công ty Software B2B có:

• Enterprise Sales.
• SMB Sales.
• Partner Sales.
• Global Customers.

Problems:

• Lead Routing đang Manual.
• Enterprise và SMB có Sales Process khác nhau.
• Partner Pricing khác Direct Pricing.
• Large Deals cần Solution Engineers tham gia.
• Managers cần Access theo Region.
• Finance cần xem Closed Won Deals.
• Customers có thể nhận nhiều Quote Versions.
• Sales Reps làm việc nhiều qua Email và Mobile.

---

Requirement 1 — Lead Routing

Business:

Lead cần được assign theo Region và Segment.

Evaluate:

• Lead Assignment Rules.
• Flow nếu Logic phức tạp hơn.

---

Requirement 2 — Different Sales Processes

Enterprise:

Qualification → Discovery → Demo → Proposal → Negotiation.

SMB:

Qualification → Proposal → Negotiation.

Think:

Sales Processes + Record Types

---

Requirement 3 — Partner Pricing

Partners nhận Pricing khác Direct Customers.

Think:

Custom Price Book

---

Requirement 4 — Complex Deal Collaboration

Large Enterprise Deal cần:

• Account Executive.
• Solution Engineer.
• Product Specialist.

Think:

Opportunity Team

---

Requirement 5 — Long-term Account Collaboration

Customer Success và Support cùng chăm sóc Strategic Accounts.

Think:

Account Team

---

Requirement 6 — Regional Management Visibility

Regional Manager cần Access Records của Sales Reps bên dưới.

Think:

Role Hierarchy

---

Requirement 7 — Finance Visibility

Finance cần xem Closed Won Opportunities.

Think:

Sharing Rule

---

Requirement 8 — Multiple Pricing Proposals

Customer Negotiation cần nhiều Proposal Versions.

Think:

Multiple Quotes

với một Quote được Sync với Opportunity tại một thời điểm.

---

Requirement 9 — Global Sales

Deals sử dụng USD, EUR, JPY.

Think:

Multi-Currency

và đánh giá Pricing, Reporting, Forecasting và Exchange Rate Requirements.

---

Requirement 10 — Productivity

Sales Reps làm việc nhiều trên Email và Mobile.

Think:

Email Integration + Salesforce Mobile

---

Kết quả không phải một Feature.

Nó là một Solution Architecture:

Bao quanh Process:

Security Collaboration Automation Email / Mobile Analytics

Đây chính là Practical Application.

---

31. Các Exam Trap cần nhớ

Trap 1 — Record Type ≠ Security

Record Type điều khiển Business Process, Picklist Values và Page Experience.

Không dùng Record Type để thay thế Record-level Security.

---

Trap 2 — Product ≠ Opportunity Product

Product:

Item / Service trong Catalog.

Opportunity Product:

Product cụ thể đang được bán trong Deal.

---

Trap 3 — Price Book ≠ Price Book Entry

Price Book:

Collection của Products / Prices.

Price Book Entry:

Product + Price Book + Price.

---

Trap 4 — Opportunity ≠ Quote

Opportunity:

Deal.

Quote:

Pricing Proposal cho Deal.

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

---

Trap 5 — Account Team ≠ Opportunity Team

Account Team:

Long-term Customer Collaboration.

Opportunity Team:

Collaboration quanh một Deal cụ thể.

---

Trap 6 — Permission ≠ Sharing

Permission:

User được phép làm gì với Object / Field / Feature.

Sharing:

User được Access Record nào.

---

Trap 7 — Sharing Rule không Restrict Access

Sharing Rules:

Open up additional Record Access.

Không dùng Sharing Rule để làm Access restrictive hơn OWD.

---

Trap 8 — Role Hierarchy ≠ Team Selling

Role Hierarchy:

Organizational Visibility.

Opportunity / Account Teams:

Collaborative Selling.

---

Trap 9 — Flow ≠ Default Answer

Flow rất mạnh.

Nhưng Salesforce có thể đã có Standard Feature chuyên biệt giải quyết Requirement tốt hơn.

---

Trap 10 — Custom Code ≠ Advanced Solution

Custom Code không tự động tốt hơn Declarative.

Solution tốt phải:

• Meet Requirements.
• Maintainable.
• Scalable.
• Secure.
• Testable.

---

Trap 11 — Multi-Currency ≠ Currency Symbol

Multi-Currency ảnh hưởng đến:

• Pricing.
• Opportunity Amounts.
• Quotes.
• Reporting.
• Forecasting.
• Revenue Analysis.

---

Trap 12 — More Automation ≠ Better Solution

Automation chỉ có giá trị khi:

Nó cải thiện Business Process.

Automating một Process tệ chỉ khiến Process tệ chạy nhanh hơn.

---

32. Consultant Decision Framework

Khi gặp một Scenario trong Exam, hãy đọc theo thứ tự:

Một câu hỏi Consultant không nên kết thúc ở:

“Can Salesforce do this?”

Nó phải tiếp tục:

“What is the most appropriate way to do this?”

---

Tổng kết

Practical Application of Agentforce Sales Expertise là nơi những kiến thức Sales Cloud riêng lẻ bắt đầu kết nối thành một Solution hoàn chỉnh.

Bạn cần hiểu:

Nhưng đừng học chúng như một danh sách Feature.

Hãy luôn bắt đầu bằng:

Business Requirement

sau đó đi qua:

Business Process → Data → Security → Automation → Collaboration → Pricing → Productivity → Analytics

và cuối cùng mới chọn:

Salesforce Solution

Mental Model quan trọng nhất của Phần 4:

Requirement → Standard Capability → Declarative → Extension → Custom

và luôn đánh giá:

Why? → Alternative? → Trade-off? → Maintainability? → Scalability?

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

Biết Salesforce

và:

Biết thiết kế Salesforce Solution.

Ở Phần 5, chúng ta sẽ chuyển sang một domain mà mọi Solution đều phụ thuộc vào:

Data Management (18%) — Data Migration, Integration, Data Quality và Scalability.

Bởi vì dù Sales Process được thiết kế tốt đến đâu:

Bad Data → Bad CRM → Bad Analytics → Bad Decisions

---

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

• Salesforce Certified Agentforce Sales Consultant Exam Guide
• Salesforce Help — Products and Price Books
• Salesforce Help — Product Concepts
• Salesforce Help — Guidelines for Creating Products
• Salesforce Help — Create Custom Price Books
• Salesforce Help — Quotes
• Salesforce Help — Considerations for Creating and Managing Quotes
• Salesforce Trailhead — Sell as a Team
• Salesforce Trailhead — Team Selling & Opportunity Splits
• Salesforce Trailhead — Set Up Account Teams
• Salesforce Trailhead — Create Sharing Rules

Tip: Với domain này, đừng học theo kiểu “Feature này dùng để làm gì?”. Hãy đổi câu hỏi thành: “Business Requirement nào khiến Feature này trở thành Solution phù hợp hơn các Alternative?”