بناء تدفق موافقات في Power Automate ── رقمنة الاعتماد الداخلي والطلبات الورقية والبريدية

«نطبع مستند الاعتماد، ونختمه، ونمرّره إلى القسم المجاور، ثم يعود بعد أسبوع كامل» أو «نرسل استمارة الطلب بصيغة Excel كمرفق بريد، وتكون الموافقة مجرد رد يقول ‹تمت الموافقة›». نتلقى كثيراً طلبات من شركات اعتمدت بالفعل Microsoft 365 تريد معالجة هذا النوع من إجراءات الطلب والموافقة.

يملك Power Automate آلية مخصّصة تُسمى الموافقات (Approvals)، وغالباً ما يمكن بناء تدفق موافقات يكتفي فيه المستخدم بالضغط على زر الموافقة من Teams أو Outlook، ضمن نطاق الترخيص الحالي دون تكلفة إضافية. لكن هناك مسافة بين «تشغيل أول تدفق بنجاح» وبين «تشغيله بثقة كجزء من العمل اليومي». أين تبقى سجلات الموافقة؟ ماذا يحدث إذا أهمل الموافِق الطلب؟ ومن يصلح التدفق إذا استقال الموظف المسؤول عنه؟ في هذا المقال نرتب المكوّنات الأساسية لتدفق الموافقات، ونقاط التصميم التي يكثر التعثر فيها في العمل الفعلي، وأخيراً الخط الفاصل لما ينبغي إنجازه عبر Power Automate.

1. الخلاصة أولاً

• أساس الموافقات في Power Automate هو إجراء «ابدأ وانتظر الموافقة» (Start and wait for an approval). يمكن الاختيار من بين 5 أنواع للموافقة: «مطلوب موافقة الجميع»، و«أول استجابة»، و«استجابة مخصّصة (الجميع / شخص واحد)»، و«الموافقة المتسلسلة».¹
• يمكن للموافِق الاستجابة من Teams أو Outlook أو بوابة Power Automate أو تطبيق الهاتف المحمول أيّاً كان. لا حاجة تقريباً لأن يتعلم أحد استخدام شاشة جديدة لمجرد الموافقة.²³
• نقطة استقبال الطلبات الواقعية تنحصر في ثلاثة خيارات: Microsoft Forms / قائمة SharePoint / تطبيق الموافقات في Teams. إن أردت لاحقاً عرض القوائم وتجميع البيانات، فجعل قائمة SharePoint المحور هو الأسلوب المعتمد.
• سجل تنفيذ التدفق لا يظهر افتراضياً إلا لمدة 28 يوماً، وأقصى مدة لتنفيذ واحد هي 30 يوماً قبل حدوث مهلة زمنية (timeout). لا تعتمد على سجل التنفيذ كأثر للموافقة، بل أدرج منذ البداية تصميماً يكتب النتيجة إلى قائمة SharePoint أو ما شابه.⁴⁵
• استقالة مالك التدفق أو انتقاله هو أكبر مخاطر التشغيل لتدفق الموافقات. أنجز إعداد المالكين المشاركين وطريقة التعامل مع الاتصالات (connections) في نفس يوم بدء التشغيل.⁶
• محاولة تنفيذ الموافقات متعددة المراحل ذات التفرعات الشرطية الكثيرة، أو لوائح الاعتماد الداخلي ذات متطلبات التفويض بالنيابة أو التدقيق الصارمة، كما هي، تجعل الصيانة عبر Power Automate غير ممكنة. عندئذ يدخل الأمر ضمن نطاق أنظمة سير العمل أو تطوير البرمجيات المخصّصة (Custom Software Development).

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 21، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. ما مشكلة الاعتماد الداخلي الورقي والبريد؟

ما يجعل الموافقة على مستندات الاعتماد الورقية أو ملفات Excel المرفقة بالبريد أمراً شاقاً ليس العناء بحد ذاته، بل عدم وضوح الحالة. الأمور المشتركة التي نسمعها في الاستشارات هي غالباً هذه الثلاثة:

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

تُحل هذه المشكلات تقريباً بـ«تجميع حالة الطلب وسجلاته في مكان واحد». وإن كانت الشركة قد اعتمدت Microsoft 365 بالفعل، فإن مكان التخزين (SharePoint) ومسار الإشعارات (Teams/Outlook) والأتمتة (Power Automate) موجودة بالفعل بين يديها.

3. المكوّنات الأساسية لموافقات Power Automate

إجراء «ابدأ وانتظر الموافقة»

