در بسیاری از اتوماسیون‌ها لازم نیست تمام مراحل بلافاصله و پشت سر هم اجرا شوند. گاهی لازم است بعد از دریافت اطلاعات چند دقیقه صبر کنید، پیام یادآوری را چند ساعت بعد ارسال کنید یا ادامه یک Workflow را تا رسیدن به زمان مشخصی به تعویق بیندازید.
برای مثال، فرض کنید یک فروشگاه اینترنتی دارید و می‌خواهید بعد از ثبت سفارش، ابتدا پیام تأیید برای مشتری ارسال شود و سپس دو ساعت بعد، پیام دیگری برای پیگیری سفارش ارسال کنید. اگر تمام مراحل بدون تأخیر اجرا شوند، پیام دوم نیز بلافاصله فرستاده می‌شود و نتیجه موردنظر شما به دست نمی‌آید.
در n8n می‌توانید برای چنین سناریوهایی از Node به نام Wait استفاده کنید. این Node امکان متوقف کردن موقت اجرای Workflow و ادامه دادن آن پس از سپری شدن زمان یا در شرایط زمانی پشتیبانی‌شده را فراهم می‌کند.
در این مقاله یاد می‌گیرید Wait چیست، چگونه آن را تنظیم کنید، چه تفاوتی با Schedule Trigger دارد و چگونه از آن در اتوماسیون‌های واقعی استفاده کنید.
Wait در n8n چیست؟
Wait یکی از Nodeهای n8n است که برای به تعویق انداختن ادامه اجرای Workflow استفاده می‌شود.
فرض کنید Workflow شما شامل مراحل زیر است:
- دریافت اطلاعات مشتری
- ارسال پیام اولیه
- انتظار به مدت مشخص
- ارسال پیام پیگیری
اگر Node مربوط به Wait را بین مرحله دوم و چهارم قرار دهید، ادامه اجرا تا پایان زمان انتظار به تعویق می‌افتد.
کاربردهای رایج Wait عبارت‌اند از:
- ارسال پیام یادآوری پس از ثبت سفارش
- فاصله انداختن بین درخواست‌های API
- انتظار پیش از بررسی دوباره وضعیت یک عملیات
- اجرای مراحل بعدی پس از سپری شدن زمان مشخص
- ایجاد تأخیر در فرایندهای پیگیری مشتری
- به تعویق انداختن ادامه یک Workflow تا زمان مشخص، در صورت پشتیبانی حالت انتخاب‌شده
نکته مهم این است که Wait با خاموش کردن یا متوقف کردن دائمی Workflow تفاوت دارد. هدف این Node به تعویق انداختن ادامه اجرای همان فرایند است، نه لغو آن.
همچنین Wait برای همه سناریوهای زمان‌بندی مناسب نیست. اگر می‌خواهید یک Workflow هر روز در ساعت مشخصی از ابتدا اجرا شود، معمولاً Schedule Trigger انتخاب مناسب‌تری است.
تفاوت Wait با Schedule Trigger چیست؟
این دو Node ممکن است از نظر زمان‌بندی شبیه به هم به نظر برسند، اما کاربرد متفاوتی دارند.
| ویژگی | Wait | Schedule Trigger |
|---|---|---|
| کاربرد اصلی | به تعویق انداختن ادامه اجرای جاری | شروع اجرای Workflow بر اساس برنامه زمانی |
| شروع فرایند | معمولاً پس از رسیدن اجرا به این Node | در زمان‌بندی تعریف‌شده |
| مثال | ارسال پیام دو ساعت بعد از ثبت سفارش | اجرای گزارش فروش هر روز ساعت ۹ |
| ارتباط با اجرای قبلی | ادامه همان اجرای متوقف‌شده | شروع یک اجرای جدید طبق برنامه |
برای مثال، اگر می‌خواهید پس از ثبت هر سفارش، دقیقاً دو ساعت برای پیگیری صبر کنید، Wait مناسب است.
اما اگر می‌خواهید هر روز ساعت ۹ صبح گزارش فروش روز قبل تولید شود، Schedule Trigger انتخاب منطقی‌تری خواهد بود.
در بعضی سناریوها می‌توان از هر دو استفاده کرد؛ مثلاً Schedule Trigger هر روز فهرست سفارش‌های نیازمند پیگیری را بررسی کند و سپس Workflow متناسب با هر سفارش را اجرا کند.
چگونه Wait Node را در n8n اضافه کنیم؟
برای شروع، یک Workflow آزمایشی می‌سازیم که پس از اجرای دستی، مدتی صبر کند و سپس مرحله بعدی را اجرا کند.
مرحله اول: ایجاد Workflow
وارد پنل n8n شوید و یک Workflow جدید بسازید.
یک Manual Trigger به Workflow اضافه کنید تا بتوانید فرایند را به‌صورت دستی آغاز کنید.
سپس Node مربوط به Wait را به Workflow اضافه کنید.
ساختار ساده Workflow به این شکل خواهد بود:
Manual Trigger → Wait → Edit Fields
در این مثال، Edit Fields برای نمایش یک مقدار نمونه بعد از پایان انتظار استفاده می‌شود.
مرحله دوم: تنظیم Wait
روی Node مربوط به Wait کلیک کنید تا تنظیمات آن نمایش داده شود.
بسته به نسخه n8n، گزینه‌های مربوط به زمان انتظار و حالت ادامه اجرا ممکن است در بخش پارامترهای Node نمایش داده شوند.
یکی از حالت‌های رایج، تعیین یک فاصله زمانی مشخص است. برای مثال، می‌توانید تنظیم کنید Workflow به مدت ۳۰ ثانیه منتظر بماند.
در تنظیمات زمان انتظار، مقدار و واحد زمانی را متناسب با نیاز خود انتخاب کنید.
مرحله سوم: تنظیم Node بعد از Wait
پس از Wait، یک Node از نوع Edit Fields اضافه کنید.
در این Node می‌توانید فیلدی مانند status بسازید و مقدار آن را برابر با completed قرار دهید.
این مقدار صرفاً برای نمایش نتیجه آزمایش است و نشان می‌دهد Workflow پس از انتظار به مرحله بعدی رسیده است.
مرحله چهارم: اجرای آزمایشی
Workflow را اجرا کنید و رفتار آن را بررسی کنید.
اجرای Workflow به Wait می‌رسد و ادامه فرایند به تعویق می‌افتد. پس از پایان زمان انتظار، مرحله بعدی اجرا می‌شود.
مدت انتظار واقعی ممکن است به زمان‌بندی داخلی سیستم، بار سرور و شرایط اجرای n8n وابسته باشد؛ بنابراین Wait را ابزار تضمین اجرای دقیق در یک میلی‌ثانیه مشخص در نظر نگیرید.
روش‌های استفاده از Wait در n8n
Wait می‌تواند در سناریوهای مختلفی استفاده شود. حالت دقیق در دسترس به نسخه n8n و تنظیمات Node بستگی دارد.
۱. انتظار برای مدت زمان مشخص
این حالت زمانی کاربرد دارد که می‌خواهید بعد از رسیدن Workflow به Wait، مدت مشخصی صبر کنید.
برای مثال:
- ۱۰ ثانیه پس از دریافت درخواست
- ۵ دقیقه پس از ارسال پیام
- ۲ ساعت پس از ثبت سفارش
- ۱ روز پس از ارسال ایمیل
برای استفاده از این حالت، گزینه انتظار برای مدت زمان مشخص را انتخاب کنید و مقدار و واحد زمانی را وارد کنید.
برای مثال، در یک Workflow آزمایشی می‌توانید انتظار ۳۰ ثانیه‌ای تنظیم کنید تا رفتار Node را مشاهده کنید.
این روش برای فاصله انداختن بین مراحل یک فرایند مناسب است؛ اما اگر زمان اجرای دقیق بر اساس تقویم مهم باشد، بهتر است از حالت زمانی مناسب یا ابزار زمان‌بندی دیگری استفاده کنید.
۲. ادامه اجرا در زمان مشخص
در برخی حالت‌های Wait می‌توانید ادامه اجرای Workflow را به زمان مشخصی موکول کنید.
برای مثال، فرض کنید پیام اولیه ساعت ۱۰ صبح ارسال شده و می‌خواهید ادامه فرایند ساعت ۳ بعدازظهر انجام شود.
در این سناریو باید حالت مربوط به زمان مشخص را انتخاب کنید و زمان موردنظر را مطابق تنظیمات Node وارد کنید.
اگر زمان را با Expression از داده‌های قبلی می‌گیرید، ابتدا بررسی کنید مقدار نهایی در قالب مورد انتظار Node باشد.
همچنین منطقه زمانی اهمیت دارد. اگر Workflow روی سرور اجرا می‌شود، منطقه زمانی سرور یا تنظیمات مربوط به زمان n8n ممکن است با منطقه زمانی موردنظر کسب‌وکار شما متفاوت باشد. پیش از استفاده در محیط اصلی، این مورد را آزمایش کنید.
۳. انتظار تا یک زمان محاسبه‌شده
گاهی زمان ادامه اجرا از قبل ثابت نیست و بر اساس داده‌های Workflow تعیین می‌شود.
برای مثال، ممکن است در داده سفارش یک زمان پیگیری ذخیره شده باشد. در این شرایط، اگر حالت انتخابی Wait از Expression پشتیبانی کند، می‌توانید مقدار زمان را از داده‌های قبلی دریافت کنید.
فرض کنید فیلد followUpAt شامل زمان موردنظر باشد. یک Expression مفهومی برای دسترسی به آن چنین است:
{{ $json.followUpAt }}
این Expression فقط مقدار فیلد را می‌خواند؛ قالب دقیق تاریخ و زمان باید با انتظار تنظیمات همان Node مطابقت داشته باشد.
قبل از استفاده در محیط اصلی، موارد زیر را بررسی کنید:
- آیا فیلد واقعاً در ورودی وجود دارد؟
- آیا مقدار آن یک تاریخ معتبر است؟
- آیا منطقه زمانی مشخص است؟
- آیا زمان موردنظر در آینده قرار دارد؟
- رفتار Node هنگام دریافت مقدار خالی یا نامعتبر چیست؟
بهتر است داده‌های تاریخ و زمان را پیش از رسیدن به Wait اعتبارسنجی کنید تا اجرای Workflow به دلیل ورودی نامعتبر دچار مشکل نشود.
مثال عملی: ارسال پیام پیگیری دو ساعت پس از ثبت سفارش
یکی از کاربردهای مناسب Wait، ایجاد تأخیر در فرایند پیگیری سفارش‌های فروشگاه اینترنتی است.
فرض کنید پس از ثبت سفارش، می‌خواهید پیام تأیید ارسال شود و دو ساعت بعد، یک پیام پیگیری برای مشتری آماده شود.
ساختار مفهومی Workflow:
Trigger سفارش → آماده‌سازی داده‌ها → ارسال پیام اول → Wait → ارسال پیام دوم
مرحله اول: دریافت سفارش
Workflow باید اطلاعات سفارش را از منبع موردنظر دریافت کند؛ برای مثال، Webhook فروشگاه یا Node مربوط به سرویس سفارش‌ها.
داده‌های موردنیاز می‌توانند شامل شناسه سفارش، شماره تماس مشتری و وضعیت سفارش باشند.
مرحله دوم: ارسال پیام اولیه
در این مرحله می‌توانید از Node مناسب برای سرویس پیام‌رسان یا سامانه پیامکی استفاده کنید.
برای مثال، پیام اولیه می‌تواند شامل تأیید دریافت سفارش باشد.
نوع Node و اطلاعات اتصال به سرویس مقصد به ارائه‌دهنده پیامک یا پیام‌رسان شما بستگی دارد. اطلاعات احراز هویت را به‌صورت امن و از طریق Credentials مدیریت کنید.
مرحله سوم: اضافه کردن Wait
پس از ارسال پیام اولیه، Wait را به Workflow متصل کنید.
حالت انتظار برای مدت مشخص را انتخاب کنید و زمان را روی دو ساعت تنظیم کنید.
در این مرحله، ادامه اجرای جاری تا پایان زمان انتظار به تعویق می‌افتد.
مرحله چهارم: بررسی وضعیت سفارش
این مرحله در یک سیستم واقعی بسیار مهم است.
فرض کنید مشتری در فاصله دو ساعت سفارش را لغو کرده یا سفارش به وضعیت دیگری تغییر کرده است. اگر بدون بررسی وضعیت، پیام پیگیری ارسال شود، ممکن است پیام نامناسبی به مشتری برسد.
بنابراین، بهتر است پس از Wait، وضعیت فعلی سفارش را دوباره از منبع معتبر دریافت کنید.
مرحله پنجم: استفاده از IF برای تصمیم‌گیری
پس از دریافت وضعیت جدید، یک Node از نوع IF اضافه کنید.
شرط را به‌گونه‌ای تنظیم کنید که مشخص شود آیا سفارش هنوز در وضعیتی قرار دارد که ارسال پیام پیگیری برای آن مناسب است یا خیر.
- اگر سفارش هنوز نیازمند پیگیری است، پیام دوم ارسال شود.
- اگر سفارش لغو شده یا قبلاً تکمیل شده است، پیام ارسال نشود یا مسیر مناسب دیگری اجرا شود.
در این مثال، Wait فقط تأخیر را مدیریت می‌کند؛ تصمیم‌گیری درباره ارسال پیام بر اساس وضعیت جدید با IF انجام می‌شود.
نکته مهم: اگر Workflow برای هر سفارش جداگانه اجرا می‌شود، باید برای تعداد اجراهای هم‌زمان و نگهداری وضعیت سفارش‌ها نیز برنامه داشته باشید. در فروشگاه‌های پرترافیک، طراحی و آزمایش این فرایند پیش از استفاده در محیط اصلی ضروری است.
مثال دوم: ایجاد فاصله بین درخواست‌های API
فرض کنید یک Workflow باید اطلاعات ۱۰۰ محصول را از یک سرویس خارجی دریافت کند.
اگر برای هر محصول درخواست جداگانه ارسال شود، ممکن است سرویس مقصد محدودیت تعداد درخواست اعمال کند یا به دلیل تعداد زیاد درخواست‌ها پاسخ‌دهی کندتر شود.
در برخی سناریوها، اضافه کردن Wait بین بخش‌هایی از فرایند می‌تواند به کاهش سرعت ارسال درخواست‌ها کمک کند.
برای مثال، ساختار مفهومی فرایند چنین است:
دریافت فهرست محصولات → پردازش محصولات → Wait → ادامه پردازش
اما یک نکته مهم وجود دارد: اگر Wait را فقط بعد از یک Node قرار دهید که تمام ۱۰۰ درخواست را پشت سر هم اجرا کرده است، تأخیر ایجادشده جلوی درخواست‌های قبلی را نمی‌گیرد.
اگر هدف شما محدود کردن نرخ درخواست‌هاست، باید طراحی پردازش را به‌گونه‌ای انجام دهید که فاصله زمانی در محل مناسب اعمال شود؛ برای مثال، بین گروه‌های درخواست یا در ساختاری که هر درخواست را با زمان‌بندی مناسب اجرا می‌کند.
همچنین اگر API محدودیت مشخصی برای تعداد درخواست‌ها دارد، مستندات آن را بررسی کنید. Wait به‌تنهایی تضمین نمی‌کند که محدودیت نرخ درخواست‌ها رعایت شود؛ زیرا ممکن است Workflowهای دیگری نیز هم‌زمان به همان API درخواست ارسال کنند.
آیا Wait باعث مصرف منابع سرور می‌شود؟
این موضوع به نحوه اجرا، نسخه n8n، تنظیمات استقرار و مدت انتظار بستگی دارد.
Wait برای مدیریت اجرای به‌تعویق‌افتاده طراحی شده است و نباید آن را معادل نگه داشتن یک حلقه پردازشی فعال برای تمام مدت انتظار در نظر گرفت. با این حال، اجرای Workflow همچنان باید وضعیت لازم برای ادامه کار را نگهداری کند و منابع سیستم نیز محدود هستند.
اگر Workflowهای زیادی دارید که هرکدام برای ساعت‌ها یا روزها منتظر می‌مانند، بهتر است رفتار اجرای متوقف‌شده، پایگاه داده و تنظیمات نگهداری داده‌ها را در محیط خود بررسی کنید.
برای نمونه، در یک سامانه فروشگاهی با هزاران سفارش، ممکن است تعداد زیادی اجرای منتظر وجود داشته باشد. پیش از طراحی چنین معماری‌ای، باید ظرفیت زیرساخت، سیاست نگهداری Executionها و نحوه مدیریت اجرای طولانی‌مدت را ارزیابی کنید.
تفاوت Wait با Retry On Fail
Wait و Retry On Fail هر دو می‌توانند باعث شوند یک فرایند بلافاصله ادامه پیدا نکند، اما کاربرد آن‌ها متفاوت است.
Retry On Fail برای تلاش مجدد پس از شکست یک Node استفاده می‌شود. در مقابل، Wait برای به تعویق انداختن ادامه اجرای Workflow به کار می‌رود.
برای مثال، اگر درخواست HTTP به دلیل اختلال موقت ناموفق شود، Retry On Fail می‌تواند تلاش مجدد را مدیریت کند.
اما اگر می‌خواهید پس از ارسال یک پیام، دو ساعت صبر کنید و سپس وضعیت سفارش را بررسی کنید، Wait انتخاب مناسب‌تری است.
در بعضی Workflowها می‌توان از هر دو استفاده کرد؛ مثلاً درخواست بررسی وضعیت سفارش، تنظیمات Retry داشته باشد و پیش از بررسی بعدی، Wait اجرا شود.
البته برای خطاهای دائمی یا عملیات حساس، نباید صرفاً با افزایش تعداد تلاش‌ها یا زمان انتظار، علت اصلی مشکل را نادیده گرفت.
تفاوت Wait با زمان‌بندی مستقل یک Workflow
فرض کنید می‌خواهید هر روز ساعت ۹ صبح گزارش فروش تولید شود. در این حالت، Schedule Trigger معمولاً انتخاب مناسبی است؛ زیرا هدف شما آغاز اجرای جدید بر اساس برنامه زمانی است.
اما اگر پس از ثبت هر سفارش، می‌خواهید دو ساعت بعد همان فرایند ادامه پیدا کند، Wait مناسب‌تر است.
یک روش دیگر برای بعضی سناریوها این است که زمان پیگیری را در پایگاه داده ذخیره کنید و یک Workflow زمان‌بندی‌شده، سفارش‌های سررسیدشده را بررسی کند. این معماری می‌تواند برای حجم زیاد کار یا فرایندهایی که نیاز به کنترل دقیق وضعیت دارند مناسب باشد، اما به طراحی پایگاه داده، جلوگیری از پردازش تکراری و مدیریت خطا نیاز دارد.
بنابراین، انتخاب بین Wait و Schedule Trigger به این بستگی دارد که آیا می‌خواهید اجرای جاری را ادامه دهید یا در زمان مشخص یک اجرای جدید آغاز کنید.
خطاهای رایج هنگام استفاده از Wait در n8n
۱. انتخاب واحد زمانی اشتباه
ممکن است قصد داشته باشید ۳۰ دقیقه انتظار ایجاد کنید، اما مقدار یا واحد زمانی را اشتباه وارد کنید.
راهکار: مقدار و واحد زمان را قبل از ذخیره بررسی کنید و ابتدا با زمان کوتاه در یک Workflow آزمایشی رفتار Node را بسنجید.
۲. استفاده از تاریخ نامعتبر
اگر زمان انتظار از داده‌های قبلی دریافت شود و قالب تاریخ اشتباه باشد، ممکن است Node نتواند مقدار را مطابق انتظار پردازش کند.
راهکار: مقدار ورودی را پیش از Wait اعتبارسنجی کنید و قالب موردنیاز حالت انتخاب‌شده را رعایت کنید.
۳. فراموش کردن بررسی وضعیت جدید
در فرایندهای چندمرحله‌ای، ممکن است شرایط در زمان انتظار تغییر کند.
برای مثال، سفارش لغو شده یا مشتری قبلاً پاسخ داده باشد.
راهکار: پس از Wait، در صورت اهمیت وضعیت فعلی، اطلاعات را دوباره دریافت و با IF یا Switch بررسی کنید.
۴. استفاده از Wait برای زمان‌بندی تکرارشونده
اگر می‌خواهید هر روز یا هر هفته یک Workflow اجرا شود، ایجاد یک فرایند طولانی با Waitهای تکرارشونده همیشه بهترین انتخاب نیست.
راهکار: برای شروع اجرا در زمان‌های تکرارشونده، Schedule Trigger را بررسی کنید.
۵. فرض کردن اینکه زمان انتظار دقیقاً در همان لحظه تمام می‌شود
بار سرور، زمان‌بندی اجرا و شرایط زیرساخت ممکن است روی زمان واقعی ادامه اجرا تأثیر بگذارند.
راهکار: برای کارهایی که به زمان دقیق یا تضمین‌های سخت‌گیرانه نیاز دارند، معماری مناسب و ابزار زمان‌بندی متناسب با نیاز را انتخاب کنید.
بهترین روش‌های استفاده از Wait در پروژه‌های واقعی
برای استفاده مطمئن‌تر از Wait، نکات زیر را در نظر بگیرید:
- زمان انتظار را متناسب با نیاز واقعی کسب‌وکار انتخاب کنید.
- برای زمان‌های پویا، ورودی‌ها و قالب تاریخ را اعتبارسنجی کنید.
- پس از انتظار، وضعیت داده‌های مهم را دوباره بررسی کنید.
- برای شروع اجرای دوره‌ای Workflow از Schedule Trigger استفاده کنید.
- در صورت نیاز به محدودیت نرخ درخواست‌ها، ساختار پردازش را متناسب با محدودیت API طراحی کنید.
- Workflowهای طولانی و تعداد زیاد اجراهای منتظر را روی زیرساخت خود آزمایش کنید.
- برای عملیات مهم، مسیر مدیریت خطا و جلوگیری از اجرای تکراری را در نظر بگیرید.
- از نگهداری غیرضروری داده‌های حساس در ورودی‌ها، خروجی‌ها و گزارش‌های اجرا خودداری کنید.
جمع‌بندی
Wait در n8n ابزاری برای به تعویق انداختن ادامه اجرای Workflow است. با استفاده از آن می‌توانید بین مراحل یک فرایند فاصله زمانی ایجاد کنید، پیام‌های پیگیری را با تأخیر ارسال کنید یا ادامه پردازش را به زمان مشخصی موکول کنید.
با این حال، Wait با Schedule Trigger و Retry On Fail تفاوت دارد. برای ادامه یک اجرای جاری پس از گذشت زمان، Wait مناسب است؛ برای آغاز اجرای جدید در زمان‌بندی مشخص، Schedule Trigger را در نظر بگیرید؛ و برای تلاش مجدد پس از شکست یک Node، از Retry On Fail استفاده کنید.
در پروژه‌های واقعی، به‌ویژه اتوماسیون سفارش‌ها و پیام‌رسانی، بهتر است پس از پایان انتظار وضعیت فعلی داده‌ها را دوباره بررسی کنید تا تصمیم‌ها بر اساس اطلاعات قدیمی گرفته نشوند.
سؤالات متداول
Wait در n8n چه کاری انجام می‌دهد؟
Wait اجرای جاری Workflow را به تعویق می‌اندازد و اجازه می‌دهد فرایند پس از پایان زمان انتظار یا بر اساس حالت پشتیبانی‌شده ادامه پیدا کند.
چگونه در n8n بعد از چند دقیقه پیام ارسال کنیم؟
Node مربوط به ارسال پیام را پس از Wait قرار دهید و زمان انتظار را روی تعداد دقیقه موردنظر تنظیم کنید. اگر ارسال پیام به وضعیت سفارش یا پاسخ مشتری وابسته است، پیش از ارسال وضعیت را دوباره بررسی کنید.
تفاوت Wait با Schedule Trigger چیست؟
Wait برای به تعویق انداختن ادامه اجرای جاری استفاده می‌شود، درحالی‌که Schedule Trigger اجرای Workflow را بر اساس برنامه زمانی آغاز می‌کند.
آیا می‌توان زمان Wait را با Expression تعیین کرد؟
در حالت‌ها و فیلدهایی که از Expression پشتیبانی می‌کنند، می‌توانید زمان را از داده‌های قبلی دریافت کنید. قالب تاریخ، منطقه زمانی و معتبر بودن مقدار باید با تنظیمات Node سازگار باشد.
آیا Wait برای جلوگیری از محدودیت API کافی است؟
خیر. Wait می‌تواند در ایجاد فاصله زمانی بین مراحل کمک کند، اما رعایت محدودیت نرخ درخواست‌ها به ساختار پردازش، تعداد اجراهای هم‌زمان و سیاست سرویس مقصد نیز بستگی دارد.
آیا Wait برای ارسال پیام یادآوری مناسب است؟
بله، برای سناریوهایی مانند ارسال پیام یادآوری پس از ثبت سفارش یا گذشت مدت مشخصی از یک رویداد می‌تواند مفید باشد. در فرایندهای مهم، بهتر است پیش از ارسال پیام، وضعیت فعلی مشتری یا سفارش بررسی شود.
آیا می‌توان Workflow را چند روز در حالت انتظار نگه داشت؟
امکان و نحوه اجرای انتظار طولانی به قابلیت‌های نسخه و تنظیمات محیط n8n بستگی دارد. برای چنین سناریوهایی باید رفتار اجرای متوقف‌شده، نگهداری داده‌ها، ظرفیت زیرساخت و بازیابی پس از راه‌اندازی مجدد را در محیط واقعی بررسی کنید.
