الحقول معمارية أيضًا

🌐 متاح أيضًا بـ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)

صورة مولّدة بالذكاء الاصطناعي

ترجمة بالذكاء الاصطناعي. لم يراجعها المجتمع بعد. اقرأ بالإنجليزية

الوحدة 6 من 10 في فصل معمارية بيانات Salesforce، الفصل 3 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: اختر الكائن المناسب · التالي: للعلاقات عواقب

السؤال الذي تجيب عنه هذه الوحدة: كيف ينبغي أن تمثّل Salesforce كل قطعة من البيانات تمثيلًا ماديًا؟

إنشاء حقل يستغرق نحو دقيقة. New Field، اختر نوعًا، سمّه، Next، Next، Save. ولهذا بالضبط لا تُعامل الحقول كمعمارية.

ادخل مؤسسة عمرها عشر سنوات وافتح الحساب. خمسمئة حقل. Status2__c، Legacy_Status__c، Old_Status__c، Status_New__c. ثلاثة أرقام عملاء مختلفة. خانة اختيار لن يحذفها أحد لأن أحدًا لا يعرف أي تكامل ما زال يستخدمها. إنشاء الحقل استغرق دقيقة. والعيش معه يستغرق سنوات. لذا ففكرة هذه الوحدة بسيطة: الحقل قرار معماري. ليس دائمًا قرارًا كبيرًا، لكن كل حقل يرمّز شيئًا عن معنى البيانات أو سلوكها أو تعريفها أو جودتها، ومثل الكائنات، الحقول سهلة الإضافة وصعبة الإزالة على نحو مفاجئ.

ماذا تعني هذه البيانات فعلًا؟

في الفصل 2 أعطينا كياناتنا سمات: للتوصيلة نافذة زمنية مجدولة، وللشاحنة رقم VIN. والآن ننفّذها، وهنا يقفز الناس مباشرة إلى «حقل نصي». انتظر. قبل النوع، أريد أن أعرف ما الذي تعنيه البيانات. هل هي رقم، أم معرّف تصادف أنه يحتوي على أرقام؟ تاريخ، أم لحظة في الزمن؟ نص حر، أم واحد من مجموعة معتمدة؟ يُدخله شخص، أم يملكه نظام آخر؟ هل يمكن أن يتغير؟ هل يجب أن يكون فريدًا؟ هل يمكن أن يكون مفقودًا؟ هل ينبغي تخزينه أصلًا، أم حسابه؟ هذه ليست أسئلة Setup. إنها أسئلة معمارية بيانات، ونوع الحقل يأتي بعد أن نجيب عنها.

الرقم ليس دائمًا رقمًا

تعطي Steve Trucking كل شاحنة رقمًا في الأسطول، مثل 001247. حقل Number؟ على الأرجح لا. هل نجمع أرقام الأسطول معًا؟ هل الشاحنة 1247 ناقص الشاحنة 1246 تساوي شاحنة واحدة؟ إنه معرّف تصادف أنه يحتوي على أرقام، بل إن حقل Number سيُسقط الأصفار البادئة. والأمر نفسه ينطبق على الرموز البريدية، ورموز المنتجات، وأرقام الحسابات، وأرقام التتبع. شكل القيمة لا يخبرك بمعناها. اختر النوع من أجل السلوك الذي تحتاج إليه، لا وفق شكل البيانات النموذجية.

هل يحتاج إنسان إلى التعرّف عليه؟

كل كائن مخصص يحصل على حقل Name، والقرار الأول هو نص أم رقم تلقائي. أسأل: هل يحتاج إنسان إلى التعرّف على هذا الشيء؟ يعرف الناس شريك التجزئة باسمه والشاحنة برقمها في الأسطول. لكن بيان شحنة (manifest) يولّده النظام كل ليلة؟ لا ينبغي لأحد أن يكتب «Manifest 10-02 Number 3» لأن Salesforce طلبت اسمًا. أعطه رقمًا تلقائيًا. فقط لا تخلط بين ذلك الاسم المولَّد ومعرّف السجل: الرقم التلقائي يساعد المستخدمين، ومعرّف Salesforce يعرّف السجل، ومرجع بيان الشحنة الخاص بشريك التجزئة قد يعرّف الشيء نفسه عبر الأنظمة. ثلاث مهام مختلفة.

