ฟิลด์ก็คือสถาปัตยกรรม

🌐 มีให้อ่านอีก 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 จาก 10 ในบท สถาปัตยกรรมข้อมูล Salesforce บทที่ 3 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: เลือกออบเจกต์ให้ถูก · ถัดไป: ความสัมพันธ์มีผลตามมา

คำถามที่โมดูลนี้ตอบ: Salesforce ควรแทนข้อมูลแต่ละชิ้นในเชิงกายภาพอย่างไร?

การสร้างฟิลด์ใช้เวลาราวหนึ่งนาที New Field เลือกประเภท ตั้งชื่อ Next, Next, Save นั่นคือเหตุผลที่ฟิลด์ไม่ได้ถูกปฏิบัติเหมือนสถาปัตยกรรม

ลองเข้าไปใน org ที่มีอายุสิบปีแล้วเปิดบัญชี ห้าร้อยฟิลด์ Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c หมายเลขลูกค้าสามชุด checkbox ที่ไม่มีใครกล้าลบเพราะไม่มีใครรู้ว่าการผสานรวมไหนยังใช้มันอยู่ การสร้างฟิลด์ใช้เวลาหนึ่งนาที การอยู่กับมันใช้เวลาหลายปี ดังนั้นแนวคิดของโมดูลนี้เรียบง่าย: ฟิลด์คือการตัดสินใจเชิงสถาปัตยกรรม ไม่ได้ใหญ่เสมอไป แต่ทุกฟิลด์บรรจุบางอย่างเกี่ยวกับความหมาย พฤติกรรม ตัวตน หรือคุณภาพของข้อมูล และเช่นเดียวกับออบเจกต์ ฟิลด์เพิ่มง่ายและเอาออกยากอย่างน่าประหลาดใจ

ข้อมูลนี้หมายถึงอะไรจริงๆ?

ในบทที่ 2 เราให้แอตทริบิวต์แก่เอนทิตี: การจัดส่งมีช่วงเวลาที่นัดไว้ รถบรรทุกมี VIN ตอนนี้เรา implement มัน และนี่คือจุดที่คนกระโดดไปที่ “ฟิลด์ข้อความ” ทันที เดี๋ยวก่อน ก่อนประเภท ผมอยากรู้ว่าข้อมูลหมายถึงอะไร มันเป็นตัวเลข หรือเป็นตัวระบุที่บังเอิญมีตัวเลข? เป็นวันที่ หรือเป็นช่วงเวลาหนึ่งขณะ? ข้อความอิสระ หรือหนึ่งในชุดค่าที่อนุมัติ? คนกรอก หรือระบบอื่นเป็นเจ้าของ? เปลี่ยนได้ไหม? ต้องไม่ซ้ำไหม? หายไปได้ไหม? ควรเก็บไว้เลยไหม หรือคำนวณเอา? นั่นไม่ใช่คำถามเกี่ยวกับ Setup มันคือคำถามสถาปัตยกรรมข้อมูล และประเภทฟิลด์มาหลังจากเราตอบมัน

ตัวเลขไม่ได้เป็นตัวเลขเสมอไป

Steve Trucking ให้หมายเลขประจำกองรถแก่รถบรรทุกทุกคัน เช่น 001247 ฟิลด์ตัวเลข? คงไม่ เราเอาหมายเลขกองรถมาบวกกันไหม? รถคันที่ 1247 ลบรถคันที่ 1246 เท่ากับรถหนึ่งคันหรือ? มันคือตัวระบุที่บังเอิญมีตัวเลข และฟิลด์ Number ยังจะตัดเลขศูนย์นำหน้าทิ้งด้วย รหัสไปรษณีย์ รหัสสินค้า หมายเลขบัญชี และหมายเลขติดตามพัสดุก็เช่นกัน หน้าตาของค่าไม่ได้บอกคุณว่ามันหมายถึงอะไร เลือกประเภทตามพฤติกรรมที่คุณต้องการ ไม่ใช่ตามหน้าตาของข้อมูลตัวอย่าง

คนต้องระบุมันไหม?

ทุกออบเจกต์ที่กำหนดเองได้ฟิลด์ Name และการตัดสินใจแรกคือข้อความหรือ auto number ผมถามว่า: คนต้องระบุสิ่งนี้ไหม? คนรู้จักพันธมิตรค้าปลีกจากชื่อ และรู้จักรถบรรทุกจากหมายเลขกองรถ แต่ใบรายการสินค้าที่ระบบสร้างทุกคืนล่ะ? ไม่ควรมีใครต้องพิมพ์ “ใบรายการ 10-02 หมายเลข 3” เพียงเพราะ Salesforce บังคับให้มี Name ให้ใช้ auto number แค่อย่าสับสนระหว่าง Name ที่สร้างขึ้นนั้นกับตัวตนของเรกคอร์ด: auto number ช่วยผู้ใช้ Salesforce ID ระบุเรกคอร์ด และหมายเลขอ้างอิงใบรายการของพันธมิตรค้าปลีกเองอาจระบุสิ่งเดียวกันข้ามระบบ สามหน้าที่ที่ต่างกัน

