0

راهنمای عملی ساخت Approval Workflow چندمرحله‌ای در ManageEngine AppCreator؛ از Form و Criteria و Approver تا Action، API، امنیت، گزارش و استقرار سازمانی.

شرکت مدانت
شرکت مدانت
[ مجری تخصصی پیاده‌سازی چارچوب ITIL و تحول دیجیتال ]
Approval Workflow در AppCreator؛ ساخت گردش تأیید چندمرحله‌ای از فرم تا اجرا

فرض کنید واحد خرید یک درخواست ۸۰۰ میلیون تومانی ثبت کرده است. درخواست باید ابتدا توسط مدیر واحد، بعد مالی و در صورت عبور از یک سقف مشخص توسط مدیر ارشد تأیید شود. اگر موضوع خرید تجهیزات IT باشد، شاید تیم فناوری اطلاعات هم باید مشخصات فنی را بررسی کند. در بسیاری از سازمان‌ها این مسیر هنوز با ایمیل، فایل Excel، تماس تلفنی و پیام در گروه‌های کاری جلو می‌رود؛ در نتیجه معلوم نیست درخواست دقیقاً کجاست، چه کسی آن را معطل کرده و نسخه نهایی اطلاعات کدام است.

برای چنین سناریوهایی همیشه لازم نیست یک سامانه بزرگ سازمانی از صفر نوشته شود. ManageEngine AppCreator یک پلتفرم Low-code درون‌سازمانی است که می‌تواند فرم، داده، Approval Workflow، گزارش، داشبورد و Integration را در یک Application سفارشی کنار هم قرار دهد. در این راهنما، تمرکز ما روی Approval Workflow در AppCreator است: چطور یک فرآیند تأیید چندمرحله‌ای بسازیم که هم قابل کنترل باشد و هم بعداً بتوان آن را توسعه داد.

اگر هدف شما شناخت کلی پلتفرم است، ابتدا صفحه ManageEngine AppCreator در مدانت را ببینید. این مقاله وارد یک Use Case مشخص می‌شود و با صفحه محصول رقابت نمی‌کند.

Approval Workflow در AppCreator دقیقاً چه کاری انجام می‌دهد؟

در AppCreator، Approval Process یک Workflow است که رکورد ثبت‌شده از طریق Form را بر اساس ترتیب تعریف‌شده برای تأیید یا رد به تصمیم‌گیرندگان می‌فرستد. مدیر Application می‌تواند تعیین کند کدام رکوردها وارد فرآیند تأیید شوند، چند سطح Approval وجود داشته باشد، Approver هر سطح چه کسی باشد و بعد از Approve یا Reject چه Actionهایی اجرا شوند.

مستندات رسمی ManageEngine مثال‌هایی مثل Expense Report و Leave Request را مطرح می‌کنند؛ جایی که مقدار درخواست می‌تواند مسیر Approval را تغییر دهد. همین منطق را می‌توان برای خرید، درخواست دسترسی، قرارداد، درخواست استخدام، تغییر قیمت، ثبت Vendor، درخواست پروژه یا فرآیندهای اختصاصی سازمان به‌کار برد.

چرا ایمیل و Excel برای Approval چندمرحله‌ای زود فرسوده می‌شوند؟

موضوع ایمیل / Excel Approval Workflow در AppCreator
وضعیت درخواست وابسته به پیگیری دستی در رکورد و Workflow قابل مشاهده
مسیر تأیید اغلب شفاهی یا پراکنده قاعده‌مند و قابل تغییر
شرط مبلغ/نوع درخواست وابسته به تشخیص افراد قابل تعریف با Criteria
ردیابی تصمیم در رشته ایمیل‌ها پخش می‌شود در Context همان رکورد نگهداری می‌شود
اعلان دستی یا با Ruleهای جدا Actionهای Workflow
گزارش مدیریتی نیازمند تجمیع دستی Report و Dashboard
Integration معمولاً پیچیده API و Actionهای Integration

مسئله اصلی فقط سرعت نیست. وقتی Approval به یک فرآیند قابل‌ردیابی تبدیل می‌شود، سازمان می‌تواند Bottleneck، زمان ماندگاری درخواست، نرخ رد، تعداد Rework و حجم کار هر Approver را نیز اندازه‌گیری کند.

