Steve Trucking ผมจะออกแบบอย่างไร

🌐 มีให้อ่านอีก 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 ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

โมดูลที่ 6 จาก 6 ในบท ข้อมูลหลักและตัวตน บทที่ 6 ของหลักสูตร Data Architect และเป็นจุดจบของส่วนที่ 1 ก่อนหน้า: เมื่ออำนาจชี้ขาดถูกแบ่งกัน · ถัดไป: ส่วนที่ 2 เริ่มด้วย การออกแบบเพื่อรองรับขนาด (coming soon)

คำถามที่จุดตรวจสอบนี้ตอบ: คุณประกอบส่วนที่ 1 เข้าด้วยกันบนสถานการณ์จริงได้ไหม?

ลองทำโจทย์ก่อน นี่คือคำเฉลยแบบทีละขั้นของผมสำหรับโจทย์ท้าทายของจุดตรวจสอบที่ 1 ถ้าคุณยังไม่ได้วาดการออกแบบของคุณเอง ให้ทำก่อนอ่านต่อ คุณค่าอยู่ที่การเปรียบเทียบเหตุผลของคุณกับของผม ไม่ใช่การอ่านคำตอบ

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

เริ่มจากตัวเลข

จากบรีฟ: การจัดส่งราว 3,300 ครั้งต่อวันทำการ หนึ่งล้านครั้งต่อปี เติบโต 30% ต่อปี ราว 1.6 รายการต่อการจัดส่ง (1.6 ล้านต่อปี) ราวแปดการเปลี่ยนสถานะต่อการจัดส่ง (8 ล้านต่อปี) รูปถ่ายสี่ถึงห้าล้านรูปต่อปี ค่า GPS ราว 200,000 ค่าต่อวัน เคสราว 180,000 เคสต่อปี พันธมิตรค้าปลีกสามรายส่งใบรายการสินค้าสามวิธี ศูนย์กระจายสินค้าเก้าแห่ง รถบรรทุก 330 คันกับทีมจัดส่งสองคน และ Steve Trucking ใช้ org ของ Salesforce หนึ่งตัวที่มี Service Cloud, Field Service และพอร์ทัลพันธมิตรอยู่แล้ว นับเลขศูนย์ก่อนวาดกล่องแรก มันจะตัดสินหลายเรื่องด้านล่าง

แกนของการจัดส่ง: มองไปที่ยานแม่

การจัดส่งคือหัวใจ และ Field Service ทำหน้าที่จัดส่งอยู่แล้ว ผมจึงเริ่มจากโมเดลมาตรฐานของ Field Service อย่างที่ส่วนตัวอย่างของบทที่ 3 ทำ:

แนวคิดทางธุรกิจ	ออบเจกต์ของ Salesforce	ทำไม
พันธมิตรค้าปลีก	Account (ประเภทเรกคอร์ด Retail Partner)	ธุรกิจที่ Steve Trucking ทำสัญญาด้วย มีสัญญา เคส และการเข้าถึงพอร์ทัล
พนักงานของพันธมิตร (ผู้จัดการ DC พนักงานร้าน)	Contact	ผู้ใช้พอร์ทัลต้องเป็นผู้ติดต่อ
การจัดส่งหนึ่งครั้ง: ผู้รับหนึ่งคน ที่อยู่หนึ่งแห่ง คำสั่งซื้อของพันธมิตรหนึ่งรายการ วันเดียว	Work Order	หน่วยงานของ Field Service การจัดตาราง แอปมือถือ และรายงานบริการผูกอยู่กับมัน
แต่ละสินค้าหรือบริการ: ตู้เย็น การติดตั้ง การขนของเก่าออก	Work Order Line Item	แบ่งงาน ขับเคลื่อนเช็กลิสต์และการออกใบแจ้งหนี้
ประเภทของจุดแวะ: จัดส่งอย่างเดียว พร้อมติดตั้ง พร้อมขนของเก่าออก	Work Type	กำหนดระยะเวลา ทักษะ และเช็กลิสต์การติดตั้ง
การเข้าเยี่ยมที่นัดไว้และช่วงเวลาของมัน	Service Appointment	สิ่งที่ Field Service จัดตารางและแอปของทีมแสดง
ทีมจัดส่งและรถบรรทุก พื้นที่จัดส่งของ DC	Service Resource, Service Crew, Service Territory	Field Service จัดตารางทีมเป็นทรัพยากรเดียว
คำถามของผู้รับ การเคลมของพันธมิตร	Case	คอนโซลบริการ entitlement, email-to-case
รายการของพันธมิตรสำหรับวันอังคารที่ DC ฟีนิกซ์	Manifest__c (กำหนดเอง)	ไม่มีอะไรมาตรฐานที่แทนหน่วยของการรับ การกระทบยอด และการเล่นซ้ำ

