รักษาข้อมูลให้สอดคล้องกัน

🌐 มีให้อ่านอีก 28 ภาษา

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

ภาพสร้างด้วย AI

แปลโดย AI ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

โมดูลที่ 9 จาก 10 ในบท สถาปัตยกรรมข้อมูล Salesforce บทที่ 3 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: ความเป็นเจ้าของและวงจรชีวิต · ถัดไป: ออกแบบโมเดลเชิงกายภาพของ Salesforce

คำถามที่โมดูลนี้ตอบ: ผมจะรักษาข้อมูลให้สอดคล้องกันได้อย่างไร และแต่ละชั้นมีต้นทุนเท่าไร?

ทุกคนอยากได้ข้อมูลที่สะอาด ผมไม่เคยเดินเข้าประชุมเก็บความต้องการแล้วมีใครพูดว่า “สิ่งที่เราอยากได้จริงๆ คือข้อมูลที่ไม่สอดคล้องกัน” ความเห็นไม่ตรงกันมาทีหลัง: เราจะบังคับใช้กฎที่ไหน? บนหน้าจอ? ฟิลด์ที่จำเป็น? picklist กฎการตรวจสอบความถูกต้อง กฎข้อมูลซ้ำ flow หรือ Apex? ทั้งหมดช่วยได้ แต่ใช้แทนกันไม่ได้ และทุกชั้นมีต้นทุน

กฎทั่วไปของผมคือ ดันกฎลงไปให้ต่ำที่สุดเท่าที่สมเหตุสมผล ถ้าค่าหนึ่งเป็นได้แค่หนึ่งในห้าอย่าง อย่าให้คนพิมพ์อะไรก็ได้แล้วค่อยใช้ระบบอัตโนมัติเก็บกวาดทีหลัง ถ้าสองเรกคอร์ดต้องไม่มีตัวระบุซ้ำกันเด็ดขาด อย่าพึ่งให้ใครสักคนสังเกตเห็นในรายงาน ถ้ากฎต้องเป็นจริงไม่ว่าเรกคอร์ดจะมาจากหน้าจอ API การผสานรวม การโหลดข้อมูล หรือเอเจนต์ อย่าบังคับใช้มันแค่ใน UI ยิ่งกฎอยู่ใกล้ข้อมูลเท่าไร ก็ยิ่งเลี่ยงยากเท่านั้น ผมเรียกมันว่าบันไดความสอดคล้อง

ขั้นที่หนึ่ง: ประเภทฟิลด์และคำศัพท์

กฎความสอดคล้องข้อแรกคือข้อจากโมดูลที่ 6: เลือกประเภทให้ถูก วันที่คือ Date ช่วงขณะหนึ่งคือ Date/Time เงินคือ Currency นั่นคือความสอดคล้องก่อนที่ใครจะเขียนกฎสักข้อ

ทำให้สถานะการจัดส่งเป็นฟิลด์ข้อความ แล้วคุณจะได้ Delivered, delivered, DELIVERED, Complete, Done และ Dropped off และต้องมีใครสักคนมานั่งดูว่าหกค่านั้นหมายถึงสิ่งเดียวกันไหม หรือกำหนดคำศัพท์ครั้งเดียว: Delivered ค่าเดียว ความหมายเดียว ทำให้มันเป็น picklist แบบจำกัดค่า เพื่อให้ปฏิเสธทุกอย่างที่ไม่อยู่ในรายการ แม้ผ่าน API และใช้ชุดค่าส่วนกลาง (global value set) เมื่อหลายฟิลด์ใช้รายการเดียวกัน (โมดูลที่ 6 มีรายละเอียด)

แต่อย่าใช้ picklist แค่เพื่อกันไม่ให้คนพิมพ์ มันเป็นค่าจริงๆ หรือเป็นอีกเอนทิตีหนึ่ง? ศูนย์กระจายสินค้าเก้าแห่งที่มีแค่ชื่ออาจดูเหมือน picklist แต่เก้าแห่งที่มีที่อยู่ ผู้จัดการ ความจุ และรถบรรทุก คือเรกคอร์ด กฎควรเสริมโมเดล ไม่ใช่ชดเชยโมเดลที่แย่ และถ้ามันเป็นคำศัพท์ที่ควบคุมจริงๆ ก็ควบคุมที่ฟิลด์ อย่าปล่อยให้วุ่นวายแล้วค่อยสร้าง flow เพื่อเปลี่ยน AZ, Arizona, Ariz และ Phoenix area ให้เป็นค่าที่คุณต้องการตั้งแต่แรก