شاشة التفاصيل

اختر نوعًا، وانقر Next، فيطلب منك Setup التفاصيل. هذه هي الشاشة التي تُتخذ فيها فعلًا معظم قرارات هذه الوحدة، وعادةً على عجل.

New Custom Field، الخطوة 2: التفاصيل (لقطة شاشة، 2026-10-12). الحجم الكامل

خانتان تتشابهان وتؤديان مهمتين مختلفتين. Description (الوصف) للأشخاص الذين يصونون المؤسسة، والآن لأدوات الذكاء الاصطناعي التي تقرؤه: ما يعنيه الحقل، ومن يملكه، ومن أين يأتي. وHelp Text (نص المساعدة) للمستخدم على الشاشة: ما الذي يكتبه هنا. املأ الاثنين. ثم تأتي Required وUnique وExternal ID، وكل واحد منها يستحق قسمًا خاصًا به. وتحتها، يمكن أن تكون Default Value (القيمة الافتراضية) صيغة، بحيث يبدأ السجل الجديد بقيمة معقولة بدلًا من الفراغ.

Required قرار أكبر مما يبدو

في معالج الحقول خانة اختيار صغيرة اسمها Required (إلزامي)، وكما رأينا في الفصل 1، يمكن أن تكون قنبلة موقوتة. لديك كائن منذ خمس سنوات ومليونا سجل، والآن يقرر أحدهم أن حقلًا جديدًا يجب أن تكون له قيمة دائمًا. ماذا عن المليوني سجل السابقة له؟ والتكاملات التي لا ترسله؟ والأتمتة التي تُنشئ السجل قبل أن تُعرف القيمة؟ والعملية التي لا تظهر فيها القيمة إلا بعد ثلاث خطوات؟

«إلزامي» يبدو قرارًا يتعلق بجودة البيانات، وأحيانًا يكون كذلك. لكن متى تصبح القيمة معروفة جزء من عملية العمل. لذا لا تحدد Required لأن أحدهم يقول «نريد ذلك دائمًا». اسأل متى تُعرف، ومن يقدّمها، وما الذي يحدث حين لا تكون موجودة. وسنضع هذا على سُلّم الاتساق الكامل في الوحدة 7.

Unique له معنى أيضًا

إذا وسمت حقلًا بأنه فريد، فأنا أُدلي بتصريح عن العمل: لا «إنه لا يتكرر عادةً»، بل «لا يجوز أبدًا أن يحمل سجلان هذه القيمة». هذا قوي. والشاشة تجعلك تقرر شيئًا آخر: هل «ABC» و«abc» القيمة نفسها أم قيمتان مختلفتان؟ عدم التمييز بين حالة الأحرف هو الخيار الافتراضي الأكثر أمانًا لأي شيء يكتبه شخص. وقاعدة المفاتيح من الفصل 2، فريد، وثابت، وبلا معنى، وليس بيانات شخصية أبدًا، تنطبق هنا. إذا قال لي أحدهم إن البريد الإلكتروني للموظف فريد، أبدأ بالسؤال: هل يمكن أن يتغير، وهل يمكن أن يغادر شخص ثم يعود، وهل يمكن إعادة استخدام العناوين، وما الذي يحدث بعد استحواذ؟ قد يكون البريد الإلكتروني مفيدًا، بل فريدًا اليوم. لكن هذا لا يجعله معرّفًا جيدًا.

معرّفات External ID: التعريف عبر الحدود

هنا تثبت External IDs جدارتها. تصفها الشاشة جيدًا: يصبح الحقل «معرّف السجل الفريد من نظام خارجي». لدى نظام ERP العميل 873492؛ ولدى Salesforce معرّف السجل الخاص بها. عندما يرسل نظام ERP تحديثًا، كيف نعرف إلى أي سجل ينتمي؟ اوسم حقلًا بأنه External ID فيستطيع التكامل إجراء upsert عليه: إنشاء السجل إن لم يكن موجودًا، وتحديثه إن كان موجودًا (Upsert a Record Using an External ID (opens in a new tab)). وعندما تحمّل السجلات الأبناء، يمكنك أن تشير إلى الأب بـ External ID الخاص به بدلًا من الاستعلام عن معرّف Salesforce أولًا. أحب أن أقول إنك تدع Salesforce تُجري البحث نيابةً عنك. قوي جدًا.