หน้าจอรายละเอียด

เลือกประเภท คลิก Next แล้วการตั้งค่า (Setup) ก็จะถามรายละเอียด นี่คือหน้าจอที่การตัดสินใจส่วนใหญ่ในโมดูลนี้เกิดขึ้นจริง และมักเกิดอย่างเร่งรีบ

New Custom Field ขั้นที่ 2: รายละเอียด (ภาพหน้าจอ 2026-10-12) ขนาดเต็ม

มีสองช่องที่ดูคล้ายกันแต่ทำงานต่างกัน Description (คำอธิบาย) มีไว้สำหรับคนที่ดูแล org และตอนนี้รวมถึงเครื่องมือ AI ที่อ่านมันด้วย: ฟิลด์นี้หมายถึงอะไร ใครเป็นเจ้าของ มาจากไหน Help Text (ข้อความช่วยเหลือ) มีไว้สำหรับผู้ใช้ที่อยู่หน้าจอ: ต้องพิมพ์อะไรตรงนี้ กรอกทั้งสองช่อง จากนั้นก็มาถึง Required, Unique และ External ID ซึ่งแต่ละอย่างควรมีหัวข้อของตัวเอง ด้านล่างนั้น Default Value (ค่าเริ่มต้น) เป็นสูตรได้ เรกคอร์ดใหม่จึงเริ่มต้นด้วยค่าที่สมเหตุสมผลแทนที่จะว่างเปล่า

การบังคับกรอกเป็นการตัดสินใจที่ใหญ่กว่าที่เห็น

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

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

ความไม่ซ้ำก็มีความหมาย

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

External ID: ตัวตนข้ามขอบเขต

นี่คือจุดที่ External ID พิสูจน์คุณค่า หน้าจออธิบายไว้ได้ดี: ฟิลด์นี้กลายเป็น “the unique record identifier from an external system” (ตัวระบุเรกคอร์ดที่ไม่ซ้ำจากระบบภายนอก) ERP มีลูกค้า 873492 Salesforce มี ID ของเรกคอร์ดของตัวเอง เมื่อ ERP ส่งการอัปเดต เราจะรู้ได้อย่างไรว่ามันเป็นของเรกคอร์ดไหน? ทำเครื่องหมายฟิลด์เป็น External ID แล้วการผสานรวมก็ upsert ตามมันได้: สร้างเรกคอร์ดถ้ายังไม่มี อัปเดตถ้ามีแล้ว (Upsert a Record Using an External ID (opens in a new tab) ภาษาอังกฤษ) และเมื่อคุณโหลดเรกคอร์ดลูก คุณชี้ไปที่แม่ด้วย External ID ของมันได้ แทนที่จะต้องคิวรีหา Salesforce ID ก่อน ผมชอบพูดว่าคุณให้ Salesforce ทำ lookup แทนคุณ ทรงพลังมาก

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

ฟิลด์ทีละประเภท

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

การตั้งค่า (Setup), New Custom Field ขั้นที่ 1: ประเภทข้อมูล (ภาพหน้าจอ 2026-10-12) ขนาดเต็ม

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

กลุ่ม	ประเภท	สิ่งที่ต้องจำ
คำนวณ	Auto Number	ยาวได้ถึง 30 อักขระ ในนั้น 20 อักขระเป็นคำนำหน้าหรือคำต่อท้าย เป็นป้ายสำหรับคน ไม่ใช่ตัวตนของเรกคอร์ด
	Formula	คำนวณตอนอ่าน ไม่ได้จัดเก็บ 3,900 อักขระ
	Roll-Up Summary	นับ รวม ค่าต่ำสุด หรือค่าสูงสุดของ detail ใช้ได้กับ master-detail เท่านั้น