ขั้นที่สอง: Required และ Unique

Required และ Unique น่าดึงดูดเพราะเรียบง่าย: ติ๊กช่อง ปัญหาจบ บางครั้งก็ใช่ ถ้ารถบรรทุกทุกคันมีหมายเลขกองรถตั้งแต่วันที่ถูกสร้าง และไม่มีสองคันใช้หมายเลขเดียวกัน ทั้งสองช่องก็แสดงกฎทางธุรกิจจริง นั่นคือความสอดคล้องที่แข็งแรง

แต่เมื่อแพลตฟอร์มบังคับใช้กฎแล้ว มันไม่สนว่ากระบวนการของคุณมีข้อยกเว้นบ่ายวันอังคาร ผมใช้ตัวอย่างนี้ในคลาสมาหลายปี ออบเจกต์หนึ่งมีมาสักพักแล้ว มีเรกคอร์ดมากมาย มีคนเพิ่มฟิลด์และติ๊ก Required เขาทดสอบสร้างเรกคอร์ด: ใช้ได้สวยงาม แล้วคืนวันเสาร์ deploy เทสต์รัน และคลาสเทสต์เก่าตัวหนึ่งสร้างออบเจกต์โดยไม่มีฟิลด์ใหม่ บูม หรือมีคนแก้เรกคอร์ดเก่าจากก่อนที่ฟิลด์จะมีอยู่ หรือการผสานรวมส่ง payload เดิมที่ส่งมาห้าปี บูม “แต่เราไม่ได้เปลี่ยนฟิลด์นั้นนะ” แพลตฟอร์มไม่สน: คุณเปลี่ยนสัญญาว่าเรกคอร์ดที่ถูกต้องคืออะไร กฎใหม่ไม่ได้มีผลแค่กับข้อมูลใหม่ มันเปลี่ยนสิ่งที่คุณทำได้กับข้อมูลเก่า

ขั้นที่สาม: กฎการตรวจสอบความถูกต้อง

กฎการตรวจสอบความถูกต้อง (validation rule) ให้เราพูดสิ่งที่ซับซ้อนกว่ามาก ถ้าสถานะเป็น Delivered เวลาจัดส่งจริงต้องถูกกรอก ถ้าจุดแวะเป็นงานติดตั้ง เช็กลิสต์ต้องครบก่อนจะปิดจุดแวะได้ มันทำงานเมื่อบันทึกเรกคอร์ด จึงปกป้องเรกคอร์ดไม่ว่าจะบันทึกจากหน้าเพจ API การโหลดข้อมูล การผสานรวม หรือเอเจนต์ นั่นคือประเด็น ถ้ากฎต้องปกป้องเรกคอร์ด ให้วางไว้ตรงที่การเขียนทุกครั้งต้องผ่าน

และมันก็มีเขี้ยวเล็บ นั่นคือจุดแข็งและต้นทุนของมัน

ปัญหาเรกคอร์ดเก่า

ตรงนี้เริ่มน่าเกลียด คุณมีหนึ่งล้านเรกคอร์ด และวันนี้คุณเพิ่มกฎ: เวลาจัดส่งต้องไม่ก่อนเวลาออกเดินทางของเส้นทาง สมเหตุสมผล แต่เรกคอร์ดเก่าสองหมื่นรายการฝ่าฝืนมัน เพราะการย้ายข้อมูลเมื่อเจ็ดปีก่อน ผู้ใช้เปิดเรกคอร์ดหนึ่งแล้วเปลี่ยนเบอร์โทรศัพท์ บันทึก กฎทำงาน “ผมเปลี่ยนเบอร์โทร ทำไมมาบอกผมเรื่องเวลาจัดส่งจากปี 2019?” เป็นคำถามที่ยุติธรรม

