Ở các phần trước, chúng ta đã đi từ Configuration & Setup, xây dựng Data Model, đến Object Manager & App Builder và bắt đầu tự động hóa với Flow Builder.

Nhưng một Salesforce Org tốt không chỉ cần “đúng kiến trúc”. Nó còn phải giúp người dùng làm việc nhanh hơn, phối hợp tốt hơn và mở rộng tính năng mà không phải tự xây mọi thứ từ đầu.

Đó chính là phạm vi của nhóm kiến thức Productivity, Collaboration & AppExchange.

---

1. Activity Management: Task hay Event?

Trong thực tế, rất nhiều Admin mới sử dụng Task và Event gần như interchangeable. Đây là một sai lầm nhỏ nhưng rất dễ xuất hiện trong bài thi Salesforce Administrator.

Cách nhớ đơn giản nhất:

Task = Việc cần làm. Event = Một lịch hẹn có thời gian cụ thể.

Task: “Tôi cần làm việc này”

Task đại diện cho một công việc cần được thực hiện.

Ví dụ:

• Gọi điện cho khách hàng.
• Gửi báo giá.
• Follow up một Lead.
• Kiểm tra Contract.
• Nhắc Sales Manager duyệt một Opportunity.

Task có thể có Due Date, Status, Priority và Assigned To, nhưng bản chất của nó vẫn là một công việc cần hoàn thành.

Ví dụ:

“Ngày mai gọi lại cho khách hàng ABC.”

Đây là Task.

Event: “Tôi có lịch vào thời điểm này”

Event đại diện cho một hoạt động có thời gian bắt đầu và kết thúc cụ thể trên Calendar.

Ví dụ:

• Meeting với khách hàng từ 09:00–10:00.
• Demo sản phẩm lúc 14:00.
• Internal meeting từ 15:30–16:00.
• Training cho Sales team.

Ví dụ:

“Ngày mai 09:00–10:00 họp với khách hàng ABC.”

Đây là Event.

Bẫy phòng thi: Activity Timeline ≠ Related List

Đây là một điểm Admin rất dễ nhầm.

Activity Timeline là component trên Lightning Record Page, giúp người dùng nhìn thấy lịch sử và hoạt động liên quan đến record theo dạng timeline.

Trong khi đó, Related List là khu vực hiển thị các record liên quan thông qua relationship.

Nói cách khác:

Activity Timeline là cách người dùng theo dõi Activity. Related List là cách Salesforce hiển thị các related records.

Khi câu hỏi hỏi về trải nghiệm quản lý hoạt động ngay trên record, hãy nghĩ đến Activity Timeline, thay vì mặc định chọn Related List.

---

2. Chatter: Collaboration không chỉ là “đăng bài”

Chatter được Salesforce thiết kế để người dùng trao đổi, chia sẻ thông tin và cộng tác ngay bên trong Org.

Điểm quan trọng không phải là nhớ tên các loại Group, mà phải hiểu khi nào dùng loại nào.

Public Group

Public Group phù hợp khi nội dung cần được nhiều người trong Org nhìn thấy và tham gia.

Ví dụ:

Công ty tạo Group “Salesforce Admin Community” để Admin ở các team cùng trao đổi kinh nghiệm.

Phù hợp cho những nội dung mang tính mở và không yêu cầu kiểm soát thành viên quá chặt.

Private Group

Private Group dành cho nội dung cần giới hạn thành viên.

Ví dụ:

Team Sales đang chuẩn bị một deal lớn và cần trao đổi về chiến lược giá, nhưng không muốn toàn bộ công ty nhìn thấy.

Khi đó, Private Group là lựa chọn phù hợp.

Broadcast Group

Broadcast Group tập trung vào truyền thông một chiều.

Ví dụ:

Ban lãnh đạo muốn thông báo chính sách mới cho toàn bộ Sales team.

Người quản trị hoặc người được cấp quyền có thể đăng thông báo, trong khi thành viên chủ yếu theo dõi thông tin thay vì tự do thảo luận như một nhóm collaboration thông thường.

Cách nhớ khi đi thi

Hãy tư duy theo câu hỏi:

• Ai cũng có thể tham gia? → Public
• Cần giới hạn thành viên? → Private
• Chủ yếu để truyền thông/thông báo? → Broadcast

Đừng học thuộc tên Group mà không gắn với business purpose.

---

3. Salesforce Mobile App: Đừng nghĩ Mobile chỉ là “bản thu nhỏ”

Một quan niệm sai khá phổ biến là:

“Salesforce Mobile App chỉ đơn giản là Salesforce Desktop chạy trên điện thoại.”

Thực tế, Admin có thể tùy biến trải nghiệm mobile để phù hợp với cách nhân viên làm việc ngoài hiện trường.

Ví dụ, một Sales Rep thường xuyên gặp khách hàng có thể cần truy cập nhanh:

• Accounts.
• Contacts.
• Opportunities.
• Tasks.
• Calendar.
• Các custom app hoặc chức năng đặc thù.

Admin có thể cấu hình trải nghiệm mobile, bao gồm branding và các thành phần hiển thị phù hợp với người dùng.