قبل از ساخت Workflow، فرآیند را روی کاغذ درست کنید

Low-code سرعت ساخت را بالا می‌برد، اما فرآیند مبهم را خودکار نمی‌کند. قبل از ورود به AppCreator باید حداقل پنج سؤال روشن باشد:

  • چه کسی درخواست را ثبت می‌کند؟
  • چه داده‌هایی برای تصمیم‌گیری لازم است؟
  • چه شرطی مسیر Approval را تغییر می‌دهد؟
  • چه کسانی حق تأیید یا رد دارند؟
  • بعد از تأیید نهایی چه اتفاقی باید رخ دهد؟

اگر پاسخ این سؤال‌ها هر بار به تشخیص افراد تغییر کند، ابتدا باید Business Rule مشخص شود. Automation روی Rule پایدار ارزش ایجاد می‌کند؛ نه روی استثناهای تعریف‌نشده.

معماری پیشنهادی: Form → Criteria → Approver → Action → Report

برای اینکه Application بعداً قابل نگهداری بماند، Approval را در پنج لایه ببینید:

  1. Form: داده خام و لازم برای تصمیم.
  2. Criteria: اینکه کدام رکورد وارد کدام مسیر شود.
  3. Approver: فرد، Role یا Field تصمیم‌گیر.
  4. Action: کاری که پس از Approve/Reject انجام می‌شود.
  5. Report: دید مدیریتی و عملیاتی از وضعیت فرآیند.

این تفکیک ساده، جلوی یکی از مشکلات رایج را می‌گیرد: قراردادن همه منطق در یک Form شلوغ و وابسته کردن Application به چند Script پیچیده.

مرحله اول: Form را برای تصمیم‌گیری طراحی کنید، نه فقط ثبت اطلاعات

فرض کنیم می‌خواهیم «درخواست خرید سازمانی» بسازیم. یک Form مناسب می‌تواند شامل این فیلدها باشد:

  • درخواست‌دهنده و واحد سازمانی
  • نوع خرید: کالا، نرم‌افزار، خدمت یا اشتراک
  • مبلغ تخمینی
  • مرکز هزینه
  • فروشنده پیشنهادی
  • شرح توجیه کسب‌وکار
  • پیوست پیشنهاد قیمت
  • فوریت
  • مالک فنی در صورت خرید IT

هر فیلدی باید یک دلیل داشته باشد. اگر Approver برای تصمیم به داده‌ای نیاز دارد ولی آن داده در Form نیست، Workflow به تماس تلفنی برمی‌گردد و ارزش Automation کم می‌شود.

مرحله دوم: Approval Workflow را بسازید

در راهنمای رسمی AppCreator، ایجاد Approval از بخش Workflows شروع می‌شود. مسیر اصلی این است که یک Workflow جدید بسازید، گزینه During Approval Process را انتخاب کنید، Form هدف را مشخص کنید و سپس تعیین کنید فرآیند برای همه رکوردها اجرا شود یا فقط رکوردهایی که Criteria مشخصی دارند.

اگر فرآیند ساده است، می‌توان آن را برای همه Submissionها اجرا کرد. اما در محیط واقعی معمولاً Criteria ارزش زیادی دارد؛ چون همه درخواست‌ها به یک سطح تصمیم‌گیری نیاز ندارند.

مرحله سوم: Criteria را طوری بنویسید که فرآیند قابل توضیح باشد

یک مدل نمونه برای خرید:

شرط مسیر پیشنهادی
کمتر از ۵۰ میلیون تومان مدیر واحد
۵۰ تا ۵۰۰ میلیون مدیر واحد → مالی
بیش از ۵۰۰ میلیون مدیر واحد → مالی → مدیر ارشد
خرید نرم‌افزار یا تجهیزات IT افزودن تأیید فنی IT
Vendor جدید افزودن بررسی Vendor/حقوقی

اعداد بالا فقط مثال معماری هستند، نه پیشنهاد مالی. Threshold باید از Policy واقعی سازمان بیاید. مزیت Criteria این است که Rule به‌جای حافظه افراد، در Application اجرا می‌شود.

