Giữ dữ liệu nhất quán

🌐 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 9 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: Quyền sở hữu và vòng đời · Tiếp theo: Thiết kế mô hình vật lý Salesforce

Câu hỏi mô-đun này trả lời: Làm sao để giữ dữ liệu nhất quán, và mỗi tầng tốn gì?

Ai cũng muốn dữ liệu sạch. Tôi chưa từng bước vào một buổi lấy yêu cầu mà có người nói: “Điều chúng tôi thực sự muốn là dữ liệu không nhất quán.” Bất đồng đến sau: chúng ta thực thi các quy tắc ở đâu? Trên màn hình? Một trường bắt buộc? Một danh sách chọn, một quy tắc xác thực, một quy tắc trùng lặp, một flow, Apex? Tất cả đều giúp được. Chúng không thể thay thế cho nhau, và mỗi tầng đều có cái giá của nó.

Quy tắc chung của tôi là đẩy quy tắc xuống thấp nhất mà bạn có thể một cách hợp lý. Nếu một giá trị chỉ có thể là một trong năm thứ, đừng để người ta gõ bất cứ gì rồi dọn dẹp sau bằng tự động hóa. Nếu hai bản ghi không bao giờ được trùng một mã định danh, đừng trông vào việc ai đó phát hiện ra nó trong một báo cáo. Nếu một quy tắc phải đúng bất kể bản ghi đến từ màn hình, API, tích hợp, lần nạp dữ liệu hay tác tử, đừng chỉ thực thi nó ở giao diện. Quy tắc càng nằm gần dữ liệu, càng khó lách qua. Tôi gọi đó là nấc thang nhất quán.

Nấc một: kiểu trường và bộ từ vựng

Quy tắc nhất quán đầu tiên là quy tắc từ mô-đun 6: chọn đúng kiểu. Một ngày là Date, một thời điểm là Date/Time, tiền là Currency. Đó là sự nhất quán trước khi có ai viết một quy tắc.

Hãy để trạng thái của một lần giao hàng là trường văn bản và bạn sẽ có Delivered, delivered, DELIVERED, Complete, Done và Dropped off, và ai đó sẽ phải tìm hiểu xem sáu giá trị đó có cùng nghĩa không. Hoặc định nghĩa bộ từ vựng một lần: Delivered, một giá trị, một ý nghĩa. Hãy dùng một danh sách chọn hạn chế để nó từ chối mọi thứ không có trong danh sách, kể cả qua API, và một bộ giá trị toàn cục khi nhiều trường dùng chung danh sách đó (mô-đun 6 có chi tiết).

Nhưng đừng dùng danh sách chọn chỉ để ngăn người ta gõ. Nó thực sự là một giá trị, hay một thực thể khác? Chín trung tâm phân phối mỗi cái một tên có thể trông như một danh sách chọn; chín cái có địa chỉ, người quản lý, công suất và xe tải là các bản ghi. Quy tắc nên củng cố mô hình, không bù đắp cho một mô hình tồi. Và nếu nó thực sự là một bộ từ vựng được kiểm soát, hãy kiểm soát nó ngay ở trường. Đừng cho phép hỗn loạn rồi xây một flow để biến AZ, Arizona, Ariz và Phoenix area thành giá trị mà bạn muốn ngay từ đầu.

Nấc hai: bắt buộc và duy nhất

Bắt buộc và Duy nhất hấp dẫn vì chúng đơn giản: đánh dấu ô, xong vấn đề. Đôi khi. Nếu mỗi xe tải có một số hiệu đội xe từ ngày được tạo, và không có hai xe nào trùng số, cả hai ô đều thể hiện các quy tắc nghiệp vụ thực sự. Đó là sự nhất quán mạnh.

Nhưng một khi nền tảng thực thi một quy tắc, nó không quan tâm quy trình của bạn có ngoại lệ vào chiều thứ Ba. Tôi đã dùng ví dụ này trong lớp nhiều năm. Một đối tượng đã tồn tại một thời gian, với rất nhiều bản ghi. Ai đó thêm một trường và đánh dấu Required. Họ thử tạo một bản ghi: chạy đẹp. Rồi tối thứ Bảy, triển khai, các bài kiểm thử chạy, và một lớp kiểm thử cũ tạo đối tượng mà không có trường mới. Bùm. Hoặc ai đó sửa một bản ghi cũ có từ trước khi trường tồn tại. Hoặc tích hợp gửi cùng gói dữ liệu nó đã gửi suốt năm năm. Bùm. “Nhưng chúng tôi đâu có đổi trường đó.” Nền tảng không quan tâm: bạn đã thay đổi hợp đồng về thế nào là một bản ghi hợp lệ. Một quy tắc mới không chỉ ảnh hưởng đến dữ liệu mới; nó thay đổi những gì bạn có thể làm với dữ liệu cũ.