محور تدفق الموافقات هو إجراء موصل الموافقات (Approvals) المسمى «ابدأ وانتظر الموافقة (Start and wait for an approval)». عند تحديد عنوان طلب الموافقة وتفاصيله والموافِق، يتوقف التدفق عند هذه النقطة، وينتظر استجابة الموافِق قبل الانتقال إلى الإجراء التالي.¹

توجد خمسة أنواع للموافقة.¹

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

ولاستخدام ميزة الموافقات، يلزم وجود قاعدة بيانات Microsoft Dataverse. تُحفظ سجلات طلبات الموافقة واستجاباتها في Dataverse، وتُهيأ تلقائياً في البيئة الافتراضية عند إنشاء أول تدفق موافقات، لذا يمكن عادة البدء بالاستخدام دون الانتباه لهذا الأمر. وبما أن موصل الموافقات موصل قياسي، يمكن إنشاء تدفق موافقات بأي ترخيص يتيح استخدام الموصلات القياسية (كـ Office 365 مثلاً).¹

ما هو Dataverse ── أين يلزم الانتباه إليه

Dataverse الذي ظهر هنا لأول مرة هو أساس حفظ البيانات المشترك في Power Platform. بعبارة مبسطة: قاعدة بيانات سحابية تُعد داخل مستأجر Microsoft 365 الخاص بالشركة، وتُستخدم مكاناً للبيانات التي تتعامل معها تطبيقات Power Apps والتدفقات. ميزة الموافقات محمولة فوق هذا الأساس، و«إلى من ومتى طُلبت الموافقة، ومن استجاب وكيف» تُكتب كسجلات في جداول Dataverse.

في الإنشاء والتشغيل اليوميين لا يلزم الانتباه إلى Dataverse تقريباً، لكن تظهر في ثلاثة مواضع فقط.

• عند استخدام الموافقات لأول مرة في بيئة جديدة. في البيئة الافتراضية تُعد تلقائياً، لكن في بيئة أنشئت حديثاً لقسم ما يلزم التحقق من وجود قاعدة بيانات Dataverse.¹
• عندما يتراكم سجل الموافقات. يستهلك سجل الموافقات مساحة تخزين البيئة، وقد يصبح عرضة للحذف لأسباب تتعلق بالسعة. هنا سبب عدم الاعتماد على سجل التنفيذ ولا على Dataverse كأثر (الفصل التالي).⁷
• عندما تريد قراءة سجلات الموافقة وكتابتها مباشرة. إن بُنيت البنية على لمس الجداول مباشرة بموصل Dataverse، يُصنَّف ذلك الموصل في الطبقة المتميزة، فيظهر حديث الترخيص الإضافي.⁸

أي أن الخط هو: «الاستخدام العادي للموافقات بلا ترخيص إضافي؛ ولمس Dataverse نفسه يغيّر الحديث».

من أين يستجيب الموافِق

يصل طلب الموافقة إلى الموافِق عبر البريد الإلكتروني وتطبيق Power Automate للهاتف المحمول.³ وفي Outlook تصل رسالة موافقة منسّقة يمكن الاستجابة منها مباشرة.⁹ والموافقات الموجهة إلى مستخدم فردي يصلها إشعار في Teams أيضاً، ويمكن الموافقة أو الرفض أو إدخال تعليق من دردشة Teams أو من تطبيق الموافقات.² وانعدام عائق «تسجيل الدخول إلى موقع مخصّص لمجرد الموافقة» هو المحرّك الأول لترسيخ تدفق الموافقات في العمل اليومي.

هناك نقطة تنبيه واحدة: إذا كانت جهة الموافقة مجموعة Microsoft 365، فلن يُرسل إشعار Teams. فإشعارات Teams تصل فقط للموافقات الموجهة إلى مستخدم فردي.¹⁰

الصورة الكاملة للتدفق

إذا أخذنا طلب شراء كمثال، فإن الصورة الكاملة تكون على هذا الشكل.

