اختر الكائن المناسب
متاح أيضًا بـ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)
الوحدة 5 من 10 في فصل معمارية بيانات Salesforce، الفصل 3 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: أين تعيش هذه البيانات؟ · التالي: الحقول معمارية أيضًا
السؤال الذي تجيب عنه هذه الوحدة: أي نوع من كائنات Salesforce ينبغي أن يصبحه مفهوم العمل هذا، وما الذي تسمح به التراخيص؟
من أسهل الأشياء في Salesforce إنشاء كائن مخصص. ولهذا بالضبط أظن أننا نُنشئ منها الكثير.
أنت في جلسة متطلبات ويقول أحدهم: «نحتاج إلى تتبّع موزّعينا». كائن مخصص جديد: Distributor. انتهى. إلا أنني أريد من المعماري أن يطرح سؤالًا مختلفًا أولًا: ما هو الموزّع؟ إنه شركة. ولدى Salesforce بالفعل طريقة جيدة جدًا لتمثيل الشركة. اسمها الحساب (Account). هذا لا يعني أن الإجابة دائمًا هي الحساب. لكن إذا كان عليّ أن أشرح لماذا لا تكون شركة ما حسابًا، فأريد سببًا أفضل من «الإدارة تسميهم موزّعين».
هنا يلتقي النموذج المنطقي من الفصل 2 بالمنصة، وموقفي المبدئي بسيط: إذا كان مفهوم العمل يتوافق توافقًا نظيفًا مع الغرض المقصود من كائن قياسي، فابدأ من هناك.
ابدأ بالمعنى
Section titled “ابدأ بالمعنى ”حتى عندما يستحق شيء ما أن يكون كائنًا، فهو لا يستحق تلقائيًا أن يكون كائنًا مخصصًا. اسأل ما الذي يمثله الشيء فعلًا. عمل تجاري أو منظمة بأي شكل؟ ابدأ بالحساب. شخص يعمل مع تلك المنظمة؟ جهة اتصال (Contact). شيء يملكه العميل أو اشتراه؟ الأصل (Asset). شيء تحاول بيعه؟ الآن تدخل الفرصة (Opportunity) في الحديث.
لهذا نظرنا إلى السفينة الأم أولًا، في الوحدة 2. تلك النماذج لا تناسب كل عمل تجاري، لكن لا ينبغي أن نتجاهلها لأن بناء نموذجنا الخاص يبدو أنظف. قبل New Custom Object، اسأل كيف تنمذج Salesforce هذا المفهوم، وما الذي بُني حول ذلك النموذج، وما الذي ستتخلى عنه إذا استبدلته.
اختبار التوافق النظيف
Section titled “اختبار التوافق النظيف ”اختباري سؤال واحد: هل يتوافق مفهوم العمل هذا توافقًا نظيفًا مع الغرض المقصود من الكائن القياسي؟ إذا كان كذلك، فميلي نحو الكائن القياسي.
الموزّع شركة لنا علاقة بها، لذا فالحساب توافق نظيف. لا يضايقني أن يسمي المستخدمون شركة ما موزّعًا، وأخرى مورّدًا، وأخرى شريك تجزئة، وأخرى عميلًا. هذه أدوار عمل، ولا تحتاج إلى أربعة كائنات مادية. أسماء العمل المختلفة لا تعني تلقائيًا بُنى بيانات مختلفة. يمكن لنوع، أو نوع سجل، أو علاقة أن يحمل الفرق.
والاختبار يعمل في الاتجاه الآخر أيضًا. في الفصل 1 تركتك مع سؤال: لدى عمل تجاري لأحد العملاء مواقع توصيل كثيرة. هل ينبغي أن يكون كل موقع حسابًا، أم كائنًا مخصصًا؟
الحساب يعطيك الكثير. تحصل على حقول العنوان، وعلى كل ما يتوقع عنوان حساب أصلًا: التقارير، والخرائط، والتكاملات. لكنك تحصل أيضًا على العبء: حقول كثيرة، ومشاركة، وتسلسل هرمي، وملكية، وكل ما يتعلق بالحساب، ومعظمه لا صلة له بعنوان منفصل. ستحمل أشياء ثقيلة كثيرة لن تستخدمها، من أجل عنوان بديل فقط.
أما الكائن المخصص، ابنًا للحساب، فيمكن أن يكون خفيفًا: حقول العنوان فقط، مكان نوصل إليه، بدورة حياة خاصة به أستطيع التحكم فيها باستقلال.
إذن هو توازن: الوزن الذي تتحمله مقابل القيمة التي تحصل عليها. إذا كان كل ما أحتاجه عنوانًا بدورة حياة خاصة به، فهنا أتجه إلى المخصص.
والأمر نفسه مع المشكلات الفرعية في الحالة. إذا كانت كل مشكلة فرعية حالة حقًا، يعمل عليها وكيل خدمة، ولها حالتها ومستوى خدمتها، فاجعلها متداخلة عبر Parent Case من الوحدة 2. لكن إذا كانت مجرد بند في قائمة مراجعة لا يعمل عليه أحد كحالة، فالحالة الكاملة تحمل الكثير مما لن تستخدمه أبدًا، وقد يكون ابن مخصص بسيط أخف وزنًا. لا لأن المخصص أنظف. بل لأن المعنى مختلف، أو الوزن غير مناسب.
الكائنات القياسية تأتي بأمتعتها
Section titled “الكائنات القياسية تأتي بأمتعتها ”عندما تختار كائنًا قياسيًا، فأنت تختار أكثر من حقوله. أنت تختار شيئًا تفهمه منتجات Salesforce بالفعل: التقارير، والأتمتة، والعلاقات المدمجة، وميزات المنتجات، وحزم AppExchange، وكل ما ستبنيه Salesforce لاحقًا. ويمكن أن يكون لذلك قيمة هائلة.
والكائنات القياسية تأتي أيضًا بآرائها: سلوك قائم، وعلاقات، واعتبارات أمنية، وأحيانًا متطلبات ترخيص، وميزات لا تحتاج إليها. لذا فإن «استخدم الكائنات القياسية دائمًا» ليست قاعدتي. ليست لديّ قاعدة «دائمًا». لديّ ميل: استخدم الكائن القياسي حين يكون المعنى توافقًا نظيفًا ويكون سلوك المنصة حوله عونًا للتصميم لا خصمًا له. إذا قضيت خمس سنوات أجعل الفرصة تتصرف كشيء ليس فرصة بيع، فلم أكسب شيئًا بالبقاء على القياسي. كل ما فعلته أنني قدّمت التنازل الخاطئ في الاتجاه الآخر.
الأصل مثال جيد
Section titled “الأصل مثال جيد ”الأصل (Asset) أحد الكائنات القياسية التي يغفل عنها الناس. أبسط طريقة أستطيع أن أصوغه بها: إنه شيء يملكه العميل. ربما اشتراه منا، وربما لا. ما زلت أهتم بمنتج لمنافس موجود في موقع عميلي، لأنني أصونه، أو أحاول استبداله، أو أحتاج إلى فهم قاعدته المركّبة. إذا أنشأت Customer_Product__c دون أن أنظر إلى الأصل أولًا، فقد تخطيت سؤالًا معماريًا. الأصل لا يفوز تلقائيًا، لكنه يستحق التقييم.
الحسابات الشخصية: متى يكون الشخص هو الحساب؟
Section titled “الحسابات الشخصية: متى يكون الشخص هو الحساب؟ ”في الوحدة 2 تعرّفنا إلى الحسابات الشخصية: حساب وجهة اتصال في سجل واحد، للعملاء الأفراد. والآن القرار.
موقفي: في B2C، يصعب الاستغناء عنها. فالكثير يأتي جاهزًا مع الحسابات وجهات الاتصال إلى حد أن التكلفة والعبء يستحقان. وهناك تكلفة فعلًا: نحو ضعف تخزين حساب الأعمال، ومفتاح لا يمكنك إيقافه، وبعض التراخيص الخارجية لا تستطيع استخدامها. فلا يمكن استخدام Partner Community مع الحسابات الشخصية (Experience Cloud User Licenses (opens in a new tab)). لذا فالسؤال ليس «هل لدينا أشخاص في قاعدة بياناتنا؟» كل مؤسسة لديها أشخاص. بل هو «هل الشخص هو الحساب فعلًا في هذا العمل؟» كون جهة الاتصال شخصًا لا يجعلها حسابًا شخصيًا. العلاقة التجارية هي التي تفعل ذلك.
والآن دعني أعقّد كل شيء: التراخيص
Section titled “والآن دعني أعقّد كل شيء: التراخيص ”حتى الآن: حدّد المفهوم، وابحث عن أنظف توافق قياسي، واتجه إلى المخصص حين لا يتوافق المعنى. والآن سؤال المعماري التالي: من يحتاج إلى استخدامه؟ يمكنك أن تصمّم نموذجًا جميلًا ثم تكتشف أن نصف الأشخاص الذين يحتاجون إلى البيانات غير مرخّصين للكائنات التي اخترتها. التراخيص جزء من نموذج البيانات.
ثلاثة تراخيص داخلية
Section titled “ثلاثة تراخيص داخلية ”ابدأ بموظفيك. داخل الشركة، هناك ثلاثة أنواع من التراخيص أريد أن يعرفها كل معماري عن ظهر قلب، لأنها تحدد ما يستطيع كل مستخدم رؤيته وفعله، وبالتالي ما يستطيع نموذج بياناتك الاعتماد عليه.
Sales Cloud (الآن Agentforce Sales). لهؤلاء المستخدمين ترخيص المستخدم الكامل Salesforce: كائنات CRM القياسية، وأي تطبيق قياسي أو مخصص. أي العملاء المحتملين والفرص والتوقعات فوق الحسابات وجهات الاتصال، بل والحالات أيضًا: يستطيع مندوب المبيعات رؤية الحالات المفتوحة لعميل قبل مكالمة. أما إنشاء الحملات وتشغيلها فيتطلب قطعة أخرى، هي ترخيص الميزة Marketing User.
Service Cloud (الآن Agentforce Service). ترخيص المستخدم Salesforce نفسه، مُعدّ للخدمة. الحالات في المركز، ويُعمل عليها في Service Console: ترخيص الميزة Service Cloud User هو ما يفتح Salesforce Console for Service. وهنا تعيش اتفاقيات مستوى الخدمة (SLA)، عبر إدارة الاستحقاقات والمعالم (milestones)، وهنا يأتي Knowledge، الذي تشتريه معظم الإصدارات كإضافة.
Platform (Salesforce Platform). للأشخاص الذين يحتاجون إلى تطبيقاتك المخصصة، لا إلى CRM. يحصلون على الحسابات، وجهات الاتصال، والتقارير، ولوحات المعلومات، والمستندات، وكل تطبيق مخصص في المؤسسة. وما لا يحصلون عليه: التوقعات، والعملاء المحتملون، والحملات، والفرص. تكلفته أقل، ولهذا بالضبط تعمل عليه تطبيقات مخصصة كبيرة كثيرة، ولهذا بالضبط يمكن أن يوقع نموذج بياناتك في الخطأ.
| Sales Cloud | Service Cloud | Platform | |
|---|---|---|---|
| ترخيص المستخدم | Salesforce | Salesforce | Salesforce Platform |
| مصمَّم من أجل | البيع | دعم العملاء | التطبيقات المخصصة |
| الحسابات، جهات الاتصال | نعم | نعم | نعم |
| العملاء المحتملون، الفرص، التوقعات | نعم | نعم | لا |
| الحالات | نعم، لرؤية حالات العميل | في المركز، في Service Console | لا |
| اتفاقيات مستوى الخدمة | لا | نعم، الاستحقاقات والمعالم | لا |
| الكائنات والتطبيقات المخصصة | نعم | نعم | نعم |
اقرأ الجدول كما يقرؤه المعماري. إذا كانت مجموعة كبيرة من المستخدمين على Platform، فأي تصميم يضع عملهم على الفرصة معطّل قبل أن يبدأ. وإذا احتاج المديرون التنفيذيون إلى أرقام SLA، فالترخيص الذي يحملونه يقرر ما إذا كانوا يستطيعون رؤيتها. هذه الأنواع الثلاثة تحدد السلوك.
عندما يقرر الترخيص الكائن
Section titled “عندما يقرر الترخيص الكائن ”الفرصة هي الضحية التي صادفتها أكثر من غيرها. رأيتها في الجدول: مستخدمو Platform لا يحصلون عليها (Standard User Licenses (opens in a new tab))، ومستخدمو Customer Community لا يستطيعون العمل عليها أيضًا. فيبدو المتطلب كأنه فرصة، ويقول أحدهم «لنستخدم الفرصة»، ثم أسأل من يحتاج إلى الوصول. إذا كانت شريحة كبيرة على تراخيص Platform أو Customer Community، فالترخيص لم يعد تفصيلًا من تفاصيل الشراء. إنه قيد معماري، وعادةً ما يدفع التصميم نحو كائن مخصص.
ويعمل الأمر صعودًا أيضًا. في الصف أسأل: الرئيس التنفيذي يريد لوحات معلومات جميلة؛ ترخيص Sales أم Service؟ مستخدم Sales يستطيع رؤية كائنات المبيعات بل والحالات، لذا فلوحات المبيعات وأعداد الحالات المفتوحة يكفيها Sales. لكن لحظة أن يريد المدير التنفيذي مؤشرات أداء SLA (كم تبقى حتى تتجاوز الحالة مستوى خدمتها)، فإن تلك البيانات تقع في الاستحقاقات والمعالم، وإدارة الاستحقاقات تحتاج إلى Agentforce Service، المعروف سابقًا بـ Service Cloud (Supported Editions for Service Features (opens in a new tab)). والآن أنت تُرقّي تراخيص المديرين التنفيذيين. أصغِ إلى متطلب العمل، واعرف أي ترخيص يقع تحت البيانات التي يحتاج إليها.
الملعب
Section titled “الملعب ”أفكر في التراخيص كأنها مقاعد في ملعب. الجميع يشاهدون المباراة نفسها. إذا اشتريت المقاعد الغالية في المنتصف، أرى الفريقين عن قرب. وإذا كنت في الأعلى في الزاوية على المدرجات المكشوفة، فالمقاعد غير مبطّنة وأشاهد بالمنظار.
هذه هي التراخيص الخارجية، للأشخاص من خارج الشركة: العملاء والشركاء الذين يسجلون الدخول إلى موقع Experience Cloud. وهناك ثلاثة أريدك أن تعرفها.
Customer Community: المدرجات المكشوفة. مصمَّم لأعداد كبيرة من المستخدمين الخارجيين الذين يحتاجون إلى الحالات والمعرفة: عميل يتابع حالة الدعم الخاصة به. تكلف المقاعد نحو النصف ويمكن أن تُمنح لأعداد هائلة من المستخدمين. وما الذي تخسره هناك في الأعلى؟ التقارير، ولوحات المعلومات، وجدول المشاركة: المشاركة القائمة على الأدوار التي تحصل عليها الفئات الأعلى. وهو يعمل مع الحسابات الشخصية.
Customer Community Plus: في منتصف الطريق نزولًا. تصفه Salesforce بأنه الترخيص للمستخدمين الخارجيين الذين يحتاجون إلى التقارير ولوحات المعلومات والمشاركة القياسية: عميل يدير وصول أشخاص آخرين، أو يحتاج إلى رؤية أرقامه.
Partner Community: أقرب من ذلك، للأعمال بين الشركات (B2B)، مع الوصول إلى بيانات المبيعات. يعمل الشركاء على العملاء المحتملين والفرص: يسجلون الصفقات، ويديرون الحملات معك. هذا هو المقعد الخارجي الذي يصل إلى كائنات المبيعات. وفيه عقبة واحدة: لا يمكن استخدامه مع الحسابات الشخصية (Experience Cloud User Licenses (opens in a new tab)).
الخطأ هو التصميم كأن الجميع يحملون التذكرة الغالية، ثم الاكتشاف عند التنفيذ أن معظم مستخدميك لا يستطيعون دخول القسم الذي وضعت فيه بياناتهم. حينها لديك ثلاثة خيارات: شراء مقاعد مختلفة، أو نقل التجربة، أو إعادة تصميم النموذج. والثلاثة كلها معمارية.
طريقة الدفع تغيّر التصميم
Section titled “طريقة الدفع تغيّر التصميم ”هناك سؤال آخر ينساه الناس: كيف سيسجّل هؤلاء المستخدمون الدخول؟ تأتي التراخيص الخارجية بشكلين. على أساس العضوية (member-based): تدفع لكل مستخدم، وهذا يناسب 500 شريك يسجلون الدخول كل يوم. على أساس تسجيل الدخول (login-based): تشتري عددًا من عمليات تسجيل الدخول شهريًا، وهذا يناسب خمسة ملايين عميل يسجلون الدخول بضع مرات في السنة. وتسجيل الدخول أكثر من مرة في اليوم نفسه يُحتسب تسجيل دخول واحدًا (Experience Cloud User Licenses (opens in a new tab)).
لذا عندما يقول أحدهم «نبني بوابة للعملاء»، فسؤالي التالي ليس أي قالب. بل: من هم العملاء، وكم عددهم، وكم مرة يأتون، وما البيانات التي يحتاجون إليها، وما المسموح لهم أن يفعلوه بها؟
عندما يشكّل الترخيص النموذج
Section titled “عندما يشكّل الترخيص النموذج ”أحيانًا لا يختار الترخيص الكائن فحسب؛ بل يلوي النموذج كله. بعض تراخيص المنصة تقصر المستخدمين على تطبيق مخصص واحد من عشرة كائنات مخصصة كحد أقصى (مثل Lightning Platform – One App؛ Standard User Licenses (opens in a new tab)).
في مشروع مبكر، لشركة كبيرة للخدمات المهنية والإنشاءات، كان علينا أن نبني شيئًا يشبه LinkedIn للقوى العاملة كلها: وظائف الجميع، ومهاراتهم، وشهاداتهم، ولغاتهم، ومشاريعهم، حتى يتمكنوا من إيجاد باني الجسور المعتمد في بلد معين. لولا الحد، لبنيت كائنًا للمستخدم والوظيفة، والمستخدم والمهارة، والمستخدم والشهادة، والمستخدم واللغة، والمستخدم والمشروع، إضافة إلى قوائم مرجعية للشهادات والمشاريع. لكن تحت ترخيص من عشرة كائنات، ومع تعليمات بعدم استنفادها كلها، لم يكن ذلك ممكنًا. فصار الأمر لعبة «خمّن اللحن»: بأقل كم كائن أستطيع بناء هذا؟ كانت الإجابة اثنين. كائن مرجعي واحد، بنوع سجل لكل نوع من القوائم (وظيفة، مهارة، شهادة، لغة، مشروع)، وكائن واحد لسمات المستخدم، بأنواع سجلات مطابقة، يشير إليه.
لم يكن النموذج الأمثل. كان إعداد التقارير عليه مزعجًا، وكنت أفضّله أنظف. لكن هذا ما سمح به الترخيص. أسمّي هذه كائنات السكين السويسرية: احتفظ بهذا النمط في جيبك الخلفي، وحين لا تترك الحدود مجالًا، اكسر الزجاج واتجه إلى الفصل بأنواع السجلات. فقط اعرف ما الذي تقايضه. فالأذونات المختلفة لكل نوع سجل قد تجبرك على تقسيم الكائن على أي حال.
لم يعد الناس هم المستخدمين الوحيدين
Section titled “لم يعد الناس هم المستخدمين الوحيدين ”أصبح سؤال آخر عن التراخيص مهمًا: ماذا عن الأشياء التي ليست أشخاصًا؟ للتكاملات هويات. وللوكلاء هويات. ولدى Salesforce الآن ترخيص Salesforce Integration للتكاملات بين الأنظمة: عبر API فقط، وليس للبشر، مع خمسة مضمّنة في كل مؤسسة من إصدارات Enterprise وUnlimited وPerformance (Standard User Licenses (opens in a new tab)). لذا لا تسأل فقط أي المستخدمين يحتاجون إلى الوصول. اسأل أي الهويات تحتاج إليه: شخص، أو عميل، أو شريك، أو تكامل، أو وكيل. ثم ما الذي يحتاج كل منها إلى رؤيته وفعله.
ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. مع تحوّل الوكلاء إلى مستهلك آخر للبيانات ومنشئ لها، لم يعد اختيار الكائن والتراخيص متعلقًا بالشاشات البشرية فقط. اعرف بأي هوية يعمل الوكيل، وما الذي تستطيع تلك الهوية الوصول إليه، وما إذا كان النموذج يضع البيانات التي يحتاج إليها خلف كائن أو إذن لا يستطيع استخدامه.
Steve Trucking: حالة سهلة وأخرى صعبة
Section titled “Steve Trucking: حالة سهلة وأخرى صعبة ”تعمل Steve Trucking مع شركاء التجزئة (Retail Partners). ما هو شريك التجزئة؟ عمل تجاري. سهل: الحساب. لا أُنشئ Retail_Partner__c لأن أحدهم استخدم كلمة «شريك».
والآن المستلم (Recipient)، الشخص الذي يستلم الثلاجة. جهة اتصال؟ حساب شخصي؟ شيء آخر؟ مليون مستلم جديد في السنة، وهم عملاء شركاء التجزئة، لا عملاؤنا. هذا بالضبط نوع السؤال الذي لا أريد فيه أن أقفز إلى كائن قبل أن أفهم العلاقة والوصول والحجم. وسنقرره في نقطة التحقق في نهاية الجزء 1.
ما الذي يقرره المعماري هنا
Section titled “ما الذي يقرره المعماري هنا ”- هل يتوافق مفهوم العمل توافقًا نظيفًا مع الغرض المقصود من كائن قياسي، أم أن معناه أو وزنه مختلف.
- هل التسميات التجارية المختلفة كيانات مختلفة أم مجرد أدوار مختلفة للكيان نفسه.
- هل يستطيع كل شخص، ومستخدم خارجي، وتكامل، ووكيل يحتاج إلى البيانات أن يصل إلى الكائن المختار تحت التراخيص المخطط لها.
- كيف يشكّل عدد المستخدمين ونمط تسجيل الدخول (على أساس العضوية أو على أساس تسجيل الدخول) الترخيص والنموذج.
- متى يبرر حد الترخيص نموذجًا أقل من الأمثل، وكم تكلف تلك المقايضة في التقارير والأذونات.
المقصود ليس أن الكائنات القياسية جيدة والمخصصة سيئة. بل أن للاختيار عواقب، وأحيانًا لا يقرره الاسم على الإطلاق، بل الأشخاص، والآلات، الذين يحتاجون إلى استخدامه.
للاستزادة
Section titled “للاستزادة ”- Salesforce Help، Standard User Licenses (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-02، وأُعيد التحقق في 2026-10-12): مستخدمو Platform لا يحق لهم الوصول إلى التوقعات والعملاء المحتملين والحملات والفرص؛ تطبيق مخصص واحد من 10 كائنات مخصصة كحد أقصى؛ خمسة تراخيص Salesforce Integration في كل مؤسسة من إصدار Enterprise.
- 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): اتفاقيات مستوى الخدمة (إدارة الاستحقاقات) مع Agentforce Service؛ وKnowledge بتكلفة إضافية في معظم الإصدارات.
- Salesforce Help، Available Feature Licenses (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-12): Service Cloud User، «الوصول إلى Salesforce Console for Service»؛ وMarketing User لإنشاء الحملات وإدارتها.