ดังนั้นกฎการตรวจสอบความถูกต้องไม่ควรบอกแค่อะไรต้องเป็นจริง มันควรบอกเมื่อไรจะบังคับใช้ ฟังก์ชันอย่าง ISNEW() และ ISCHANGED() ให้คุณจำกัดขอบเขตกฎไว้ที่เรกคอร์ดใหม่ หรือที่การบันทึกที่ฟิลด์ที่เกี่ยวข้องเปลี่ยนจริง (Validation Rule Considerations (opens in a new tab) ภาษาอังกฤษ)

แต่เรกคอร์ดไม่ได้เปลี่ยนเฉพาะตอนที่คนแก้ไข และเหตุผลหลายอย่างอยู่นอกการควบคุมของคุณ การผสานรวมอัปเดตสถานะข้ามคืน flow ประทับวันที่ ผู้จัดการมอบหมายเขตการขายใหม่และเจ้าของเปลี่ยนบนหนึ่งหมื่นเรกคอร์ด มีคนแก้ไขรายการจัดส่ง roll-up บนการจัดส่งคำนวณใหม่ และนั่นก็บันทึกการจัดส่ง กฎการตรวจสอบความถูกต้องของการจัดส่งจึงทำงานกับผู้ใช้ที่ไม่เคยแตะมันเลย (Roll-Up Summary Field (opens in a new tab) ภาษาอังกฤษ เตือนว่าข้อผิดพลาดจากการตรวจสอบอาจแสดงบน detail หรือ master) การบันทึกแต่ละครั้งเหล่านั้นต้องเจอกฎใหม่ของคุณ ดังนั้นสำหรับทุกกฎใหม่ ให้ถามว่า: กฎนี้ควรใช้กับการบันทึกนั้นไหม?

นี่คือทางเลือก และคุณสานมันเข้าไปในกฎ:

• เสมอ ในทุกการบันทึก ถูกต้องเมื่อกฎเกี่ยวกับเรกคอร์ดจริงๆ และข้อมูลเก่าผ่าน แต่ให้รู้ว่า “ทุกการบันทึก” หมายถึงอะไร: งาน batch ที่แค่เปลี่ยนเจ้าของ หรือการแก้ไขเล็กๆ ใดๆ ในฟิลด์ใดก็ได้บนเรกคอร์ด ก็ต้องผ่านกฎนี้ด้วย
• เฉพาะเรกคอร์ดใหม่ ด้วย ISNEW() กฎตรวจเรกคอร์ดครั้งเดียวตอนสร้าง และไม่ตรวจอีกเลย อดีตยังเป็นอย่างที่เคยเป็น แต่อนาคตก็เช่นกัน: การแก้ไขทีหลังอาจทำให้เรกคอร์ดใหม่ฝ่าฝืนกฎ และไม่มีใครหยุดมัน ถ้าเรื่องนั้นสำคัญ ให้ใช้คู่กับข้อถัดไป
• เฉพาะเมื่อฟิลด์ที่เกี่ยวข้องเปลี่ยน ด้วย ISCHANGED() การแก้หมายเลขโทรศัพท์จะไม่ปลุกกฎเรื่องเวลาจัดส่ง
• ไม่ใช้กับผู้เขียนบางราย custom permission ที่ตรวจในสูตรเป็น $Permission ทำให้ผู้ใช้การผสานรวมหรือการย้ายข้อมูลผ่านไปได้ ขณะที่คนยังต้องทำตามกฎ (How to Reference a Custom Permission in a Validation Rule (opens in a new tab) ภาษาอังกฤษ) ให้อย่างตั้งใจ และให้น้อยคน
• ตั้งแต่วันที่หนึ่งเป็นต้นไป โดยเปรียบเทียบ CreatedDate กับวันที่กฎเริ่มใช้งาน เมื่อ “ใหม่” หมายถึง “ตั้งแต่เราเริ่มบังคับใช้เรื่องนี้” ต่างจาก ISNEW() ตรงที่มันยังตรวจเรกคอร์ดเหล่านั้นในทุกการบันทึกครั้งต่อๆ ไป คำเตือนเดียวกันจึงใช้ได้: การเปลี่ยนแปลงเล็กน้อย เช่นการอัปเดตเจ้าของแบบ batch อาจล้มเหลวบนเรกคอร์ดที่เพี้ยนไปแล้ว