Nấc ba: quy tắc xác thực

Quy tắc xác thực cho phép chúng ta nói những điều phong phú hơn nhiều. Nếu trạng thái là Delivered, thời gian giao hàng thực tế phải được điền. Nếu điểm dừng là lắp đặt, danh sách kiểm tra phải hoàn tất trước khi đóng điểm dừng. Chúng chạy khi bản ghi được lưu, nên chúng bảo vệ bản ghi bất kể nó được lưu từ một trang, API, lần nạp dữ liệu, tích hợp hay tác tử. Đó chính là điểm mấu chốt. Nếu quy tắc phải bảo vệ bản ghi, hãy đặt nó ở nơi mọi lần ghi đều gặp phải.

Chúng cũng có răng. Đó vừa là sức mạnh vừa là cái giá của chúng.

Vấn đề bản ghi cũ

Đây là chỗ mọi thứ trở nên xấu xí. Bạn có một triệu bản ghi, và hôm nay bạn thêm một quy tắc: thời gian giao hàng không được trước giờ khởi hành của tuyến. Hợp lý. Nhưng hai mươi nghìn bản ghi cũ vi phạm nó, nhờ một lần chuyển đổi dữ liệu bảy năm trước. Một người dùng mở một trong số đó và đổi số điện thoại. Lưu. Quy tắc kích hoạt. “Tôi đổi số điện thoại. Sao lại báo tôi về thời gian giao hàng từ năm 2019?” Câu hỏi chính đáng.

Vì vậy một quy tắc xác thực không nên chỉ nói điều gì phải đúng. Nó nên nói khi nào thực thi điều đó. Các hàm như ISNEW() và ISCHANGED() cho phép bạn giới hạn quy tắc cho bản ghi mới, hoặc cho những lần lưu mà các trường liên quan thực sự thay đổi (Validation Rule Considerations (opens in a new tab), tiếng Anh).

Nhưng một bản ghi không chỉ thay đổi khi có người sửa nó, và nhiều lý do nằm ngoài tầm kiểm soát của bạn. Tích hợp cập nhật trạng thái qua đêm. Một flow đóng dấu một ngày. Một người quản lý giao lại một lãnh thổ và chủ sở hữu thay đổi trên mười nghìn bản ghi. Ai đó sửa một mặt hàng giao, trường tổng hợp cuộn lên trên lần giao hàng tính lại, và việc đó lưu lần giao hàng, nên quy tắc xác thực của lần giao hàng chạy với một người dùng chưa từng chạm vào nó (Roll-Up Summary Field (opens in a new tab) cảnh báo rằng lỗi xác thực có thể hiện trên bản ghi chi tiết hoặc bản ghi master). Mỗi lần lưu đó đều gặp quy tắc mới của bạn. Vì vậy với mỗi quy tắc mới, hãy hỏi: quy tắc này có nên áp dụng cho lần lưu đó không?

Đây là các lựa chọn, và bạn đan chúng vào quy tắc:

• Luôn luôn, ở mọi lần lưu. Đúng khi quy tắc thực sự nói về bản ghi và dữ liệu cũ vượt qua được. Nhưng hãy biết “mọi lần lưu” nghĩa là gì: một batch job chỉ đổi chủ sở hữu, hay bất kỳ chỉnh sửa nhỏ nào ở bất kỳ trường nào trên bản ghi, cũng phải vượt qua nó.
• Chỉ cho bản ghi mới, với ISNEW(). Quy tắc kiểm tra bản ghi một lần, khi nó được tạo, và không bao giờ nữa. Quá khứ giữ nguyên như cũ, nhưng tương lai cũng vậy: một lần sửa sau đó có thể khiến một bản ghi mới vi phạm quy tắc mà không ai ngăn lại. Nếu điều đó quan trọng, hãy kết hợp với lựa chọn tiếp theo.
• Chỉ khi các trường liên quan thay đổi, với ISCHANGED(). Sửa số điện thoại không đánh thức quy tắc về thời gian giao hàng.
• Không áp dụng cho một số bên ghi nhất định. Một quyền tùy chỉnh (custom permission), được kiểm tra trong công thức bằng $Permission, cho phép người dùng tích hợp hay một lần chuyển đổi dữ liệu đi qua, trong khi con người vẫn phải tuân theo quy tắc (How to Reference a Custom Permission in a Validation Rule (opens in a new tab)). Hãy cấp nó có chủ ý và cho ít người.
• Từ một ngày trở đi, so sánh CreatedDate với ngày quy tắc bắt đầu có hiệu lực, khi “mới” nghĩa là “kể từ khi chúng ta bắt đầu thực thi điều này”. Khác với ISNEW(), cách này tiếp tục kiểm tra các bản ghi đó ở mọi lần lưu sau, nên cùng lời cảnh báo vẫn áp dụng: một thay đổi nhỏ, như một lần cập nhật chủ sở hữu hàng loạt, có thể thất bại trên một bản ghi đã lệch đi.

Thêm một quy tắc cho các bản ghi bạn đã có? Hãy nghĩ kỹ các hệ quả trước khi bật nó lên. Mọi bản ghi hiện có giờ phải vượt qua nó ở lần lưu tiếp theo, và lần lưu đó có thể đến từ một nơi bạn không ngờ: một tích hợp hằng đêm, một lần đổi chủ sở hữu hàng loạt, một trường tổng hợp cuộn lên, một lần cập nhật hàng loạt từ list view. Cái nào trong số đó sẽ chạm vào nó, và chuyện gì xảy ra với job đó khi một bản ghi thất bại? Phần Trước khi bạn bật nó lên có trình tự tôi dùng.

Đừng viết lại lịch sử để làm vừa lòng quy tắc

Còn hai mươi nghìn bản ghi cũ thì sao? Nếu dữ liệu sai và bạn biết giá trị đúng, hãy sửa nó. Nhưng tôi đã thấy một kiểu “sửa” khác: không ai biết sự thật lịch sử, họ chỉ cần bản ghi vượt qua, nên họ cập nhật chúng bằng những giá trị thỏa mãn quy tắc hôm nay. Tôi không thích điều đó. Cập nhật bản ghi cũ để tuân thủ sẽ thay đổi LastModifiedDate và phá hủy thông tin lịch sử quan trọng, còn bịa ra giá trị nghĩa là giả vờ chúng ta biết điều gì đó về quá khứ mà thực ra không biết. Hãy cho quy tắc một lối miễn trừ cho các bản ghi có trước nó thay vì viết lại lịch sử. Có thể xấu xí, nhưng trung thực.

Xác thực trên giao diện không phải là xác thực dữ liệu

Đặt một trường là bắt buộc trên bố cục trang và người dùng không thể lưu nếu thiếu nó. Rồi tích hợp hằng đêm chèn 50.000 bản ghi. Nó có dùng trang của bạn không? Không. Lần nạp hàng loạt, ứng dụng khách API hay tác tử cũng không. Một yêu cầu ở giao diện bảo vệ màn hình đó, không phải dữ liệu. Xác thực trường trên dynamic forms cũng có thể bị né theo cách tương tự. Vì vậy hãy hỏi: dữ liệu này có thể đi vào từ đâu? Lightning, cổng thông tin, di động, tích hợp, API, lần nạp hàng loạt, Flow, Apex, một tác tử. Càng nhiều cửa, tôi càng ít tin vào một quy tắc chỉ canh giữ một cửa.

Nấc bốn: quy tắc trùng lặp

Giờ chúng ta chuyển từ sự nhất quán bên trong một bản ghi sang sự nhất quán giữa các bản ghi. Acme Corporation, ACME Corp, Acme Inc.: bốn khách hàng hay một? Không quy tắc trường nào trả lời được. Quy tắc khớp định nghĩa cách so sánh các bản ghi; quy tắc trùng lặp quyết định chuyện gì xảy ra khi tìm thấy một bản ghi có khả năng trùng: cho phép kèm cảnh báo, chặn, hoặc báo cáo. Bạn có thể có tối đa năm quy tắc trùng lặp đang hoạt động trên mỗi đối tượng và tối đa ba quy tắc khớp trong mỗi quy tắc, và khóa khớp thu hẹp mỗi lần so sánh xuống 100 bản ghi có khả năng trùng nhất (Things to Know About Duplicate Rules (opens in a new tab), tiếng Anh).