لاحظ أن رقم نظام ERP لا يصبح معرّف سجل Salesforce. إنه سمة، وقد يحمل السجل عدة سمات من هذا النوع: معرّف العميل في ERP، ومعرّف قديم، ومعرّف لدى شريك. لا بأس بذلك. يمكن أن تعرف عدة أنظمة الكيان التجاري الواحد بطرق مختلفة. والسؤال المعماري هو أي نظام يملك كل معرّف، وما الوعد الذي يقطعه: اوسمه بأنه فريد فقط إذا كان العمل يضمن ذلك حقًا.

نوعًا بعد نوع

والآن الأنواع نفسها. افتح New Field على أي كائن فيعرض لك Setup القائمة كلها، مجمّعة بالطريقة التي سأمر بها عليها: الحقول التي تحسبها Salesforce لك، وحقول العلاقات، ثم أنواع البيانات.

Setup، New Custom Field، الخطوة 1: أنواع البيانات (لقطة شاشة، 2026-10-12). الحجم الكامل

إليك القائمة كلها في لمحة، مع الشيء الوحيد الذي أريدك أن تتذكره عن كل نوع.

المجموعة	النوع	تذكّر
محسوبة	Auto Number	حتى 30 حرفًا، 20 منها للبادئة أو اللاحقة؛ تسمية للناس، لا معرّف السجل
	Formula	تُحسب عند القراءة، ولا تُخزَّن؛ 3,900 حرف
	Roll-Up Summary	عدد السجلات التفصيلية أو مجموعها أو أدناها أو أعلاها؛ في علاقة رئيسي-تفصيلي فقط
العلاقات	Lookup، Master-Detail، External Lookup	الوحدة 7
البيانات	Checkbox	صواب أو خطأ، مع قيمة افتراضية تختارها؛ وقد تظهر null في التدفقات (flows)
	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 (الصيغة) تحسب قيمة من حقول أخرى. إنها قوية، وتُحسب عند قراءة السجل، لا عند حفظه، لذا لا يوجد شيء مخزَّن يمكن أن يتقادم. وأنت تختار ما تُرجعه الصيغة: خانة اختيار، أو عملة، أو تاريخ، أو تاريخ/وقت، أو رقم، أو نسبة مئوية، أو نص، أو وقت.

New Custom Field، الصيغة: اختيار نوع الإرجاع (لقطة شاشة، 2026-10-12). الحجم الكامل

ثم تكتب الصيغة نفسها، بالحقول والعوامل والدوال، وتتحقق من صياغتها. لاحظ زر Use Formula Assistant: سيساعدك الذكاء الاصطناعي من Salesforce الآن في كتابة الصيغة. استخدمه، ثم اقرأ ما كتبه. أنت من يملك الصيغة، لا المساعد.

محرر الصيغ، مع Formula Assistant (لقطة شاشة، 2026-10-12). الحجم الكامل يمكن أن تصل الصيغة إلى 3,900 حرف، ولا يمكن أن تتجاوز 15,000 بايت عند حفظها أو ترجمتها؛ ويمكن تقسيم الصيغة الطويلة على عدة حقول صيغ يشير بعضها إلى بعض. ولا يمكن استخدام حقول Text Area (Long) ولا الحقول المشفّرة ولا حقول Description فيها.

حقول Roll-Up Summary (الملخص التجميعي) تقع على السجل الرئيسي وتحسب عدد سجلاته التفصيلية، أو مجموعها، أو أدناها، أو أعلاها. ولا تعمل إلا عبر علاقة رئيسي-تفصيلي (master-detail)، وهذا من أكبر أسباب اختيار علاقة رئيسي-تفصيلي أصلًا. وسنعود إليها، وإلى حدودها، في الوحدة 7.

مخزَّنة أم مشتقة؟