ทุกอย่างที่เหลือเป็นมาตรฐาน การต้านทานออบเจกต์ที่กำหนดเองเพิ่มเติมเป็นความตั้งใจ: คำถามของบทที่ 1 คือเมื่อไรสถาปนิกควรต้านทานออบเจกต์อีกตัว และตรงนี้คำตอบคือ “แทบทุกครั้ง” ตัวอย่างเช่น บรรทัดคำสั่งซื้อของพันธมิตรไม่ใช่ออบเจกต์ใหม่ มันคือ Work Order ที่ระบุด้วยหมายเลขอ้างอิงของพันธมิตร

Click to enlarge

มันเติบโตมาจากบทสรุปของบทที่ 3 (ออกแบบโมเดลเชิงกายภาพของ Salesforce): ออบเจกต์เดิมในตำแหน่งเดิม โดยเพิ่มทีมจัดส่ง พื้นที่จัดส่ง เคส และสิ่งที่จุดตรวจสอบที่ 1 เก็บไว้นอก core

คีย์ที่จับคู่คำสั่งซื้อของพันธมิตรกับการจัดส่ง

แต่ละบรรทัดในใบรายการสินค้ากลายเป็น Work Order หนึ่งรายการ ลิงก์กับ Manifest ของมัน คีย์คือคำถามที่ผมอยากได้คำตอบมากที่สุด: เรารู้ได้อย่างไรว่าบรรทัดนี้จากพันธมิตรคือการจัดส่งนั้น? คำตอบของผม: External ID บน Work Order ที่สร้างจากพันธมิตรค้าปลีกกับหมายเลขอ้างอิงคำสั่งซื้อและการจัดส่งของพันธมิตรเอง (ประมาณ KEYSTONE-PHX-8843119-1) ทำเครื่องหมายว่าไม่ซ้ำ หนึ่งฟิลด์ต่อแหล่งที่มา หนึ่งต่อหนึ่ง มันเป็นตัวระบุของพันธมิตร ไม่ใช่ของเรา: “หลายตัวระบุสำหรับสิ่งเดียว” ของบทที่ 2 และ “พันธมิตรเป็นเจ้าของหมายเลขอ้างอิงคำสั่งซื้อของตัวเอง” ของโมดูลที่ 1