flowchart TD
    Submit[إدخال مقدّم الطلب<br/>إرسال Forms / تسجيل في قائمة SharePoint] --> Trigger[بدء تشغيل التدفق السحابي<br/>مشغّل استجابة جديدة / إضافة عنصر]
    Trigger --> Record[تسجيل محتوى الطلب في قائمة SharePoint<br/>الحالة: بانتظار الموافقة]
    Record --> Approval[ابدأ وانتظر الموافقة<br/>إرسال الطلب إلى الموافِق]
    Approval -- Teams / Outlook / الهاتف المحمول --> Response{الاستجابة}
    Response -- موافقة --> UpdateOK[تحديث حالة القائمة إلى «تمت الموافقة»<br/>تسجيل الموافِق والتاريخ والتعليق في الأعمدة]
    Response -- رفض / إعادة للتصحيح --> UpdateNG[تحديث الحالة إلى «أُعيد للتصحيح»<br/>إشعار مقدّم الطلب بالسبب]
    Response -- انتهاء المهلة --> Remind[إشعار تذكير / تصعيد]
    UpdateOK --> NotifyOK[إشعار مقدّم الطلب بالنتيجة]
    UpdateNG --> Resubmit[يعدّل مقدّم الطلب ويعيد التقديم]
    Resubmit -- شرط المشغّل يبدأ فقط<br/>عند «إعادة التقديم» --> Trigger

النقطة المهمة هي إدراج خطوة «التسجيل» قبل إجراء الموافقة وبعده. سنشرح السبب في الفصل 5.

4. كيف نصمم نقطة استقبال الطلبات؟

سهولة استخدام تدفق الموافقات تتحدد بنقطة استقبال إدخال الطلب أكثر من جانب الموافقة نفسه. الخيارات الواقعية ثلاثة.

معايير القرار هي كالتالي.

• إذا أردت فقط رقمنة الموافقة الفردية كل مرة، يكفي تطبيق الموافقات في Teams دون الحاجة لإنشاء تدفق. تطبيق الموافقات ميزة تتيح إرسال طلب موافقة فوراً من الدردشة، ويعمل على أساس بنية Power Automate، لكن لا يتطلب إنشاء تدفق.¹¹
• إذا كان الهدف استبدال استمارة الطلب، فأسرع طريقة هي جعل Forms نقطة الاستقبال، واستقبال الاستجابة عبر التدفق وتحويلها إلى الموافقة. وتتوفّر أيضاً قوالب لإدراج محتوى استجابة Forms داخل طلب الموافقة.¹³
• إذا أردت إدارتها كسجل للطلبات، اجعل قائمة SharePoint المحور. حتى لو كان Forms هو المدخل، إذا نُقلت الاستجابة إلى القائمة في بداية التدفق، يصبح عمود الحالة (بانتظار الموافقة / تمت الموافقة / أُعيد للتصحيح) والعروض مرئية للجميع لمعرفة «أين توقف الطلب الآن». والجواب الحقيقي عن مشكلة الاعتماد الورقي والبريدي المذكورة في المقدمة يكمن هنا فعلياً.

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

5. نقاط تصميم فعّالة في العمل الفعلي

أين تُحفظ سجلات الموافقة ── لا تعتمد على سجل التنفيذ

هذا أهم قرار تصميمي. لا يظهر سجل تنفيذ التدفق افتراضياً إلا لمدة 28 يوماً.⁴ إذا كان التدفق مدرجاً ضمن حل (solution)، يمكن الاحتفاظ بالبيانات الوصفية لسجل التنفيذ في Dataverse، لكن مدة الاحتفاظ الافتراضية هنا أيضاً 28 يوماً، وتعديلها متروك للمسؤول.¹⁴

بعبارة أخرى، أي ممارسة تعتمد على البحث لاحقاً في سجل التنفيذ عن «من وافق ومتى» ستنهار خلال شهر واحد. صحيح أن سجلات طلبات الموافقة واستجاباتها نفسها تُحفظ في Dataverse¹⁵، لكن الاطلاع على جداول Dataverse في كل مرة للتدقيق أو الاستفسار اليومي ليس أمراً واقعياً، كما أن سجل الموافقات يستهلك مساحة تخزين البيئة، فقد يصبح عرضة للحذف لأسباب تتعلق بالسعة.⁷

في العمل الفعلي، أدرج دائماً خطوة تكتب النتيجة والموافِق وتاريخ الاستجابة والتعليق إلى أعمدة قائمة SharePoint مباشرة بعد إجراء الموافقة. بما أن إجراء «ابدأ وانتظر الموافقة» يعيد الاستجابة والموافِق والتعليق كمخرجات¹⁵، يكفي تسجيل ذلك مباشرة في الأعمدة. بهذا يجتمع الطلب وسجل الموافقة في نفس السطر من نفس القائمة، ويمكن الاحتفاظ بهما لسنوات حسب طريقة تشغيل القائمة.