Cái giá của chúng là ma sát. Nếu mọi tài khoản một nhân viên kinh doanh tạo ra đều báo Possible duplicate found, đôi khi đó chính là điều bạn muốn, và đôi khi người ta học cách bấm qua mà không đọc. Các bản ghi hợp lệ có thể trông giống nhau, và một tích hợp có thể cần hành vi khác với con người. Và lời cảnh báo là của chính Salesforce: thông báo và danh sách các bản ghi có thể trùng của nó có thể không hòa hợp với một màn hình tùy chỉnh bạn đã xây, và khi lần lưu là không giao diện (headless), một tích hợp, một lần nạp dữ liệu, một tác tử, thì hoàn toàn không có màn hình nào để hiện nó. Vì vậy hãy quyết định một bản trùng hiện ra thế nào trên mọi đường: một cảnh báo cho con người, một lần lưu bị chặn và một lỗi cho API, hoặc tùy chọn Report và các bộ bản ghi trùng (duplicate record sets) để ai đó xem lại sau. Kiến trúc tốt không phải là thực thi tối đa; mà là thực thi đúng.

Và hãy kiểm tra quy tắc trùng lặp thực sự canh giữ những cánh cửa nào (Things to Know About Duplicate Rules (opens in a new tab)). Qua API và các công cụ nhập dữ liệu, không ai thấy cảnh báo: một quy tắc đặt ở chế độ cảnh báo đơn giản là chặn lần lưu. Một số đường bỏ qua các quy tắc hoàn toàn: Quick Create, nút Undelete, một lần hợp nhất thủ công, các bản ghi được thêm bởi Lightning Sync hay Einstein Activity Capture. Và các bản ghi được lưu cùng một lúc không được so sánh với nhau, chỉ với các bản ghi đã có trong Salesforce. Nạp một tệp có cùng một khách hàng xuất hiện hai lần, và cả hai dòng đều có thể lọt qua. Quy tắc trùng lặp là một tấm lưới tốt. Nó không phải là ổ khóa trên cửa.

Kiến thức hay ra thi. Quy tắc trùng lặp không so sánh các bản ghi được lưu cùng một lúc với nhau, chỉ với các bản ghi đã có trong Salesforce. Qua API và các công cụ nhập dữ liệu thì không có cảnh báo: một bản trùng mà quy tắc bắt được đơn giản là không được lưu. Và một lần lưu cùng mọi thứ nó kích hoạt chạy như một giao dịch: nếu bất kỳ phần nào thất bại, tất cả đều được hoàn tác.

Một ranh giới. Quy tắc trùng lặp giữ một org sạch sẽ. Chúng không giải quyết danh tính ở cấp doanh nghiệp. Nếu Salesforce có Acme Corporation, ERP có ACME-10382 và hệ thống thanh toán có khách hàng 77193, quy tắc trùng lặp không thể cho bạn biết đó là cùng một công ty. Đó là dữ liệu chủ, chương 6.

Nấc năm: tự động hóa

Một số quy tắc quá phức tạp cho các nấc thấp hơn: chúng cần bản ghi liên quan, một hệ thống khác, bản ghi phụ thuộc, một quy trình nhiều bước. Đó là Flow, Apex, đôi khi là logic tích hợp. (Không phải Workflow Rules hay Process Builder; chúng đã hết hỗ trợ.) Tự động hóa mạnh mẽ và tốn kém hơn: nhiều bộ phận chuyển động hơn, nhiều kiểm thử hơn, nhiều xử lý lỗi hơn, nhiều cách để một tự động hóa vấp vào tự động hóa khác. Và code mang theo lỗi của riêng nó. Nếu kiểu trường thực thi được, tôi không viết Apex. Nếu một quy tắc xác thực nói rõ được, tôi không xây flow chỉ vì Flow có sẵn đó. Đừng giải một bài toán về trường bằng một cỗ máy quy trình.

Tất cả hoặc không gì cả: khi các bản ghi thay đổi cùng nhau