ทำไมมันสำคัญ: ใบรายการสินค้ามาถึงล่วงหน้าหนึ่งถึงสองวัน และถูกแก้ไขในวันนั้น ด้วยคีย์นั้น ใบรายการสินค้าทุกฉบับที่ส่งซ้ำหรือแก้ไขจะ upsert แทนการสร้างซ้ำ การแก้ไขอัปเดต Work Order ฟิลด์หนึ่งบันทึกมันไว้ และการเปลี่ยนแปลงกับการจัดส่งที่วางเส้นทางแล้วจะแจ้งเตือนผู้ประสานงาน: การเปลี่ยนแปลงของพันธมิตรถูกนำไปใช้ แต่ถูกทำเครื่องหมายไว้จนกว่าฝ่ายจัดส่งจะยืนยัน นี่ยังเป็นสิ่งที่เปลี่ยนไปจากภาพของบทที่ 4 ด้วย วันนี้ใบรายการสินค้าทุกใบลงที่ RouteDesk และผู้ประสานงานคีย์เส้นทางซ้ำเข้า Salesforce และคีย์จุดแวะที่เสร็จแล้วกลับ ในการออกแบบนี้ ใบรายการสินค้าเข้ามาที่ Salesforce โดยตรง upsert ด้วยคีย์ของพันธมิตร RouteDesk ถูกปลดระวาง และการคีย์ซ้ำก็สิ้นสุดลง บทการผสานรวมออกแบบรูปแบบขาเข้าทั้งสาม การตัดสินใจด้านข้อมูลคือคีย์

ผู้รับ: บัญชีบุคคล ผู้ติดต่อ หรือไม่ใช่ทั้งสอง?

นี่คือการตัดสินใจด้านข้อมูลที่น่าสนใจที่สุดในส่วนที่ 1 ดังนั้นนี่คือทางเลือก แล้วตามด้วยการเลือกของผม

ทางเลือก A: บัญชีบุคคล ผู้รับแต่ละคนกลายเป็นบัญชีบุคคล ลิงก์กับทุกการจัดส่ง ข้อดี: เป็นมาตรฐาน ทำงานได้เป็นธรรมชาติกับ Service Cloud การส่งข้อความ และคอนโซล จำผู้รับที่กลับมาซ้ำได้ ข้อเสีย: ผู้รับใหม่ราวหนึ่งล้านคนต่อปี แต่ละคนเป็นบัญชีบุคคลที่ใช้พื้นที่จัดเก็บราวสองเท่าของบัญชีธุรกิจ (Estimated Record Size by Object Type (opens in a new tab) ภาษาอังกฤษ) ภายในสองปีจึงกลายเป็นหนึ่งในออบเจกต์ที่ใหญ่ที่สุดใน org และผู้รับไม่ใช่ลูกค้าของ Steve Trucking พวกเขาเป็นลูกค้าของพันธมิตรค้าปลีกแต่ละราย และ Steve Trucking ต้องไม่รวมลูกค้าของพันธมิตรรายหนึ่งเข้ากับของอีกรายเด็ดขาด (S2)

ทางเลือก B: ผู้ติดต่อใต้บัญชีของพันธมิตรค้าปลีก ข้อเสีย: ผู้ติดต่อหนึ่งล้านรายใต้สามหรือสี่บัญชีคือ parent-child skew ในระดับมหาศาล เกินแนวทางของ Salesforce ที่ราว 10,000 ลูกต่อแม่ไปไกลมาก (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab) ภาษาอังกฤษ) นี่คือทางเลือกที่ควรแสดง แล้วปฏิเสธ

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

นั่นคือความสมดุลที่ต้องหาให้เจอ จะมีวันที่ต้องจำได้ว่าการจัดส่งหลายครั้งเป็นของคนคนเดียวกัน ที่ที่เดียวกันไหม? ต้องให้คนคนนั้นล็อกอินได้ไหม? นั่นคือเส้นแบ่งระหว่างผู้รับที่ต้องมีเรกคอร์ดของตัวเอง กับรายละเอียดผู้รับที่เป็นแค่ข้อมูลเกี่ยวกับการจัดส่ง และมีทางสายกลางด้วย เก็บ ID ลูกค้าของพันธมิตรค้าปลีกเองไว้เป็นฟิลด์บนการจัดส่ง คือ Retail Partner Customer ID (ID ลูกค้าของพันธมิตรค้าปลีก) มันไม่ได้สร้างเรกคอร์ดผู้รับ แต่มันผูกการจัดส่งที่พันธมิตรส่งมาสำหรับลูกค้ารายเดียวกันเข้าด้วยกัน ซึ่งเป็นจุดเริ่มของประสบการณ์ลูกค้าที่เป็นหนึ่งเดียวมากขึ้น และมันพากลับไปยังระบบของพันธมิตรค้าปลีกโดยตรง ซึ่งเป็นที่ที่ลูกค้ารายนั้นอยู่จริงๆ มันคือตัวระบุของพวกเขา จึงมีความหมายก็ต่อเมื่อใช้คู่กับพันธมิตรเท่านั้น: ลูกค้าหมายเลข 4417 ของพันธมิตรรายหนึ่งไม่เกี่ยวอะไรกับของอีกราย

