Permission Set vs. Profile

يمتلك كل مستخدم profile واحد؛ وتضيف permission sets طبقة وصول إضافية فوقه، وتوصي Salesforce بالخيار الأخير.

التعريف

يتحكم كل من profiles وpermission sets فيما يمكن لمستخدم Salesforce رؤيته وفعله، لكنهما يعملان بشكل مختلف: يمتلك كل مستخدم profile واحدًا بالضبط، يحدد صلاحيات أساسية للكائنات والحقول والنظام، بينما تكون permission sets إضافية ويمكن للمستخدم أن يحمل أي عدد منها لإضافة صلاحيات إضافية دون تغيير profile الخاص به. تدفع Salesforce منذ سنوات باتجاه permission sets (وpermission set groups، التي تجمع عدة sets معًا) باعتبارها النموذج الموصى به، لأن profiles قليلة مع permission sets قابلة للتركيب تتوسع بشكل أفضل بكثير من صيانة عشرات الـ profiles شبه المتطابقة لأدوار مختلفة قليلاً. يُعد الانتقال من التحكم بالوصول القائم بشكل كبير على profiles إلى التحكم القائم على permission sets مشروع Salesforce DevOps شائعًا بحد ذاته، لأن profiles وpermission sets تُنشر كأنواع بيانات وصفية منفصلة وفك تشابك سنوات من تضخم profiles يتطلب تخطيطًا دقيقًا. يغطي دليلنا لـ Salesforce DevOps التحكم بالوصول كجزء من استراتيجية إصدار أوسع.

من واقع الاستخدام

إزاي بيشتغل في Serpent

تنشر Serpent بيانات profile وpermission set الوصفية مثل أي مكوّن آخر، تُتابَع عبر Work Item وتُدرج في فحوصات preflight، بحيث لا يُشحن تغيير في الوصول أبدًا بصمت جنبًا إلى جنب مع عمل غير ذي صلة. تُظهر مقارنة الـ org انحراف الصلاحيات بين بيئات sandbox والإنتاج، وهذا يهم بالنسبة لـ permission sets أكثر من معظم أنواع البيانات الوصفية، لأن أخطاء الوصول غالبًا ما تكون غير مرئية حتى يصطدم مستخدم بجدار. لا تفرض Serpent أي نموذج وصول يجب استخدامه، لكنها تجعل كليهما قابلًا للتدقيق وقابلًا للتراجع بنقرة واحدة (one-click rollback). راجع إدارة الـ org في Serpent لمعرفة كيفية تتبّع تغييرات الصلاحيات.

أسئلة شائعة