هناك تنبيه واحد فقط. في أنواع الموافقين المتعددين مثل «مطلوب موافقة الجميع» أو الاستجابة المخصّصة (الجميع)، تُعاد الاستجابات (Responses) كمصفوفة بعدد الأشخاص.³ وإذا كُتبت هذه بالكتابة فوق مجموعة أعمدة واحدة بالترتيب، لن يبقى سوى آخر استجابة، لذا يجب تسجيل الموافقين المتعددين إما بإضافة سطر جديد لكل استجابة إلى قائمة سجل منفصلة، أو بتنسيق استجابات الجميع في نص واحد قبل تسجيله في العمود.

المهلة الزمنية والتذكير ── لا يمكن إنشاء «موافقة بلا موعد نهائي»

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

الحل يتألف من مرحلتين.

1. ضبط مهلة زمنية صريحة لإجراء الموافقة. حدد المهلة الزمنية بصيغة ISO 8601 (مثال: P3D لثلاثة أيام) في إعدادات الإجراء، وجهّز في تكوين شرط التنفيذ تفرعاً لحالة «عند انتهاء المهلة».¹⁶ النقطة التي يجب الانتباه إليها هنا هي أن انتظار الموافقة الأصلي ينتهي عند حدوث المهلة الزمنية. حتى لو استجاب الموافِق بعد ذلك، فلن تُنفَّذ الخطوات اللاحقة لهذا التنفيذ (مثل كتابة النتيجة). بعبارة أخرى، تفرع المهلة الزمنية ليس مكاناً «للاستمرار بالانتظار مع التذكير»، بل مكان «لإيقاف المحاولة الحالية واتخاذ الخطوة التالية». إذا أردت التذكير، أرسل إشعاراً في تفرع المهلة الزمنية ثم أعد إصدار طلب موافقة جديد.
2. الموافقات التي قد تتجاوز 30 يوماً، اقسم التدفق إلى تدفقين. الإرشاد الرسمي يوصي ببنية يُرسل فيها طلب الموافقة فقط عبر إجراء «إنشاء الموافقة (v2)» وينتهي التدفق الأول، بينما تُنفَّذ المعالجة اللاحقة للاستجابة في تدفق منفصل. بما أن سجل الموافقة موجود في Dataverse، يمكن معالجة الاستجابة حتى بعد انتهاء تنفيذ التدفق الأصلي. وإذا أردت بناء تذكير مرن دون قطع الانتظار، فإن هذه البنية المزدوجة أسهل بناء أيضاً.¹⁷ وتجدر الإشارة إلى وجود مساحة تصميم في طريقة تشغيل التدفق الثاني؛ فإذا اخترت بنية تلتقط تغييرات جدول الموافقات مباشرة عبر مشغّل موصل Dataverse، فانتبه إلى أن موصل Dataverse يقع ضمن نطاق الترخيص المتميز (بينما تندرج إجراءات موصل الموافقات نفسه ضمن النطاق القياسي¹).⁸

خطوات ضبط المهلة الزمنية والتفرع

الموضع يصعب فهمه بالنص، لذا نكتب عمليات المصمم بالترتيب.

1. من «…» في أعلى يمين بطاقة إجراء «ابدأ وانتظر الموافقة» افتح Settings، وفي حقل Timeout أدخل مدة بصيغة ISO 8601. ثلاثة أيام: P3D، واثنتا عشرة ساعة: PT12H. إن تُرك فارغاً ينتظر حتى حد فترة تنفيذ التدفق (30 يوماً).
2. تحت إجراء الموافقة ضع إجراءً واحداً تريد تنفيذه عند انتهاء المهلة (مثل إشعار تذكير).
3. من «…» في أعلى يمين ذلك الإجراء افتح Configure run after، وحدد لإجراء الموافقة السابق «انتهت المهلة» فقط. الافتراضي هو «اكتمل بنجاح»، فلا تنسَ إلغاءه.
4. معالجة حالة الموافقة (كتابة النتيجة وإشعار مقدّم الطلب) رتّبها كتفرع آخر من إجراء الموافقة، واتركها على «اكتمل بنجاح». عند التفرع بتكوين شرط التنفيذ يظهر التفرعان متوازيين في المصمم.

كيف تُبنى «تذكير بعد 3 أيام، وتصعيد إلى الأعلى بعد 7 أيام»

هذا ما يُراد بناؤه غالباً، لذا نعرض بنية متسلسلة من مرحلتين إلى ثلاث. المرحلة الأولى تنتظر 3 أيام؛ إن لم تأت استجابة يُرسل تذكير ويُعاد الطلب إلى المدير نفسه؛ وإن مرت 4 أيام أخرى يُحوَّل إلى شخص أعلى.