กำลังเพิ่มกฎให้เรกคอร์ดที่คุณมีอยู่แล้ว? คิดถึงผลกระทบให้ถี่ถ้วนก่อนเปิดใช้ ตอนนี้ทุกเรกคอร์ดที่มีอยู่ต้องผ่านกฎในการบันทึกครั้งถัดไป และการบันทึกนั้นอาจมาจากที่ที่คุณไม่คาดคิด: การผสานรวมทุกคืน การเปลี่ยนเจ้าของแบบ batch roll-up การอัปเดตจำนวนมากจาก list view ตัวไหนบ้างที่จะชนมัน และจะเกิดอะไรขึ้นกับงานนั้นเมื่อเรกคอร์ดหนึ่งล้มเหลว? หัวข้อก่อนที่คุณจะเปิดใช้ มีลำดับขั้นที่ผมใช้

อย่าเขียนประวัติศาสตร์ใหม่เพื่อเอาใจกฎ

แล้วเรกคอร์ดเก่าสองหมื่นรายการล่ะ? ถ้าข้อมูลผิดและคุณรู้ค่าที่ถูก ก็แก้มัน แต่ผมเคยเห็น “การแก้” อีกแบบ: ไม่มีใครรู้ความจริงในอดีต เขาแค่ต้องการให้เรกคอร์ดผ่าน จึงอัปเดตด้วยค่าที่ทำให้กฎวันนี้พอใจ ผมไม่ชอบแบบนั้น การอัปเดตเรกคอร์ดเก่าให้ผ่านกฎเปลี่ยน LastModifiedDate และทำลายข้อมูลประวัติสำคัญ และการแต่งค่าขึ้นมาก็หมายถึงการแกล้งทำว่าเรารู้บางอย่างเกี่ยวกับอดีตที่เราไม่รู้ ให้กฎมีทางเลี่ยงสำหรับเรกคอร์ดที่มีอยู่ก่อนกฎ แทนการเขียนประวัติศาสตร์ใหม่ มันอาจดูไม่สวย แต่ซื่อสัตย์

การตรวจสอบใน UI ไม่ใช่การตรวจสอบข้อมูล

ทำให้ฟิลด์จำเป็นบน page layout แล้วผู้ใช้จะบันทึกไม่ได้ถ้าไม่กรอก แล้วการผสานรวมตอนกลางคืนก็ insert 50,000 เรกคอร์ด มันใช้หน้าเพจของคุณไหม? ไม่ การโหลดข้อมูลจำนวนมาก ไคลเอนต์ API หรือเอเจนต์ก็ไม่ได้ใช้ ข้อกำหนดใน UI ปกป้องหน้าจอนั้น ไม่ใช่ข้อมูล การตรวจสอบฟิลด์บน dynamic forms ก็ถูกเลี่ยงได้แบบเดียวกัน ดังนั้นให้ถามว่า ข้อมูลนี้เข้ามาทางไหนได้บ้าง? Lightning พอร์ทัล มือถือ การผสานรวม API การโหลดข้อมูลจำนวนมาก Flow Apex เอเจนต์ ยิ่งมีประตูมาก ผมยิ่งไม่ไว้ใจกฎที่เฝ้าแค่ประตูเดียว

ขั้นที่สี่: กฎข้อมูลซ้ำ

ตอนนี้เราขยับจากความสอดคล้องภายในเรกคอร์ดไปสู่ความสอดคล้องข้ามเรกคอร์ด Acme Corporation, ACME Corp, Acme Inc.: ลูกค้าสี่รายหรือรายเดียว? ไม่มีกฎระดับฟิลด์ข้อไหนตอบได้ กฎการจับคู่ (matching rule) กำหนดว่าจะเปรียบเทียบเรกคอร์ดอย่างไร กฎข้อมูลซ้ำ (duplicate rule) ตัดสินว่าจะเกิดอะไรขึ้นเมื่อพบข้อมูลที่น่าจะซ้ำ: อนุญาตพร้อมคำเตือน บล็อก หรือรายงาน คุณมีกฎข้อมูลซ้ำที่ใช้งานได้สูงสุดห้ากฎต่อออบเจกต์ และกฎการจับคู่สูงสุดสามกฎในแต่ละกฎ และ match key จำกัดการเปรียบเทียบแต่ละครั้งไว้ที่ 100 เรกคอร์ดที่น่าจะซ้ำที่สุด (Things to Know About Duplicate Rules (opens in a new tab) ภาษาอังกฤษ)