مرحله چهارم: Approver را درست انتخاب کنید

AppCreator در Approval Process چند مدل اصلی برای Approver دارد: User، Role و Field. این تفاوت در طراحی سازمانی مهم است.

User؛ وقتی مسئول ثابت است

برای فرآیندی با مسئول ثابت می‌توان یک User مشخص را Approver قرار داد. این مدل ساده است، اما اگر شخص تغییر کند باید Configuration به‌روز شود.

Role؛ وقتی مسئولیت مهم‌تر از نام فرد است

اگر نقش سازمانی مثل «مدیر مالی» یا «مدیر خرید» تصمیم‌گیر است، Role انتخاب پایدارتری است. افراد ممکن است تغییر کنند، اما نقش فرآیندی باقی می‌ماند.

Field؛ وقتی Approver از خود رکورد تعیین می‌شود

گاهی Approver برای هر رکورد متفاوت است؛ مثلاً «مدیر مستقیم درخواست‌دهنده» یا «مالک Application». در این حالت Users Field می‌تواند مبنای Approver قرار گیرد. مستندات AppCreator تصریح می‌کنند که در این مدل فقط Users Fieldهای Form برای انتخاب در دسترس هستند.

چند سطح Approval بسازیم؟

امکان چندمرحله‌ای بودن به این معنی نیست که هر فرآیند باید پنج امضا داشته باشد. هر Approval اضافه، Lead Time را بالا می‌برد. سطح تأیید باید به Risk، مبلغ، حساسیت داده یا Impact تصمیم متصل باشد.

یک اصل عملی این است: مسیر کم‌ریسک را کوتاه و مسیر پرریسک را کنترل‌شده کنید. اگر یک درخواست کم‌هزینه و تکراری از همان زنجیره‌ای عبور کند که خرید سرمایه‌ای بزرگ طی می‌کند، کاربران به‌تدریج راه‌های دور زدن فرآیند را پیدا می‌کنند.

بعد از Approve یا Reject چه Actionی اجرا شود؟

Approval فقط یک دکمه «تأیید» نیست. ارزش واقعی وقتی ایجاد می‌شود که تصمیم، Action بعدی را فعال کند. AppCreator برای Approval Process امکان اجرای Actionها را فراهم می‌کند. یکی از Actionهای پیش‌فرض، Email Notification است و می‌توان مقدارهایی از Form، System Field و Approval Variable را به پیام وارد کرد.

در سناریوی خرید، بعد از تأیید نهایی می‌توان:

  • به درخواست‌دهنده ایمیل وضعیت ارسال کرد.
  • شماره Approval را در پیام قرار داد.
  • رکورد را وارد مرحله «آماده سفارش» کرد.
  • اطلاعات را از طریق Integration یا API به سامانه دیگری منتقل کرد.
  • در صورت رد، دلیل رد را برای اصلاح درخواست نمایش داد.

AppCreator همچنین Actionهای Integration دارد؛ برای نمونه در مستندات رسمی، Push کردن داده تأییدشده به Zoho CRM توضیح داده شده است.

API را برای اتصال فرآیند سفارشی به سامانه‌های دیگر وارد معماری کنید

در سازمان واقعی، AppCreator نباید جزیره باشد. API v2 این محصول RESTful است و با OAuth 2.0 کار می‌کند. APIها امکان افزودن، خواندن، به‌روزرسانی و حذف داده، کار با فایل و دریافت Meta Information را فراهم می‌کنند.

برای مثال بعد از تأیید یک درخواست می‌توان یک Integration طراحی کرد که اطلاعات را به ERP، Service Desk، CRM یا سامانه داخلی منتقل کند. در طراحی Integration باید Limitهای API هم دیده شوند؛ مستند فعلی AppCreator برای API v2 حداکثر ۲۰۰ رکورد در هر Request و ۵۰ Request در دقیقه برای هر Endpoint و Public IP را ذکر می‌کند و سقف روزانه نیز به Subscription وابسته است.

