السؤال الجوهري: ما الذي يحدد صلاحيات المستخدم؟
عندما يسأل أحدهم "كيف حصل مستخدم على صلاحية الوصول إلى هذا الحقل؟"، فإن الإجابة الصحيحة دائمًا ما تكون مزيجًا من عدة عوامل: يحدد ملف التعريف (Profile) صلاحية الوصول الأساسية، وتضيف مجموعات مجموعات الصلاحيات (Permission Set Groups) المخصصة للمستخدم إمكانات بناءً على دوره الوظيفي، وأحيانًا يتم التعامل مع استثناء معين من خلال مجموعة صلاحيات (Permission Set) واحدة إضافية. المشكلة الفعلية هي أن معظم المؤسسات تبني هذا المزيج في الاتجاه المعاكس - تبدأ بملف تعريف (Profile) واسع النطاق يضم كل شيء تقريبًا، ثم "تصلح" المشكلات المحددة بصلاحيات فردية لا يتذكر أحد إزالتها.
يُبنى نموذج الصلاحيات السليم في الاتجاه المعاكس: ملف تعريف (Profile) محدود قدر الإمكان، يحدد بشكل أساسي الترخيص (Licensing)، الوصول الافتراضي للتطبيق (App Visibility)، وخصائص تسجيل الدخول (Login Properties)؛ وتُنقل جميع إمكانيات العمل الفعلية - مثل الكائنات (Objects)، الحقول (Fields)، والعمليات (Actions) - إلى مجموعات الصلاحيات (Permission Sets) ومجموعات مجموعات الصلاحيات (Permission Set Groups). من المهم التوضيح: تتناول هذه المقالة مستوى الكائن (Object)، الحقل (Field)، وصلاحيات النظام (System Permissions) فقط. أما قضايا رؤية السجلات بين المستخدمين - مثل إعدادات الافتراضيات على مستوى المؤسسة (OWD)، التسلسل الهرمي للأدوار (Role Hierarchy)، وقواعد المشاركة (Sharing Rules) - فتُناقش في دليل رؤية ومشاركة البيانات، لأنها تمثل طبقة قرار منفصلة ذات مقايضات خاصة بها.
الوحدات الثلاث ودور كل منها
| الوحدة | ما الذي تحدده | عدد الوحدات الممكنة للمستخدم | متى يتم اختيارها |
|---|---|---|---|
| Profile | الترخيص (Licensing)، الرؤية الافتراضية للتطبيق (Default App Visibility)، تخطيط الصفحة (Page Layout)، ساعات/عناوين IP لتسجيل الدخول (Login Hours/IP) | واحد فقط | الاختلافات البنيوية بين أنواع المستخدمين |
| Permission Set | صلاحيات الكائن (Object)، الحقل (Field)، فئة Apex (Apex Class)، علامة التبويب (Tab) - تضيف فقط | حسب الحاجة | إمكانية واحدة ذات صلة ببعض الأدوار |
| Permission Set Group | تجميع لعدة مجموعات صلاحيات (Permission Sets) تحت اسم واحد، مع إمكانية الكتم (Muting) | حسب الحاجة | مجموعة ثابتة من الصلاحيات تمثل دورًا وظيفيًا كاملاً |
الفرق بين مجموعة الصلاحيات (Permission Set) ومجموعات مجموعات الصلاحيات (Permission Set Group) ليس تقنيًا فقط - بل هو تنظيمي. مجموعة الصلاحيات (Permission Set) الواحدة مناسبة لإمكانية واحدة ومحددة ("الوصول إلى التقارير المالية"). أما مجموعات مجموعات الصلاحيات (Permission Set Group) فتكون مناسبة عندما يراد تخصيص "حزمة عمل" كاملة لقسم أو دور، وتحديثها في مكان واحد عند تغييرها.
إطار القرار: إلى أي وحدة تنتمي الصلاحية الجديدة؟
عندما يثار طلب لإضافة صلاحية وصول، فإن السؤال الأول ليس "إلى أي ملف تعريف (Profile) يجب إضافتها؟" بل "إلى أي وحدة تنتمي هذه الصلاحية من الناحية الهيكلية؟":
- هل هذه الصلاحية تميز جميع أصحاب نفس نوع الترخيص؟ إذا كان الأمر كذلك - فهذا مكان لملف تعريف (Profile)، بشرط أن يتعلق الأمر بجميع أصحاب الترخيص وليس بمجموعة فرعية.
- هل هذه إمكانية عمل تحتاجها مجموعة وظيفية معينة دائمًا مع صلاحيات إضافية؟ إذا كان الأمر كذلك - فهذا مكان لمجموعة مجموعات الصلاحيات (Permission Set Group)، حتى لو كان يتطلب تقسيمها أولاً إلى عدة مجموعات صلاحيات (Permission Sets) منفصلة للسماح بدمج مرن.
- هل هذه صلاحية محددة ومؤقتة لمستخدم واحد أو استثناء؟ إذا كان الأمر كذلك - مجموعة صلاحيات (Permission Set) مستقلة، تُخصص يدويًا وتُراجع في التدقيق الدوري.
- هل من المفترض أن تسلب الصلاحية شيئًا من مستخدم معين ضمن مجموعة أوسع؟ هنا يأتي دور مجموعة الصلاحيات الصامتة (Muting Permission Set) ضمن مجموعة مجموعات الصلاحيات (Permission Set Group) - وهي الأداة الوحيدة في Salesforce التي تسمح بتقليل الصلاحيات دون لمس ملف التعريف (Profile) أو تفكيك المجموعة.
القاعدة التي تمنع معظم الانحراف (Drift): لا يتم أبدًا تعديل ملف تعريف (Profile) لحل مشكلة مستخدم واحد. إذا كان التعديل يُعرف على أنه استثناء، فإنه يمر عبر مجموعة صلاحيات (Permission Set) موثقة ولها تاريخ مراجعة.
قائمة تحقق لبناء نموذج صلاحيات من البداية
- ☐ تم تحديد الأدوار الوظيفية الفعلية (وليس الأقسام التنظيمية) وتم تسمية كل دور بوضوح.
- ☐ لكل دور، تم تحديد قائمة الإمكانيات المطلوبة على مستوى الكائن (Object)، الحقل (Field)، وفئة Apex (Apex Class).
- ☐ تم بناء مجموعات صلاحيات (Permission Sets) مركزة على إمكانية واحدة، وليست "كومة صلاحيات" عامة.
- ☐ تلقى كل دور مجموعة مجموعات صلاحيات (Permission Set Group) واحدة تجمع الإمكانيات ذات الصلة.
- ☐ تم تقليص ملفات التعريف (Profiles) لتقتصر على اختلافات الترخيص والبنية التحتية فقط.
- ☐ تم تحديد عملية للحالات الاستثنائية: من يوافق على مجموعة صلاحيات (Permission Set) محددة ولأي مدة.
- ☐ تم تحديد وتيرة مراجعة (ربع سنوية على الأقل) تقارن الصلاحيات النشطة بالدور الحالي.
- ☐ تم تحديد مالك واحد (Owner) لصيانة نموذج الصلاحيات لمواجهة التغييرات الهيكلية التنظيمية.
سيناريو مؤسسي: شركة تأمين بثلاث وحدات مبيعات
لنأخذ مثال شركة تأمين متوسطة الحجم تضم حوالي ثلاثمائة مستخدم لـ Salesforce، مقسمين إلى ثلاث وحدات: المبيعات المباشرة، المبيعات عبر الوكلاء، والمطالبات. قبل المشروع، كان لدى الشركة اثني عشر ملف تعريف (Profiles) مختلفًا، بعضها نسخ شبه متطابقة تم إنشاؤها "لإصلاح" صلاحية واحدة لمجموعة صغيرة. النتيجة المعتادة: عندما ينضم وكيل جديد، لم يكن أحد يعلم على وجه اليحديد أي من ملفات التعريف الاثني عشر يناسبه، وكانت الإجابة الفعلية هي "انسخ من شخص مشابه".
أعاد فريق الهندسة بناء النموذج: ثلاثة ملفات تعريف (Profiles) فقط، حسب نوع الترخيص (Sales Cloud الكامل، Community للوكلاء الخارجيين، Service Cloud للمطالبات). وفوقها، سبع مجموعات مجموعات صلاحيات (Permission Set Groups) حسب الدور الوظيفي الفعلي - ممثل مبيعات، مدير فريق مبيعات، وكيل خارجي، مدير وكلاء، محقق مطالبات، مدير مطالبات، ودور وسيط يتعامل مع المبيعات والمطالبات معًا. تم تشكيل كل مجموعة مجموعات صلاحيات (Permission Set Group) من مجموعات صلاحيات (Permission Sets) مركزة مثل "الوصول إلى وثائق التأمين النشطة" أو "الموافقة على استرداد مالي حتى سقف محدد"، بحيث يمكن دمجها مرة أخرى عند إنشاء دور جديد دون بناء صلاحية من الصفر.
النتائج الملموسة: انخفض وقت إعداد مستخدم جديد من عدة أيام (تضمنت فحصًا يدويًا لأي ملف تعريف (Profile) مناسب) إلى عدة ساعات، وانخفض عدد طلبات الدعم من نوع "ليس لدي وصول إلى الحقل X" إلى النصف في الربع الذي تلا الانتقال، لأن معظم هذه الطلبات كانت ناتجة عن ملف تعريف (Profile) لم يتضمن الإمكانية ولم يكن واضحًا لمن يجب الاتصال للإصلاح.
المخاطر الشائعة والإجراءات الوقائية
| المخاطرة | كيف تظهر عمليًا | إجراء وقائي |
|---|---|---|
| تحول Profile إلى أداة إصلاح محددة | تعدد Profiles شبه متطابقة، كل منها لمجموعة صغيرة | نقل كل صلاحية محددة إلى Permission Set وتقليص Profiles إلى الترخيص فقط |
| عدم اتساق Field-Level Security | نفس الحقل مكشوف في مكان ومحظور في مكان آخر | توثيق مصفوفة FLS مركزية لكل حقل حساس ومراجعتها في كل إصدار |
| "التصاق" الصلاحيات بعد تغيير الدور الوظيفي | المستخدم الذي غير دوره يحتفظ بصلاحيات من الدور السابق | عملية إلغاء تعيين الدور (Offboarding-from-role) التي تزيل مجموعة مجموعات الصلاحيات (Permission Set Group) القديمة قبل إضافة الجديدة |
| صلاحيات النظام (System Permissions) واسعة جدًا (View All Data, Modify All) | تُعطى "لتوفير الوقت" ولا تُزال لاحقًا | موافقة مخصصة وتاريخ انتهاء صلاحية لكل صلاحية نظام واسعة النطاق |
| عدم وجود مالك لنموذج الصلاحيات | كل فريق يضيف صلاحيات دون رؤية شاملة | مالك واحد (Owner) يوافق على كل Permission Set أو Group جديد قبل النشر |
مقاييس للتحقق من صحة النموذج
| المجال | ما الذي يتم قياسه | وتيرة الفحص |
|---|---|---|
| التكرار غير الضروري | عدد الوظائف النشطة (Profiles) بالنسبة لعدد أنواع التراخيص الفعلية | ربع سنوي |
| دقة الصلاحيات | نسبة المستخدمين الذين تتطابق صلاحياتهم مع الدور المسجل في الموارد البشرية | ربع سنوي |
| الاستثناءات المفتوحة | عدد مجموعات الصلاحيات (Permission Sets) المحددة التي لا تحتوي على تاريخ مراجعة | شهري |
| الصلاحيات الواسعة النطاق | عدد المستخدمين الذين لديهم صلاحيات View All Data / Modify All Data بدون مبرر موثق | شهري |
| وقت الإعداد | متوسط الوقت من طلب وصول جديد إلى التخصيص الكامل | مستمر |
في الإصدار الأول من المتابعة، يفضل الاكتفاء بثلاثة مقاييس من الخمسة، والتوسع فقط بعد وجود خط أساس موثوق. المقياس الذي لا يمتلك مالكًا (Owner) وتاريخ مراجعة يميل إلى الاختفاء من التقرير بعد الشهر الأول.
كيف تتكامل هذه العناصر في البنية الشاملة
نموذج الصلاحيات الجيد هو شرط مسبق، وليس بديلاً، لتخطيط رؤية السجلات (OWD، Role Hierarchy، Sharing Rules) - يكمل هذان الموضوعان بعضهما البعض ولكنهما يُحلان بشكل منفصل. عادةً ما تكتشف المؤسسة التي تحاول حل مشكلة الرؤية عن طريق توسيع الملف التعريفي (Profile)، أو العكس، أن الحل هش بمجرد تغير الهيكل التنظيمي. عندما تنتقل المؤسسة بين بيئات Salesforce متعددة (Multi Orgs) وبيئة Salesforce واحدة (Single Org)، فإن نموذج الصلاحيات هو أحد الأمور التي يجب إعادة تخطيطها - يتوفر توسع في هذا الموضوع في دليل Single Org مقابل Multi Org. وعندما تعتمد الصلاحية نفسها على منطق مشروط معقد، فمن المجدي النظر فيما إذا كان التنفيذ ينتمي إلى Flow أو Apex، كما هو مفصل في دليل Flow مقابل Apex.
في المؤسسات التي تدير عمليات تعتمد على الأحداث بين الأنظمة، يجب التأكد من أن صلاحيات مستخدمي الخدمة (Integration Users) مبنية على نفس المبدأ - مجموعة صلاحيات (Permission Set) مركزة وليست ملف تعريف (Profile) واسع النطاق مع "System Administrator" كخيار افتراضي مناسب. يرتبط هذا الموضوع بالتخطيط الأوسع للتواصل بين الأنظمة، الموضح في دليل هندسة Salesforce المعتمدة على الأحداث.
ملخص
يُبنى نموذج الصلاحيات الذي يصمد أمام اختبار الزمن من الأسفل إلى الأعلى: إمكانيات مركزة في مجموعات الصلاحيات (Permission Sets)، وتجميعها وفقًا لدور وظيفي حقيقي في مجموعات مجموعات الصلاحيات (Permission Set Groups)، وملف تعريف (Profile) يحافظ على دور ضئيل يقتصر على الترخيص والبنية التحتية فقط. العلامة الواضحة للفشل هي تعدد ملفات التعريف (Profiles) التي تم إنشاؤها لحل مشكلات محددة - كل ملف تعريف إضافي من هذا النوع هو دين يتراكم حتى لا يتذكر أحد سبب وجوده. عندما لا تتوفر القدرة الداخلية لبناء أو تنظيف نموذج موجود، فإن خدمة هندسة CRM توفر مسارًا عمليًا لبداية مركزة.