أتمتة الرسائل توفر وقتًا، لكن الرسالة قد تخرج باسم عميل خاطئ أو بسعر لم يعد متاحًا. إضافة نقطة مراجعة بشرية إلى سير العمل تجعل الرسالة تتوقف عند مرحلة محددة قبل التنفيذ. هذا مفيد خصوصًا عندما يكتب الذكاء الاصطناعي مسودة أو عندما تأتي بيانات الطلب من أكثر من مصدر.
ما السيناريو الذي سنبنيه؟
سنفترض وجود طلب تجريبي يحتاج إلى رسالة تأكيد. المسار المقترح هو: قراءة بيانات الطلب، إعداد مسودة، إرسالها للمراجع، انتظار القرار، ثم إرسال الرسالة المعتمدة أو تسجيل الرفض. هذا تصميم إرشادي؛ لن نتصل بعملاء حقيقيين أثناء الاختبار.
الإعداد في عقدة Gmail
توثق n8n عملية Send and Wait for Approval في عقدة Gmail. اختر بيانات الاتصال المعتمدة، ثم Message كمورد والعملية الخاصة بالإرسال وانتظار الموافقة. حدد بريد المراجع، واكتب موضوعًا ونصًا يشرحان المطلوب. يمكن اختيار موافقة فقط أو موافقة ورفض. أسماء الخيارات قد تختلف مع تحديث الواجهة.
ماذا تضع في رسالة المراجعة؟
اكتب رقم الطلب التجريبي، وسبب المراجعة، والنص النهائي المقترح كما سيصل إلى العميل. لا تكتفِ بإرسال «هل توافق؟» دون سياق. لو المسودة تعتمد على سعر أو سياسة شحن، أظهر المعلومة التي بُنيت عليها. على المراجع أن يستطيع مقارنة الرسالة بالطلب بسرعة.
افصل القرار عن الإرسال النهائي
لا تفترض أن انتهاء الانتظار يعني الموافقة. افحص المخرجات الفعلية للعقدة في نسختك، وابنِ شرطًا يميز القبول عن الرفض. اجعل فرع الرفض يسجل الحالة أو يعيدها للتعديل، وفرع القبول ينفذ الإرسال النهائي. وفي المسارات المعقدة، تشير وثائق n8n إلى إمكان استخدام Wait لتصميم عملية مناسبة.
مثال افتراضي يمنع خطأ شائعًا
الطلب التجريبي يحتوي قطعتين بسعر إجمالي 800، لكن المسودة تقول «سعر القطعة 800». المراجع يرفضها ويضيف سببًا واضحًا. بعد التصحيح، تُنشأ نسخة جديدة للمراجعة؛ لا تجعل الموافقة على نسخة قديمة صالحة لأي نص يتغير بعد القرار. اربط كل موافقة بمعرف المسودة أو سجل النسخة.
اختبر أربع حالات
- قبول مسودة صحيحة: يجب أن تصل رسالة واحدة فقط إلى بريد الاختبار.
- رفض مسودة: يجب ألا تُرسل الرسالة النهائية.
- غياب الرد: يجب أن تظل الحالة معروفة، مع إجراء متابعة مناسب لتصميمك.
- إعادة تشغيل الطلب نفسه: يجب اكتشاف أنه أُرسل سابقًا قبل تكرار الإرسال.
تجنب الإرسال المكرر
احتفظ بسجل يحتوي معرف الطلب ومعرف المسودة وحالة القرار ووقت الإرسال. قبل الإرسال النهائي افحص حالة الطلب. هذا لا يغني عن تصميم موثوق للتزامن؛ إذا كانت هناك عمليات متوازية، فقد تحتاج إلى تخزين يضمن عدم اعتماد الإرسال نفسه مرتين. ابدأ بمسار بسيط، ثم اختبر حالات الفشل قبل توسيع الاستخدام.
الصلاحيات والخصوصية
استخدم حسابًا معتمدًا وأقل صلاحيات لازمة. لا تضع كلمات مرور أو رموز وصول في نص رسالة المراجعة. أرسل للمراجع البيانات التي يحتاجها فقط، واستخدم بيانات تجريبية أثناء بناء المسار. وجود مراجعة بشرية لا يبرر نقل معلومات العميل إلى جهة غير مخولة.
أسئلة شائعة
هل الموافقة البشرية تلغي الأتمتة؟
لا. يمكنك أتمتة جمع البيانات وإعداد المسودة والتسجيل، والإبقاء على قرار واحد للمراجع.
هل كل رسالة تحتاج موافقة؟
حدد ذلك بحسب طبيعة الرسالة واحتمال الخطأ. التغييرات المهمة في السعر أو الالتزام تستحق ضوابط أوضح من إشعار تجريبي روتيني.
كيف أعرف أن المسار يعمل؟
راجع سجل التنفيذ ومخرجات كل فرع وبريد الاختبار. نجاح عقدة منفردة لا يكفي لإثبات صحة المسار كله.
ابدأ برسالة تجريبية واحدة ومراجع واحد. عندما تنجح حالات القبول والرفض والتكرار، يصبح الانتقال إلى الاستخدام الفعلي أسهل في المراجعة والمتابعة.
اقرأ أيضًا: شروحات n8n والأتمتة.
مصدر رسمي: n8n: Gmail Message Operations. تمت مراجعة المقال في 7 أكتوبر 2026.