Identity Lifecycle Automation with Entra ID Governance Workflows | أتمتة دورة حياة الهوية في Entra ID: الموظف يتعين أو يمشي والنظام يتصرف لوحده

أتمتة دورة حياة الهوية في Entra ID: الموظف يتعين أو يمشي والنظام يتصرف لوحده

إزاي تستخدم Lifecycle Workflows في Entra ID Governance عشان تسيب الـ onboarding والـ offboarding يحصلوا لوحدهم من غير ما تفتح Ticket واحد.

---

المقدمة

لو شغال في أي بيئة فيها أكتر من 200، 300 موظف، بتعرف كويس المشكلة: الـ HR بيضيف موظف جديد في نظام الـ HR بتاعه، وبعدين في اليوم اللي المفروض يبدأ فيه الشغل بيتفاجئ إنه مش عنده حساب، أو الأكونت موجود بس مش داخل الجروبات الصحيحة، أو الأسوأ: موظف اتفصل من شهرين وحسابه لسه فاعل وعنده Access على SharePoint وTeams. أنا شخصيًا شفت الحالة التالتة في أكتر من عميل، وده بالذات اللي خلاني أعتمد على Lifecycle Workflows بدل ما أفضل معتمد على Scripts يدوية أو Power Automate flows مبعثرة كل واحد فيها بيعمل حاجة مختلفة.

الفكرة إن Entra ID Governance بيوفر لك engine جاهز اسمه Lifecycle Workflows، بيربط بين حالة الموظف في HR source (زي Workday أو SAP SuccessFactors) وبين اللي بيحصل فعليًا في Entra ID: إنشاء الحساب، الإضافة للجروبات، إرسال welcome email، وفي الآخر، تعطيل الحساب وإزالة الـ licenses لما الموظف يمشي.

💡 المتطلبات:

• Microsoft Entra ID Governance license (أو Entra ID P2 مع add-on) لكل مستخدم داخل في scope الـ workflow
• Global Administrator أو Lifecycle Workflows Administrator role
• الحسابات لازم يكون عندها attribute بيدل على تاريخ التعيين (employeeHireDate) أو تاريخ الانفصال (employeeLeaveDateTime)، ودي غالبًا بتيجي من HR source عبر Entra ID Cloud Sync أو HR-driven provisioning
• Microsoft Graph PowerShell SDK أو Graph Explorer لو عايز تدير الـ workflows بـ API مباشرة

يعني إيه Lifecycle Workflows بالظبط

Lifecycle Workflows هو feature داخل Entra ID Governance بيعتمد على 3 عناصر: Trigger (إيه اللي يشغّل الـ workflow: تاريخ معين، أو event زي joiner/leaver/mover)، وScope (على مين ينطبق الـ workflow، عن طريق dynamic membership rule)، وTasks (اللي هو الأكشنز الفعلية زي Send email, Add to group, Disable account, Generate Temporary Access Pass).

مايكروسوفت وفرت categories جاهزة: Joiner (قبل وبعد أول يوم شغل)، Leaver (قبل وبعد آخر يوم شغل)، وMover (لما الموظف يتنقل بين departments). كل category عندها templates جاهزة تقدر تعدل عليها بدل ما تبني من صفر.

إنشاء Workflow لـ Onboarding (Joiner) خطوة بخطوة

1. تحديد الـ Trigger والـ Scope

في الـ portal، تروح Identity Governance > Lifecycle workflows > Workflows > Create. تختار template "Onboard pre-hire employee" اللي بيتشغل قبل تاريخ employeeHireDate بعدد أيام تحدده أنت (مثلًا 5 أيام قبل).

# مثال على Dynamic Membership Rule للـ Scope
(user.department -eq "Sales") -and (user.employeeHireDate -ne $null)

2. إضافة الـ Tasks

الترتيب المنطقي اللي بستخدمه أنا في أغلب الحالات:

1. Generate Temporary Access Pass وإرساله للمانجر مش للموظف (لأن الموظف لسه معندوش وسيلة يستقبل بيها الباس)
2. Add user to groups (الجروبات الخاصة بالـ department)
3. Add user to Teams
4. Assign licenses (مباشرة، مش عن طريق group-based licensing لو عايز تتحكم في التوقيت بدقة)
5. Send welcome email to manager

3. تفعيل الـ Workflow وربطه بـ Microsoft Graph

لو عايز تدير الموضوع كله بـ API بدل الـ portal (مفيد لو بتعمل CI/CD للـ governance configs)، ده الـ endpoint الأساسي:

POST https://graph.microsoft.com/beta/identityGovernance/lifecycleWorkflows/workflows

{
  "category": "joiner",
  "displayName": "Onboard Sales Employees",
  "isEnabled": true,
  "isSchedulingEnabled": true,
  "executionConditions": {
    "@odata.type": "#microsoft.graph.identityGovernance.triggerAndScopeBasedConditions",
    "scope": {
      "@odata.type": "#microsoft.graph.identityGovernance.ruleBasedSubjectSet",
      "rule": "(department -eq 'Sales')"
    },
    "trigger": {
      "@odata.type": "#microsoft.graph.identityGovernance.timeBasedAttributeTrigger",
      "timeBasedAttribute": "employeeHireDate",
      "offsetInDays": -5
    }
  }
}