هل نحتاج إلى تخزين هذه القيمة أصلًا؟ إذا كانت لديّ الكمية وسعر الوحدة، فهل يحتاج أحد، أو أتمتة ما، إلى صيانة إجمالي؟ ربما ينبغي أن تشتقه صيغة: مصدر واحد للحساب، يُعاد حسابه عند القراءة، فتغيّر الكمية وتتبعها الإجابة. وللصيغ حدودها الخاصة (حجم الحفظ وطول العرض؛ Formula Field Limits and Restrictions (opens in a new tab))، والمعقدة منها تصبح صعبة الصيانة.

لكن أحيانًا لا يريد العمل إجابة اليوم. بل يريد الإجابة كما كانت. إذا تغيّرت قاعدة الخصم العام المقبل، فهل ينبغي أن تُظهر فاتورة العام الماضي فجأة مبلغًا مختلفًا؟ بالطبع لا. لذا فالسؤال ليس «هل تستطيع Salesforce حساب هذا؟» بل «هل هذا حساب حالي أم حقيقة تاريخية؟» الحقائق التاريخية تُخزَّن.

حقول العلاقات

علاقات Lookup وMaster-Detail وExternal Lookup حقول أيضًا، وفيها تصبح خطوط نموذجك حقيقية. علاقة البحث هي الرابط الفضفاض؛ وعلاقة رئيسي-تفصيلي تربط حياة الابن وملكيته وأمانه بالأب؛ وعلاقة البحث الخارجية تصل إلى كائن خارجي من الوحدة 4، بالمطابقة على External ID الخاص به. والاختيار بينها قرار كبير بما يكفي ليحصل على وحدة خاصة به.

Checkbox (خانة الاختيار)

خانة الاختيار أبسط حقل على الإطلاق: صواب أو خطأ، محددة أو غير محددة. وهي مثالية لحقيقة نعم/لا عن السجل: Is Active، Install Required، Signed For. عندما تُنشئ واحدة، تجعلك Salesforce تختار قيمتها الافتراضية، محددة أو غير محددة، وهذا قرار حقيقي: إنها ما يبدأ به كل سجل جديد، بما في ذلك السجلات التي يُنشئها تكامل دون أن يرسل الحقل. التقارير وطرق عرض القوائم تصفّيها كـ True وFalse؛ وأدوات الاستيراد والتصدير الأسبوعي تُظهرها كـ 1 و0.

فخ واحد ينبغي معرفته. للحقل على السجل قيمتان، لكن الأتمتة من حوله يمكن أن تكون لها قيمة ثالثة. في التدفق (flow)، متغير خانة الاختيار الذي لم يُضبط قط يكون null، لا false، وحفظه في سجل يفشل (Trailblazer Community (opens in a new tab)؛ وانظر أيضًا مشكلة Salesforce المعروفة W-11208535 (opens in a new tab)). اختر قيمة افتراضية معقولة، واجعل تدفقاتك وشيفرتك تتعامل مع null عن قصد.

Number وPercent وCurrency

Number (الرقم) يخزّن عددًا حقيقيًا، ويُسقط أي أصفار بادئة، ولهذا بالضبط لا يكون رقم الأسطول مثل 001247 من نوع Number. تقرّب Salesforce حقول الأرقام بالنصف بعيدًا عن الصفر: 12.345 تصبح 12.35، و−12.345 تصبح −12.35. وفي حقول الدمج (merge fields)، تقرّب وفق إعدادات المستخدم المحلية (locale)، لا وفق المنازل العشرية التي حددتها على الحقل.

Percent (النسبة المئوية) يخزّن عددًا عشريًا ويعرض نسبة مئوية: أدخل 0.10 فترى 10%. وتفقد القيم دقتها بعد 15 منزلة عشرية.