اگر سازمان شما ServiceDesk Plus Cloud دارد و در حال طراحی Automationهای جدید مبتنی بر Agent است، مقاله MCP در ServiceDesk Plus Cloud؛ اتصال امن AI Agentها به ITSM را هم ببینید. AppCreator و MCP یک چیز نیستند، اما هر دو نشان می‌دهند معماری جدید Automation باید Integration و کنترل دسترسی را از ابتدا جدی بگیرد.

AppCreator یا Workflow خود ServiceDesk Plus؟

یکی از مهم‌ترین تصمیم‌ها این است که اصلاً آیا فرآیند باید در AppCreator ساخته شود یا نه.

سناریو انتخاب منطقی‌تر
Incident، Service Request، Change و فرآیندهای استاندارد ITSM ابتدا قابلیت Native در ServiceDesk Plus را بررسی کنید
فرم و فرآیند اختصاصی مالی، حقوقی، منابع انسانی یا عملیات AppCreator گزینه جدی است
Application سفارشی با Data Model مستقل AppCreator
تیکتینگ سازمانی با SLA، CMDB و Knowledge ServiceDesk Plus
فرآیندی که چند سامانه را با Rule اختصاصی به هم متصل می‌کند AppCreator یا Integration Architecture ترکیبی

قاعده مهم: قابلیت Native بالغ را دوباره نسازید. اگر نیاز شما مدیریت Incident یا Change است، ابتدا ServiceDesk Plus را بررسی کنید. AppCreator زمانی بیشترین ارزش را دارد که Business Process واقعاً اختصاصی باشد یا Data Model و Experience متفاوتی لازم داشته باشد. برای معیارهای انتخاب ابزار ITSM نیز مقاله راهنمای انتخاب نرم‌افزار تیکتینگ سازمانی مفید است.

امنیت Workflow را از روز اول طراحی کنید

فرآیند Approval معمولاً داده‌های حساس دارد: مبلغ، اطلاعات پرسنلی، قرارداد، Vendor یا درخواست دسترسی. بنابراین امنیت نباید به مرحله آخر پروژه موکول شود.

Role و Permission را حداقلی کنید

کاربر ثبت‌کننده لزوماً نباید همه درخواست‌های واحدهای دیگر را ببیند. Approver هم فقط باید داده‌ای را ببیند که برای تصمیم لازم است. AppCreator از Role و Permission برای کنترل دسترسی استفاده می‌کند.

Directory را به‌جای User Management موازی در نظر بگیرید

AppCreator از نسخه 2.4.0 در فوریه ۲۰۲۵ قابلیت LDAP را برای همگام‌سازی Directory و پشتیبانی بهتر از Role-Based Access Control اضافه کرده است. در محیطی که Directory سازمان مرجع هویت است، این قابلیت می‌تواند مدیریت کاربر موازی را کاهش دهد.

Portal را با MFA یا Passkey سخت‌سازی کنید

Release Notes فعلی نشان می‌دهند AppCreator برای Portalها MFA و در نسخه 2.6.0 مورخ ۱۰ ژوئیه ۲۰۲۶ Passkey را هم به‌عنوان First-factor Authentication اضافه کرده است. همچنین امکان تعیین MFA Trust Days از صفر تا ۳۰ روز فراهم شده است.

نوع فایل آپلودی را محدود کنید

در نسخه 2.6.1 مورخ ۳ اوت ۲۰۲۶، File Upload Field امکان محدود کردن File Typeهای مجاز را دریافت کرده است. اگر Form شما پیوست می‌گیرد، Allowlist نوع فایل یک کنترل ساده اما مهم است؛ مخصوصاً برای Portalهای بیرونی.

نسخه‌های جدید AppCreator چه نکته‌ای برای Workflowهای سازمانی دارند؟

در زمان نگارش این راهنما، Release Notes رسمی آخرین به‌روزرسانی ثبت‌شده را Version 2.6.1 در ۳ اوت ۲۰۲۶ نشان می‌دهد. علاوه بر محدودسازی نوع فایل، امکان Drill-through برای Aggregateها نیز اضافه شده است. نسخه 2.6.0 در ۱۰ ژوئیه ۲۰۲۶ نیز Batch Workflowها را طوری تغییر داده که بعد از ۱۵ Failure متوالی متوقف شوند تا Failure Loop بی‌پایان و مصرف غیرضروری Quota کاهش یابد؛ Bulk Insert API و Passkey Portal هم در همان Release آمده‌اند.