ความสัมพันธ์	Lookup, Master-Detail, External Lookup	โมดูลที่ 7
ข้อมูล	Checkbox	จริงหรือเท็จ มีค่าเริ่มต้นที่คุณเลือก แต่ null ยังโผล่มาใน flow ได้
	Number, Percent, Currency	กฎการปัดเศษ เลขศูนย์นำหน้าหายไป ทศนิยม 15 ตำแหน่ง
	Date, Date/Time, Time	วัน ช่วงขณะ หรือเวลาของวัน ช่วงขณะถูกจัดเก็บเป็น UTC
	Email, Phone, URL	จัดรูปแบบและตรวจสอบตอนบันทึก: 80, 40 และ 255 อักขระ
	Geolocation, Address	ฟิลด์ผสมที่นับมากกว่าหนึ่งฟิลด์: 3 และ 9
	Picklist, Multi-Select	คำศัพท์ที่ควบคุม โดยมีผู้ดูแลระบบเป็นเจ้าของ
	Text, Text Area, Long, Rich, Encrypted	ไม่เกิน 255 อยู่บนเรกคอร์ดและทำดัชนีได้ เกินกว่านั้นไม่มีดัชนีหรือการกรอง

ฟิลด์ที่ Salesforce คำนวณให้

Auto Number กำหนดหมายเลขถัดไปในลำดับให้กับทุกเรกคอร์ดใหม่ ในรูปแบบที่คุณกำหนด เช่น T-{000000} ใช้มันเมื่อคนต้องการชื่อเรียกที่จำง่าย และไม่ควรมีใครต้องคิดขึ้นเอง ค่าทั้งหมดยาวได้ถึง 30 อักขระ และ 20 อักขระในนั้นสงวนไว้สำหรับคำนำหน้าหรือคำต่อท้าย แค่จำจากบทที่ 2 ไว้: มันเป็นป้ายสำหรับคน ไม่ใช่ตัวตนของเรกคอร์ด และตัวเลขก็ไม่ได้เรียงต่อเนื่องกันเป๊ะเสมอไป

ฟิลด์ Formula คำนวณค่าจากฟิลด์อื่น มันทรงพลัง และมันถูกคำนวณตอนที่อ่านเรกคอร์ด ไม่ใช่ตอนที่บันทึก จึงไม่มีอะไรที่จัดเก็บไว้แล้วล้าสมัย คุณเลือกได้ว่าสูตรจะคืนค่าอะไร: checkbox, currency, date, date/time, number, percent, text หรือ time

New Custom Field สูตร: การเลือกประเภทค่าที่คืน (ภาพหน้าจอ 2026-10-12) ขนาดเต็ม

จากนั้นคุณเขียนตัวสูตรเอง ด้วยฟิลด์ ตัวดำเนินการ และฟังก์ชัน แล้วตรวจไวยากรณ์ สังเกตปุ่ม Use Formula Assistant: ตอนนี้ AI ของ Salesforce จะช่วยคุณเขียนสูตร ใช้มัน แล้วอ่านสิ่งที่มันเขียน คุณเป็นเจ้าของสูตร ไม่ใช่ผู้ช่วย

ตัวแก้ไขสูตร พร้อม Formula Assistant (ภาพหน้าจอ 2026-10-12) ขนาดเต็ม สูตรหนึ่งยาวได้ถึง 3,900 อักขระ และต้องไม่เกิน 15,000 ไบต์เมื่อบันทึกหรือคอมไพล์ สูตรที่ยาวแบ่งไปไว้ในหลายฟิลด์สูตรที่อ้างอิงกันได้ ฟิลด์ข้อความยาว ฟิลด์ที่เข้ารหัส และฟิลด์ Description ใช้ในสูตรไม่ได้

ฟิลด์ Roll-Up Summary อยู่บน master และนับ รวม หรือหาค่าต่ำสุดหรือสูงสุดของเรกคอร์ด detail ของมัน ใช้ได้เฉพาะข้ามความสัมพันธ์ master-detail เท่านั้น ซึ่งเป็นหนึ่งในเหตุผลที่ใหญ่ที่สุดที่จะเลือก master-detail เลย เราจะกลับมาดูมันและข้อจำกัดของมันในโมดูลที่ 7

เก็บไว้หรือคำนวณ?

เราต้องเก็บค่านี้ไว้เลยไหม? ถ้าผมมีจำนวนและราคาต่อหน่วย ต้องมีใครสักคน หรือระบบอัตโนมัติสักตัว ดูแลยอดรวมไหม? บางทีสูตรควรคำนวณมัน: แหล่งเดียวสำหรับการคำนวณ คำนวณใหม่ทุกครั้งที่อ่าน เปลี่ยนจำนวนแล้วคำตอบก็ตามไป สูตรก็มีข้อจำกัดของมันเอง (ขนาดเมื่อบันทึกและความยาวที่แสดง; Formula Field Limits and Restrictions (opens in a new tab) ภาษาอังกฤษ) และสูตรที่ซับซ้อนก็ดูแลยาก

