بناء سير موافقات باستخدام 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 غير ممكنة. عندئذٍ يدخل الأمر ضمن نطاق أنظمة سير العمل (workflow systems) أو التطوير بالتعاقد.

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

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

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

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

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

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

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

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

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

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

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

يصل طلب الموافقة إلى الموافِق عبر البريد الإلكترونيّ وتطبيق 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 يوماً، وتعديلها متروك للمسؤول (admin).¹²

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يبقى سجلّ التعديل في سجلّ إصدارات القائمة، ما يحلّ أيضاً مشكلة اختلاط «أيّ نسخة تخصّها الملاحظة». يمكن أيضاً بناء حلقة 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 للفاتورة بالبريد الإلكتروني»

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

تتعامل شركة Komura Soft LLC مع استشارات رقمنة تدفّقات العمل بالاستفادة من 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. لا يستطيع الطرف الذي أصدر الطلب إعادة التوزيع، لكن يمكنه إلغاء الطلب وتغيير الموافِق في سير العمل وإعادة التشغيل. للاستعداد للغياب الدائم، يقلّ التعثّر إذا صُمِّم سير العمل بحيث لا يُثبَّت الموافِق كشخص واحد بل يُرسَل إلى عدّة أشخاص أو مجموعة. كما أنّ من المهمّ إعداد المالكين المشاركين منذ البداية استعداداً لاستقالة مالك سير العمل نفسه.

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

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

غو كومورا

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

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