الحفاظ على اتساق البيانات

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

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

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

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

السؤال الذي تجيب عنه هذه الوحدة: كيف أحافظ على اتساق البيانات، وكم تكلف كل طبقة؟

الجميع يريد بيانات نظيفة. لم أدخل قط اجتماع متطلبات قال فيه أحد: «ما نريده حقًا هو بيانات غير متسقة». الخلاف يأتي لاحقًا: أين نفرض القواعد؟ على الشاشة؟ حقل إلزامي؟ قائمة اختيار، أم قاعدة تحقق، أم قاعدة تكرار، أم تدفق، أم Apex؟ كلها تساعد. لكنها ليست قابلة للتبادل، ولكل طبقة تكلفتها.

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

الدرجة الأولى: نوع الحقل والمفردات

قاعدة الاتساق الأولى هي التي من الوحدة 6: اختر النوع الصحيح. التاريخ Date، واللحظة Date/Time، والمال Currency. هذا اتساق قبل أن يكتب أحد قاعدة.

اجعل حالة التوصيلة حقلًا نصيًا وستحصل على Delivered وdelivered وDELIVERED وComplete وDone وDropped off، وسيكون على أحدهم أن يكتشف ما إذا كانت تلك الست تعني الشيء نفسه. أو عرّف المفردات مرة واحدة: Delivered، قيمة واحدة، ومعنى واحد. اجعلها قائمة اختيار مقيّدة بحيث ترفض أي شيء ليس في القائمة، حتى عبر API، ومجموعة قيم عامة حين تتشارك عدة حقول القائمة (الوحدة 6 فيها التفاصيل).

لكن لا تستخدم قائمة اختيار لمجرد منع الناس من الكتابة. هل هي قيمة حقًا، أم كيان آخر؟ تسعة مراكز توزيع لكل منها اسم قد تبدو قائمة اختيار؛ وتسعة لها عناوين ومديرون وسعة وشاحنات هي سجلات. ينبغي أن تعزز القاعدة النموذج، لا أن تعوّض عن نموذج سيئ. وإذا كانت حقًا مفردات مضبوطة، فاضبطها عند الحقل. لا تسمح بالفوضى ثم تبني تدفقًا يحوّل AZ وArizona وAriz وPhoenix area إلى القيمة التي أردتها أصلًا.

الدرجة الثانية: الإلزام والتفرد

Required وUnique جذابان لأنهما بسيطان: حدد الخانة، وحُلّت المشكلة. أحيانًا. إذا كان لكل شاحنة رقم في الأسطول منذ يوم إنشائها، ولا تتشارك شاحنتان رقمًا، فالخانتان تعبّران عن قواعد عمل حقيقية. هذا اتساق قوي.

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

الدرجة الثالثة: قواعد التحقق

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

ولها أنياب أيضًا. وهذه قوتها وتكلفتها.

مشكلة السجلات القديمة

هنا يصبح الأمر قبيحًا. لديك مليون سجل، واليوم تضيف قاعدة: لا يمكن أن يكون وقت التوصيل قبل انطلاق المسار. معقول. لكن عشرين ألف سجل قديم تخالفها، بفضل ترحيل جرى قبل سبع سنوات. يفتح مستخدم أحدها ويغيّر رقم الهاتف. حفظ. تنطلق القاعدة. «غيّرت رقم هاتف. لماذا تحدثني عن وقت توصيل من 2019؟» سؤال منصف.

لذا لا ينبغي لقاعدة التحقق أن تقول فقط ما يجب أن يكون صحيحًا. بل ينبغي أن تقول متى تُفرض. دوال مثل ISNEW() وISCHANGED() تتيح لك قصر القاعدة على السجلات الجديدة، أو على عمليات الحفظ التي تتغير فيها الحقول المعنية فعلًا (Validation Rule Considerations (opens in a new tab)).