ต้นทุนของมันคือแรงเสียดทาน ถ้าทุกบัญชีที่พนักงานขายสร้างขึ้นข้อความ Possible duplicate found บางครั้งนั่นคือสิ่งที่คุณต้องการพอดี และบางครั้งคนก็เรียนรู้ที่จะคลิกผ่านโดยไม่อ่าน เรกคอร์ดที่ถูกต้องอาจดูคล้ายกันได้ และการผสานรวมอาจต้องการพฤติกรรมที่ต่างจากคน และคำเตือนนั้นเป็นของ Salesforce เอง: การแจ้งเตือนและรายการข้อมูลที่อาจซ้ำของมันอาจไม่กลมกลืนกับหน้าจอที่กำหนดเองที่คุณสร้าง และเมื่อการบันทึกเป็นแบบ headless (ไม่มีหน้าจอ) เช่น การผสานรวม การโหลดข้อมูล เอเจนต์ ก็ไม่มีหน้าจอให้แสดงเลย ดังนั้นตัดสินว่าข้อมูลซ้ำจะปรากฏอย่างไรในทุกเส้นทาง: คำเตือนสำหรับคน การบล็อกการบันทึกพร้อมข้อผิดพลาดสำหรับ API หรือตัวเลือก Report และ duplicate record set ให้ใครสักคนตรวจทีหลัง สถาปัตยกรรมที่ดีไม่ใช่การบังคับใช้สูงสุด แต่คือการบังคับใช้ที่ถูกต้อง

และตรวจดูว่ากฎข้อมูลซ้ำเฝ้าประตูไหนบ้างจริงๆ (Things to Know About Duplicate Rules (opens in a new tab) ภาษาอังกฤษ) ผ่าน API และเครื่องมือนำเข้าข้อมูล ไม่มีใครเห็นคำเตือน: กฎที่ตั้งให้แจ้งเตือนจะบล็อกการบันทึกไปเลย บางเส้นทางข้ามกฎไปทั้งหมด: Quick Create ปุ่ม Undelete การผสานด้วยตนเอง เรกคอร์ดที่เพิ่มโดย Lightning Sync หรือ Einstein Activity Capture และเรกคอร์ดที่บันทึกในจังหวะเดียวกันจะไม่ถูกเปรียบเทียบกันเอง แต่เทียบกับเรกคอร์ดที่อยู่ใน Salesforce แล้วเท่านั้น โหลดไฟล์ที่มีลูกค้าคนเดียวกันสองครั้ง แล้วทั้งสองแถวอาจผ่านเข้ามาได้ กฎข้อมูลซ้ำเป็นตาข่ายที่ดี แต่มันไม่ใช่กุญแจล็อกประตู

ความรู้ที่ออกสอบ กฎข้อมูลซ้ำไม่เปรียบเทียบเรกคอร์ดที่บันทึกในจังหวะเดียวกันกันเอง เทียบกับเรกคอร์ดที่อยู่ใน Salesforce แล้วเท่านั้น ผ่าน API และเครื่องมือนำเข้าไม่มีการแจ้งเตือน: ข้อมูลซ้ำที่กฎจับได้จะไม่ถูกบันทึกเลย และการบันทึกกับทุกอย่างที่มันกระตุ้นจะทำงานเป็นธุรกรรมเดียว: ถ้าส่วนใดล้มเหลว ทั้งหมดจะย้อนกลับ

ขอบเขตข้อหนึ่ง กฎข้อมูลซ้ำรักษา org เดียวให้สะอาด มันไม่ได้แก้ปัญหาตัวตนระดับองค์กร ถ้า Salesforce มี Acme Corporation, ERP มี ACME-10382 และระบบเรียกเก็บเงินมีลูกค้าหมายเลข 77193 กฎข้อมูลซ้ำบอกคุณไม่ได้ว่านั่นคือบริษัทเดียวกัน นั่นคือข้อมูลหลัก บทที่ 6

ขั้นที่ห้า: ระบบอัตโนมัติ