Currency (العملة) منسّق للمال، وفي مؤسسة بعدة عملات يحمل رمز عملته ويمكنه استخدام أسعار الصرف؛ ومع advanced currency management (opens in a new tab) (الإدارة المتقدمة للعملات)، يمكن للفرص أن تستخدم أسعار صرف مؤرَّخة، أي سعر الفترة التي أُغلقت فيها الصفقة. الفرص وما حولها فقط (المنتجات، والجداول، والتقسيمات، وتقاريرها) تستخدم الأسعار المؤرَّخة؛ أما حقول العملة على الكائنات الأخرى فتحتفظ بالسعر الثابت الواحد. وانتبه إلى التقريب: بلا منازل عشرية، تقتطع Salesforce ببساطة (23.5 تصبح 23)؛ ومع منزلة أو أكثر، تقرّب بالنصف بعيدًا عن الصفر.

Date وDate/Time وTime

ثلاثة أنواع، وثلاثة معانٍ مختلفة. Date (التاريخ) يوم: ينتهي العقد في تاريخ. Date/Time (التاريخ/الوقت) لحظة: وصلت التوصيلة في 9:42 ذلك الصباح. Time (الوقت) وقت من اليوم بلا تاريخ إطلاقًا: يفتح المتجر في 7:00، كل يوم.

الفخ هو اللحظة. تخزّن Salesforce قيم التاريخ/الوقت بتوقيت GMT (UTC). الوقت الذي يكتبه المستخدم يُقرأ في المنطقة الزمنية الخاصة به، ويُحوَّل، ويُخزَّن؛ وعندما يقرؤه أحد، يُحوَّل مرة أخرى إلى المنطقة الزمنية للقارئ. وفي معظم الأحيان هذا بالضبط ما تريده. لكن إليك المثال الذي أعطيه في الصف: منسّق في لوس أنجلوس يسجّل توصيلة في وقت متأخر من ليلة الأحد، الساعة 22:00 بتوقيت المحيط الهادئ. في الأسفل، خزّنت Salesforce صباح الاثنين، الساعة 05:00 بتوقيت GMT. تقرير مجمّع حسب اليوم في منطقة زمنية أخرى، أو تكامل يقرأ القيمة الخام، يمكن أن يضع توصيلة الأحد تلك يوم الاثنين. «اليوم الذي حدث فيه الأمر» يعتمد على ساعة من تسأل. انتبه إلى المناطق الزمنية للمستخدمين، وقرّر أيها يقصده العمل.

وكن حذرًا عند المقارنة بينها. في الأسفل، التاريخ/الوقت رقم واحد كبير: يقرؤه Apex على أنه عدد المللي ثانية منذ 1 يناير 1970، 00:00:00 بتوقيت GMT (Datetime Class (opens in a new tab)). إنه لحظة دقيقة، لا يوم. لذا فالسؤال عما إذا كانت قيمتا تاريخ/وقت متساويتين (==) لا يفعل تقريبًا أبدًا ما تريده: 9:42:00 و9:42:01 غير متساويتين، ولا «الاثنين» وأي لحظة يوم الاثنين. بدلًا من ذلك، اطلب نطاقًا: في البداية أو بعدها (>=) وفي النهاية أو قبلها (<=). «كل توصيلة يوم الاثنين» هي كل توصيلة >= الاثنين 00:00 و<= الاثنين 23:59:59، في المنطقة الزمنية التي قررت أن العمل يقصدها.

وإليك طرفة: لا تستطيع Salesforce تخزين أي تاريخ كان. التواريخ الصالحة تمتد من 1 يناير 1700 حتى 31 ديسمبر 4000، وتعطي Salesforce النطاق نفسه للتواريخ وللتاريخ/الوقت (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) حين يكون لدى المؤسسة نظام هاتف متصل. 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 (العنوان) يحمل عنوانًا كاملًا، الشارع والمدينة والولاية أو المقاطعة والرمز البريدي والبلد، ويستطيع المستخدمون البحث عن عنوان وتعبئة أجزائه تلقائيًا.

كلاهما حقل مركّب: حقل واحد على الشاشة، وعدة حقول في الأسفل. وهما يكلّفان أكثر من حقل واحد من حد كائنك: Geolocation يُحتسب ثلاثة حقول مخصصة، وAddress يُحتسب تسعة. وعلى كائن مزدحم بالفعل، هذا مهم.

Picklist وMulti-Select