لكن السجل لا يتغير فقط حين يعدّله شخص، وكثير من الأسباب خارج سيطرتك. التكامل يحدّث الحالة خلال الليل. تدفق يختم تاريخًا. مدير يعيد إسناد منطقة فيتغير المالك على عشرة آلاف سجل. يعدّل أحدهم بند توصيلة، فيُعاد حساب الملخص التجميعي على التوصيلة، وهذا يحفظ التوصيلة، فتنطلق قاعدة التحقق الخاصة بالتوصيلة على مستخدم لم يلمسها قط (ينبّه Roll-Up Summary Field (opens in a new tab) إلى أن أخطاء التحقق قد تظهر على السجل التفصيلي أو الرئيسي). كل عملية حفظ من هذه تقابل قاعدتك الجديدة. لذا مع كل قاعدة جديدة، اسأل: هل ينبغي أن تنطبق هذه القاعدة على عملية الحفظ تلك؟

هذه هي الخيارات، وأنت تنسجها في القاعدة:

• دائمًا، في كل عملية حفظ. صحيح حين تكون القاعدة فعلًا عن السجل وتجتازها البيانات القديمة. لكن اعرف ما تعنيه «كل عملية حفظ»: مهمة دفعية لا تغيّر إلا المالك، أو أي تعديل صغير على أي حقل في أي مكان من السجل، يجب أن يجتازها أيضًا.
• للسجلات الجديدة فقط، باستخدام ISNEW(). تتحقق القاعدة من السجل مرة واحدة، عند إنشائه، ولا تعود أبدًا. يبقى الماضي كما كان، لكن المستقبل أيضًا: تعديل لاحق قد يجعل سجلًا جديدًا يخالف القاعدة ولن يوقفه أحد. إذا كان ذلك مهمًا، فاقرنها بالخيار التالي.
• فقط حين تتغير الحقول التي تخصها، باستخدام ISCHANGED(). تعديل رقم الهاتف لا يوقظ قاعدة وقت التوصيل.
• ليس لكتّاب معيّنين. إذن مخصص (custom permission)، يُفحص في الصيغة كـ $Permission، يتيح لمستخدم التكامل أو لترحيل بيانات أن يمر بينما يظل الناس يقابلون القاعدة (How to Reference a Custom Permission in a Validation Rule (opens in a new tab)). امنحه عن قصد ولقلة.
• من تاريخ فصاعدًا، بمقارنة CreatedDate بيوم بدء العمل بالقاعدة، حين يعني «جديد» «منذ بدأنا فرض هذا». وعلى خلاف ISNEW()، يظل يفحص تلك السجلات في كل حفظ لاحق، لذا ينطبق التحذير نفسه: تغيير بسيط، مثل تحديث دفعي للمالك، قد يفشل على سجل انحرف.

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

لا تُعِد كتابة التاريخ لإرضاء القاعدة

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

التحقق في الواجهة ليس تحققًا من البيانات

اجعل حقلًا إلزاميًا في تخطيط الصفحة فلا يستطيع المستخدمون الحفظ دونه. ثم يُدرج التكامل الليلي 50,000 سجل. هل استخدم صفحتك؟ لا. ولا التحميل الجماعي، ولا عميل API، ولا الوكيل. المتطلب في الواجهة يحمي تلك الشاشة، لا البيانات. ويمكن التملّص من التحقق في حقول النماذج الديناميكية (dynamic forms) بالطريقة نفسها. لذا اسأل: من أين يمكن أن تدخل هذه البيانات؟ Lightning، والبوابة، والهاتف المحمول، والتكامل، وAPI، والتحميل الجماعي، وFlow، وApex، والوكيل. كلما كثرت الأبواب، قلّت ثقتي بقاعدة لا تحرس إلا واحدًا منها.

الدرجة الرابعة: قواعد التكرار

الآن ننتقل من الاتساق داخل السجل إلى الاتساق عبر السجلات. Acme Corporation، وACME Corp، وAcme Inc.: أربعة عملاء أم واحد؟ لا تستطيع أي قاعدة حقل الإجابة عن ذلك. قواعد المطابقة تحدد كيف تُقارن السجلات؛ وقواعد التكرار تقرر ما الذي يحدث حين يُعثر على تكرار محتمل: السماح مع تحذير، أو المنع، أو الإبلاغ. يمكن أن يكون لديك حتى خمس قواعد تكرار نشطة لكل كائن وحتى ثلاث قواعد مطابقة في كل منها، ومفاتيح المطابقة تضيّق كل مقارنة إلى أرجح 100 تكرار (Things to Know About Duplicate Rules (opens in a new tab)).