กฎบางข้อซับซ้อนเกินกว่าขั้นล่างๆ: ต้องใช้เรกคอร์ดที่เกี่ยวข้อง ระบบอื่น เรกคอร์ดที่พึ่งพากัน กระบวนการหลายขั้นตอน นั่นคือ Flow, Apex บางครั้งก็ตรรกะการผสานรวม (ไม่ใช่ Workflow Rules หรือ Process Builder ซึ่งหมดการสนับสนุนแล้ว) ระบบอัตโนมัติทรงพลังและแพงกว่า: ชิ้นส่วนที่เคลื่อนไหวมากขึ้น การทดสอบมากขึ้น การจัดการข้อผิดพลาดมากขึ้น และหนทางมากขึ้นที่ระบบอัตโนมัติตัวหนึ่งจะไปสะดุดอีกตัว และโค้ดก็นำข้อผิดพลาดของตัวเองมาด้วย ถ้าประเภทฟิลด์บังคับใช้ได้ ผมไม่เขียน Apex ถ้ากฎการตรวจสอบความถูกต้องพูดได้ชัด ผมไม่สร้าง flow เพียงเพราะมี Flow ให้ใช้ อย่าแก้ปัญหาระดับฟิลด์ด้วยเครื่องยนต์กระบวนการ

ทั้งหมดหรือไม่มีเลย: เมื่อเรกคอร์ดเปลี่ยนไปด้วยกัน

จนถึงตอนนี้แต่ละขั้นปกป้องการบันทึกหนึ่งครั้ง แต่เรกคอร์ดเปลี่ยนไปด้วยกัน: การจัดส่งกับรายการของมัน คำสั่งซื้อกับบรรทัดของมัน flow ที่อัปเดตสามออบเจกต์ ตรงนี้แพลตฟอร์มให้การรับประกันที่แข็งแรง การบันทึกและทุกอย่างที่มันกระตุ้น ทั้ง trigger, flow และคลาสที่มันเรียก ทำงานเป็นธุรกรรมเดียว: ถ้าส่วนใดล้มเหลว ทั้งหมดจะถูกย้อนกลับและไม่มีอะไรถูก commit (Apex Transactions (opens in a new tab) ภาษาอังกฤษ) คุณจะไม่ได้การจัดส่งครึ่งเดียว

งานแบบ bulk คือข้อยกเว้นที่คุณเลือกเอง การโหลดข้อมูลหรือเมธอด Database ของ Apex อนุญาตให้สำเร็จบางส่วนได้: เรกคอร์ดที่ดีถูกบันทึก ที่เสียกลับมาพร้อมข้อผิดพลาด และต้องมีใครสักคนจัดการมัน (DML Statements vs. Database Class Methods (opens in a new tab) ภาษาอังกฤษ) นั่นมักถูกต้องสำหรับการโหลดหนึ่งล้านแถว แต่เมื่อนั้นความสอดคล้องก็เป็นกระบวนการ: ใครอ่านไฟล์ข้อผิดพลาด และจะเกิดอะไรขึ้นกับเรกคอร์ดที่ล้มเหลว?

แล้วก็มีเรื่องจังหวะเวลา การบันทึกสองครั้งในจังหวะเดียวกันอาจผ่านการตรวจที่แต่ละครั้งจะไม่ผ่านถ้าอยู่ลำพัง flow ที่หาคำสั่งซื้อที่มีอยู่แล้วจึงสร้างใหม่อาจปล่อยให้สองรายการผ่านไป และเราเพิ่งเห็นว่ากฎข้อมูลซ้ำไม่เปรียบเทียบเรกคอร์ดที่บันทึกในเวลาเดียวกัน ฟิลด์ที่ทำเครื่องหมาย Unique หรือ External ID ถูกแพลตฟอร์มตรวจในทุกการบันทึก จึงมีแค่หนึ่งรายการที่ชนะ นั่นเป็นอีกเหตุผลที่ควรดันความไม่ซ้ำลงไปที่ฟิลด์ การล็อก การแย่งชิงทรัพยากร และการลองใหม่เป็นเรื่องใหญ่ของมันเอง บทที่ 11 ธุรกรรม การทำงานพร้อมกัน และความน่าเชื่อถือ ลงลึกเรื่องนี้

ดันกฎลงไป จนกว่ามันจะไม่ควรอยู่ตรงนั้น

