Chọn đúng đối tượng

🌐 Cũng có bằng 28 ngôn ngữ khác

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh

Mô-đun 5 trong 10 của chương Kiến trúc dữ liệu Salesforce, chương 3 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Dữ liệu này nằm ở đâu? · Tiếp theo: Trường cũng là kiến trúc

Câu hỏi mô-đun này trả lời: Khái niệm nghiệp vụ này nên trở thành loại đối tượng Salesforce nào, và giấy phép cho phép những gì?

Một trong những việc dễ làm nhất trong Salesforce là tạo một đối tượng tùy chỉnh. Đó chính là lý do tôi nghĩ chúng ta tạo ra quá nhiều.

Bạn đang trong một buổi lấy yêu cầu và ai đó nói: “Chúng tôi cần theo dõi các nhà phân phối.” Đối tượng tùy chỉnh mới: Distributor. Xong. Chỉ có điều tôi muốn kiến trúc sư hỏi một câu khác trước: nhà phân phối là gì? Đó là một công ty. Salesforce đã có một cách khá tốt để biểu diễn một công ty. Nó tên là Tài khoản. Điều đó không có nghĩa câu trả lời luôn là Tài khoản. Nhưng nếu tôi phải giải thích vì sao một công ty không phải là Tài khoản, tôi muốn một lý do tốt hơn “phía nghiệp vụ gọi họ là nhà phân phối”.

Đây là nơi mô hình logic của chương 2 gặp nền tảng, và lập trường xuất phát của tôi rất đơn giản: nếu khái niệm nghiệp vụ phù hợp trọn vẹn với mục đích dự định của một đối tượng chuẩn, hãy bắt đầu từ đó.

Bắt đầu từ ý nghĩa

Ngay cả khi một thứ xứng đáng là một đối tượng, nó không tự động xứng đáng là một đối tượng tùy chỉnh. Hãy hỏi nó thực sự đại diện cho điều gì. Một doanh nghiệp hay tổ chức dưới bất kỳ hình thức nào? Hãy bắt đầu với Tài khoản. Một người làm việc với tổ chức đó? Liên hệ. Thứ gì đó khách hàng sở hữu hoặc đã mua? Tài sản. Thứ gì đó bạn đang cố bán? Giờ thì Cơ hội mới có mặt trong cuộc trò chuyện.

Đó là lý do chúng ta đã nhìn về phi thuyền mẹ trước tiên, trong mô-đun 2. Các mô hình đó không hợp với mọi doanh nghiệp, nhưng chúng ta không nên phớt lờ chúng chỉ vì tự xây thì cảm giác gọn gàng hơn. Trước khi bấm Đối tượng tùy chỉnh mới, hãy hỏi Salesforce mô hình hóa khái niệm này thế nào, những gì đã được xây quanh mô hình đó, và bạn sẽ từ bỏ điều gì nếu thay thế nó.

Phép thử phù hợp trọn vẹn

Phép thử của tôi là một câu hỏi: khái niệm nghiệp vụ này có phù hợp trọn vẹn với mục đích dự định của đối tượng chuẩn không? Nếu có, tôi nghiêng về đối tượng chuẩn.

Một nhà phân phối là một công ty chúng ta có quan hệ, nên Tài khoản phù hợp trọn vẹn. Tôi không bận tâm việc người dùng gọi công ty này là nhà phân phối, công ty khác là nhà cung cấp, công ty khác là đối tác bán lẻ và công ty khác nữa là khách hàng. Đó là các vai trò nghiệp vụ, và chúng không cần bốn đối tượng vật lý. Những tên gọi nghiệp vụ khác nhau không tự động có nghĩa là những cấu trúc dữ liệu khác nhau. Một loại, một loại bản ghi hay một quan hệ có thể mang sự khác biệt đó.

Phép thử cũng hoạt động theo chiều ngược lại. Trong chương 1, tôi đã để lại cho bạn một câu hỏi: doanh nghiệp của một khách hàng có nhiều địa điểm giao hàng. Mỗi địa điểm nên là một Tài khoản, hay một đối tượng tùy chỉnh?