تكلفتها هي الاحتكاك. إذا كان كل حساب يُنشئه مندوب يقول Possible duplicate found (عُثر على تكرار محتمل)، فأحيانًا هذا بالضبط ما تريده، وأحيانًا يتعلم الناس النقر متجاوزين دون قراءة. السجلات المشروعة قد تتشابه، والتكامل قد يحتاج إلى سلوك مختلف عن الشخص. والتحذير ملك Salesforce نفسها: تنبيهها وقائمتها بالتكرارات المحتملة قد لا ينسجمان مع شاشة مخصصة بنيتها، وحين يكون الحفظ بلا واجهة (headless)، تكاملًا أو تحميل بيانات أو وكيلًا، فلا توجد شاشة أصلًا لعرضه عليها. لذا قرّر كيف يظهر التكرار على كل مسار: تحذير لشخص، أو حفظ ممنوع وخطأ لـ API، أو خيار Report ومجموعات السجلات المكررة ليراجعها أحد لاحقًا. المعمارية الجيدة ليست أقصى فرض؛ بل الفرض الصحيح.

وتحقق من الأبواب التي تحرسها قاعدة التكرار فعلًا (Things to Know About Duplicate Rules (opens in a new tab)). عبر API وأدوات استيراد البيانات، لا أحد يرى التحذير: القاعدة المضبوطة على التنبيه تمنع الحفظ ببساطة. وبعض المسارات تتخطى القواعد كليًا: Quick Create، وزر Undelete، والدمج اليدوي، والسجلات التي يضيفها Lightning Sync أو Einstein Activity Capture. والسجلات المحفوظة في اللحظة نفسها لا تُقارن بعضها ببعض، بل بالسجلات الموجودة في Salesforce فقط. حمّل ملفًا فيه العميل نفسه مرتين، فقد يمر الصفان كلاهما. قاعدة التكرار شبكة جيدة. لكنها ليست قفلًا على الباب.

معلومة للاختبار. قواعد التكرار لا تقارن السجلات المحفوظة في اللحظة نفسها بعضها ببعض، بل بالسجلات الموجودة في Salesforce فقط. وعبر API وأدوات الاستيراد لا يوجد تنبيه: التكرار الذي تلتقطه القاعدة لا يُحفظ ببساطة. والحفظ وكل ما يطلقه يعملان كمعاملة واحدة: إذا فشل أي جزء، يُتراجع عن الكل.

حد واحد. قواعد التكرار تبقي مؤسسة واحدة نظيفة. لكنها لا تحل مسألة الهوية على مستوى المؤسسة. إذا كان في Salesforce Acme Corporation، وفي نظام ERP ACME-10382، وفي نظام الفوترة العميل 77193، فلا تستطيع قاعدة التكرار أن تخبرك أنها الشركة نفسها. هذه بيانات رئيسية، الفصل 6.

الدرجة الخامسة: الأتمتة

بعض القواعد أعقد من أن تحملها الدرجات الأدنى: تحتاج إلى سجلات مرتبطة، أو نظام آخر، أو سجلات معتمدة، أو عملية متعددة الخطوات. هذا Flow، وApex، وأحيانًا منطق التكامل. (لا Workflow Rules ولا Process Builder؛ فقد خرجا من الدعم.) الأتمتة قوية وأغلى: أجزاء متحركة أكثر، واختبار أكثر، ومعالجة أخطاء أكثر، وطرق أكثر لأن تتعثر أتمتة بأخرى. والشيفرة تجلب أخطاءها الخاصة. إذا كان نوع الحقل يستطيع فرضها، فلا أكتب Apex. وإذا كانت قاعدة تحقق تقولها بوضوح، فلا أبني تدفقًا لمجرد أن Flow موجود. لا تحل مشكلة حقل بمحرك عمليات.

الكل أو لا شيء: حين تتغير السجلات معًا

حتى الآن تحمي كل درجة عملية حفظ واحدة. لكن السجلات تتغير معًا: توصيلة وبنودها، وطلب وبنوده، وتدفق يحدّث ثلاثة كائنات. وهنا تعطيك المنصة ضمانًا قويًا. الحفظ وكل ما يطلقه، المشغّلات (triggers)، والتدفقات، والفئات التي تستدعيها، تعمل كمعاملة واحدة: إذا فشل أي جزء، يُتراجع عن الأمر كله ولا يُعتمد شيء (Apex Transactions (opens in a new tab)). لن تحصل على نصف توصيلة.