قائمة الاختيار (picklist) تتحكم فيما يستطيع المستخدمون إدخاله: قيمة واحدة من قائمة تحددها أنت. الحالة؟ قائمة اختيار، على الأرجح. لكن القيم بيانات وصفية، وعلى مسؤول أن يضيفها أو يغيّرها. لذا ما زلت أسأل من يملك القيم، وكم مرة تتغير، وهل تحتاج عدة كائنات إلى القائمة نفسها، وهل تحمل القيم معلومات خاصة بها، وهل يملك نظام آخر هذه المفردات.

ومكان عيش القيم قرار أيضًا. عندما تُستخدم قائمة مرة واحدة، على حقل واحد، احتفظ بالقيم على الحقل نفسه، على الكائن؛ وهذا ما تفعله Salesforce افتراضيًا. لكن عندما تبدأ المجموعة نفسها من القيم بالظهور في عدة أماكن، منطقة على الحساب، وعلى التوصيلة، وعلى المستودع، رقِّها إلى مجموعة قيم عامة قبل أن تتباعد النسخ. مجموعة القيم العامة (global value set) تحتفظ بقائمة واحدة لها جميعًا، حتى 1,000 قيمة، النشطة وغير النشطة معًا (Picklist Limitations (opens in a new tab)). ووصف Setup نفسه يقول لماذا يهم ذلك: مجموعة القيم «مقيّدة حتى لا يستطيع المستخدمون إضافة قيم غير معتمدة عبر API». قائمة واحدة، ومالك واحد، ولا تكامل يتسلل بتهجئة جديدة.

هذه النقطة الأخيرة هي الفرق بين المقيّدة وغير المقيّدة. في قائمة الاختيار المقيّدة، لا يُسمح إلا بالقيم التي حددها المسؤول، من أي مصدر: المستخدم أو الاستيراد أو التكامل الذي يرسل أي شيء آخر يحصل على خطأ، «bad value for restricted picklist field»، ولا يُحفظ السجل. وفي قائمة الاختيار غير المقيّدة، ما زال المستخدمون يختارون من القائمة على الشاشة، لكن API والاستيراد والأتمتة تستطيع إرسال أي قيمة، فتحفظها Salesforce وتضيفها كقيمة غير نشطة (Picklist Limitations (opens in a new tab)؛ Create a Custom Picklist Field (opens in a new tab)). وهكذا ينتهي الحال بمؤسسة إلى «Delivered» و«delivered» و«Dlvrd». مجموعات القيم العامة مقيّدة دائمًا. خياري الافتراضي هو المقيّدة؛ وغير المقيّدة خيار متعمّد حين يملك نظام آخر القيم حقًا، وعندئذ يتولى أحدهم تنظيف القيم غير النشطة.

Setup، Picklist Value Sets: مجموعة قيم عامة جديدة (لقطة شاشة، 2026-10-12). الحجم الكامل

قائمة الاختيار متعددة التحديد (multi-select picklist) تتيح للمستخدم اختيار عدة قيم، تُخزَّن معًا مفصولة بفواصل منقوطة. مريحة على الشاشة، ومزعجة في كل مكان آخر: أصعب في التصفية والتقارير والتكامل، ولا يمكن استخدامها في مرشح حقل الملخص التجميعي. وعدة قيم لسجل واحد تعني عادةً درس الفصل 2: هناك كائن ابن يحاول الخروج.

ولقائمة الاختيار أيضًا قيمة أكثر من القيم التي حددتها: الفراغ. يمكن أن يبقى السجل بلا شيء محدد، وهذا يوقع الناس. في صيغة أو قاعدة تحقق لا يمكنك اختبار قائمة اختيار بـ ISBLANK وحدها؛ بل تكتب ISBLANK(TEXT(Field__c))، أو ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab)). لذا قرّر ما الذي تعنيه «لا قيمة» لكل قائمة اختيار: هل هي مسموحة، وماذا تعني حين تحدث؟ ثم اجعل صيغك وقواعد التحقق ومرشحاتك تتعامل معها.