Một Tài khoản cho bạn rất nhiều thứ. Bạn có các trường địa chỉ, và mọi thứ vốn đã trông đợi một địa chỉ Tài khoản: báo cáo, bản đồ, tích hợp. Nhưng bạn cũng nhận luôn phần gánh nặng: rất nhiều trường, chia sẻ, phân cấp, quyền sở hữu, mọi thứ treo trên một Tài khoản, và phần lớn trong đó chẳng liên quan gì đến một địa chỉ riêng. Bạn sẽ phải mang theo rất nhiều thứ nặng nề mà bạn không dùng, chỉ để có một địa chỉ khác.

Một đối tượng tùy chỉnh, là con của Tài khoản, có thể rất gọn nhẹ: chỉ các trường địa chỉ, một nơi chúng ta giao hàng đến, với vòng đời riêng mà tôi có thể kiểm soát độc lập.

Vậy đây là chuyện cân bằng: sức nặng bạn gánh lấy so với giá trị bạn nhận được. Nếu tất cả những gì tôi cần là một địa chỉ có vòng đời riêng, đó là chỗ tôi chọn tùy chỉnh.

Với các vấn đề con trên một trường hợp cũng vậy. Nếu mỗi vấn đề con thực sự là một trường hợp, được một nhân viên hỗ trợ xử lý, với trạng thái và mức dịch vụ riêng, hãy lồng chúng bằng Trường hợp cha (Parent Case) từ mô-đun 2. Nhưng nếu nó chỉ là một mục trong danh sách kiểm tra mà không ai xử lý như một trường hợp, thì một trường hợp đầy đủ mang theo rất nhiều thứ nó sẽ không bao giờ dùng, và một đối tượng con tùy chỉnh đơn giản có thể nhẹ hơn. Không phải vì tùy chỉnh gọn gàng hơn. Mà vì ý nghĩa khác, hoặc sức nặng không phù hợp.

Đối tượng chuẩn đi kèm hành lý

Khi chọn một đối tượng chuẩn, bạn chọn nhiều hơn các trường của nó. Bạn chọn một thứ mà các sản phẩm của Salesforce đã hiểu: báo cáo, tự động hóa, quan hệ dựng sẵn, tính năng sản phẩm, gói AppExchange, và bất cứ thứ gì Salesforce xây tiếp theo. Điều đó có thể vô cùng giá trị.

Đối tượng chuẩn cũng đi kèm quan điểm riêng: hành vi sẵn có, quan hệ, các cân nhắc bảo mật, đôi khi yêu cầu giấy phép, và những tính năng bạn không cần. Vì vậy “luôn dùng đối tượng chuẩn” không phải quy tắc của tôi. Tôi không có quy tắc “luôn luôn”. Tôi có một khuynh hướng: dùng đối tượng chuẩn khi ý nghĩa phù hợp trọn vẹn và hành vi nền tảng quanh nó giúp thiết kế thay vì chống lại nó. Nếu tôi mất năm năm bắt Cơ hội hoạt động như một thứ không phải cơ hội bán hàng, tôi chẳng được gì khi giữ nó là đối tượng chuẩn. Tôi chỉ đã thỏa hiệp sai theo chiều ngược lại.

Tài sản là một ví dụ tốt

Tài sản là một trong những đối tượng chuẩn người ta hay bỏ qua. Cách đơn giản nhất tôi có thể nói: đó là thứ khách hàng có. Có thể họ mua nó từ chúng ta, có thể không. Tôi vẫn quan tâm đến một sản phẩm của đối thủ đang nằm tại địa điểm của khách hàng, vì tôi đang bảo trì nó, hay đang cố thay thế nó, hay tôi cần hiểu cơ sở thiết bị đã lắp đặt của họ. Nếu tôi tạo Customer_Product__c mà không xem Tài sản trước, tôi đã bỏ qua một câu hỏi kiến trúc. Tài sản không tự động thắng, nhưng nó xứng đáng được đánh giá.

Tài khoản cá nhân: khi nào người đó chính là tài khoản?

Trong mô-đun 2, chúng ta đã gặp tài khoản cá nhân: một tài khoản và một liên hệ trong cùng một bản ghi, dành cho khách hàng là cá nhân. Giờ đến quyết định.