แต่บางครั้งธุรกิจไม่ต้องการคำตอบของวันนี้ มันต้องการคำตอบอย่างที่มันเคยเป็น ถ้ากฎส่วนลดเปลี่ยนในปีหน้า ใบแจ้งหนี้ของปีที่แล้วควรแสดงยอดเงินต่างไปทันทีหรือ? แน่นอนว่าไม่ ดังนั้นคำถามไม่ใช่ “Salesforce คำนวณสิ่งนี้ได้ไหม?” แต่คือ “นี่เป็นการคำนวณปัจจุบัน หรือข้อเท็จจริงในอดีต?” ข้อเท็จจริงในอดีตต้องถูกเก็บไว้

ฟิลด์ความสัมพันธ์

ความสัมพันธ์ Lookup, Master-Detail และ External Lookup ก็เป็นฟิลด์ด้วย และเป็นที่ที่เส้นในโมเดลของคุณกลายเป็นของจริง lookup คือการเชื่อมแบบหลวม master-detail ผูกชีวิต ความเป็นเจ้าของ และความปลอดภัยของลูกไว้กับแม่ ส่วน external lookup เอื้อมไปถึงออบเจกต์ภายนอกจากโมดูลที่ 4 โดยจับคู่ตาม External ID ของมัน การเลือกระหว่างสามอย่างนี้เป็นการตัดสินใจที่ใหญ่พอจะได้โมดูลของตัวเอง

Checkbox

checkbox เป็นฟิลด์ที่ง่ายที่สุด: จริงหรือเท็จ ติ๊กหรือไม่ติ๊ก เหมาะกับข้อเท็จจริงแบบใช่/ไม่ใช่เกี่ยวกับเรกคอร์ด: Is Active, Install Required, Signed For เมื่อคุณสร้างมัน Salesforce บังคับให้คุณเลือกค่าเริ่มต้น ติ๊กหรือไม่ติ๊ก และนั่นเป็นการตัดสินใจจริงจัง: มันคือค่าที่ทุกเรกคอร์ดใหม่เริ่มต้น รวมถึงเรกคอร์ดที่การผสานรวมสร้างโดยไม่ได้ส่งฟิลด์นี้มา รายงานและ list view กรองมันเป็น True และ False ส่วนเครื่องมือนำเข้าและการส่งออกรายสัปดาห์แสดงเป็น 1 และ 0

มีกับดักหนึ่งที่ควรรู้ ฟิลด์บนเรกคอร์ดมีสองค่า แต่ระบบอัตโนมัติรอบๆ มันอาจมีค่าที่สาม ใน flow ตัวแปร checkbox ที่ไม่เคยถูกกำหนดค่าคือ null ไม่ใช่ false และการบันทึกมันลงเรกคอร์ดจะล้มเหลว (Trailblazer Community (opens in a new tab) ภาษาอังกฤษ ดูเพิ่มที่ known issue ของ Salesforce W-11208535 (opens in a new tab)) เลือกค่าเริ่มต้นที่สมเหตุสมผล และทำให้ flow และโค้ดของคุณจัดการ null อย่างตั้งใจ

Number, Percent และ Currency

Number เก็บจำนวนจริง และตัดเลขศูนย์นำหน้าทิ้ง ซึ่งเป็นเหตุผลที่หมายเลขรถอย่าง 001247 ไม่ใช่ Number Salesforce ปัดเศษฟิลด์ตัวเลขแบบปัดครึ่งออกจากศูนย์ (half away from zero): 12.345 กลายเป็น 12.35 และ −12.345 กลายเป็น −12.35 และใน merge field มันปัดตาม locale ของผู้ใช้ ไม่ใช่ตามจำนวนตำแหน่งทศนิยมที่คุณตั้งไว้บนฟิลด์

Percent เก็บทศนิยมและแสดงเป็นเปอร์เซ็นต์: ใส่ 0.10 แล้วคุณจะเห็น 10% ค่าจะเสียความแม่นยำหลังทศนิยม 15 ตำแหน่ง

Currency จัดรูปแบบสำหรับเงิน และใน org ที่มีหลายสกุลเงิน มันพกรหัสสกุลเงินของตัวเองและใช้อัตราแลกเปลี่ยนได้ ด้วย advanced currency management (opens in a new tab) โอกาสทางการขายใช้อัตราแลกเปลี่ยนตามช่วงวันที่ (dated) ได้ คืออัตราของช่วงเวลาที่ดีลปิด มีเพียงโอกาสทางการขายและสิ่งที่อยู่รอบๆ มัน (ผลิตภัณฑ์ ตารางเวลา การแบ่งยอด และรายงานของสิ่งเหล่านี้) ที่ใช้อัตราตามช่วงวันที่ ฟิลด์สกุลเงินบนออบเจกต์อื่นยังใช้อัตราคงที่อัตราเดียว ระวังการปัดเศษ: ถ้าไม่มีตำแหน่งทศนิยม Salesforce จะตัดทิ้งเฉยๆ (23.5 กลายเป็น 23) ถ้ามีหนึ่งตำแหน่งขึ้นไป จะปัดครึ่งออกจากศูนย์