flowchart TD
    A1[ابدأ وانتظر الموافقة المرحلة 1<br/>الموافِق: المدير المباشر<br/>المهلة في الإعدادات P3D] --> Q1{هل جاءت استجابة}
    Q1 -- موافقة / رفض --> Rec[كتابة النتيجة إلى قائمة SharePoint<br/>إشعار مقدّم الطلب]
    Q1 -- 3 أيام بلا استجابة --> R1[إرسال إشعار تذكير<br/>تكوين شرط التنفيذ: انتهت المهلة]
    R1 --> A2[ابدأ وانتظر الموافقة المرحلة 2<br/>الموافِق: المدير نفسه<br/>المهلة في الإعدادات P4D]
    A2 --> Q2{هل جاءت استجابة}
    Q2 -- موافقة / رفض --> Rec
    Q2 -- 4 أيام إضافية بلا استجابة --> R2[إرسال إشعار تصعيد<br/>تكوين شرط التنفيذ: انتهت المهلة]
    R2 --> A3[ابدأ وانتظر الموافقة المرحلة 3<br/>الموافِق: شخص أعلى<br/>بلا ضبط مهلة]
    A3 --> Rec

عند البناء ثلاث نقاط.

• المرحلة 2 والمرحلة 3 «طلب موافقة جديد». طلب المرحلة 1 انتهى بعد 3 أيام، فيصل إلى Teams أو Outlook لدى الموافِق كطلب منفصل. أضف إلى عنوان الطلب «【تذكير】» أو «【تصعيد】»، وأدرج تاريخ التقديم وعدد الأيام المنقضية في المتن، فيفهم المستلم الوضع.
• اجمع مجموع المهلات ضمن 30 يوماً للتدفق. المثال أعلاه يستخدم 3 أيام في المرحلة 1 + 4 أيام في المرحلة 2 = 7 أيام، فيبقى للمرحلة 3 أقل من 23 يوماً بقليل. كلما زادت المراحل قلّ هامش المرحلة 3.
• إن أردت تجميع كتابة النتيجة في موضع واحد فاستخدم متغيرات. نتيجة الموافقة تخرج من إجراء مختلف في كل مرحلة، فإن كُتبت كما هي تتضاعف خطوة الكتابة إلى ثلاثة مواضع. في بداية التدفق هيئ متغير سلسلة (مثال: نتيجة الموافقة) والموافِق، وضع بعد كل إجراء موافقة «تعيين متغير» واحداً، ثم اكتب إلى القائمة مرة واحدة في النهاية؛ فتصير الصيانة أسهل.

يمكن أيضاً لف «مهلة ← تذكير ← إعادة طلب» داخل حلقة Do until، لكن لحلقة Do until حداً أعلى خاصاً بها (60 تكراراً وساعة واحدة افتراضياً)، وإذا وضعت داخلها إجراءً طويل الأمد مثل انتظار الموافقة، فلن تبدأ الدورة الثانية بعد الأولى ما لم تمدَّد مهلة الحلقة صراحة عبر «تغيير الحدود».⁵¹⁸ رابط «Change limits» هذا داخل بطاقة إجراء Do until؛ عند فتحه يمكن تحديد Count وTimeout. العدد هو عدد التكرارات (افتراضي 60)، والمهلة حقل حد زمني للحلقة كلها بصيغة ISO 8601 (افتراضي PT1H). إن أردت ثلاث دورات لموافقة تنتظر 3 أيام، اجعل العدد 3 والمهلة P10D مثلاً: «قيمة أطول من مجموع زمن الدورات المتصور». لكن تمديد هذا لا يمدد 30 يوماً للتدفق كله.

بالنسبة لاعتماد الشركات الصغيرة والمتوسطة، الأسلوب الواقعي هو أن تُحدد أولاً قاعدة داخلية مثل «تذكير بعد 3 أيام، وتصعيد إلى المدير بعد 7 أيام»، ثم تُنفَّذ إما بحلقة إعادة الطلب أو ببنية التدفقين.

إعادة التوزيع عند غياب الموافِق