Quan điểm của tôi: với B2C, rất khó để làm mà không có chúng. Có quá nhiều thứ đi kèm sẵn với Tài khoản và Liên hệ đến mức chi phí và gánh nặng là đáng. Và chi phí là có thật: dung lượng lưu trữ khoảng gấp đôi một tài khoản doanh nghiệp, một công tắc bạn không thể tắt, và một số giấy phép bên ngoài không dùng được chúng. Partner Community không dùng được với tài khoản cá nhân (Experience Cloud User Licenses (opens in a new tab), tiếng Anh). Vì vậy câu hỏi không phải là “cơ sở dữ liệu của chúng ta có con người không?” Org nào cũng có con người. Câu hỏi là “trong doanh nghiệp này, người đó có thực sự là tài khoản không?” Một Liên hệ là một con người không biến nó thành tài khoản cá nhân. Quan hệ kinh doanh mới quyết định điều đó.

Click to enlarge

Giờ để tôi làm mọi thứ phức tạp lên: giấy phép

Đến đây: tìm khái niệm, tìm sự phù hợp chuẩn gọn gàng nhất, chọn tùy chỉnh khi ý nghĩa không khớp. Giờ là câu hỏi tiếp theo của kiến trúc sư: ai cần dùng nó? Bạn có thể thiết kế một mô hình tuyệt đẹp rồi phát hiện một nửa số người cần dữ liệu không được cấp phép cho các đối tượng bạn đã chọn. Giấy phép là một phần của mô hình dữ liệu.

Ba giấy phép nội bộ

Hãy bắt đầu với chính người của bạn. Bên trong công ty, có ba loại giấy phép mà tôi muốn mọi kiến trúc sư nắm thật chắc, vì chúng quyết định mỗi người dùng thấy gì và làm được gì, và do đó mô hình dữ liệu của bạn có thể trông cậy vào điều gì.

Sales Cloud (nay là Agentforce Sales). Những người dùng này có giấy phép người dùng Salesforce đầy đủ: các đối tượng CRM chuẩn, và mọi ứng dụng chuẩn hay tùy chỉnh. Tức là khách hàng tiềm năng, cơ hội và dự báo bên cạnh tài khoản và liên hệ, và cả trường hợp nữa: một nhân viên bán hàng có thể xem các trường hợp đang mở của khách hàng trước một cuộc gọi. Để tạo và chạy chiến dịch cần thêm một mảnh nữa, giấy phép tính năng Marketing User.

Service Cloud (nay là Agentforce Service). Cùng giấy phép người dùng Salesforce, được thiết lập cho dịch vụ. Trường hợp nằm ở trung tâm, được xử lý trong Service Console: giấy phép tính năng Service Cloud User là thứ mở Salesforce Console for Service. Đây là nơi thỏa thuận mức dịch vụ (SLA) tồn tại, thông qua quản lý quyền lợi (entitlement management) và các mốc (milestone), và là nơi Knowledge xuất hiện, thứ mà hầu hết các phiên bản phải mua thêm.

Platform (Salesforce Platform). Dành cho những người cần các ứng dụng tùy chỉnh của bạn, không cần CRM. Họ có tài khoản, liên hệ, báo cáo, bảng điều khiển, tài liệu và mọi ứng dụng tùy chỉnh trong org. Những gì họ không có: dự báo, khách hàng tiềm năng, chiến dịch và cơ hội. Nó rẻ hơn, chính vì vậy mà rất nhiều ứng dụng tùy chỉnh lớn chạy trên nó, và cũng chính vì vậy mà nó có thể khiến mô hình dữ liệu của bạn bị hớ.

	Sales Cloud	Service Cloud	Platform
Giấy phép người dùng	Salesforce	Salesforce	Salesforce Platform
Xây dựng cho	Bán hàng	Hỗ trợ khách hàng	Ứng dụng tùy chỉnh
Tài khoản, liên hệ	Có	Có	Có
Khách hàng tiềm năng, cơ hội, dự báo	Có	Có	Không
Trường hợp	Có, để xem các trường hợp của khách hàng	Ở trung tâm, trong Service Console	Không
Thỏa thuận mức dịch vụ	Không	Có, quyền lợi và mốc	Không
Đối tượng và ứng dụng tùy chỉnh	Có	Có	Có