Date, Date/Time และ Time

สามประเภท สามความหมายที่ต่างกัน Date คือวัน: สัญญาหมดอายุในวันหนึ่ง Date/Time คือช่วงขณะ: การจัดส่งมาถึงตอน 9:42 เช้าวันนั้น Time คือเวลาของวันโดยไม่มีวันที่เลย: ร้านเปิด 7:00 ทุกวัน

กับดักอยู่ที่ช่วงขณะ Salesforce เก็บค่า date/time เป็น GMT (UTC) เวลาที่ผู้ใช้พิมพ์จะถูกอ่านตามเขตเวลาของผู้ใช้คนนั้น แปลงแล้วจัดเก็บ เมื่อมีคนอ่าน มันก็ถูกแปลงอีกครั้งเป็นเขตเวลาของผู้อ่าน ส่วนใหญ่นั่นคือสิ่งที่คุณต้องการพอดี แต่นี่คือตัวอย่างที่ผมยกในคลาส: ผู้ประสานงานในลอสแอนเจลิสบันทึกการจัดส่งตอนดึกคืนวันอาทิตย์ เวลา 22:00 ตามเวลาแปซิฟิก เบื้องหลัง Salesforce เก็บเป็นเช้าวันจันทร์ 05:00 GMT รายงานที่จัดกลุ่มตามวันในเขตเวลาอื่น หรือการผสานรวมที่อ่านค่าดิบ อาจย้ายการจัดส่งวันอาทิตย์นั้นไปเป็นวันจันทร์ได้ “วันที่มันเกิดขึ้น” ขึ้นอยู่กับว่าคุณถามนาฬิกาของใคร ระวังเขตเวลาของผู้ใช้ และตัดสินว่าธุรกิจหมายถึงเขตเวลาไหน

และระวังตอนเปรียบเทียบด้วย เบื้องหลัง date/time คือตัวเลขก้อนใหญ่ก้อนเดียว: Apex อ่านมันเป็นจำนวนมิลลิวินาทีนับตั้งแต่ 1 มกราคม 1970 เวลา 00:00:00 GMT (Datetime Class (opens in a new tab) ภาษาอังกฤษ) มันคือช่วงขณะที่แม่นยำ ไม่ใช่วัน ดังนั้นการถามว่า date/time สองค่าเท่ากันไหม (==) แทบไม่เคยได้ผลอย่างที่คุณต้องการ: 9:42:00 กับ 9:42:01 ไม่เท่ากัน และ “วันจันทร์” กับช่วงขณะใดๆ ในวันจันทร์ก็ไม่เท่ากัน ให้ถามเป็นช่วงแทน: ตั้งแต่จุดเริ่มต้น (>=) และไม่เกินจุดสิ้นสุด (<=) “ทุกการจัดส่งในวันจันทร์” คือทุกการจัดส่งที่ >= วันจันทร์ 00:00 และ <= วันจันทร์ 23:59:59 ในเขตเวลาที่คุณตัดสินแล้วว่าธุรกิจหมายถึง

และอีกเรื่องที่สนุก: Salesforce เก็บวันที่แบบไหนก็ได้ไม่ได้ วันที่ที่ใช้ได้อยู่ระหว่าง 1 มกราคม 1700 ถึง 31 ธันวาคม 4000 และ Salesforce ให้ช่วงเดียวกันทั้งสำหรับ date และ date/time (Data Import Dates (opens in a new tab) ภาษาอังกฤษ) แม้แต่ขอบเขตก็เป็นช่วงขณะใน GMT ดังนั้นสำหรับผู้ใช้ในเวลาแปซิฟิก ค่าที่เร็วที่สุดที่ใช้ได้คือ 16:00 ของวันที่ 31 ธันวาคม 1699 วันก่อตั้งของสมาคมประวัติศาสตร์ของคุณอาจใส่ไม่ได้ และเทคนิค “ไม่มีวันสิ้นสุด” แบบคลาสสิกอย่าง 31 ธันวาคม 9999 ก็ถูกปฏิเสธ ถ้าคุณต้องการค่าตัวยึดในอนาคตอันไกล มันต้องอยู่ในปี 4000 หรือก่อนหน้านั้น

Email, Phone และ URL