حالات غياب الموافِق لفترة طويلة تحدث حتماً. يستطيع الشخص الذي تلقى طلب الموافقة إعادة توزيعها (Reassign) إلى شخص آخر من قائمة الموافقات في بوابة Power Automate. أما إعادة الترتيب من جانب مصدر الطلب، فتتم عبر إلغاء الطلب وتغيير الموافِق وإعادة التشغيل.⁹ النقطة التي يجب الانتباه إليها هي أنه في التدفق ذي التشغيل التلقائي كما في هذا المقال، يكون هذا عمل مالك التدفق وليس مقدّم الطلب، لأن طلب الموافقة صادر من الحساب المستخدم في اتصال التدفق، ويتطلب تغيير الموافِق صلاحية تحرير التدفق. ينبغي تحديد «من يصلح التدفق عندما يكون الموافِق في إجازة مرضية» بالتزامن مع موضوع المالكين المشاركين في الفصل التالي.

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

حلقة إعادة الطلب للتصحيح عند الرفض

كان «إعادة للتصحيح ← تعديل ← إعادة تقديم» أصعب ما يمكن تتبعه في الاعتماد الورقي، لكن يمكن التعبير عنه بسهولة بتصميم يعتمد على عمود حالة. الشكل الأساسي هو كالتالي.

• تعريف «موافقة» و«إعادة للتصحيح» عبر الاستجابة المخصّصة¹
• في حال إعادة الطلب للتصحيح، تُحدَّث حالة القائمة إلى «أُعيد للتصحيح»، ويُسجَّل تعليق الموافِق في العمود، ويُشعر مقدّم الطلب
• يعدّل مقدّم الطلب عنصر القائمة ويغيّر الحالة إلى «إعادة تقديم» (أو يعيد الإرسال عبر Forms)
• يعمل التدفق من جديد بمشغّل تحديث العنصر، وتُعاد إحالته للموافقة

ما يحتاج انتباهاً واحداً في هذا الشكل هو أن كتابة التدفق نفسه إلى القائمة قد يعيد تشغيل التدفق ذاته. فإذا بقي المشغّل «عند إنشاء عنصر أو تعديله» كما هو، فإن اللحظة التي يحدّث فيها التدفق عمود الحالة إلى «بانتظار الموافقة» أو «تمت الموافقة»، يستوفي هذا التحديث نفسه شرط المشغّل، ما يؤدي إلى طلبات موافقة مزدوجة أو حلقة لا نهائية. يستطيع التدفق السحابي تشغيل نفسه بنفسه، ويحذّر Power Automate أيضاً من احتمال الحلقة اللانهائية عند الحفظ.¹⁹ الحل هو أن تُكتب في المشغّل نفسه، عبر شروط المشغّل (trigger conditions)، عبارة «شغّل فقط عندما يكون عمود الحالة ‹إعادة تقديم› (أو عنصراً جديداً)»، بدل استبعادها بفرع شرطي لاحق. فالتحديثات التي لا تستوفي شرط المشغّل لا يحدث لها تنفيذ للتدفق أصلاً، وبالتالي لا تُستهلك أيضاً من عدد مرات التنفيذ.²⁰

شروط المشغّل تُكتب سطراً سطراً بصيغة تبدأ بـ @ في Trigger Conditions داخل Settings من «…» في أعلى يمين بطاقة المشغّل. إن أردت التشغيل فقط عندما يكون عمود الاختيار ApprovalStatus في قائمة SharePoint هو «إعادة تقديم»، يكون كالتالي.

@equals(triggerOutputs()?['body/ApprovalStatus/Value'], '再申請')

إن أردت التشغيل أيضاً عند الإنشاء الجديد (عمود الحالة فارغ)، اجمع بـ or.

@or(equals(triggerOutputs()?['body/ApprovalStatus/Value'], '再申請'), empty(triggerOutputs()?['body/ApprovalStatus/Value']))

ثلاث نقاط في الكتابة.

• @ مرة واحدة في البداية فقط. لا تضعها على equals أو empty المتداخلين.
• حدد عمود الاختيار حتى /Value. عمود الاختيار يُعاد ككائن لا كنص، فالمقارنة بـ body/ApprovalStatus لا تطابق. إن كان العمود نصاً بسطر واحد فلا حاجة لـ /Value.
• لا تستخدم اليابانية في الاسم الداخلي للعمود. إن استخدمت SharePoint اسماً يابانياً للعمود، يصبح الاسم الداخلي سلسلة مرمّزة مثل _x72b6__x614b_، وكتابة الاسم المعروض كما هو في الصيغة لا تطابق. أنشئ الأعمدة التي يشير إليها التدفق بأسماء إنجليزية رقمية ثم غيّر الاسم المعروض إلى اليابانية، فتتفادى استهلاك الوقت في هذا النوع من الصيغ. يُؤكد الاسم الداخلي من عنوان URL لصفحة تفاصيل العمود في إعدادات القائمة (بعد Field=).

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