Hãy đọc bảng này theo cách một kiến trúc sư đọc. Nếu một nhóm người dùng lớn dùng Platform, bất kỳ thiết kế nào đặt công việc của họ lên một Cơ hội đều hỏng ngay từ trước khi bắt đầu. Nếu ban điều hành cần số liệu SLA, giấy phép họ đang dùng quyết định họ có xem được hay không. Ba loại này quyết định hành vi.

Click to enlarge

Khi giấy phép quyết định đối tượng

Cơ hội là nạn nhân tôi gặp nhiều nhất. Bạn đã thấy trong bảng: người dùng Platform không có nó (Standard User Licenses (opens in a new tab), tiếng Anh), và người dùng Customer Community cũng không làm việc được với nó. Vậy là yêu cầu trông giống một Cơ hội, ai đó nói “mình dùng Cơ hội đi”, rồi tôi hỏi ai cần truy cập. Nếu một nhóm lớn dùng giấy phép Platform hoặc Customer Community, giấy phép không còn là một chi tiết mua sắm nữa. Nó là một ràng buộc kiến trúc, và thường đẩy thiết kế về phía một đối tượng tùy chỉnh.

Nó cũng tác động theo chiều đi lên. Trong lớp tôi hỏi: CEO muốn các bảng điều khiển đẹp; giấy phép Sales hay Service? Một người dùng Sales thấy được các đối tượng bán hàng và cả trường hợp, nên với bảng điều khiển bán hàng và số trường hợp đang mở, Sales là ổn. Nhưng ngay khi lãnh đạo muốn KPI về SLA (còn bao lâu nữa thì một trường hợp vi phạm mức dịch vụ), dữ liệu đó nằm trong entitlement và milestone, và quản lý entitlement cần Agentforce Service, trước đây là Service Cloud (Supported Editions for Service Features (opens in a new tab), tiếng Anh). Giờ bạn phải nâng cấp giấy phép của các lãnh đạo. Hãy lắng nghe yêu cầu nghiệp vụ, và biết giấy phép nào nằm bên dưới dữ liệu nó cần.

Sân vận động

Tôi nghĩ về giấy phép như những chỗ ngồi trong sân vận động. Ai cũng đang xem cùng một trận đấu. Nếu tôi mua chỗ đắt tiền ở giữa, tôi thấy được cả hai đội cận cảnh. Nếu tôi ở tít trên góc khán đài, ghế không có đệm và tôi phải xem bằng ống nhòm.

Đó là các giấy phép bên ngoài, dành cho những người ngoài công ty: khách hàng và đối tác đăng nhập vào một trang Experience Cloud. Có ba loại tôi muốn bạn biết.

Customer Community: hàng ghế trên cao. Được xây cho số lượng lớn người dùng bên ngoài cần trường hợp và kiến thức: một khách hàng kiểm tra trường hợp hỗ trợ của mình. Chỗ ngồi giá chỉ khoảng một nửa và có thể cấp cho số lượng người dùng khổng lồ. Ở trên đó bạn mất gì? Báo cáo, bảng điều khiển, và bảng chia sẻ: kiểu chia sẻ dựa trên vai trò mà các hạng cao hơn có. Nó có dùng được với tài khoản cá nhân.

Customer Community Plus: khoảng nửa đường xuống. Salesforce mô tả nó là giấy phép cho người dùng bên ngoài cần báo cáo, bảng điều khiển và chia sẻ chuẩn: một khách hàng quản lý quyền truy cập của người khác, hoặc cần xem số liệu của mình.

Partner Community: gần sân hơn nữa, cho doanh nghiệp với doanh nghiệp, với quyền truy cập dữ liệu bán hàng. Đối tác làm việc với khách hàng tiềm năng và cơ hội: họ đăng ký thương vụ, và họ chạy chiến dịch cùng bạn. Đó là chỗ ngồi bên ngoài với tới được các đối tượng bán hàng. Một điểm vướng: nó không dùng được với tài khoản cá nhân (Experience Cloud User Licenses (opens in a new tab), tiếng Anh).