ในความเห็นทางวิชาชีพของผม ทางเลือก C คือทางเลือกที่ถูก ส่วนที่จำไม่ได้นั้นยอมรับได้ หรือแม้แต่น่าพึงปรารถนา: Steve Trucking ไม่มีความสัมพันธ์กับคนเหล่านี้นอกเหนือจากการจัดส่ง มันคือโมดูลที่ 1 อีกครั้ง: ผู้รับเป็นลูกค้าของพันธมิตร และพันธมิตรเป็นผู้มีอำนาจชี้ขาดว่าพวกเขาคือใคร และมันคือบทที่ 5: ข้อมูลส่วนบุคคลที่ไปอยู่ในที่เดียว ผูกกับการจัดส่งเดียว ปกป้อง เก็บรักษา และลบได้ง่ายกว่ามาก และมันยังผ่านรูปแบบบรรทัดฐานของบทที่ 2: รายละเอียดของผู้รับเป็นหนึ่งต่อหนึ่งกับการจัดส่ง จึงควรอยู่บนการจัดส่ง ออบเจกต์ลูกของผู้รับแยกต่างหากจะประหยัดค่าที่ซ้ำกันได้นิดหน่อย แลกกับออบเจกต์อีกตัว ความสัมพันธ์อีกเส้น และภาระของมัน และทางเดียวที่มันจะประหยัดได้มากกว่านั้นคือการถือว่าคนคนเดียวกันเป็นหนึ่งเดียวข้ามพันธมิตรค้าปลีก ซึ่งเราจะไม่ทำ ดังนั้นการจัดส่งจึงถือข้อมูลผู้รับไว้ โดยมี Retail Partner Customer ID เป็นทางกลับไปยังระบบของพันธมิตรเอง

Click to enlarge

ผมจะรวมผู้รับข้ามพันธมิตรไหม?

John Smith, 123 Main Street ปรากฏในใบรายการสินค้าของ Redrock และของ Brightwave น่าจะเป็นคนเดียวกัน Steve Trucking ควรรวมพวกเขาไหม? ไม่ และตั้งใจไม่รวม การรวมผู้รับข้ามพันธมิตรค้าปลีกจะละเมิด S2: พันธมิตรต้องไม่เห็นผู้รับของพันธมิตรรายอื่นเด็ดขาด และตัวตนรวมคือสะพานที่ทำให้ข้อมูลรั่วพอดี นี่คือจุดยืนของบทนี้ที่นำมาใช้: จับคู่น้อยไว้ในที่ที่การรวมผิดมีราคาแพง และตรงนี้การรวมผิดแพงมาก

ถ้าภายหลังพันธมิตรค้าปลีกรายหนึ่งต้องการให้จำผู้รับที่กลับมาซ้ำได้ภายในการจัดส่งของตัวเอง นั่นเป็นงานของเครื่องมือ identity resolution เช่นของ Data 360 ที่จำกัดขอบเขตไว้ที่พันธมิตรรายนั้น: แผนที่แบบ registry ไม่ใช่บัญชีบุคคล และไม่ข้ามพันธมิตรเด็ดขาด แผนที่ว่าใครคือใครไม่ได้ให้ความเป็นเจ้าของ และไม่ได้ให้การเข้าถึง

อะไรอยู่ใน org และอะไรไม่อยู่

