เลือกออบเจกต์ให้ถูก

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

โมดูลที่ 5 จาก 10 ในบท สถาปัตยกรรมข้อมูล Salesforce บทที่ 3 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: ข้อมูลนี้อยู่ที่ไหน? · ถัดไป: ฟิลด์ก็คือสถาปัตยกรรม

คำถามที่โมดูลนี้ตอบ: แนวคิดทางธุรกิจนี้ควรกลายเป็นออบเจกต์ Salesforce แบบไหน และสิทธิ์การใช้งานอนุญาตอะไรบ้าง?

หนึ่งในสิ่งที่ทำได้ง่ายที่สุดใน Salesforce คือการสร้างออบเจกต์ที่กำหนดเอง และนั่นคือเหตุผลที่ผมคิดว่าเราสร้างมันมากเกินไป

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

นี่คือจุดที่โมเดลเชิงตรรกะจากบทที่ 2 พบกับแพลตฟอร์ม และจุดยืนเริ่มต้นของผมเรียบง่าย: ถ้าแนวคิดทางธุรกิจเข้ากับจุดประสงค์ที่ตั้งใจไว้ของออบเจกต์มาตรฐานอย่างพอดี ให้เริ่มจากตรงนั้น

เริ่มจากความหมาย

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

นั่นคือเหตุผลที่เรามองไปที่ยานแม่ก่อนใน โมดูลที่ 2 โมเดลเหล่านั้นไม่ได้เข้ากับทุกธุรกิจ แต่เราไม่ควรมองข้ามมันเพียงเพราะการสร้างเองรู้สึกสะอาดกว่า ก่อนกด New Custom Object ให้ถามว่า Salesforce สร้างโมเดลแนวคิดนี้อย่างไร อะไรถูกสร้างรอบโมเดลนั้นแล้ว และคุณต้องสละอะไรถ้าแทนที่มัน

บททดสอบความเข้ากันอย่างพอดี

บททดสอบของผมคือคำถามข้อเดียว: แนวคิดทางธุรกิจนี้เข้ากับจุดประสงค์ที่ตั้งใจไว้ของออบเจกต์มาตรฐานอย่างพอดีหรือไม่? ถ้าใช่ ผมเอนไปทางออบเจกต์มาตรฐาน

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

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

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

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

ดังนั้นมันคือการชั่งน้ำหนัก: น้ำหนักที่คุณแบกรับ เทียบกับคุณค่าที่คุณได้ ถ้าสิ่งที่ผมต้องการคือที่อยู่ที่มีวงจรชีวิตของตัวเอง นั่นคือจุดที่ผมเลือกแบบกำหนดเอง

เรื่องย่อยใต้เคสก็เหมือนกัน ถ้าแต่ละเรื่องย่อยเป็นเคสจริงๆ มีเอเจนต์ทำงานกับมัน มีสถานะและระดับบริการของตัวเอง ก็ซ้อนมันด้วย Parent Case จากโมดูลที่ 2 แต่ถ้ามันเป็นแค่รายการในเช็กลิสต์ที่ไม่มีใครทำงานกับมันในฐานะเคส เคสเต็มรูปแบบจะแบกสิ่งที่มันไม่มีวันใช้ไว้มากมาย และออบเจกต์ลูกที่กำหนดเองแบบง่ายๆ อาจเบากว่า ไม่ใช่เพราะแบบกำหนดเองสะอาดกว่า แต่เพราะความหมายต่างกัน หรือน้ำหนักไม่เข้ากัน

ออบเจกต์มาตรฐานมาพร้อมสัมภาระ

เมื่อคุณเลือกออบเจกต์มาตรฐาน คุณเลือกมากกว่าฟิลด์ของมัน คุณเลือกสิ่งที่ผลิตภัณฑ์ของ Salesforce เข้าใจอยู่แล้ว: รายงาน ระบบอัตโนมัติ ความสัมพันธ์สำเร็จรูป ฟีเจอร์ของผลิตภัณฑ์ แพ็กเกจ AppExchange และอะไรก็ตามที่ Salesforce จะสร้างต่อไป นั่นอาจมีค่าอย่างยิ่ง

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