เหล่านี้คือฟิลด์ที่มีรูปแบบ และมันทำมากกว่าเก็บตัวอักษร Email เก็บได้ถึง 80 อักขระและถูกตรวจรูปแบบให้ถูกต้อง บนผู้ติดต่อและลูกค้าเป้าหมาย การคลิกมันจะเริ่มเขียนอีเมลถึงที่อยู่นั้น Phone เก็บได้ถึง 40 อักขระ จัดรูปแบบเป็นหมายเลขโทรศัพท์ และกลายเป็นคลิกเพื่อโทร (click-to-dial) เมื่อ org เชื่อมต่อระบบโทรศัพท์ไว้ URL เก็บได้ถึง 255 อักขระและเปิดเป็นลิงก์ นั่นคือแพลตฟอร์มให้พฤติกรรมคุณมาฟรีๆ และเป็นเหตุผลที่ผมจะไม่มีวันเก็บหมายเลขโทรศัพท์ไว้ในฟิลด์ข้อความธรรมดา

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

Geolocation และ Address

Geolocation เก็บละติจูดและลองจิจูด เบื้องหลัง ฟิลด์ที่ชื่อ Location__c จริงๆ คือสองค่าที่คุณอ่านและกำหนดแยกกันได้ คือ Location__Latitude__s และ Location__Longitude__s และคุณคิวรีตามมันได้: ฟังก์ชัน DISTANCE และ GEOLOCATION ของ SOQL หาเรกคอร์ดภายในรัศมีที่กำหนด หรือเรียงตามระยะทาง “ทุกการจัดส่งที่ยังเปิดอยู่ภายใน 25 ไมล์จากรถบรรทุกคันนี้” คือคิวรีเดียว: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab) ภาษาอังกฤษ) Address เก็บที่อยู่ทั้งหมด ถนน เมือง รัฐหรือจังหวัด รหัสไปรษณีย์ และประเทศ และผู้ใช้ค้นหาที่อยู่แล้วให้ระบบกรอกส่วนต่างๆ ให้ได้

ทั้งสองอย่างเป็นฟิลด์ผสม (compound field): หน้าจอเห็นเป็นฟิลด์เดียว แต่เบื้องหลังมีหลายฟิลด์ และมันนับมากกว่าหนึ่งฟิลด์ในขีดจำกัดของออบเจกต์: Geolocation นับเป็นฟิลด์ที่กำหนดเองสามฟิลด์ และ Address นับเป็นเก้าฟิลด์ บนออบเจกต์ที่แน่นอยู่แล้ว เรื่องนี้สำคัญ

Picklist และ Multi-Select

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

ค่าอยู่ที่ไหนก็เป็นการตัดสินใจเหมือนกัน เมื่อรายการถูกใช้ครั้งเดียวบนฟิลด์เดียว ให้เก็บค่าไว้บนตัวฟิลด์เอง บนออบเจกต์ ซึ่งเป็นสิ่งที่ Salesforce ทำโดยค่าเริ่มต้น แต่เมื่อชุดค่าเดียวกันเริ่มโผล่ในหลายที่ เช่น Region บนบัญชี บนการจัดส่ง และบนคลังสินค้า ให้ยกระดับมันเป็นชุดค่าส่วนกลาง ก่อนที่สำเนาจะเริ่มเพี้ยนไปคนละทาง ชุดค่าส่วนกลาง (global value set) เก็บรายการเดียวไว้ให้ทุกฟิลด์ใช้ ได้ถึง 1,000 ค่า รวมทั้งค่าที่ใช้งานและไม่ใช้งาน (Picklist Limitations (opens in a new tab) ภาษาอังกฤษ) คำอธิบายของการตั้งค่าเองก็บอกว่าทำไมมันสำคัญ: ชุดค่านี้ “is restricted so users can’t add unapproved values through the API” (ถูกจำกัดไว้ ผู้ใช้จึงเพิ่มค่าที่ไม่ได้รับอนุมัติผ่าน API ไม่ได้) รายการเดียว เจ้าของคนเดียว และไม่มีการผสานรวมไหนแอบใส่ตัวสะกดใหม่เข้ามา