والعمل الجماعي هو الاستثناء الذي تختاره. تحميل البيانات أو دالة Database في Apex يمكن أن يسمح بالنجاح الجزئي: تُحفظ السجلات الجيدة، وتعود السيئة مع أخطائها، وعلى أحد أن يتعامل معها (DML Statements vs. Database Class Methods (opens in a new tab)). وهذا غالبًا صحيح لتحميل مليون صف، لكن الاتساق عندئذ يصبح عملية: من يقرأ ملف الأخطاء، وما الذي يحدث للسجلات التي فشلت؟

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

ادفع القاعدة نزولًا، حتى لا يعود مكانها هناك

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

لكل طبقة تكلفتها

Click to enlarge

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

قبل أن تفعّلها

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

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

Steve Trucking: احمِ التوصيلة

خذ توصيلة. حالتها تأتي من مفردات واحدة: قائمة اختيار، مقيّدة. ومرجع طلب شريك التجزئة يجب أن يكون فريدًا لكل شريك، لذا فهو External ID، موسوم بأنه فريد، يُستخدم لإجراء upsert لبيان الشحنة. ووقت التوصيل الفعلي إلزامي بمجرد أن تصبح الحالة Delivered: قاعدة تحقق، مقصورة على ذلك التغيير. ومحطة التركيب لا يمكن إغلاقها حتى تكتمل قائمة مراجعتها وتُلتقط صورها المطلوبة (لغسالة الأطباق: خط الماء، وخط التصريف، والاستواء): قاعدة تحقق، أو أتمتة إذا كان عليها فحص الصور المخزنة خارج المنصة. والطلب نفسه الواصل مرتين من بيان شحنة أُعيد إرساله يلتقطه External ID؛ وطلبان مختلفان متشابهان مسألة مطابقة.

لاحظ أنني لم أقل «ضعها كلها في تدفق». كل قاعدة تقف على درجتها الخاصة. ومع كل قاعدة، اسأل: ما أدنى طبقة تفرض هذا تمامًا على كل مسار كتابة مهم؟

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

• على أي درجة تنتمي كل قاعدة: نوع الحقل، أو المفردات المضبوطة، أو الإلزام أو التفرد، أو قاعدة التحقق، أو قاعدة التكرار، أو الأتمتة.
• أي مسارات الكتابة يجب حمايتها: الواجهة، والبوابة، والهاتف المحمول، والتكاملات، والتحميلات الجماعية، وواجهات API، والأتمتة، والوكلاء.
• هل تنطبق قاعدة جديدة على السجلات التاريخية، أم تُقصر على البيانات الجديدة والمتغيرة مع استثناء للماضي.
• هل يمكن تصحيح البيانات السيئة القائمة بناءً على أدلة، بدلًا من إعادة كتابتها لتجتاز.
• كم من الاحتكاك والتعقيد والصيانة تستحق القاعدة.

البيانات النظيفة لا تأتي من مطالبة الناس بإدخال بيانات جيدة. بل تأتي من معمارية تجعل الشيء الصحيح سهلًا، والشيء الخاطئ صعبًا، والقواعد المهمة صعبة التجاوز. والتالي: نجمع الفصل معًا على شريحة من Steve Trucking.

للاستزادة

• Salesforce Help، How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) وRoll-Up Summary Field (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-13).
• Salesforce Help، Picklist Limitations (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-02).
• Salesforce Help، Validation Rule Considerations (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-02).
• Salesforce Help، Things to Know About Duplicate Rules (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-13): الحدود، والمسارات التي لا تعمل فيها القواعد، وعمليات الحفظ عبر API والاستيراد الممنوعة دون تنبيه، وعدم مقارنة عمليات الحفظ المتزامنة.
• Apex Developer Guide، Apex Transactions (opens in a new tab) وDML Statements vs. Database Class Methods (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-13): المعاملة الواحدة يُتراجع عنها كوحدة؛ ودوال Database يمكن أن تسمح بالنجاح الجزئي.
• Salesforce Help، Workflow Rules & Process Builder End of Support (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-02).