وأحيانًا تكون السمة كيانًا في الحقيقة. يطلب أحدهم قائمة اختيار لمراكز التوزيع. هناك تسعة. سهل. ثم نعلم أن لكل واحد عنوانًا ومديرًا وساعات عمل وسعة ومنطقة وشاحنات. هذه ليست قائمة اختيار؛ هذا شيء. لا تحوّل كيانًا إلى قائمة اختيار لمجرد أنه ليس كثيرًا بعد. يبدو ذلك رائعًا في السنة الأولى ومريعًا في السنة الخامسة. (في الوحدة 5 من الفصل 2 قواعدي التقريبية لمتى تستحق القائمة كائنًا خاصًا بها.)

عائلة النصوص

أُدرّس النص على أنه نوعان، والخط الفاصل بينهما 255 حرفًا.

حتى 255: يُخزَّن مع السجل. Text (النص) يحمل حتى 255 حرفًا، ويمكنك استخدامه في كل مكان تقريبًا: في الصيغ، والمرشحات، والتقارير، وطرق عرض القوائم، كحقل فريد أو 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)). والصور المرفوعة إلى حقل نص منسّق يمكن أن تصل إلى 1 MB لكل منها، وتُحتسب على تخزين الملفات، بينما يُحتسب النص على تخزين البيانات (Rich Text Area Field Considerations (opens in a new tab)). لذا إذا احتاج أي أحد إلى البحث في القيمة أو فرزها أو مطابقتها أو إعداد تقارير عليها، فأبقِها تحت 255 وأبقِها حقل Text.

Text (Encrypted) يخزّن حتى 175 حرفًا بشكل مشفّر، باستخدام Classic Encryption. وإذا كانت مؤسستك تستخدم Shield Platform Encryption، فأنت تشفّر حقل Text عاديًا بدلًا من ذلك، ويمكن تشفير أنواع أخرى كثيرة بهذه الطريقة أيضًا.

أعطِ كل حقل وصفًا

معياري: كل حقل يحصل على وصف. أؤمن بهذا منذ زمن طويل، وفي زمن الذكاء الاصطناعي صار أهم من أي وقت مضى: كل أداة ذكاء اصطناعي وكل وكيل يقرأ مؤسستك يقرأ الأوصاف ليفهم ما يعنيه الحقل. الوصف الفارغ تخمين ينتظر أن يحدث. ماذا يعني Customer_Status__c؟ من يملكه؟ من أين يأتي؟ هل يستطيع المستخدمون تعديله، أم سيكتب نظام ERP فوقه الليلة؟ بعد ستة أشهر لن أتذكر، وبعد ثلاث سنوات لن يعرف المسؤول الذي يصون المؤسسة ما لم نخبره. التسمية ليست توثيقًا، ولا اسم API كذلك.

على الكائنات المشتركة بكثافة (الحساب، وجهة الاتصال، والفرصة) أستخدم أيضًا بادئات تسمية للحقول المتخصصة، بحيث يظهر أصلها وغرضها في الاسم نفسه: كل ما يملكه نظام ERP يبدأ بالبادئة نفسها، مثلًا. لا أسعى إلى أسماء API من اثنتي عشرة كلمة. أريد أن يشرح النموذج نفسه بنفسه.

صنّف ما يهم: حقول التصنيف

تعطي Salesforce كل حقل طقمًا من البيانات الوصفية للتصنيف. أسميها حقول التصنيف (taxonomy fields). يمكنك أن تسجّل مالك البيانات (data owner)؛ واستخدام الحقل (field usage) (Active، DeprecateCandidate، Hidden)؛ ومستوى حساسية البيانات (data sensitivity level) (Public، Internal، Confidential، Restricted، MissionCritical)؛ وتصنيف الامتثال (compliance categorization): PII، HIPAA، GDPR، PCI، CCPA وغيرها. وهي تعمل على الحقول القياسية كما تعمل على المخصصة (Data Classification Metadata Fields (opens in a new tab)).

لماذا العناء؟ لأن العمليات تستطيع قراءتها. اوسم حقلًا بـ GDPR فتستطيع عملية أن تجد كل حقل GDPR على سجل وتحجبه أو تزيله. وعندما ترسل طبقة الثقة في Salesforce موجّهًا (prompt) إلى نموذج لغوي كبير، تستطيع استخدام هذا التصنيف بالضبط لحجب الحقول الحساسة: تستبدل اسم العميل، مثلًا «Maria Lopez»، بعنصر نائب في طريق الخروج، فلا يرى النموذج الاسم أبدًا، ويُعاد الاسم إلى الرد في طريق العودة (Einstein Trust Layer (opens in a new tab)).