“ต่ำที่สุดเท่าที่สมเหตุสมผล” ไม่ได้แปลว่า “ต่ำที่สุดเสมอ” ถ้าฟิลด์จำเป็นเฉพาะเมื่อโอกาสทางการขายถึงขั้นหนึ่ง การทำให้มันจำเป็นในสคีมาก็ผิด กฎนั้นมีเงื่อนไข ดังนั้นกฎการตรวจสอบความถูกต้องคือขั้นที่ถูก ถ้าข้อมูลซ้ำควรเตือนคน แต่การผสานรวมที่อนุมัติแล้วมีการกระทบยอดของตัวเอง ก็ออกแบบสำหรับทั้งสองทาง เป้าหมาย: ชั้นที่ต่ำที่สุดที่แสดงกฎทางธุรกิจได้อย่างถูกต้อง

ทุกชั้นมีต้นทุน

Click to enlarge

นี่คือการแลกเปลี่ยนได้เสียที่ผมอยากให้คุณเห็น ประเภทฟิลด์และค่าที่ควบคุมเรียบง่ายและแข็งแรง แต่เฉพาะกับสิ่งที่ฟิลด์แสดงได้ Required และ Unique ทื่อ: เมื่อเปิดแล้ว การเขียนทุกครั้งต้องผ่าน กฎการตรวจสอบความถูกต้องแสดงเงื่อนไขที่ซับซ้อนกว่าได้ แต่อาจบล็อกการแก้ไขเรกคอร์ดเก่าและทำให้ deploy สะดุด กฎข้อมูลซ้ำปกป้องข้ามเรกคอร์ด แต่เพิ่มแรงเสียดทานให้ผู้ใช้และการผสานรวม ระบบอัตโนมัติจัดการได้ทุกอย่าง แต่ทำให้คุณต้องรับผิดชอบการประสานงาน ข้อผิดพลาด การทดสอบ และประสิทธิภาพ ไม่มีชั้นไหนฟรี เลือกชั้นของแต่ละกฎโดยรู้ว่ามันล้มเหลวอย่างไร

ก่อนที่คุณจะเปิดใช้

การเพิ่มกฎให้ org ที่มีอยู่คือการทยอยใช้งาน ไม่ใช่การติ๊กช่อง วันนี้มีกี่เรกคอร์ดที่ฝ่าฝืน และเพราะอะไร? มันผิดจริงไหม? เรารู้ค่าที่ถูกได้ไหม? กฎนี้เป็นจริงในอดีต หรือแค่จากนี้ไป? การผสานรวม เทสต์ และระบบอัตโนมัติตัวไหนจะชนมัน? ลำดับที่ดี: วัด ทำความสะอาดสิ่งที่พิสูจน์ได้ว่าผิด กำหนดขอบเขตกฎ เพิ่มทางเลี่ยงที่ตั้งใจสำหรับประวัติที่ถูกต้อง ทดสอบทุกเส้นทางการเขียน แล้วจึงบังคับใช้ การวัดและการทำความสะอาดเป็นศาสตร์ของมันเอง ทั้งการทำโปรไฟล์ข้อมูล การทำให้เป็นมาตรฐาน การเฝ้าระวัง และการดูแลข้อมูล และบทที่ 5 คุณภาพและธรรมาภิบาลข้อมูล ครอบคลุมเรื่องเหล่านี้ ดีกว่าการติ๊กช่องวันศุกร์แล้วไปเจอผลที่ตามมาคืนวันเสาร์มาก

นอกเหนือจากการสอบ: AI เปลี่ยนอะไร เอเจนต์สร้างเรกคอร์ดได้เร็วกว่าคนไหนๆ และสร้างเรกคอร์ดที่แย่ได้เร็วพอกัน “ผู้ใช้รู้ว่าไม่ควรทำแบบนั้น” ไม่ใช่การป้องกันเมื่อผู้ใช้คือเอเจนต์ วางกฎสำคัญไว้ในชั้นข้อมูล ที่ซึ่งผู้เขียนทุกรายต้องผ่าน เพื่อที่เอเจนต์จะไม่ต้องจำกฎที่ไม่ได้เขียนไว้ของบริษัท

Steve Trucking: ปกป้องการจัดส่ง