برای پروژه Production، قبل از استفاده از یک قابلیت جدید Build واقعی محیط و Release Notes همان Build را بررسی کنید.

سناریوی کامل: درخواست خرید از ثبت تا سفارش

یک طراحی عملی می‌تواند این مسیر را داشته باشد:

  1. کاربر Form خرید را تکمیل و پیشنهاد قیمت را پیوست می‌کند.
  2. Validation بررسی می‌کند مبلغ و مرکز هزینه تکمیل شده باشند.
  3. Criteria نوع درخواست و مبلغ را تشخیص می‌دهد.
  4. برای خرید IT، مالک فنی به مسیر اضافه می‌شود.
  5. مدیر واحد Approval سطح اول را انجام می‌دهد.
  6. در مبالغ بالاتر، مالی و مدیر ارشد وارد می‌شوند.
  7. در Reject، دلیل رد اجباری ثبت و درخواست برای اصلاح برمی‌گردد.
  8. در Approval نهایی، Email/Integration اجرا می‌شود.
  9. Report وضعیت Open، Approved، Rejected و Aging را نمایش می‌دهد.
  10. Dashboard زمان متوسط تأیید هر مرحله را به مدیر فرآیند نشان می‌دهد.

این معماری هم برای خرید و هم برای فرآیندهایی مثل درخواست قرارداد، اضافه‌کاری، دسترسی به سامانه، ثبت Vendor یا درخواست سرمایه‌ای قابل بومی‌سازی است.

Auditability؛ Approval بدون دلیل تصمیم ناقص است

برای فرآیند حساس، صرف ثبت Approved/Rejected کافی نیست. بهتر است داده تصمیم شامل Comment، زمان تصمیم، Approver، Level و Context درخواست باشد. اگر Reject باعث اصلاح و ارسال مجدد می‌شود، Versioning منطقی هم مهم است تا مشخص باشد Approver کدام نسخه داده را دیده است.

این موضوع مخصوصاً وقتی اهمیت دارد که واحد حسابرسی یا Compliance بعداً بپرسد «چرا این خرید یا دسترسی تأیید شد؟».

KPIهایی که بعد از پیاده‌سازی باید اندازه بگیرید

KPI سؤال مدیریتی
Approval Lead Time از ثبت تا تأیید نهایی چقدر زمان می‌برد؟
Aging by Level درخواست‌ها بیشتر در کدام سطح معطل می‌شوند؟
Rejection Rate چند درصد درخواست‌ها رد می‌شوند؟
Rework Rate چند درخواست برای اصلاح برمی‌گردند؟
Auto-routing Rate چه سهمی بدون دخالت دستی به Approver درست می‌رسد؟
Exception Rate چند پرونده از مسیر استاندارد خارج می‌شوند؟

اگر فقط فرم کاغذی را دیجیتال کنیم ولی زمان چرخه و Bottleneck را نسنجیم، بخش مهمی از ارزش Low-code استفاده نشده است.

اشتباهات رایج در پروژه Approval Workflow

  • کپی کردن فرآیند بد: دیجیتال کردن یک زنجیره ۹ امضایی، آن را خوب نمی‌کند.
  • Hard-code کردن افراد: تا جای ممکن مسئولیت را به Role یا Field متصل کنید.
  • نداشتن مسیر Reject: رد درخواست باید مشخص کند کاربر چه چیزی را اصلاح کند.
  • ندیدن Delegation: غیبت Approver نباید کل فرآیند را متوقف کند؛ این مورد باید در طراحی عملیاتی بررسی شود.
  • ساختن قابلیت Native از صفر: اگر فرآیند استاندارد ITSM است، ابتدا ServiceDesk Plus را بررسی کنید.
  • نادیده گرفتن Permission: هر رکورد Approval بالقوه داده حساس دارد.
  • Integration بدون Error Handling: اگر API مقصد Fail شد، رکورد نباید در وضعیت مبهم بماند.
  • نبود Owner: هر Application باید مالک کسب‌وکار و مالک فنی مشخص داشته باشد.