ประเด็นสุดท้ายนั้นคือความต่างระหว่างแบบจำกัดค่า (restricted) กับแบบไม่จำกัดค่า (unrestricted) บน picklist แบบจำกัดค่า อนุญาตเฉพาะค่าที่ผู้ดูแลระบบกำหนดไว้ ไม่ว่ามาจากทางไหน: ผู้ใช้ การนำเข้า หรือการผสานรวมที่ส่งค่าอื่นมาจะได้ข้อผิดพลาด “bad value for restricted picklist field” และเรกคอร์ดไม่ถูกบันทึก บน picklist แบบไม่จำกัดค่า ผู้ใช้ยังเลือกจากรายการบนหน้าจอ แต่ API การนำเข้า และระบบอัตโนมัติส่งค่าอะไรก็ได้ แล้ว Salesforce จะบันทึกและเพิ่มมันเป็นค่าที่ไม่ใช้งาน (Picklist Limitations (opens in a new tab) ภาษาอังกฤษ; Create a Custom Picklist Field (opens in a new tab) ภาษาอังกฤษ) นั่นคือที่มาของ org ที่มีทั้ง “Delivered”, “delivered” และ “Dlvrd” ชุดค่าส่วนกลางเป็นแบบจำกัดค่าเสมอ ค่าเริ่มต้นของผมคือแบบจำกัดค่า แบบไม่จำกัดค่าเป็นการเลือกอย่างตั้งใจสำหรับกรณีที่ระบบอื่นเป็นเจ้าของค่าจริงๆ และเมื่อนั้นต้องมีใครสักคนรับผิดชอบเก็บกวาดค่าที่ไม่ใช้งาน

การตั้งค่า (Setup), Picklist Value Sets: ชุดค่าส่วนกลางใหม่ (ภาพหน้าจอ 2026-10-12) ขนาดเต็ม

multi-select picklist ให้ผู้ใช้เลือกได้หลายค่า เก็บรวมกันโดยคั่นด้วยเครื่องหมายอัฒภาค (;) สะดวกบนหน้าจอ แต่เก้กังในทุกที่อื่น: กรอง ทำรายงาน และผสานรวมได้ยากกว่า และใช้ในตัวกรองของ roll-up summary ไม่ได้ หลายค่าสำหรับเรกคอร์ดเดียวมักหมายถึงบทเรียนจากบทที่ 2: มีออบเจกต์ลูกตัวหนึ่งพยายามจะออกมา

picklist ยังมีค่ามากกว่าที่คุณกำหนดไว้อีกหนึ่งค่า: ค่าว่าง เรกคอร์ดหนึ่งอาจไม่มีค่าใดถูกเลือก และนั่นทำให้คนพลาด ในสูตรหรือกฎการตรวจสอบความถูกต้อง คุณทดสอบ picklist ด้วย ISBLANK เพียงอย่างเดียวไม่ได้ คุณต้องเขียน ISBLANK(TEXT(Field__c)) หรือ ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab) ภาษาอังกฤษ) ดังนั้นตัดสินให้ชัดว่า “ไม่มีค่า” หมายถึงอะไรสำหรับทุก picklist: อนุญาตไหม และเมื่อเกิดขึ้นหมายความว่าอะไร? แล้วทำให้สูตร กฎการตรวจสอบความถูกต้อง และตัวกรองของคุณรองรับมัน

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

ตระกูลข้อความ

ผมสอนข้อความเป็นสองแบบ และเส้นแบ่งระหว่างมันคือ 255 อักขระ

ไม่เกิน 255: เก็บไว้กับเรกคอร์ด Text เก็บได้ถึง 255 อักขระ และคุณใช้มันได้เกือบทุกที่: ในสูตร ตัวกรอง รายงาน list view เป็นฟิลด์ที่ไม่ซ้ำหรือ External ID และทำดัชนีได้ Text Area ก็เก็บได้ 255 เช่นกัน แบบหลายบรรทัด เหมือนบันทึกสั้นๆ

เกิน 255: เก็บแบบอ้างอิง Text Area (Long) เก็บได้ถึง 131,072 อักขระ และ Text Area (Rich) เก็บได้เท่ากันพร้อมการจัดรูปแบบ ลิงก์ และรูปภาพ ผมนึกภาพว่ามันถูกเก็บไว้ด้านข้าง โดยเรกคอร์ดถือตัวชี้ไว้ และมันก็ทำตัวแบบนั้น: ไม่มีดัชนี คุณจึงทำให้มันเป็นค่าไม่ซ้ำหรือ External ID ไม่ได้ กรองมันในคำสั่ง WHERE ของ SOQL ไม่ได้ (SOQL WHERE (opens in a new tab) ภาษาอังกฤษ) สูตรใช้มันไม่ได้ (Formula Field Limits and Restrictions (opens in a new tab) ภาษาอังกฤษ) และรายงานแสดงฟิลด์ที่กำหนดเองแบบนี้เพียง 254 อักขระแรก โดยตัวกรองรายงานค้นหาแค่ราว 255 อักขระแรก (Filter Restrictions for Text Area (Long) Fields (opens in a new tab) ภาษาอังกฤษ) รูปภาพที่อัปโหลดลงฟิลด์ rich text มีขนาดได้ถึงรูปละ 1 MB และนับรวมในพื้นที่จัดเก็บไฟล์ ส่วนข้อความนับรวมในพื้นที่จัดเก็บข้อมูล (Rich Text Area Field Considerations (opens in a new tab) ภาษาอังกฤษ) ดังนั้นถ้าใครต้องค้นหา เรียงลำดับ จับคู่ หรือทำรายงานจากค่านั้น ให้เก็บไว้ไม่เกิน 255 และใช้ฟิลด์ Text