6. التشغيل والحوكمة ── لا تجعل التدفق «ملكاً لمن أنشأه»

بما أن تدفق الموافقات يتغلغل في صميم العمل، فإن اعتماده على شخص واحد يحدث أثراً كبيراً. أنجز على الأقل هاتين النقطتين في أول يوم تشغيل.

• إعداد المالكين المشاركين. يستطيع مالك التدفق الاطلاع على سجل التنفيذ، وتحرير التدفق أو إيقافه، وتحديث بيانات اعتماد الاتصالات. إذا بقي المنشئ الوحيد هو المالك، يصبح التدفق عاجزاً عن الإصلاح في اللحظة التي يستقيل فيها أو ينتقل. أضف موظف نظم المعلومات أو المرشح للخلافة كمالك مشارك. توجد أيضاً ميزة تسمح بجعل قائمة SharePoint نفسها مالكاً مشاركاً بحيث «من يملك صلاحية تعديل القائمة = من يستطيع تعديل التدفق»⁶، لكن إذا استُخدمت هذه الميزة في قائمة استقبال يكتب فيها جميع مقدّمي الطلبات كما في هذا المقال، فسيؤدي ذلك إلى منح جميع مقدّمي الطلبات صلاحية تحرير التدفق. لا تستخدم هذه الميزة في تدفق الموافقات، واقصر المالكين المشاركين على الموظف الفرد المسؤول عن التشغيل أو مجموعة إدارية مخصّصة.
• فهم طريقة التعامل مع الاتصالات. ترتبط الاتصالات (المصادقة إلى SharePoint أو Outlook) المستخدمة في التدفق بالمستخدم الذي أنشأها، ولا يمكن استخدام الاتصال المشترك إلا داخل التدفق نفسه. كما لا يستطيع المالك المشارك تغيير بيانات اعتماد اتصال أنشأه مالك آخر.⁶ من هنا تحدث حوادث مثل استمرار إرسال بريد إشعار نتيجة الموافقة من «حساب موظف مستقيل»، أو توقف التدفق بمجرد تعطيل الحساب. تحديد الحساب المستخدم للإشعار والكتابة نقطة يجب حسمها قبل إنشاء التدفق.

حتى عند إتاحة التدفق لأقسام أخرى، لا حاجة لمشاركة التدفق نفسه مع مقدّمي الطلبات. في البنية الموضحة في هذا المقال، يبدأ التدفق تلقائياً بمجرد إمكانية الإدخال في نقطة الاستقبال (Forms أو قائمة SharePoint). المبدأ هو قصر المشاركة على المعنيين بالتحرير والتشغيل فقط، وإبقاء عدد المالكين المشاركين عند الحد الأدنى الضروري.²¹

أما حوكمة Power Automate الشاملة، مثل التراخيص وفصل البيئات وسياسات DLP، فقد رتّبناها في مقال آخر بعنوان «أتمتة الأعمال باستخدام Power Automate ── الفصل بين التدفق السحابي وتدفق سطح المكتب وتصميم معالجة الأخطاء». وبما أن تدفق الموافقات أيضاً نوع من التدفق السحابي، فإن نفس المفاهيم تنطبق عليه كما هي.

7. إلى أي حد ننجز الأمر عبر Power Automate؟

موافقات Power Automate قوية، لكنها ليست أداة لتنفيذ لائحة الاعتماد الداخلي كما هي. نورد فيما يلي معايير الخط الفاصل.

كمعيار حدسي للقرار، ننظر إلى الأمر بهذا الشكل: «إذا رسمت تفرعات التدفق على ورقة ولم تعد تسع في صفحة A4، فقد بدأت تتجاوز نطاق تغطية Power Automate». وغالباً ما يكون القرار الأرخص في النهاية هو إخراج منطق تحديد مسار الموافقة وحده إلى الخارج (جدول Dataverse أو نظام منفصل)، أو الانتقال إلى نظام مخصّص، بدلاً من إجبار التدفق على النمو.

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

8. الخلاصة