สินทรัพย์เป็นตัวอย่างที่ดี

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

บัญชีบุคคล: เมื่อไรที่คนคือบัญชี?

ในโมดูลที่ 2 เราได้รู้จักบัญชีบุคคลแล้ว: บัญชีและผู้ติดต่อในเรกคอร์ดเดียว สำหรับลูกค้าที่เป็นบุคคล ทีนี้มาถึงการตัดสินใจ

จุดยืนของผม: สำหรับ B2C แทบจะขาดมันไม่ได้ มีหลายอย่างมากที่มาพร้อมบัญชีและผู้ติดต่อตั้งแต่แกะกล่อง จนต้นทุนและภาระนั้นคุ้มค่า และมันมีต้นทุนจริง: ใช้พื้นที่จัดเก็บราวสองเท่าของบัญชีธุรกิจ เป็นสวิตช์ที่เปิดแล้วปิดไม่ได้ และสิทธิ์การใช้งานภายนอกบางแบบใช้มันไม่ได้ Partner Community ใช้กับบัญชีบุคคลไม่ได้ (Experience Cloud User Licenses (opens in a new tab) ภาษาอังกฤษ) ดังนั้นคำถามไม่ใช่ “ในฐานข้อมูลของเรามีคนไหม?” ทุก org มีคน คำถามคือ “ในธุรกิจนี้ คนคนนั้นคือบัญชีจริงหรือเปล่า?” การที่ผู้ติดต่อเป็นคนไม่ได้ทำให้มันเป็นบัญชีบุคคล ความสัมพันธ์ทางธุรกิจต่างหากที่ทำ

Click to enlarge

ทีนี้ขอทำให้ทุกอย่างซับซ้อนขึ้น: สิทธิ์การใช้งาน

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

สิทธิ์การใช้งานภายในสามแบบ

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

Sales Cloud (ปัจจุบันคือ Agentforce Sales) ผู้ใช้กลุ่มนี้มีสิทธิ์ผู้ใช้ Salesforce เต็มรูปแบบ: ออบเจกต์ CRM มาตรฐาน และแอปมาตรฐานหรือแอปที่กำหนดเองใดก็ได้ นั่นคือลูกค้าเป้าหมาย โอกาสทางการขาย และการพยากรณ์ยอดขาย นอกเหนือจากบัญชีและผู้ติดต่อ และยังรวมถึงเคสด้วย: พนักงานขายเห็นเคสที่เปิดอยู่ของลูกค้าได้ก่อนโทรหา การสร้างและดำเนินแคมเปญต้องใช้อีกชิ้นหนึ่ง คือสิทธิ์การใช้งานฟีเจอร์ Marketing User

Service Cloud (ปัจจุบันคือ Agentforce Service) สิทธิ์ผู้ใช้ Salesforce แบบเดียวกัน แต่ตั้งค่าไว้สำหรับงานบริการ เคสอยู่ตรงกลาง ทำงานใน Service Console: สิทธิ์การใช้งานฟีเจอร์ Service Cloud User คือสิ่งที่เปิด Salesforce Console for Service ให้ใช้ นี่คือที่ที่ข้อตกลงระดับบริการ (SLA) อยู่ ผ่านการจัดการ entitlement และ milestone และเป็นที่ที่ Knowledge เข้ามา ซึ่งรุ่นส่วนใหญ่ต้องซื้อเป็นส่วนเสริม