Một khái niệm đáng chú ý là Mobile Launchpad. Đây là điểm truy cập giúp người dùng nhanh chóng mở các ứng dụng hoặc chức năng được cấu hình cho trải nghiệm mobile.

Trong phòng thi, nếu câu hỏi nhấn mạnh:

“Administrator muốn cải thiện trải nghiệm người dùng trên Salesforce Mobile App”

đừng chỉ nghĩ đến Permission Set hay Profile.

Hãy nhớ rằng Mobile App cũng là một trải nghiệm có thể được Admin cấu hình và branding, chứ không phải một ứng dụng hoàn toàn cố định.

---

4. AppExchange: Managed Package vs Unmanaged Package

Đây là một trong những bẫy quan trọng nhất khi học AppExchange.

Hãy tưởng tượng công ty bạn cần một giải pháp e-signature.

Có hai lựa chọn:

1. Tự build một package rồi phân phối.
2. Cài một package từ AppExchange.

Nhưng khi nói về package, Admin cần đặc biệt phân biệt:

Tiêu chí	Managed Package	Unmanaged Package
Source code	Không cho subscriber xem/sửa code của package	Có thể xem và sửa
Upgrade	Có thể upgrade version	Không hỗ trợ upgrade theo cơ chế managed package
Mục đích	Phân phối sản phẩm thương mại	Phân phối code để tiếp tục tùy chỉnh
Ownership	Vendor kiểm soát package	Subscriber có thể tiếp tục customize

Managed Package: “Tôi dùng sản phẩm của Vendor”

Managed Package phù hợp khi một vendor xây dựng một sản phẩm Salesforce và muốn kiểm soát source code cũng như vòng đời sản phẩm.

Ví dụ:

Một công ty mua giải pháp quản lý Contract từ một ISV trên AppExchange.

Vendor phát hành:

Version 1.0 → Version 1.1 → Version 2.0

Khách hàng có thể nhận các bản nâng cấp từ vendor.

Quan trọng hơn, subscriber không được tự ý chỉnh sửa source code của package.

Đây chính là mô hình phù hợp với một commercial application.

Unmanaged Package: “Tôi lấy code và tự chịu trách nhiệm”

Unmanaged Package phù hợp khi mục tiêu là phân phối source code để subscriber có thể tiếp tục chỉnh sửa.

Ví dụ:

Một consulting company xây một bộ custom components dùng làm starting point cho khách hàng.

Khách hàng cài package rồi muốn:

• Sửa Apex.
• Sửa Visualforce.
• Thay đổi logic.
• Customize sâu theo business requirement.

Unmanaged Package phù hợp hơn.

Nhưng có một cái giá phải trả:

Khi subscriber đã sửa code, vendor không thể quản lý lifecycle theo cách của Managed Package và không thể cung cấp upgrade package theo cơ chế Managed Package.

---

Business Scenario: Chọn Package nào?

Giả sử một ISV xây dựng ứng dụng “Advanced Contract Management” để bán cho hàng trăm doanh nghiệp trên AppExchange.

ISV muốn:

• Bảo vệ source code.
• Kiểm soát sản phẩm.
• Phát hành version mới.
• Cho phép khách hàng nhận upgrade.
• Không muốn khách hàng sửa trực tiếp logic lõi.

Đáp án: Managed Package.

Ngược lại, nếu công ty tư vấn muốn cung cấp một bộ Apex Classes, Objects và Components làm template để khách hàng tự chỉnh sửa sâu theo từng dự án, thì Unmanaged Package phù hợp hơn.

Mẹo nhớ cực nhanh

Managed = Vendor manages the code & upgrades.

Unmanaged = Customer can modify the code, but loses the managed upgrade model.

Nếu đề thi mô tả “commercial product”, “protect intellectual property”, “upgrade”, “vendor”, hãy lập tức nghĩ đến Managed Package.

Nếu đề nhấn mạnh “customer needs to modify source code”, hãy nghĩ đến Unmanaged Package.

---

Kết luận: Productivity chính là cách Salesforce biến “CRM” thành “Work Platform”

Sau khi hiểu Activity Management, Chatter, Mobile App và AppExchange, chúng ta bắt đầu thấy một bức tranh lớn hơn.

Salesforce không chỉ lưu dữ liệu.

Nó giúp người dùng:

Quản lý công việc → cộng tác → làm việc trên mobile → mở rộng platform bằng AppExchange.

Và đây cũng là mindset quan trọng của một Salesforce Administrator:

Đừng chỉ hỏi “Salesforce có tính năng này không?”. Hãy hỏi “Tôi có thể cấu hình Salesforce thế nào để người dùng làm việc hiệu quả hơn?”.

Nhưng Productivity chỉ mới là một phần của bức tranh.

Ở Phần 7, chúng ta sẽ bước vào một khu vực cực kỳ quan trọng của Salesforce Platform Administrator: Sales & Marketing Apps — nơi các khái niệm như Lead, Campaign, Opportunity, Sales Process, Products, Price Books và Quote bắt đầu kết nối với nhau để tạo thành một quy trình bán hàng hoàn chỉnh.

Đó mới chính là lúc chúng ta nhìn Salesforce không còn như một tập hợp các tính năng rời rạc, mà như một hệ thống vận hành toàn bộ Sales Lifecycle của doanh nghiệp.