المشكلة الحقيقية في الاعتماد الورقي والبريدي لم تكن العناء، بل «عدم وضوح الحالة، وتشتت السجلات، وتعذّر تتبع إعادة الطلب للتصحيح». يحل تدفق موافقات Power Automate هذه المشكلات الثلاث بشكل «تجميع الطلب وسجل الموافقة في قائمة SharePoint، وإتمام عملية الموافقة عبر Teams/Outlook». وكون البدء غالباً ممكناً دون استثمار إضافي في الأنظمة ميزة كبيرة للشركات التي اعتمدت Microsoft 365 بالفعل.

في المقابل، إذا صُمم التدفق دون معرفة قيود «28 يوماً لسجل التنفيذ» و«30 يوماً لفترة التنفيذ»، ينتج تدفق موافقات «يختفي فيه الأثر» و«يفشل فيه الطلب صمتاً». إذا أُدرجت النقاط الأربع ── كتابة النتيجة، وتفرع المهلة الزمنية، والموافِقون المتعددون، والمالكون المشاركون ── في التصميم منذ البداية، يمكن تشغيل تدفق الموافقات بثقة لفترة طويلة. وعندما تريد تنفيذ تعقيد لائحة الاعتماد الداخلي كما هو، فتلك هي اللحظة المناسبة للنظر في نظام مخصّص أو تطوير البرمجيات المخصّصة.

مقالات ذات صلة

• أتمتة الأعمال باستخدام Power Automate ── الفصل بين التدفق السحابي وتدفق سطح المكتب وتصميم معالجة الأخطاء
• كيفية نقل طلبات الفاكس إلى الويب ── تصميم فترة التشغيل المزدوج وممارسات الانتقال المرحلي
• ما هو EDI؟ كيف يسهّل الطلب والتوريد بين الشركات ── من الفاكس والبريد والإدخال اليدوي إلى تكامل البيانات
• ما هي الفاتورة الرقمية؟ ── ما الفرق عن «إرسال ملف PDF للفاتورة بالبريد الإلكتروني»

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع استشارات رقمنة تدفقات العمل بالاستفادة من Microsoft 365، وصولاً إلى بناء الأنظمة الخاصة بمتطلبات الموافقة والنماذج التي لا يغطيها Power Automate.

• الاستشارة التقنية ومراجعة التصميم
• تطوير تطبيقات Windows
• التواصل معنا

روابط مرجعية

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل يمكن بناء تدفق موافقات في Power Automate بترخيص Microsoft 365 وحده؟

نعم يمكن ذلك. بما أن موصل الموافقات (Approvals) موصل قياسي، فإن أي ترخيص يتيح استخدام الموصلات القياسية (مثل Office 365) يكفي لإنشاء تدفق موافقات. لكن يلزم وجود قاعدة بيانات Microsoft Dataverse كمكان لحفظ بيانات الموافقة، وتُهيأ تلقائياً في البيئة الافتراضية عند إنشاء أول تدفق موافقات. كما يمكن تكوين التكامل مع قائمة SharePoint وForms وTeams وOutlook ضمن نطاق الموصلات القياسية أيضاً.

ماذا يحدث إذا ترك الموافِق الطلب دون استجابة؟

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

أين تُحفظ سجلات الموافقة؟ وهل يمكن استخدامها للتدقيق؟

تُحفظ طلبات الموافقة واستجاباتها كسجلات في Microsoft Dataverse، بينما لا يظهر سجل تنفيذ التدفق نفسه افتراضياً إلا لمدة 28 يوماً. الاعتماد على سجل التنفيذ للتدقيق أو الاستفسار لاحقاً أمر خطر. في العمل الفعلي نوصي بتصميم يكتب نتيجة الموافقة والموافِق وتاريخ الموافقة والتعليق إلى أعمدة قائمة SharePoint في نهاية التدفق، بحيث يمكن عرض بيانات الطلب وسجل الموافقة معاً في مكان واحد.

ماذا نفعل عندما يكون الموافِق غائباً أو مستقيلًا؟

يستطيع الشخص الذي تلقى طلب الموافقة نفسه إعادة توزيعه (Reassign) إلى شخص آخر من قائمة موافقات Power Automate. لا يستطيع الطرف الذي أصدر الطلب إعادة التوزيع، لكن يمكنه إلغاء الطلب وتغيير الموافِق في التدفق وإعادة التشغيل. للاستعداد للغياب الدائم، يقل التعثر إذا صُمم التدفق بحيث لا يُثبَّت الموافِق كشخص واحد بل يُرسل إلى عدة أشخاص أو مجموعة. كما أن من المهم إعداد المالكين المشاركين منذ البداية استعداداً لاستقالة مالك التدفق نفسه.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.