Platform (Salesforce Platform) สำหรับคนที่ต้องใช้แอปที่กำหนดเองของคุณ ไม่ใช่ CRM พวกเขาได้บัญชี ผู้ติดต่อ รายงาน แดชบอร์ด เอกสาร และแอปที่กำหนดเองทุกตัวใน org สิ่งที่พวกเขาไม่ได้: การพยากรณ์ยอดขาย ลูกค้าเป้าหมาย แคมเปญ และโอกาสทางการขาย มันราคาถูกกว่า ซึ่งเป็นเหตุผลที่แอปที่กำหนดเองขนาดใหญ่จำนวนมากทำงานบนมัน และก็เป็นเหตุผลที่มันทำให้โมเดลข้อมูลของคุณสะดุดได้

	Sales Cloud	Service Cloud	Platform
สิทธิ์ผู้ใช้	Salesforce	Salesforce	Salesforce Platform
สร้างมาเพื่อ	การขาย	การดูแลลูกค้า	แอปที่กำหนดเอง
บัญชี ผู้ติดต่อ	ได้	ได้	ได้
ลูกค้าเป้าหมาย โอกาสทางการขาย การพยากรณ์ยอดขาย	ได้	ได้	ไม่ได้
เคส	ได้ เพื่อดูเคสของลูกค้า	อยู่ตรงกลาง ใน Service Console	ไม่ได้
ข้อตกลงระดับบริการ	ไม่ได้	ได้ ผ่าน entitlement และ milestone	ไม่ได้
ออบเจกต์และแอปที่กำหนดเอง	ได้	ได้	ได้

อ่านตารางแบบที่สถาปนิกอ่าน ถ้าผู้ใช้กลุ่มใหญ่อยู่บน Platform การออกแบบใดก็ตามที่วางงานของพวกเขาไว้บนโอกาสทางการขายก็พังตั้งแต่ยังไม่เริ่ม ถ้าผู้บริหารต้องการตัวเลข SLA สิทธิ์การใช้งานที่พวกเขาใช้อยู่จะตัดสินว่าพวกเขาเห็นมันได้หรือไม่ สิทธิ์สามแบบนี้เป็นตัวกำหนดพฤติกรรม

Click to enlarge

เมื่อสิทธิ์การใช้งานเป็นตัวตัดสินออบเจกต์

โอกาสทางการขายคือผู้เคราะห์ร้ายที่ผมเจอบ่อยที่สุด คุณเห็นแล้วในตาราง: ผู้ใช้ Platform ไม่ได้ใช้มัน (Standard User Licenses (opens in a new tab) ภาษาอังกฤษ) และผู้ใช้ Customer Community ก็ทำงานกับมันไม่ได้เช่นกัน ความต้องการจึงดูเหมือนโอกาสทางการขาย มีคนพูดว่า “ใช้โอกาสทางการขายกันเถอะ” แล้วผมก็ถามว่าใครต้องเข้าถึง ถ้าประชากรกลุ่มใหญ่ใช้สิทธิ์ Platform หรือ Customer Community สิทธิ์การใช้งานก็ไม่ใช่รายละเอียดของฝ่ายจัดซื้ออีกต่อไป มันคือข้อจำกัดทางสถาปัตยกรรม และมักผลักการออกแบบไปทางออบเจกต์ที่กำหนดเอง

มันยังส่งผลในทางขึ้นด้วย ในคลาสผมถามว่า: CEO อยากได้แดชบอร์ดสวยๆ ควรใช้สิทธิ์ Sales หรือ Service? ผู้ใช้ Sales เห็นออบเจกต์การขายและเคสด้วย ดังนั้นสำหรับแดชบอร์ดการขายและจำนวนเคสที่เปิดอยู่ Sales ก็พอ แต่ทันทีที่ผู้บริหารอยากได้ KPI เรื่อง SLA (อีกนานแค่ไหนกว่าเคสจะละเมิดระดับบริการ) ข้อมูลนั้นอยู่ใน entitlement และ milestone และการจัดการ entitlement ต้องใช้ Agentforce Service ซึ่งเดิมคือ Service Cloud (Supported Editions for Service Features (opens in a new tab) ภาษาอังกฤษ) ตอนนี้คุณต้องอัปเกรดสิทธิ์ของผู้บริหาร ฟังความต้องการทางธุรกิจ และรู้ว่าสิทธิ์การใช้งานใดอยู่เบื้องหลังข้อมูลที่มันต้องการ