Click to enlarge

Sai lầm là thiết kế như thể ai cũng có vé đắt tiền, rồi phát hiện lúc triển khai rằng phần lớn người dùng không vào được khu vực nơi bạn đặt dữ liệu của họ. Khi đó bạn có ba lựa chọn: mua chỗ khác, chuyển trải nghiệm đi nơi khác, hoặc thiết kế lại mô hình. Cả ba đều là kiến trúc.

Cách họ trả tiền làm thay đổi thiết kế

Còn một câu hỏi khác người ta hay quên: những người dùng này sẽ đăng nhập thế nào? Giấy phép bên ngoài có hai dạng. Theo thành viên: bạn trả theo người dùng, phù hợp với 500 đối tác đăng nhập mỗi ngày. Theo lượt đăng nhập: bạn mua một số lượt đăng nhập mỗi tháng, phù hợp với năm triệu khách hàng đăng nhập vài lần mỗi năm. Đăng nhập nhiều hơn một lần trong cùng một ngày vẫn tính là một lượt (Experience Cloud User Licenses (opens in a new tab), tiếng Anh).

Vì vậy khi ai đó nói “chúng tôi đang xây một cổng thông tin khách hàng”, câu hỏi tiếp theo của tôi không phải là mẫu nào. Mà là: khách hàng là ai, bao nhiêu người, bao lâu họ đến một lần, họ cần dữ liệu gì, và họ được phép làm gì với nó?

Khi giấy phép định hình mô hình

Đôi khi giấy phép không chỉ chọn đối tượng; nó bẻ cong cả mô hình. Một số giấy phép nền tảng giới hạn người dùng trong một ứng dụng tùy chỉnh với tối đa mười đối tượng tùy chỉnh (ví dụ Lightning Platform – One App; Standard User Licenses (opens in a new tab), tiếng Anh).

Trong một dự án ban đầu, cho một công ty lớn về dịch vụ chuyên nghiệp và xây dựng, chúng tôi phải xây một thứ giống LinkedIn cho toàn bộ lực lượng lao động: công việc, kỹ năng, chứng chỉ, ngôn ngữ và dự án của mọi người, để họ tìm được người xây cầu có chứng chỉ ở một quốc gia nhất định. Nếu không có giới hạn, tôi sẽ xây các đối tượng người dùng-công việc, người dùng-kỹ năng, người dùng-chứng chỉ, người dùng-ngôn ngữ và người dùng-dự án, cộng với danh sách tham chiếu về chứng chỉ và dự án. Với một giấy phép mười đối tượng, và được dặn đừng dùng hết, điều đó không khả thi. Vậy là nó thành trò đoán nhạc: tôi có thể xây cái này với ít đối tượng nhất là bao nhiêu? Câu trả lời là hai. Một đối tượng tham chiếu, với một loại bản ghi cho mỗi loại danh sách (công việc, kỹ năng, chứng chỉ, ngôn ngữ, dự án), và một đối tượng thuộc tính người dùng, với các loại bản ghi tương ứng, trỏ đến nó.

Đó không phải là mô hình tối ưu. Báo cáo trên nó rất khổ, và tôi đã muốn nó gọn gàng hơn. Nhưng đó là những gì giấy phép cho phép. Tôi gọi chúng là đối tượng dao đa năng: hãy giữ mẫu này trong túi, và khi các giới hạn không còn chừa chỗ, hãy đập kính khẩn cấp và chuyển sang tách theo loại bản ghi. Chỉ cần biết mình đang đánh đổi gì. Quyền khác nhau cho mỗi loại bản ghi có thể buộc bạn phải tách đối tượng dù sao đi nữa.

Con người không còn là người dùng duy nhất