บทที่ 3 ถามว่าข้อมูลควรอยู่ที่ไหน เลขศูนย์ตอบตรงนี้:

• สถานะปัจจุบันอยู่บน Service Appointment และ Work Order ประวัติการเปลี่ยนสถานะ ราว 8 ล้านต่อปีและเพิ่มขึ้น ไม่จำเป็นต้องอยู่ใน org หลัก การเปลี่ยนแปลงแต่ละครั้งถูกเผยแพร่เป็นเหตุการณ์และเก็บในคลังข้อมูล คือ Snowflake org เก็บสถานะปัจจุบัน ประวัติยังอยู่ให้งานบริการ ปฏิบัติการ และการวิเคราะห์ใช้ แค่ไม่ได้อยู่ในฐานข้อมูลเชิงปฏิบัติการ
• รูปถ่าย (สี่ถึงห้าล้านรูปต่อปี บางรูปเห็นคนหรือภายในบ้าน) อยู่นอก core ในพื้นที่จัดเก็บที่สร้างมาสำหรับปริมาณนั้น อัปโหลดตรงจากแอปของทีม org เก็บแค่สิ่งที่ต้องใช้: เรกคอร์ดดัชนีเล็กๆ ต่อรูป หรือแค่จำนวนกับแฟล็ก “รูปติดตั้งที่กำหนดครบแล้ว” ผมชอบทางเลือกที่เบากว่า: รักษา org ให้เบา และให้ที่เก็บรูปเป็นเจ้าของดัชนีและการเก็บรักษาของมันเอง
• ค่า GPS (200,000 ต่อวัน) อยู่ใน FleetLink และไปยัง Snowflake org ต้องการแค่ตำแหน่งล่าสุดสำหรับหน้าติดตามและแผนที่ของผู้จัดการเดินรถ
• ประวัติแปดปีของ RouteDesk (ราว 5 ล้านการจัดส่ง) ไปยังคลังข้อมูลหรือที่เก็บถาวร เข้าถึงได้สำหรับการเคลม อะไรบ้าง ถ้ามี ที่จะเข้ามาใน org เป็นการตัดสินใจเรื่องการย้ายข้อมูลสำหรับส่วนที่ 2

Click to enlarge

จุดตรวจสอบที่ 1: สิ่งที่ผมจะออกแบบ ตำแหน่งเดียวกับภาพรวมระบบของบทที่ 4 (ภาพรวมระบบของ Steve Trucking) โดยการคีย์ซ้ำและสเปรดชีตหายไป

ใครเห็นอะไร และใครต้องมีไลเซนส์

• พันธมิตรค้าปลีกเห็นเฉพาะการจัดส่งของตัวเอง (S2) Work Order ทุกรายการมีพันธมิตรค้าปลีกของมัน ผู้ใช้พอร์ทัลเห็นการจัดส่งของพันธมิตรตัวเอง และผู้จัดการ DC เห็นเฉพาะของ DC ตัวเอง
• ผู้ใช้ของพันธมิตรต้องมีไลเซนส์พอร์ทัลที่รองรับกฎการแชร์และบทบาท: Customer Community Plus หรือ Partner Community ที่นั่งในสนามกีฬาของบทที่ 3: ที่นั่งราคาถูกที่สุดไม่ได้การแชร์ที่การออกแบบนี้ต้องการ ไลเซนส์ทั้งสองแบบต้องมีบทบาทสำหรับผู้ใช้ภายนอก และ Salesforce เตือนว่าบทบาทที่มากขึ้นทำให้ org ช้าลง (Experience Cloud User Licenses (opens in a new tab) ภาษาอังกฤษ) บทบาทหนึ่งบทบาทต่อพันธมิตรและต่อ DC ก็ใช้ได้ บทบาทสำหรับทุกร้านค้านั้นไม่ได้