สนามกีฬา

ผมคิดถึงสิทธิ์การใช้งานเหมือนที่นั่งในสนามกีฬา ทุกคนดูเกมเดียวกัน ถ้าผมซื้อที่นั่งแพงตรงกลาง ผมเห็นทั้งสองทีมใกล้ๆ ถ้าผมอยู่บนสุดตรงมุม ที่นั่งไม่มีเบาะและผมต้องดูผ่านกล้องส่องทางไกล

นั่นคือสิทธิ์การใช้งานภายนอก สำหรับคนนอกบริษัท: ลูกค้าและพันธมิตรที่ล็อกอินเข้าเว็บไซต์ Experience Cloud มีสามแบบที่ผมอยากให้คุณรู้

Customer Community: อัฒจันทร์ราคาถูก สร้างมาสำหรับผู้ใช้ภายนอกจำนวนมากที่ต้องการเคสและ Knowledge: ลูกค้าที่เข้ามาเช็กเคสขอความช่วยเหลือของตัวเอง ที่นั่งราคาราวครึ่งเดียว และให้ผู้ใช้จำนวนมหาศาลได้ อยู่บนนั้นคุณเสียอะไร? รายงาน แดชบอร์ด และ share table: การแชร์แบบอิงบทบาทที่ระดับสูงกว่าได้ มันใช้กับบัญชีบุคคลได้

Customer Community Plus: ลงมาราวครึ่งทาง Salesforce อธิบายว่าเป็นสิทธิ์สำหรับผู้ใช้ภายนอกที่ต้องการรายงาน แดชบอร์ด และการแชร์มาตรฐาน: ลูกค้าที่จัดการสิทธิ์เข้าถึงของคนอื่น หรือต้องเห็นตัวเลขของตัวเอง

Partner Community: ใกล้สนามขึ้นอีก สำหรับธุรกิจกับธุรกิจ เข้าถึงข้อมูลการขายได้ พันธมิตรทำงานกับลูกค้าเป้าหมายและโอกาสทางการขาย: ลงทะเบียนดีล และดำเนินแคมเปญร่วมกับคุณ นั่นคือที่นั่งภายนอกที่เข้าถึงออบเจกต์การขายได้ มีข้อแม้หนึ่งข้อ: มันใช้กับบัญชีบุคคลไม่ได้ (Experience Cloud User Licenses (opens in a new tab) ภาษาอังกฤษ)

Click to enlarge

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

วิธีที่พวกเขาจ่ายเงินเปลี่ยนการออกแบบ

ยังมีอีกคำถามที่คนมักลืม: ผู้ใช้เหล่านี้จะล็อกอินอย่างไร? สิทธิ์การใช้งานภายนอกมีสองรูปแบบ แบบอิงสมาชิก (member-based): จ่ายต่อผู้ใช้ เหมาะกับพันธมิตร 500 รายที่ล็อกอินทุกวัน แบบอิงการล็อกอิน (login-based): ซื้อจำนวนการล็อกอินต่อเดือน เหมาะกับลูกค้าห้าล้านรายที่ล็อกอินปีละไม่กี่ครั้ง การล็อกอินมากกว่าหนึ่งครั้งในวันเดียวกันยังนับเป็นหนึ่งครั้ง (Experience Cloud User Licenses (opens in a new tab) ภาษาอังกฤษ)

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

เมื่อสิทธิ์การใช้งานกำหนดรูปโมเดล

บางครั้งสิทธิ์การใช้งานไม่ได้แค่เลือกออบเจกต์ มันบิดโมเดลด้วย สิทธิ์ระดับแพลตฟอร์มบางแบบจำกัดผู้ใช้ไว้กับแอปที่กำหนดเองหนึ่งแอปที่มีออบเจกต์ที่กำหนดเองได้สูงสุดสิบตัว (เช่น Lightning Platform – One App; Standard User Licenses (opens in a new tab) ภาษาอังกฤษ)

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