✅ لو الـ workflow اتفعل صحيح، هتلاقي في تبويب "Workflow history" أول run مسجل خلال دقائق، مش لازم تستنى Trigger الوقت الحقيقي عشان تتأكد إن الـ configuration سليم.

4. تشغيل الـ Workflow يدويًا على مستخدم معين للتيست

Connect-MgGraph -Scopes "LifecycleWorkflows.ReadWrite.All"

$workflowId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
$userId = "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"

New-MgIdentityGovernanceLifecycleWorkflowWorkflowUserProcessingResult `
  -WorkflowId $workflowId `
  -BodyParameter @{ subjects = @(@{ id = $userId }) }

Offboarding: الجزء اللي غالبًا بينسوه

الـ Leaver workflows هي فعليًا الأهم من ناحية أمنية. الفكرة إنك تعمل workflow يشتغل يوم آخر يوم شغل فعليًا (مش بعده)، يعمل الآتي بالترتيب:

1. Remove user from all groups
2. Remove all licenses
3. Disable user account
4. Revoke all sessions (عن طريق task مخصص أو Graph API call مباشر)
5. Send offboarding notification to manager

⚠️ لو عندك on-premises AD متزامن بـ Entra Connect، تعطيل الحساب من Entra ID بس مش هيمنع الموظف من الدخول لو كان عنده local access منفصل. لازم الـ workflow يكون مرتبط بعملية HR كاملة، أو تستخدم write-back للـ on-prem.

Lifecycle Workflows مقابل الحل التقليدي (Custom Scripts / Power Automate)

المعيار	Lifecycle Workflows	Custom Scripts / Power Automate
الصيانة	مدمجة، بتتحدث مع Microsoft	عليك أنت بالكامل
Audit والتتبع	Workflow history مدمج بالتفاصيل	لازم تبني logging بنفسك
التكلفة	تحتاج Governance license	مجاني نسبيًا لكن تكلفة الصيانة أعلى
المرونة	محدودة بالـ tasks المتاحة	مفتوحة بالكامل

مشاكل شائعة وحلولها

المشكلة	الحل
الـ Workflow معمول ومفعل بس مش بيتشغل خالص	تأكد إن attribute التاريخ (employeeHireDate/employeeLeaveDateTime) موجود وصحيح على الحساب، الـ Trigger مبني عليه بالكامل
Task فاشلة بشكل متكرر (زي Add to group)	تحقق من إن الحساب اللي بيشغل الـ workflow (service principal) عنده الـ permissions الكافية على الجروب المستهدف، خصوصًا لو الجروب Role-Assignable
Scope بيشمل مستخدمين مش المفروض يدخلوا	راجع الـ dynamic membership rule، وجرب Validate rule syntax قبل التفعيل الفعلي
الـ Leaver workflow بيتأخر يومين قبل ما ينفذ	الـ scheduler بتاع Lifecycle Workflows بيشتغل مرة واحدة كل فترة، مش real-time، لو عايز تعطيل فوري استخدم HR event trigger مباشر أو manual run

نصائح الأمان 🔐

• خلي الـ Leaver workflow دايمًا يعمل Revoke sessions قبل Disable account، مش بعده، عشان تقفل أي token فعّال فورًا
• متعتمدش على تعطيل الحساب لوحده كضمان أمني، لازم يترافق مع مراجعة Conditional Access policies اللي ممكن تكون استثنت المستخدم
• استخدم Access Reviews بالتوازي مع Lifecycle Workflows، الـ workflows بتنفذ الأكشن بس Access Reviews بتتأكد إن الصلاحيات فعلًا لسه محتاجة تكون موجودة
• راجع Workflow history بشكل دوري في Log Analytics عن طريق تصدير الـ Audit logs، ومتفتكرش إن الـ portal history كافي للـ compliance reporting الطويل المدى
• لو عندك role-assignable groups مرتبطة بـ PIM، متسيبش الـ Lifecycle Workflow يضيف أو يشيل عضوية فيها من غير ما تربطها بمراجعة PIM eligibility

الخلاصة

Lifecycle Workflows مش حل سحري بيغطي كل سيناريوهات الـ HR الغريبة، بس هو أقرب حل موجود دلوقتي داخل Entra ID Governance يخليك تقفل الفجوة الكبيرة بين "الموظف اتفصل في النظام" و"الموظف اتقفل عليه فعليًا". الأهم إنك تبدأ صغير: workflow واحد لـ department واحد، تتابعه شهر، وبعدين توسع.

1. ابدأ بـ Leaver workflow الأول، لأنه الأخطر أمنيًا لو غاب
2. اربط الـ Trigger بـ attribute حقيقي جاي من HR source، مش تاريخ يدوي
3. راقب Workflow history وتصدير الـ logs بشكل دوري، متسيبهاش تعمل شغلها في الضلمة
4. كمّل بـ Access Reviews وPIM عشان الأتمتة متبقاش أعمى

عملت workflow زي ده في بيئتك وقابلت مشكلة مختلفة عن اللي ذكرتها؟ شاركني تجربتك في التعليقات.