نقشه راه پیشنهادی برای پیاده‌سازی AppCreator در سازمان

  1. Use Case محدود انتخاب کنید: یک فرآیند پرتکرار و قابل‌اندازه‌گیری.
  2. As-Is را ثبت کنید: مراحل، نقش‌ها، استثناها و Pain Pointها.
  3. To-Be را ساده کنید: Approvalهای غیرضروری را حذف کنید.
  4. Form و Data Model را بسازید.
  5. Approval و Criteria را پیاده کنید.
  6. Permission و Authentication را تنظیم کنید.
  7. Integration را در محیط Test بسازید.
  8. Pilot محدود اجرا کنید.
  9. KPI قبل/بعد را اندازه بگیرید.
  10. بعد از تثبیت، فرآیند بعدی را وارد پلتفرم کنید.

این مدل کمک می‌کند Low-code به «انبوهی از Appهای بی‌مالک» تبدیل نشود. سرعت ساخت باید با Governance همراه باشد.

چه زمانی AppCreator انتخاب مناسبی نیست؟

AppCreator ابزار قدرتمندی برای Application سفارشی است، اما هر مسئله‌ای را نباید با Low-code حل کرد. اگر نیاز فقط یک Feature استاندارد در محصول موجود است، Extension یا Configuration همان محصول معمولاً هزینه نگهداری کمتری دارد. اگر فرآیند Transaction بسیار پیچیده، حجم بسیار بالا یا الزام معماری تخصصی دارد نیز باید Capacity، API Limits و نیازهای Non-functional جداگانه ارزیابی شوند.

هدف انتخاب ابزار مناسب برای مسئله است، نه وارد کردن هر فرآیند به یک پلتفرم واحد.

Checklist قبل از Go-Live

  • Business Owner و Technical Owner مشخص شده‌اند.
  • Approverها با Role سازمانی تطبیق دارند.
  • Criteria با Policy رسمی سازمان تست شده است.
  • مسیر Reject و Resubmit مشخص است.
  • Permissionها با Least Privilege بررسی شده‌اند.
  • فایل‌های مجاز برای Upload محدود شده‌اند.
  • MFA/Passkey برای Portal در صورت نیاز بررسی شده است.
  • API Credential و OAuth Scope حداقلی هستند.
  • Error Handling برای Integration وجود دارد.
  • Report و KPI قبل از Production آماده‌اند.
  • Backup/Recovery و Upgrade Plan محیط مشخص است.

سخن پایانی

مزیت Approval Workflow در AppCreator فقط حذف ایمیل نیست. ارزش اصلی زمانی ایجاد می‌شود که تصمیم‌گیری سازمانی از یک مسیر نامرئی و وابسته به افراد به یک فرآیند قاعده‌مند، قابل‌ردیابی، قابل‌اندازه‌گیری و قابل اتصال به سامانه‌های دیگر تبدیل شود.

برای شروع، یک Use Case محدود انتخاب کنید؛ Form را بر اساس نیاز تصمیم‌گیرنده بسازید، Criteria را از Policy واقعی استخراج کنید، Approver را به Role مناسب وصل کنید و Action پس از تصمیم را از ابتدا طراحی کنید. سپس با Reportها ببینید Bottleneck واقعی کجاست.

مدانت برای AppCreator می‌تواند در ارزیابی Use Case، طراحی Data Model، پیاده‌سازی Workflow، Integration با API، استقرار و پشتیبانی کمک کند. برای بررسی محصول، صفحه AppCreator مدانت را ببینید؛ برای برآورد لایسنس به استعلام لایسنس محصولات ManageEngine و برای بررسی سناریوی اختصاصی سازمان به درخواست دمو و مشاوره مراجعه کنید. برای نگهداری سرویس‌های Production نیز برنامه‌های پشتیبانی مدانت در دسترس هستند.

منابع

مطالب مرتبط جهت افزایش سطح دانش شما:

22

دیدگاه شما

دیدگاه مرتبط و محترمانه بنویسید.