Cho đến giờ mỗi nấc bảo vệ một lần lưu. Nhưng các bản ghi thay đổi cùng nhau: một lần giao hàng và các mặt hàng của nó, một đơn hàng và các dòng của nó, một flow cập nhật ba đối tượng. Ở đây nền tảng cho bạn một đảm bảo mạnh. Một lần lưu cùng mọi thứ nó kích hoạt, các trigger, các flow, các lớp mà chúng gọi, chạy như một giao dịch: nếu bất kỳ phần nào thất bại, toàn bộ được hoàn tác và không có gì được ghi nhận (Apex Transactions (opens in a new tab)). Bạn không nhận được nửa lần giao hàng.

Công việc hàng loạt là ngoại lệ bạn tự chọn. Một lần nạp dữ liệu hay một phương thức Database của Apex có thể cho phép thành công một phần: các bản ghi tốt được lưu, các bản ghi xấu quay về kèm lỗi, và ai đó phải xử lý chúng (DML Statements vs. Database Class Methods (opens in a new tab)). Điều đó thường đúng cho một lần nạp một triệu dòng, nhưng khi đó sự nhất quán là một quy trình: ai đọc tệp lỗi, và chuyện gì xảy ra với các bản ghi đã thất bại?

Rồi còn chuyện thời điểm. Hai lần lưu cùng một lúc có thể cùng vượt qua một phép kiểm tra mà mỗi lần riêng lẻ sẽ không qua. Một flow tìm một đơn hàng có sẵn rồi mới tạo đơn hàng có thể để lọt hai đơn, và chúng ta vừa thấy rằng quy tắc trùng lặp không so sánh các bản ghi được lưu cùng lúc. Một trường được đánh dấu Unique, hoặc một ID bên ngoài, được nền tảng kiểm tra ở mọi lần lưu, nên chỉ một trong hai thắng. Đó là thêm một lý do để đẩy tính duy nhất xuống tận trường. Khóa, tranh chấp và thử lại là một chủ đề riêng; chương 11, Giao dịch, xử lý đồng thời và độ tin cậy, đi sâu vào đó.

Đẩy quy tắc xuống, cho đến khi nó không thuộc về chỗ đó

“Thấp nhất mà bạn có thể một cách hợp lý” không có nghĩa là “luôn thấp nhất”. Nếu một trường chỉ bắt buộc khi một cơ hội đến một giai đoạn nhất định, đặt nó bắt buộc trong lược đồ là sai; quy tắc có điều kiện, nên quy tắc xác thực là nấc đúng. Nếu một bản ghi trùng nên cảnh báo con người nhưng một tích hợp đã được duyệt có cơ chế đối chiếu riêng, hãy thiết kế cho cả hai đường. Mục tiêu: tầng thấp nhất biểu diễn đúng quy tắc nghiệp vụ.

Mỗi tầng đều có cái giá của nó

Click to enlarge

Đây là sự đánh đổi tôi muốn bạn thấy. Kiểu trường và giá trị được kiểm soát đơn giản và mạnh, nhưng chỉ cho những gì một trường có thể diễn đạt. Bắt buộc và Duy nhất thì thô: một khi bật, mọi lần ghi phải thỏa mãn chúng. Quy tắc xác thực diễn đạt các điều kiện phong phú hơn nhưng có thể chặn việc sửa bản ghi cũ và gây bất ngờ khi triển khai. Quy tắc trùng lặp bảo vệ giữa các bản ghi nhưng thêm ma sát cho người dùng và tích hợp. Tự động hóa xử lý được mọi thứ nhưng bắt bạn phải gánh việc điều phối, lỗi, kiểm thử và hiệu năng. Không có tầng nào miễn phí. Hãy chọn tầng cho mỗi quy tắc khi biết nó thất bại như thế nào.

Trước khi bạn bật nó lên

Thêm một quy tắc vào một org đang tồn tại là một đợt triển khai, không phải một ô đánh dấu. Hôm nay có bao nhiêu bản ghi vi phạm nó, và vì sao? Chúng có thực sự sai không? Chúng ta có biết được giá trị đúng không? Quy tắc đúng với lịch sử, hay chỉ từ giờ trở đi? Những tích hợp, kiểm thử và tự động hóa nào sẽ chạm vào nó? Một trình tự tốt: đo lường, dọn những gì bạn chứng minh được là sai, giới hạn phạm vi quy tắc, thêm lối miễn trừ có chủ ý cho lịch sử hợp lệ, kiểm thử mọi đường ghi, rồi mới thực thi. Đo lường và làm sạch là những kỷ luật riêng, lập hồ sơ dữ liệu (profiling), chuẩn hóa định dạng, giám sát, quản lý dữ liệu, và chương 5, Chất lượng và quản trị dữ liệu, đề cập đến chúng. Tốt hơn nhiều so với đánh dấu một ô vào thứ Sáu rồi phát hiện hậu quả vào tối thứ Bảy.

