12 نوفمبر 2025·8 دقيقة
كيف تبني تطبيق ويب للحملات مع موافقات العملاء
تعلم كيف تخطط وتبني تطبيق ويب لوكالات التسويق لإدارة الحملات، الأصول، وموافقات العملاء، مع أدوار، سير عمل، وسجل تدقيق جاهز.
تعلم كيف تخطط وتبني تطبيق ويب لوكالات التسويق لإدارة الحملات، الأصول، وموافقات العملاء، مع أدوار، سير عمل، وسجل تدقيق جاهز.
قبل أن ترسم الشاشات أو تختار التقنيات، حدد المشكلة الأساسية: الموافقات وحملات التسويق مشتتة عبر البريد، الدردشة، ومحركات الملفات المشتركة. يجب أن يجمع تطبيق الحملة الموجزات، الأصول، التعليقات، والتوقيع في مكان واحد حتى يتمكن الجميع من رؤية ما يحدث بعد ذلك—من دون مطاردة المحادثات.
تتضمن معظم سير عمل موافقات الوكالات أربع مجموعات، كل منها يحتاج أشياء مختلفة:
الموافقات المعتمدة على البريد الإلكتروني تخلق مشاكل متوقعة: مواعيد نهائية فائتة لأن أحدًا لا يرى الطلب الأحدث، ملاحظات غير واضحة مثل "اجعلها أكثر بروزًا" بلا تفاصيل، إصدارات متعددة متشظية، ودورات إعادة العمل الناتجة عن مدخلات متأخرة أو متضاربة.
عرّف نتائج قابلة للقياس حتى تتمكن من الحكم على نجاح المنتج:
للإصدار الأول، ركز على أصغر مجموعة تحافظ على تجميع الحملات والموافقات معًا:
احفظ الميزات الجميلة للوقت اللاحق: تقارير متقدمة، تكاملات عميقة، قواعد أتمتة، ومسارات موافقة مخصصة.
قبل التفكير في الشاشات أو التقنية، اكتب كيف يتحرك العمل فعليًا داخل وكالتك. يجعل سير العمل الواضح "أين وصل هذا؟" مجموعة خطوات متوقعة يمكن لتطبيقك فرضها، أتمتتها، والتقرير عنها.
يمكن وصف معظم تطبيقات موافقة الحملات بمجموعة صغيرة من اللبنات:
وثّق العلاقات: الحملة تحتوي مشاريع؛ المشاريع تحتوي مهام؛ المهام تنتج أصولًا؛ الأصول تمر عبر موافقات.
تدفق بسيط وصديق للوكالات هو:
مسودة → مراجعة داخلية → مراجعة العميل → موافق
اجعل كل حالة تعني شيئًا عمليًا. على سبيل المثال، قد تتطلب "المراجعة الداخلية" توقيع قائد الإبداع ومدير الحساب قبل أن يرى العميل العمل.
قرّر شكل التعليقات في منتجك:
المفتاح هو ربط التعليقات بإصدار الأصل، حتى لا يكون هناك جدال حول أي ملف راجعه العميل.
تباطؤات شائعة: انتظار المراجعين، خطوات لاحقة غير واضحة، وإعداد مكرر. الأتمتة الأكثر فائدة:
الموافقات الحقيقية ليست دائمًا نظيفة. خطّط لـ:
إذا استطعت وصف هذه القواعد بلغة بسيطة، فأنت جاهز لتحويلها إلى شاشات ونماذج بيانات.
تبدأ تجربة المستخدم الجيدة لتطبيق الحملة بهرم معلوماتي بسيط يعكس طريقة تفكير الوكالات: العميل → الحملة → التسليمات (الأصول). إذا استطاع المستخدمون دائمًا الإجابة عن "أين أنا؟" و"ما الخطوة التالية؟"، تتحرك الموافقات أسرع وتقل الأخطاء.
استخدم العميل كمرتكز أعلى، ثم اعرض الحملات تحته، وأخيرًا التسليمات (الإعلانات، الرسائل، صفحات الهبوط، المنشورات الاجتماعية). أبقِ نفس البنية في التنقّل، شريط المسار، والبحث حتى لا يضطر الناس لإعادة تعلّم التطبيق في كل شاشة.
قاعدة عملية: يجب أن تعرض كل تسليم دائمًا العميل، الحملة، تاريخ الاستحقاق، الحالة، والمالك بنظرة سريعة.
لوحة التحكم: قاعدة الوكالة. ركّز على ما يحتاج الانتباه اليوم: المواعيد القادمة، العناصر التي تنتظر مراجعة داخلية، والعناصر التي تنتظر موافقة العميل.
الجدول الزمني للحملة: عرض شبيه بالتقويم أو مبني على المراحل يوضح التبعيات (مثل: "الموافقة على النص" قبل "النسخة النهائية للتصميم"). اجعله قابلاً للقراءة—يجب أن يفهم الناس التقدّم بثوانٍ.
عرض مراجعة الأصول: هنا يُكسب الوقت أو يُفقد. اجعل المعاينة كبيرة، التعليقات سهلة الوصول، والإجراء التالي واضحًا.
صندوق الوارد: مكان واحد لـ"ما أحتاج الرد عليه" (تعليقات جديدة، طلبات موافقة، إشارات). هذا يقلل التنقل عبر البريد والدردشة.
يجب أن تجيب المرشحات السريعة على أسئلة وكالة حقيقية:
يجب أن يكون النداء الأساسي للعمل واضحًا: موافقة / طلب تغيير. احتفظ به ثابتًا في واجهة المراجعة (تذييل/رأس ثابت) حتى لا يطارد العملاء زر الموافقة بعد التمرير عبر التعليقات.
يراجع العملاء غالبًا بين الاجتماعات. أعطِ الأولوية للقابلية للقراءة على الهاتف: معاينة نظيفة، أزرار كبيرة، ونماذج قصيرة للتعليقات. إذا كان يمكن بلمسة فتح الأصل وبلمسة أخرى الموافقة، سترى أزمنة استجابة أسرع.
تعيش أو تموت تطبيقات الموافقة بثقة: يجب أن يشعر العملاء بالثقة أنهم لا يرون إلا ما ينبغي لهم، وفريقك يحتاج حدودًا واضحة حتى لا تُستبدل الأعمال أو تُوافق من قبل الشخص الخطأ.
يمكن لمعظم الوكالات تغطية الاحتياجات بخمس أدوار:
بدلًا من الأذونات العامة فقط، عرّف إجراءات لكل نوع كائن (حملة، تسليم، أصل، تعليق). تشمل الأفعال الاعتيادية عرض، تعليق، رفع، الموافقة، تعديل، وحذف.
الافتراضي العملي هو "أقل امتياز": يمكن للمساهمين رفع وتعديل أصولهم الخاصة، لكن حذفها أو تغيير إعدادات الحملة محصور في مديري الحساب/المشرفين.
يجب ألا يرى العملاء إلا حملاتهم، أصولهم، ومناقشاتهم. تجنب "مجلدات عملاء" مشتركة التي قد تكشف حسابات أخرى عن طريق الخطأ. الأسهل هو ربط كل حملة بحساب عميل وتطبيق فحوصات الوصول باستمرار عبر الصفحات، التنزيلات، والإشعارات.
ادعم وضعين للموافقة لكل تسليم:
قدّم روابط مشاركة للراحة، لكن اجعلها خاصة افتراضيًا: رموز محددة الوقت، خيار كلمة مرور، وإمكانية الإبطال.
قاعدة جيدة: لا تتجاوز المشاركة حد العميل—يجب أن تمنح وصولًا فقط للعناصر التي يستطيع المستخدم رؤيتها طبيعيًا.
تعيش أو تموت ميزة موافقة العميل بالوضوح. إذا لم يستطع فريقك وعملاؤك معرفة من ينتظر ماذا، تتوقف الموافقات، ويصبح "موافق" موضع خلاف.
ابدأ بمجموعة صغيرة من الحالات التي يفهمها الجميع:
تجنّب إضافة حالة جديدة لكل حالة حدية. إذا احتجت مزيدًا من التفصيل، استخدم وسومًا (مثل "مراجعة قانونية") بدل تعقيد سير العمل.
عامل كل رفع كـ إصدار غير قابل للتغيير. لا تستبدل الملفات في محلها—أنشئ v1, v2, v3… مرتبطة بنفس الأصل.
هذا يدعم محادثات نظيفة ("يرجى تحديث v3") ويمنع فقدانًا عرضيًا. في واجهتك، اجعل الإصدار الحالي واضحًا، مع إتاحة فتح الإصدارات السابقة للمقارنة.
التعليقات الحرة فقط قد تكون فوضوية. أضف بنية:
إذا دعمت رموز الوقت (للفيديو) أو دبابيس صفحة/منطقة (PDF/صور)، تصبح التعليقات أكثر قابلية للتنفيذ بشكل كبير.
عند موافقة شخص ما، سجّل:
بعد الموافقة، عرّف القواعد: عادةً قم بقفل التحرير على الإصدار الموافق عليه، لكن اسمح بإنشاء مراجعة طفيفة كإصدار جديد (تعيد الحالة إلى تحت المراجعة). هذا يحافظ على قابلية الدفاع عن الموافقات دون منع التعديلات المشروعة الأخيرة.
تعيش أو تموت الموافقات الإبداعية بمدى سهولة وصول الناس للملف الصحيح في الوقت المناسب. إدارة الأصول هي المكان الذي تتحول فيه العديد من تطبيقات الحملة إلى مصدر إحباط—تنزيلات بطيئة، أسماء ملفات مربكة، وحلقات "أي إصدار نهائي؟".
نمط نظيف هو: تخزين كائنات للملفات (سريع، قابل للتوسع، أقل كلفة) وقاعدة بيانات للبيانات الوصفية (قابلة للبحث ومنظمة).
يجب أن تتتبع قاعدة البيانات مثل: اسم الأصل، النوع، الحملة، الإصدار الحالي، من رفعه، الطوابع الزمنية، حالة الموافقة، وروابط المعاينة. طبقة التخزين تحوي الملف الثنائي وبنود مشتقة اختيارية مثل الصور المصغرة.
استهدف مجموعة صغيرة تغطي معظم سير العمل:
كن صريحًا في الواجهة حول ما هو قابل للرفع مقابل ما هو رابط فقط.
المعاينات تسرّع المراجعة وتجعلها أكثر وُدًّا للعملاء. أنشئ:
هذا يتيح لأصحاب المصلحة تصفح لوحة التسليمات دون تنزيل ملفات عالية الدقة.
حدد حدود الملفات مبكرًا (الحد الأقصى للحجم، الحد الأقصى للعدد لكل حملة، الامتدادات المدعومة). تحقق من نوع الملف والمحتوى (لا تثق بالامتدادات). إذا تعاملت مع عملاء مؤسسيين أو تقبل ملفات كبيرة، فكر في فحص الفيروسات/البرمجيات الخبيثة كجزء من خط تحميل الملفات.
الموافقات غالبًا ما تحتاج قابلية التتبع. قرّر ماذا يعني "حذف":
اقترن هذا بسياسات احتفاظ (مثلاً: الاحتفاظ بالأصول 12–24 شهرًا بعد انتهاء الحملة) حتى لا تتضخم تكاليف التخزين بلا خطة.
لا يحتاج تطبيق الحملة مع موافقات العملاء إلى بنية غريبة. يحتاج إلى حدود واضحة: واجهة ودية للبشر، API يفرض القواعد، تخزين للملفات والبيانات، وعُمّال خلفيين للتعامل مع الأعمال المعتمدة على الوقت مثل التذكيرات.
ابدأ بما يستطيع فريقك بناؤه وتشغيله بثقة. إذا كنتم تعرفون React + Node، أو Rails، أو Django، فغالبًا هذا هو الخيار الصحيح لـ v1. تفضيلات الاستضافة مهمة أيضًا: إذا أردت سهولة "push to deploy" فاختر منصة تدعم الستاك وتبسّط السجلات، التوسع، وإدارة الأسرار.
إذا أردت التحرك أسرع دون الالتزام ببناء كامل من الصفر، قد تساعدك منصة توجيهية مثل Koder.ai على النمذجة والاختبار للـ workflow (الحملات، الأصول، الموافقات، الأدوار) عبر واجهة محادثة—ثم تصدير الشيفرة عندما تكون جاهزًا للاستحواذ.
الواجهة الأمامية (تطبيق ويب): لوحات، جداول زمنية للحملات، وشاشات المراجعة. تتحدث إلى الـ API وتتعامل مع تفاصيل تجربة المستخدم في الوقت الفعلي (حالات التحميل، تقدم الرفع، سلاسل التعليقات).
واجهة خلفية/API: مصدر الحقيقة لقواعد العمل—من يمكنه الموافقة، متى يُقفل الأصل، ما هي الانتقالات المسموح بها للحالة. اجعلها مستقرة ومتوقعة.
قاعدة بيانات: تخزن الحملات، المهام، الموافقات، التعليقات، وأحداث التدقيق.
تخزين ملفات + توليد معاينات: خزّن الرفع في تخزين كائنات (مثل S3) وولّد صور مصغرة ومعاينات ليتمكن العملاء من المراجعة دون تنزيل كامل الملفات.
مهام خلفية: أي شيء لا ينبغي أن يعرقل المستخدم: إرسال الإيميلات، توليد المعاينات، التذكيرات المجدولة.
لأغلب الوكالات، يُعد المونوليث المعياري مثاليًا: قاعدة كود خلفية واحدة مع وحدات منفصلة جيدًا (أصول، موافقات، إشعارات). يمكنك إضافة خدمات حيث تفيد حقًا (مثل عامل مهام منفصل) دون تقسيم النشر مبكرًا.
عامل الإشعارات كميزة أساسية: داخل التطبيق + إيميل، مع إمكانية إلغاء الاشتراك وتتبع سلاسل واضحة. يتيح طابور مهام (BullMQ، Sidekiq، Celery، إلخ) إرسال التذكيرات بموثوقية، إعادة المحاولة عند الفشل، وتجنب تعطيل الرفع والموافقات.
خطّط لثلاث بيئات منذ البداية:
إذا أردت الغوص أعمق في الجانب البياني بعد ذلك، تابع /blog/data-model-and-database-design.
نموذج بيانات نظيف هو ما يحفظ شعور بساطة التطبيق مع نموه. الهدف هو جعل الشاشات الشائعة—قوائم الحملات، قوائم الأصول، صفحات الموافقة—سريعة ومتوقعة، مع التقاط التاريخ الذي ستحتاجه لاحقًا.
ابدأ بمجموعة صغيرة من الجداول التي تطابق عمل الوكالات:
حافظ على اتساق المعرفات (UUIDs أو أرقام—كلاهما جيد). المهم أن يحمل كل سجل طفل (clients، campaigns، assets) organization_id لتتمكن من فرض عزل البيانات.
الحالات وحدها لا تشرح ماذا حدث. أضف جداول مثل:
هذا يجعل سجلات التدقيق والمسؤولية بسيطة دون تضخيم الجداول الأساسية.
تقوم معظم الشاشات بالتصفية حسب العميل، الحالة، وتاريخ الاستحقاق. أضف فهارس مثل:
فكّر أيضًا في فهرس مُركب لما يحتاج المراجعة الآن: (organization_id, status, updated_at).
عامل السكيمة مثل كود المنتج: استخدم مهاجرات لكل تغيير. عبّئ بعض قوالب الحملات (مراحل افتراضية، حالات افتراضية، خطوات موافقة قياسية) حتى تتمكن الوكالات الجديدة من البدء بسرعة وتكون بيئات الاختبار ببيانات واقعية.
يعيش أو يموت تطبيق موافقة العميل بالثقة: يحتاج العملاء لتسجيل دخول بسيط، وفريقك يحتاج التأكد من أن الأشخاص الصحيحين فقط يرون العمل الصحيح. ابدأ بأصغر مجموعة ميزات مصادقة تبدو جاهزة للوكالة ثم وسّع.
إذا كان مستخدموك هم بالأساس عملاء يسجلون الدخول عرضيًا، فـ البريد الإلكتروني + كلمة مرور عادةً هو سلاسة كافية. للمنظمات الأكبر، فكر في SSO (Google/Microsoft) حتى يستخدموا حساباتهم المؤسسية. يمكنك دعم الاثنين لاحقًا—تجنّب جعل SSO إلزاميًا إلا إذا كان جمهورك يتوقعه.
يجب أن تكون الدعوات سريعة، واعية بالدور، ومتسامحة:
نمط جيد هو رابط سحري لتعيين كلمة المرور، حتى لا يحتاج المستخدمون الجدد لتذكر شيء مبدئيًا.
استخدم إدارة جلسات آمنة (توكنات وصول قصيرة العمر، توكنات تحديث دورانية، ملفات تعريف الارتباط httpOnly حيثما أمكن). أضف تدفق استعادة كلمة مرور قياسيًا مع توكنات منتهية الصلاحية وحيدة الاستخدام وشاشات تأكيد واضحة.
المصادقة تجيب "من أنت؟" التفويض يجيب "ماذا يمكنك أن تفعل؟" احمِ كل نقطة نهاية بفحوصات صلاحية—خصوصًا لأصول الحملة، التعليقات، والموافقات. لا تعتمد على إخفاء عناصر واجهة فقط.
احتفظ بسجلات صديقة للتدقيق (محاولات تسجيل الدخول، قبول الدعوات، تغييرات الأدوار، نشاط مريب)، لكن تجنّب تخزين الأسرار. سجِّل المعرفات، الطوابع الزمنية، تلميحات IP/الجهاز، والنتائج—ولا تسجل كلمات المرور الخام أو محتويات الملفات الخاصة أو ملاحظات العملاء السرية.
الإشعارات هي المكان الذي يجعل تطبيق الحملة مفيدًا—أو مزعجًا. الهدف بسيط: حافظ على تقدم العمل بدون أن يجعل كل تعليق صندوق بريد العميل مشتعلًا.
ابدأ بمجموعة صغيرة عالية الإشارة من المحفزات واحفظ الاتساق بين الإيميل والتطبيق:
اجعل كل إشعار يتضمن "ما حدث" والإجراء التالي مع رابط مباشر للرؤية الصحيحة (مثلاً: صفحة مراجعة الأصل أو صندوق الوارد الخاص بالموافقات).
الأدوار المختلفة تريد مستويات مختلفة من التفاصيل. أعطِ تحكمًا على مستوى المستخدم:
استخدم إعدادات ذكية افتراضية: عادةً العملاء يريدون إيميلات أقل من الفرق الداخلية، ويهتمون فقط بالعناصر التي تنتظر قرارهم.
جمّع التحديثات المتشابهة (مثل "3 تعليقات جديدة على لافتة الصفحة الرئيسية") بدل إرسال إيميل لكل تعليق. أضف ضوابط:
صفحة صندوق وارد الموافقات المخصصة تقلل التبادل غير الضروري بعرض فقط ما يحتاج العميل فعلاً فعله الآن: العناصر "تنتظر قرارك"، مواعيد الاستحقاق، ومسار بنقرة واحدة للشاشة الصحيحة. اجعلها نظيفة ويمكن الوصول إليها، واربطها من كل إيميل مراجعة (مثلاً: /approvals).
البريد ليس مضمونًا. خزّن حالة التسليم (أرسل، ارتد، فشل) وأعد المحاولة بذكاء. إذا فشل إيميل، أظهره للمسؤولين في عرض النشاط وارجع إلى الإشعارات داخل التطبيق حتى لا يتعطل سير العمل بصمت.
عندما يوافق العملاء على إبداع، فهم لا يضغطون زرًا فقط—هم يتحملون مسؤولية قرار. يجب أن تجعل تطبيقك أثر هذا القرار سهلًا في الوصول، مفهومًا، ومن الصعب الطعن فيه لاحقًا.
نفّذ خلاصة نشاط على مستويين:
اجعل الإدخالات مقروءة لغير التقنيين بصيغة ثابتة: من فعل ماذا، متى وأين. مثال: "جوردان (الوكالة) رفع Homepage Hero v3 — 12 ديسمبر، 2:14 م" و"سام (العميل) وافق على Homepage Hero v3 — 13 ديسمبر، 9:03 ص."
لتعزيز المسؤولية، خزّن سجل تدقيق لـ:
قاعدة عملية: إذا أثّر حدث على التسليمات، التوقيت، أو توقيع العميل، فيجب أن يكون في سجل التدقيق.
يجب أن تكون أحداث التدقيق عامةً غير قابلة للتغيير. إذا احتاج شيء للتصحيح، سجّل حدثًا جديدًا (مثلاً: "إعادة فتح الموافقة بواسطة الوكالة") بدل إعادة كتابة التاريخ. اسمح بتحرير الحقول الظاهرية فقط (مثل خطأ مطبعي في عنوان الأصل) لكن سجّل أن التعديل حدث.
قدّم إمكانية تصدير ملخص بسيط (PDF أو CSV) للتسليم: الإصدارات النهائية الموافق عليها، طوابع الموافقة، التعليقات الرئيسية، وروابط للأصول. هذا مفيد خصوصًا عند إغلاق المشروع أو عندما يغير العميل فرقته.
المحافظة على هذا جيدًا تقلل الارتباك، تحمي الطرفين، وتجعل برنامج إدارة الحملات يبدو موثوقًا—وليس معقّدًا.
يمكن أن تتضخم نطاقات التقارير والتكاملات بسهولة. الخدعة هي إطلاق أدنى مجموعة تساعد الفرق على إدارة العمل اليومي، ثم التوسع بناءً على الاستخدام الحقيقي.
ابدأ بعرض تقارير بسيط (أو عناصر لوحة) يدعم المراجعات الأسبوعية والترياج اليومي:
ثم أضف مؤشرات صحّة الحملة الخفيفة المفهومة بسرعة:
لا تحتاج هذه لتنبؤ مثالي—فقط إشارات واضحة وقواعد متسقة.
يجب أن تقلل التكاملات المتابعة اليدوية، لا تنشئ أوضاع فشل جديدة. أفضّل ما يستخدمه المستخدمون يوميًا:
حتى إن لم تطلق API عامة فورًا، عرّف استراتيجية توسعة واضحة:
المرحلة 1: لوحات أساسية + قوائم المعلق/المتأخر.
المرحلة 2: مؤشرات الصحة + اتجاهات زمن الدورة.
المرحلة 3: تكاملان عالي الأثر (عادةً البريد + Slack).
المرحلة 4: webhooks وAPI جاهز للشركاء.
إذا تفكر في حزم اشتراك للتقارير والتكاملات، اجعلها بسيطة وشفافة (انظر /pricing). إذا أردت طريقًا أسرع لـMVP، قد تساعدك Koder.ai أيضًا هنا: يمكنك تجربة سير الموافقة في "وضع التخطيط"، نشر بناء مُستضاف للحصول على تعليقات، والرجوع عبر لقطات عند تحسين المتطلبات.
لمزيد من أنماط سير العمل المتعمقة، يمكنك أيضًا الرجوع إلى /blog.
ابدأ بتحديد المشكلة الأساسية: الموافقات والتعليقات مبعثرة عبر البريد والإسلاك والملفات. يجب أن يجمع إصدار v1 ما يلي في مكان واحد: الموجزات، الأصول، التعليقات، والتوقيع النهائي بحيث يستطيع كل طرف سريعًا الإجابة عن:
حدد نتائج قابلة للقياس مثل زمن استجابة الموافقة ودورات المراجعة للحفاظ على نطاق العمل واقعيًا.
صمم حول أربع مجموعات شائعة:
إذا صممت فقط للمستخدمين الداخليين، فعادةً ما تتراجع تبنّي العملاء وسرعة الموافقات.
اختر مجموعة صغيرة من المقاييس المرتبطة بعوائق سير العمل الحقيقية:
قم بقياس هذه الأمور مبكرًا حتى تتمكن من تقييم التحسن بعد إطلاق v1.
يتضمن v1 العملي:
اجعل التقارير المتقدمة، التكاملات العميقة، قواعد الأتمتة، ومسارات الموافقة المخصصة لأوقات لاحقة بعد التحقق من الاستخدام.
مكّن سير العمل بنمذجة عدد قليل من الكيانات الأساسية:
ثم عرّف دورة حياة الموافقة (مثلاً: مسودة → مراجعة داخلية → مراجعة العميل → موافق) بحيث يكون لكل حالة معنى عملي: من يمكنه نقلها، ما الذي يجب أن يكون صحيحًا، وماذا يحدث بعد ذلك.
اربط دائمًا التعليقات بـ إصدار أصل لتتجنب خلافات "أي ملف؟". خيارات فعّالة:
الهيكلة تجعل التعليقات قابلة للتنفيذ وتقلل إعادة العمل.
حافظ على تنقّل بسيط متسق حول هيكل واضح: العميل → الحملة → التسليمات (الأصول). الشاشات المهمة اليومية:
أضف مرشحات عملية: عميل، تاريخ الاستحقاق، الحالة، المتعاقد/المسؤول.
ابدأ ببساطة بالأدوار التي تحتاجها معظم الوكالات:
ثم عرّف أذونات لكل كائن (حملة، تسليم، أصل، تعليق) مثل عرض/تعليق/رفع/الموافقة/تعديل/حذف. اتبع مبدأ "أقل امتياز"، ونفّذ التحقق على الواجهة الخلفية وليس بمجرد إخفاء عناصر الواجهة.
عامل كل رفع كـ إصدار جديد ثابت (v1، v2، v3…). لا تستبدل الملفات في مكانها.\n\nسجّل بيانات الموافقة:
عادةً، اقفل الإصدار الموافق عليه لكن اسمح بإنشاء إصدار جديد (يعيد الحالة إلى "قيد المراجعة") عند الحاجة لتعديلات.
هيكل مبسط كافٍ:
لـ v1، يُعد "مونوليث مُعياري" مع عامل مهام خيارًا أسهل في التطوير والتشغيل من تقسيم الخدمات المبكر.