Tekunda Team
العودة إلى المقالات
Tekunda Team
إمتى تبني تطبيق سيلزفورس مخصص بدل ما تهيّئ؟
الإجابة باختصار: ابدأ بالتهيئة دايماً. وابنِ حلاً مخصصاً لما تكون المنطق ده ميزة تنافسية حقيقية، أو لما يحتاج يشتغل بره دورة حياة السجل الواحد، أو لما تلاقي نفسك بتعيد بناء نفس الالتفاف للمرة التالتة. المُحفّز مش التعقيد، لكنه التكرار والمسؤولية: تعقيد بتهيّئه مرة واحدة مفيهوش مشكلة، وتعقيد بتشرحه من أول وجديد كل ربع سنة فيه مشكلة كبيرة.
إيه الفرق بين التهيئة والتوسيع والبناء؟
- التهيئة: كائنات قياسية، وpage layouts، وقواعد تحقق، وFlow. من غير كود يتنشر، وبيترقّى مع المنصة تلقائياً.
- التوسيع: كائنات وحقول مخصصة، وشوية Apex أو Lightning Web Component حوالين عملية قياسية في معظمها. لسه على شكل سيلزفورس.
- البناء: تطبيق مصمَّم. بنموذج بيانات وخدمات واختبارات ودورة إصدار خاصة بيه، سواء اتشحن Apex وLWC جوه مؤسستك أو كمنتج محزّم.
ومعظم النقاش حوالين "نبني ولا نهيّئ" بيكون في الحقيقة عن الفئة الوسطى دي، واللي الإجابة الصريحة فيها غالباً إنك توسّع، مش إنك تفتح مشروع جديد.
ليه التهيئة أولاً لسه هي الخيار الافتراضي الصح؟
نصيحة سيلزفورس نفسها ثابتة من عشر سنين: قيّم الإمكانيات الأصلية والتصريحية قبل ما تكتب كود. الشغل التصريحي مالوش كود اختبارات ولا مستودع ولا ضريبة ترقية، وبيتحرك تلقائياً مع كل إصدار. وحتى الحدود بتتصرف بشكل مختلف: الشغل التصريحي بيصطدم بحدود تصميم، زي عدد القواعد المسموح بيها على الكائن، والكود بيصطدم بحدود تنفيذ زي عدد استعلامات SOQL، وده أصعب بكتير إنك تصمم حواليه (Salesforce Developers).
وكمان الأرضية بترتفع باستمرار. Workflow Rules وProcess Builder بقوا غير مدعومين بعد 31 ديسمبر 2025، وما بقاش ينفع تنشئ جديد منهم، وسيلزفورس بتوجّه الفرق لأداة Migrate to Flow (Salesforce Ben). يعني أي حاجة بتبنيها النهاردة بتنافس اللي المنصة هتبلعه بكرة، وده سبب إنك تبني أقل، مش إنك ما تبنيش خالص.
التهيئة بتبطل تجيب عائد إمتى؟
دي الخمس إشارات اللي بنستخدمها. واحدة منهم بتفتح نقاش. اتنين أو أكتر بيحسموا القرار.
- الـ flow بقى برنامج. لو محدش يقدر يتوقع النتيجة بمجرد قراءته، وأي تعديل محتاج بعد ضهر كامل بتركيز، فأنت أصلاً عندك برمجيات، بس بصيغة من غير اختبارات ولا مراجعة كود ولا فروقات تستاهل القراءة.
- المطلوب نموذج بيانات مش شاشة. تقارير محتاجة تربط تلات كائنات مالهمش علاقة ببعض، أو تسلسل هرمي النموذج القياسي مش قادر يعبّر عنه، دي مشكلة تصميم. والتهيئة هتطلّع لك شكل هتفضل بتلتف حواليه للأبد.
- السلوك عايش بره دورة حياة السجل. عمليات مجدولة، واستقبال أحداث بحجم كبير، ومطابقة بين أنظمة، وإعادة محاولات وحماية من التكرار. الأتمتة التصريحية بتشتغل بالسجلات، والحاجات دي لأ.
- المنطق هو فرقك التنافسي وبيتغيّر كتير. قواعد التسعير، وذكاء التوجيه، ومنطق الاستحقاقات. أي حاجة إن تكون أحسن من المنافس بـ10% فيها بيفرق، تستاهل اختبارات وإصدارات ومسؤول واضح.
- بتدفع تمنها تلات مرات. نفس الالتفاف اتبنى تاني في بلد تانية، ووحدة أعمال تانية، ومؤسسة عميل تالتة. ده مبقاش تهيئة، ده منتج من غير تحزيم.
تقارن التكلفة الحقيقية بأمانة إزاي؟
مش تكلفة البناء مقابل تكلفة التهيئة، لكن تلات سنين ملكية على الجهتين.
- التهيئة بتحمل: ساعات الأدمن لكل تغيير، ومخاطر انحدار محدش بيقيسها، وتكلفة تدريب كل أدمن جديد لازم يفهم الالتفاف، وسقف لأي حاجة ممكن تأتمتها.
- التخصيص بيحمل: هندسة أولية، وتغطية اختبارات، ومراجعة كود، ومسار ترقية عبر تلات إصدارات في السنة، ومخاطرة إن المنصة تطرح الميزة دي مجاناً السنة الجاية.
والمقارنة بتترجّح غالباً برقم واحد محدش بيكتبه: العملية بتتغيّر كام مرة في السنة؟ التغيير المتكرر بيرجّح الكود مع اختبارات، لأن الاختبارات هي طريقتك تغيّر بأمان. والتغيير النادر بيرجّح التهيئة، لأن محدش هيضطر يحافظ على المهارة دي.
"البناء" دلوقتي معناه إيه؟
نادراً ما يكون تطبيقاً من الصفر. عملياً هو واحد من أربع أشكال: Apex وLightning Web Components جوه المؤسسة، أو مكوّن محزّم بتثبّته في أكتر من مؤسسة، أو حزمة مُدارة على AppExchange، أو خدمة بره سيلزفورس المؤسسة بتناديها عبر API أو خادم MCP، وقدامها agent action.
والأشكال المحزّمة أهم مما بتتوقع الفرق. البناء كحزمة بيفرض عليك الإصدارات ومسار الترقية والعزل اللي كنت هتتخطاهم، وبيخلي التثبيت التاني والتالت شبه مجاني. ودي الانضباطية اللي بننقلها من شغل المنتجات لشغل التنفيذ: لأن تِكوندا بتبني وتشحن منتجات AppExchange كشريك PDO، شغل التنفيذ عندنا بيرث مكوّنات جاهزة ومختبرة بدل ما يعيد بناءها كل مرة.
تمنع البناء المخصص إنه يبقى الفوضى الجاية إزاي؟
- حدّد له مسؤولاً وخطة إنهاء من أول يوم. الكود اللي مالوش صاحب بيتحول لتهيئة محدش قادر يقراها.
- حط قيم الإعدادات في custom metadata مش في الكود. الفكرة كلها إن الأعمال تقدر تغيّرها من غيرك.
- اكتب الاختبارات كمواصفة، مش كضريبة تغطية.
- راجع مع كل إصدار هل المنصة لحقتك ولا لأ. حذف الكود بتاعك نتيجة مشروعة تماماً.
ولما تتعمل صح، المكسب مش معمارية أنيقة، لكنه مكسب تشغيلي. مع ASSA ABLOY نزّلنا الحالات الأسبوعية من 3000 لـ350، بانخفاض 93% عبر 11 ألف جهاز متصل وحتى 2.5 مليون حدث في الأسبوع، في تلات أسواق ومن غير أي زيادة في فريق الدعم. الحجم ده عمره ما كان هيتحمل في Flow. ولو بتزن نفس القرار دلوقتي، اتكلم معانا قبل البناء، مش في نص عملية الإنقاذ.
FAQ
هل الكود المخصص دايماً أغلى من التهيئة؟
لا. هو أغلى في البداية وغالباً أرخص في التعديل. قارن تلات سنين ملكية، وضمّنها ساعات الأدمن ومخاطر الانحدار اللي التهيئة بتاكلها بهدوء.
إمتى الحاجة تبقى معقدة أكتر من اللازم على الـ Flow؟
استخدم اختباراً بشرياً بدل عد العناصر: لو أدمن كفء مش قادر يتوقع سلوكه بقراءته، أو مش قادر يعدّله بأمان في ساعة، يبقى بقى برمجيات.
نبني بنفسنا ولا نشتري من AppExchange؟
اشترِ لما تكون الإمكانية سلعة عامة وفي تطبيق منشور بيغطي معظم المطلوب. وابنِ لما يكون المنطق هو السبب اللي بيخلي العملاء يختاروك.
هل التخصيص بيقطعنا عن ترقيات المنصة؟
لا، طالما اتبنى كحزمة بإصدار ومجموعة اختبارات. اللي بيعطّل الترقيات هو كود غير موثّق ومالوش صاحب، وده بيحصل في التهيئة برضه.