Ngoài kỳ thi: AI thay đổi điều gì. Một tác tử có thể tạo bản ghi nhanh hơn bất kỳ ai, và tạo bản ghi xấu cũng nhanh như vậy. “Người dùng biết không nên làm thế” không phải là sự bảo vệ khi người dùng là một tác tử. Hãy đặt các quy tắc quan trọng ở tầng dữ liệu, nơi mọi bên ghi đều gặp phải, để tác tử không phải nhớ những quy tắc bất thành văn của công ty.

Steve Trucking: bảo vệ lần giao hàng

Lấy một lần giao hàng. Trạng thái của nó đến từ một bộ từ vựng: một danh sách chọn, hạn chế. Mã tham chiếu đơn hàng của Đối tác bán lẻ phải là duy nhất theo từng đối tác, nên nó là một ID bên ngoài, đánh dấu duy nhất, dùng để upsert bảng kê hàng. Thời gian giao hàng thực tế là bắt buộc khi trạng thái là Delivered: một quy tắc xác thực, giới hạn cho thay đổi đó. Một điểm dừng lắp đặt không thể đóng cho đến khi danh sách kiểm tra hoàn tất và các ảnh bắt buộc đã được chụp (với máy rửa bát là đường cấp nước, đường thoát nước và độ cân bằng): một quy tắc xác thực, hoặc tự động hóa nếu phải kiểm tra ảnh lưu ngoài nền tảng. Cùng một đơn hàng đến hai lần từ một bảng kê hàng gửi lại sẽ bị ID bên ngoài bắt được; hai đơn hàng khác nhau trông giống nhau là một câu hỏi về so khớp.

Để ý rằng tôi không nói “cho hết vào một flow”. Mỗi quy tắc nằm trên nấc riêng của nó. Với mỗi quy tắc, hãy hỏi: tầng thấp nhất thực thi điều này một cách đúng đắn cho mọi đường ghi quan trọng là gì?

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

• Mỗi quy tắc thuộc về nấc nào: kiểu trường, bộ từ vựng được kiểm soát, bắt buộc hay duy nhất, quy tắc xác thực, quy tắc trùng lặp, hay tự động hóa.
• Những đường ghi nào phải được bảo vệ: giao diện, cổng thông tin, di động, tích hợp, lần nạp hàng loạt, API, tự động hóa và tác tử.
• Một quy tắc mới áp dụng cho bản ghi lịch sử, hay chỉ giới hạn cho dữ liệu mới và dữ liệu thay đổi với lối miễn trừ cho quá khứ.
• Dữ liệu xấu hiện có có thể được sửa dựa trên bằng chứng không, thay vì bị viết lại để vượt qua.
• Một quy tắc đáng giá bao nhiêu ma sát, độ phức tạp và công bảo trì.

Dữ liệu sạch không đến từ việc yêu cầu người ta nhập dữ liệu tốt. Nó đến từ một kiến trúc làm cho điều đúng trở nên dễ, điều sai trở nên khó, và các quy tắc quan trọng khó bị lách qua. Tiếp theo, chúng ta ghép cả chương lại trên một lát cắt của Steve Trucking.

Tìm hiểu thêm

• Salesforce Help, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) và Roll-Up Summary Field (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-13.
• Salesforce Help, Picklist Limitations (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-02.
• Salesforce Help, Validation Rule Considerations (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-02.
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-13: các giới hạn, các đường mà quy tắc không chạy, lần lưu qua API và công cụ nhập bị chặn mà không có cảnh báo, các lần lưu đồng thời không được so sánh.
• Apex Developer Guide, Apex Transactions (opens in a new tab) và DML Statements vs. Database Class Methods (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-13: một giao dịch được hoàn tác như một khối; các phương thức Database có thể cho phép thành công một phần.
• Salesforce Help, Workflow Rules & Process Builder End of Support (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-02.