Thêm một câu hỏi về giấy phép đã trở nên quan trọng: còn những thứ không phải con người thì sao? Tích hợp có danh tính. Tác tử có danh tính. Salesforce giờ có giấy phép Salesforce Integration cho tích hợp giữa các hệ thống: chỉ API, không dành cho con người, với năm giấy phép đi kèm mỗi org Enterprise, Unlimited và Performance Edition (Standard User Licenses (opens in a new tab), tiếng Anh). Vì vậy đừng chỉ hỏi người dùng nào cần truy cập. Hãy hỏi danh tính nào cần truy cập: một người, một khách hàng, một đối tác, một tích hợp, một tác tử. Rồi mỗi danh tính cần thấy và làm gì.

Ngoài kỳ thi: AI thay đổi điều gì. Khi tác tử trở thành một bên tiêu thụ và tạo ra dữ liệu khác, việc chọn đối tượng và giấy phép không chỉ là chuyện màn hình cho con người. Hãy biết tác tử chạy dưới danh tính nào, danh tính đó với tới được gì, và mô hình có đặt dữ liệu tác tử cần sau một đối tượng hay quyền mà nó không dùng được hay không.

Steve Trucking: một câu dễ và một câu khó

Steve Trucking làm việc với các Đối tác bán lẻ. Đối tác bán lẻ là gì? Một doanh nghiệp. Dễ: Tài khoản. Tôi không tạo Retail_Partner__c chỉ vì ai đó dùng từ “đối tác”.

Giờ đến Người nhận, người nhận chiếc tủ lạnh. Liên hệ? Tài khoản cá nhân? Thứ gì khác? Một triệu Người nhận mới mỗi năm, là khách hàng của các Đối tác bán lẻ, không phải của chúng ta. Đó chính là loại câu hỏi mà tôi không muốn nhảy vào một đối tượng trước khi hiểu quan hệ, quyền truy cập và quy mô. Chúng ta sẽ quyết định ở điểm kiểm tra của Phần 1.

Kiến trúc sư quyết định gì ở đây

• Một khái niệm nghiệp vụ có phù hợp trọn vẹn với mục đích dự định của một đối tượng chuẩn không, hay ý nghĩa hoặc sức nặng của nó khác.
• Những nhãn nghiệp vụ khác nhau là những thực thể khác nhau, hay chỉ là những vai trò khác nhau của cùng một thực thể.
• Mọi người, người dùng bên ngoài, tích hợp và tác tử cần dữ liệu có với tới được đối tượng đã chọn theo các giấy phép dự kiến không.
• Số lượng người dùng và kiểu đăng nhập (theo thành viên hay theo lượt đăng nhập) định hình giấy phép và mô hình thế nào.
• Khi nào một giới hạn giấy phép biện minh cho một mô hình chưa tối ưu, và sự đánh đổi đó tốn gì về báo cáo và quyền.

Điều cốt lõi không phải là đối tượng chuẩn tốt còn đối tượng tùy chỉnh xấu. Mà là lựa chọn có hệ quả, và đôi khi nó hoàn toàn không được quyết định bởi danh từ, mà bởi những con người, và những cỗ máy, cần dùng nó.

Tìm hiểu thêm

• Salesforce Help, Standard User Licenses (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-02, kiểm tra lại ngày 2026-10-12: người dùng Platform không được dùng dự báo, khách hàng tiềm năng, chiến dịch và cơ hội; một ứng dụng tùy chỉnh với tối đa 10 đối tượng tùy chỉnh; năm giấy phép Salesforce Integration trong mỗi org Enterprise Edition.
• Salesforce Help, Experience Cloud User Licenses (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-02, kiểm tra lại ngày 2026-10-12: Partner Community không dùng được với tài khoản cá nhân; Customer Community Plus cho báo cáo, bảng điều khiển và chia sẻ chuẩn; nhiều lần đăng nhập trong một ngày tính là một.
• Salesforce Help, Supported Editions for Service Features (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-02, kiểm tra lại ngày 2026-10-12: thỏa thuận mức dịch vụ (quản lý quyền lợi) với Agentforce Service; Knowledge là chi phí bổ sung trong hầu hết các phiên bản.
• Salesforce Help, Available Feature Licenses (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-12: Service Cloud User, “Access the Salesforce Console for Service”; Marketing User để tạo và quản lý chiến dịch.