นั่นไม่ใช่โมเดลที่เหมาะที่สุด ทำรายงานจากมันลำบาก และผมอยากให้มันสะอาดกว่านี้ แต่นั่นคือสิ่งที่สิทธิ์การใช้งานอนุญาต ผมเรียกพวกมันว่าออบเจกต์มีดพับสวิส (Swiss army knife objects): เก็บรูปแบบนี้ไว้ในกระเป๋า และเมื่อข้อจำกัดไม่เหลือที่ว่าง ก็ทุบกระจกฉุกเฉินแล้วเปลี่ยนไปแยกด้วยประเภทเรกคอร์ด แค่รู้ว่าคุณกำลังแลกอะไร สิทธิ์ที่ต่างกันต่อประเภทเรกคอร์ดอาจบังคับให้คุณต้องแยกออบเจกต์อยู่ดี

คนไม่ใช่ผู้ใช้เพียงกลุ่มเดียวอีกต่อไป

อีกคำถามหนึ่งเรื่องสิทธิ์การใช้งานกลายเป็นเรื่องสำคัญ: แล้วสิ่งที่ไม่ใช่คนล่ะ? การผสานรวมมีตัวตน เอเจนต์มีตัวตน ตอนนี้ Salesforce มีสิทธิ์ Salesforce Integration สำหรับการผสานรวมระหว่างระบบ: ใช้ API เท่านั้น ไม่ใช่สำหรับคน โดยมีให้ห้าสิทธิ์กับทุก org รุ่น Enterprise, Unlimited และ Performance (Standard User Licenses (opens in a new tab) ภาษาอังกฤษ) ดังนั้นอย่าถามแค่ว่าผู้ใช้คนไหนต้องเข้าถึง ให้ถามว่าตัวตนใดต้องเข้าถึง: คน ลูกค้า พันธมิตร การผสานรวม เอเจนต์ แล้วแต่ละตัวตนต้องเห็นและทำอะไร

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

Steve Trucking: ข้อง่ายหนึ่งข้อ ข้อยากหนึ่งข้อ

Steve Trucking ทำงานกับพันธมิตรค้าปลีก พันธมิตรค้าปลีกคืออะไร? ธุรกิจหนึ่ง ง่าย: บัญชี ผมไม่สร้าง Retail_Partner__c เพียงเพราะมีคนใช้คำว่า “พันธมิตร”

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

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

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

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

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

• Salesforce Help, Standard User Licenses (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02 ตรวจซ้ำเมื่อ 2026-10-12): ผู้ใช้ Platform ไม่มีสิทธิ์ใช้การพยากรณ์ยอดขาย ลูกค้าเป้าหมาย แคมเปญ และโอกาสทางการขาย แอปที่กำหนดเองหนึ่งแอปที่มีออบเจกต์ที่กำหนดเองได้สูงสุด 10 ตัว สิทธิ์ Salesforce Integration ห้าสิทธิ์ในแต่ละ org รุ่น Enterprise Edition
• Salesforce Help, Experience Cloud User Licenses (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02 ตรวจซ้ำเมื่อ 2026-10-12): Partner Community ใช้กับบัญชีบุคคลไม่ได้ Customer Community Plus สำหรับรายงาน แดชบอร์ด และการแชร์มาตรฐาน การล็อกอินหลายครั้งในวันเดียวนับเป็นหนึ่งครั้ง
• Salesforce Help, Supported Editions for Service Features (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02 ตรวจซ้ำเมื่อ 2026-10-12): ข้อตกลงระดับบริการ (การจัดการ entitlement) มากับ Agentforce Service ส่วน Knowledge มีค่าใช้จ่ายเพิ่มในรุ่นส่วนใหญ่
• Salesforce Help, Available Feature Licenses (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-12): Service Cloud User “Access the Salesforce Console for Service” (เข้าถึง Salesforce Console for Service) และ Marketing User สำหรับการสร้างและจัดการแคมเปญ