ความรู้ที่ออกสอบ รู้ว่าไลเซนส์ภายนอกแบบไหนมาพร้อมการแชร์มาตรฐาน: Customer Community Plus และ Partner Community (พร้อมบทบาทสำหรับผู้ใช้ภายนอก) ไม่ใช่ Customer Community ซึ่งใช้ sharing set

• ผู้รับไม่ต้องมีไลเซนส์ หน้าติดตามแสดงการจัดส่งเดียวผ่านลิงก์ที่มีโทเคนซึ่งหมดอายุ (S3) ไม่ใช่การล็อกอิน
• ระวัง skew Work Order หลายแสนรายการต่อปีที่ชี้ไปที่บัญชีพันธมิตรสามหรือสี่บัญชีคือ account data skew ทางเลือกหนึ่งคือบัญชีลูกสำหรับแต่ละ DC ใต้พันธมิตรแต่ละราย ซึ่งกระจายลูกออกไปเก้าทางหรือมากกว่า การเก็บถาวรการจัดส่งที่เสร็จแล้วหลังช่วงเวลาเคลมทำให้ลูกที่ใช้งานอยู่ต่อแม่มีจำนวนต่ำ ส่วนที่ 2 รับเรื่องนั้น

สิ่งที่ผมจะไม่ทำ

ผมจะไม่สร้างบัญชีบุคคลสำหรับผู้รับทุกคนเพียงเพราะผู้รับเป็นบุคคล ผมจะไม่แขวนผู้ติดต่อหนึ่งล้านรายไว้ใต้สามบัญชี ผมจะไม่สร้างออบเจกต์ Delivery ที่กำหนดเองไว้ข้าง Work Order ของ Field Service ผมจะไม่รวมผู้รับข้ามพันธมิตร ผมจะไม่ใส่รูปถ่ายหรือค่า GPS หลายล้านรายการไว้ในพื้นที่จัดเก็บหลัก และผมจะไม่เรียกผู้รับที่รวมแล้วว่า golden record เว้นแต่เราได้ตัดสินใจเรื่องการจัดการข้อมูลหลักจริงๆ

สิ่งที่ยังเปิดอยู่

ส่วนที่ 1 วางโครงกระดูก ส่วนที่ 2 ทดสอบมัน ไม้บรรทัด LDV ในปีที่สาม (Work Order, Service Appointment และรายการล้วนเข้าเขตปริมาณมากภายในสองถึงสามปี) การออกแบบ query สำหรับ list view ที่จำกัดตามพันธมิตร การผสานรวมขาเข้าสามเส้นและฟีดสถานะสามเส้น การย้ายข้อมูลจาก RouteDesk ธุรกรรมในวันนั้น และการออกแบบความปลอดภัยเบื้องหลังพอร์ทัล Steve Trucking ก็จะเปลี่ยนด้วย เก็บการออกแบบนี้ไว้ คุณจะกลับมาดูมันอีก

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

• ออบเจกต์มาตรฐานใดรองรับแกน (ตรงนี้คือของ Field Service) และออบเจกต์ที่กำหนดเองใดสมเหตุสมผลจริงๆ (ตรงนี้คือหนึ่งตัว)
• คีย์ที่จับคู่บรรทัดคำสั่งซื้อของพันธมิตรแต่ละรายกับการจัดส่ง และทำไมมันเป็นของพันธมิตร
• ผู้รับคืออะไร ตามความสัมพันธ์ที่ Steve Trucking มีกับพวกเขาจริงๆ
• จะรวมตัวตนหรือไม่ และที่ไหนที่การรวมผิดมีราคาแพงเกินกว่าจะเสี่ยง
• อะไรอยู่ใน org อะไรอยู่นอก core และการออกแบบพึ่งพาไลเซนส์ใด

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

• บรีฟและโจทย์ท้าทายของ Steve Trucking (D1, D3, DC1)
• Salesforce Help, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab) Considerations for Object Relationships (opens in a new tab) และ Experience Cloud User Licenses (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (ภาษาอังกฤษ) ตามที่อ้างไว้ในบทที่ 3