Text (Encrypted) เก็บได้ถึง 175 อักขระในรูปแบบเข้ารหัส โดยใช้ Classic Encryption ถ้า org ของคุณใช้ Shield Platform Encryption คุณจะเข้ารหัสฟิลด์ Text ธรรมดาแทน และฟิลด์ประเภทอื่นอีกมากก็เข้ารหัสด้วยวิธีนั้นได้เช่นกัน

ให้ทุกฟิลด์มีคำอธิบาย

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

บนออบเจกต์ที่ใช้ร่วมกันมาก (บัญชี ผู้ติดต่อ โอกาสทางการขาย) ผมยังใช้คำนำหน้าชื่อสำหรับฟิลด์เฉพาะทาง เพื่อให้ที่มาและจุดประสงค์ปรากฏในชื่อเลย: เช่น ทุกอย่างที่ ERP เป็นเจ้าของขึ้นต้นด้วยคำนำหน้าเดียวกัน ผมไม่ได้ต้องการ API name ยาวสิบสองคำ ผมต้องการให้โมเดลอธิบายตัวเองได้

จัดประเภทสิ่งที่สำคัญ: ฟิลด์อนุกรมวิธาน

Salesforce ให้ชุดเมทาดาทาการจัดประเภทแก่ทุกฟิลด์ ผมเรียกมันว่าฟิลด์อนุกรมวิธาน (taxonomy fields) คุณบันทึกเจ้าของข้อมูล การใช้งานฟิลด์ (Active, DeprecateCandidate, Hidden) ระดับความอ่อนไหวของข้อมูล (Public, Internal, Confidential, Restricted, MissionCritical) และหมวดการปฏิบัติตามกฎระเบียบ: PII, HIPAA, GDPR, PCI, CCPA และอื่นๆ ได้ มันใช้ได้กับฟิลด์มาตรฐานและที่กำหนดเอง (Data Classification Metadata Fields (opens in a new tab) ภาษาอังกฤษ)

ทำไมต้องใส่ใจ? เพราะกระบวนการอ่านมันได้ ทำเครื่องหมายฟิลด์ว่า GDPR แล้วกระบวนการก็หาทุกฟิลด์ GDPR บนเรกคอร์ดแล้วปิดบังหรือลบได้ และเมื่อ trust layer ของ Salesforce ส่ง prompt ไปยังโมเดลภาษาขนาดใหญ่ มันใช้การจัดประเภทนี้เพื่อปิดบังฟิลด์ที่อ่อนไหวได้: มันสลับชื่อลูกค้า เช่น “Maria Lopez” เป็นตัวยึดตำแหน่งขาออก โมเดลไม่เคยเห็นชื่อนั้น และชื่อถูกสลับกลับเข้าไปในคำตอบขาเข้า (Einstein Trust Layer (opens in a new tab) ภาษาอังกฤษ)

อัปเดต ตอนนี้ Salesforce ระบุในเอกสารว่าการปิดบังข้อมูลแบบอิงรูปแบบและอิงฟิลด์สำหรับ LLM ถูกปิดสำหรับเอเจนต์: การปิดบังอาจลบบริบทที่เอเจนต์ต้องใช้ในการตอบ (Data Masking Limitations in Agentforce (opens in a new tab) ภาษาอังกฤษ) การจัดประเภทยังขับเคลื่อนการปิดบังสำหรับฟีเจอร์ generative AI อื่นๆ แต่อย่าพึ่งมันในการกันข้อมูลส่วนบุคคลออกจากเอเจนต์ นั่นเป็นการตัดสินใจเรื่องการเข้าถึงและการออกแบบ (บทที่ 12)

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

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

ทุกฟิลด์คือพันธะ

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

Click to enlarge

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

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

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

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

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02)
• Salesforce Help, Einstein Trust Layer: Designed for Trust (opens in a new tab) และ Data Masking Limitations in Agentforce (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02)
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02)
• Salesforce Help, Picklist Limitations (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02)
• Salesforce Help, Formula Field Limits and Restrictions (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02)
• Salesforce Developers, Date Formats and Date Literals (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02)