تحديث. توثّق Salesforce الآن أن الحجب القائم على الأنماط والقائم على الحقول للنماذج اللغوية الكبيرة معطّل للوكلاء: فالحجب قد يجرّد الوكيل من السياق الذي يحتاج إليه للإجابة (Data Masking Limitations in Agentforce (opens in a new tab)). ما زال التصنيف يقود الحجب في ميزات الذكاء الاصطناعي التوليدي الأخرى، لكن لا تعتمد عليه لإبعاد البيانات الشخصية عن وكيل؛ فهذا قرار وصول وتصميم (الفصل 12).

موقفي: التصنيف مهم في الأوقات الحاسمة. لا تحوّله إلى ثلاثة أسابيع من ملء كل خانة لأن الحوكمة قالت ذلك. استخدمه حيث يهم: البيانات الشخصية، والبيانات المالية، والبيانات الخاضعة للتنظيم، والحقول التي يحتاج فيها العمل إلى مالك مسمّى. المقصود أن الحساسية تكفّ عن كونها معرفة في رأس أحدهم وتصبح جزءًا من الحقل.

ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. كان التوثيق الضعيف للحقول يعاقب المسؤول التالي. والآن يضلّل كل أداة ذكاء اصطناعي وكل وكيل يقرأ المخطط: هل Flag2__c حساس، أم مرجعي، أم ما زال مستخدمًا؟ والذكاء الاصطناعي يُنشئ أيضًا الحقول أسرع من أي فريق، لذا فالأسماء والأوصاف والتصنيف جزء من المعمارية، لا من التدبير المنزلي.

كل حقل التزام

بمجرد أن يخرج حقل إلى العالم ويجمع البيانات، يبدأ كل شيء بالاتكاء عليه. الشاشات تعرضه، والتدفقات تتفرع عليه، وقواعد التحقق تفحصه، والتقارير تجمّع حسبه، والتكاملات ترسله وتقرؤه، والآن أدوات الذكاء الاصطناعي تستدل به. كل واحد منها يضع افتراضات عن الحقل: نوعه، وطوله، وما إذا كان فارغًا أبدًا، وماذا تعني قيمه. غيّر الحقل لاحقًا وسيكون عليك أن تجد كل واحد من تلك الافتراضات أولًا. إعادة تسمية قيمة في قائمة اختيار، أو تقصير حقل نصي، أو تحويل حقل Text إلى قائمة اختيار، يبدو تغييرًا صغيرًا، وقد يعطّل تكاملًا في نظام شركة أخرى. لهذا الحقل التزام.

Click to enlarge

لا أريدك أن تغادر هذه الوحدة خائفًا من إنشاء الحقول. Salesforce مبنية لتُوسَّع؛ فاستخدمها. أريد أن يتغير السؤال من «أي نوع حقل أختار؟» إلى «ماذا تعني هذه البيانات، وبأي سلوك نلتزم؟» النوع، والإلزام، والتفرد، وExternal ID، وقائمة الاختيار، والصيغة، والوصف، والتصنيف: معًا هي التعبير المادي عن النموذج المنطقي من الفصل 2.

ما الذي يقرره المعماري هنا

• ما الذي تعنيه القيمة قبل اختيار نوع الحقل، وهل هي سمة، أم معرّف، أم مفردات مضبوطة، أم في الحقيقة كيان آخر.
• هل القيمة حساب حالي يمكن اشتقاقه أم حقيقة تاريخية يجب تخزينها.
• أي نظام يملك كل معرّف، وهل تفرّده وعد عمل حقيقي.
• متى تُعرف القيمة الإلزامية فعلًا، وما الذي يحدث للسجلات والتكاملات التي لا تملكها.
• ما الوصف والتسمية والتصنيف التي يحتاج إليها الحقل حتى يستطيع الناس والعمليات والذكاء الاصطناعي استخدامه بأمان.

للاستزادة

• 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).