ลองดูการจัดส่งหนึ่งรายการ สถานะของมันมาจากคำศัพท์ชุดเดียว: picklist แบบจำกัดค่า หมายเลขอ้างอิงคำสั่งซื้อของพันธมิตรค้าปลีกต้องไม่ซ้ำต่อพันธมิตร จึงเป็น External ID ที่ทำเครื่องหมายว่าไม่ซ้ำ ใช้ upsert ใบรายการสินค้า เวลาจัดส่งจริงจำเป็นเมื่อสถานะเป็น Delivered: กฎการตรวจสอบความถูกต้อง จำกัดขอบเขตไว้ที่การเปลี่ยนแปลงนั้น จุดแวะติดตั้งปิดไม่ได้จนกว่าเช็กลิสต์จะครบและถ่ายรูปที่กำหนดแล้ว (สำหรับเครื่องล้างจาน: ท่อน้ำเข้า ท่อน้ำทิ้ง และระดับ): กฎการตรวจสอบความถูกต้อง หรือระบบอัตโนมัติถ้าต้องตรวจรูปที่เก็บไว้นอกแพลตฟอร์ม คำสั่งซื้อเดียวกันที่มาสองครั้งจากใบรายการสินค้าที่ส่งซ้ำจะถูก External ID จับได้ ส่วนคำสั่งซื้อสองรายการที่ต่างกันแต่ดูคล้ายกันเป็นคำถามเรื่องการจับคู่

สังเกตว่าผมไม่ได้พูดว่า “ใส่ทั้งหมดไว้ใน flow” แต่ละกฎอยู่บนขั้นของตัวเอง สำหรับทุกกฎ ให้ถามว่า ชั้นที่ต่ำที่สุดที่บังคับใช้สิ่งนี้ได้อย่างถูกต้องสำหรับทุกเส้นทางการเขียนที่สำคัญคืออะไร?

สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้

• แต่ละกฎอยู่บนขั้นไหน: ประเภทฟิลด์ คำศัพท์ที่ควบคุม required หรือ unique กฎการตรวจสอบความถูกต้อง กฎข้อมูลซ้ำ หรือระบบอัตโนมัติ
• เส้นทางการเขียนไหนบ้างที่ต้องปกป้อง: UI พอร์ทัล มือถือ การผสานรวม การโหลดข้อมูลจำนวนมาก API ระบบอัตโนมัติ และเอเจนต์
• กฎใหม่มีผลกับเรกคอร์ดในอดีต หรือจำกัดไว้ที่ข้อมูลใหม่และที่เปลี่ยนแปลง พร้อมทางเลี่ยงสำหรับอดีต
• ข้อมูลไม่ดีที่มีอยู่แก้ได้จากหลักฐานหรือไม่ แทนที่จะเขียนใหม่ให้ผ่าน
• กฎหนึ่งข้อคุ้มกับแรงเสียดทาน ความซับซ้อน และการบำรุงรักษาแค่ไหน

ข้อมูลที่สะอาดไม่ได้มาจากการขอให้คนกรอกข้อมูลดีๆ มันมาจากสถาปัตยกรรมที่ทำให้สิ่งที่ถูกทำง่าย สิ่งที่ผิดทำยาก และกฎสำคัญเลี่ยงได้ยาก ถัดไป เราประกอบบทนี้เข้าด้วยกันบนส่วนหนึ่งของ Steve Trucking

ศึกษาเพิ่มเติม

• Salesforce Help, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) และ Roll-Up Summary Field (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-13)
• Salesforce Help, Picklist Limitations (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02)
• Salesforce Help, Validation Rule Considerations (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02)
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-13): ขีดจำกัด เส้นทางที่กฎไม่ทำงาน การบันทึกผ่าน API และการนำเข้าที่ถูกบล็อกโดยไม่มีการแจ้งเตือน การบันทึกพร้อมกันที่ไม่ถูกเปรียบเทียบ
• Apex Developer Guide, Apex Transactions (opens in a new tab) และ DML Statements vs. Database Class Methods (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-13): ธุรกรรมเดียวย้อนกลับเป็นหน่วยเดียว เมธอด Database อนุญาตให้สำเร็จบางส่วนได้
• Salesforce Help, Workflow Rules & Process Builder End of Support (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02)