Automation Fallback Planning: Errors, Retries and Recovery

قم بإدراج المقاطعات.

ضع في اعتبارك المدخلات المفقودة والأنظمة غير المتوفرة والمخرجات التي لا يمكن قبولها. وصف ما يحدث للعمل الجاري بالفعل عند فشل التبعية. يمكنك التمييز بين التأخير المؤقت والحالة التي تتطلب قرار عمل، بحيث لا يتعامل سير العمل مع كل مقاطعة على أنها إعادة محاولة تلقائية.

احتفظ بمسار يدوي قابل للاستخدام.

تحديد المعلومات التي يحتاجها الشخص لمواصلة المهمة بأمان. اجعل العمل المعلق والإجراءات المكتملة مرئية لتجنب المعالجة المكررة. ناقش كيفية التدرب على المسار اليدوي أثناء البرنامج التجريبي بدلاً من افتراض أنه يمكن لشخص ما إعادة بناء المهمة عندما تتوقف الأتمتة.

قم بمراجعة ملكية الاسترداد.

قم بتعيين المسؤولية عن حل الاستثناءات وتحديد متى يمكن استئناف المعالجة الآلية. تسجيل الفحوصات اللازمة للتوفيق بين العمل اليدوي والآلي. يجب أن يكون الإجراء الاحتياطي جزءًا من تعليمات تشغيل سير العمل، وليس مستندًا منفصلاً لا يعرف أحد الرجوع إليه.

Work through failure before expanding the workflow

List where a task can fail: input validation, an unavailable dependency, an uncertain result or a partially completed action. For each point, determine whether the system knows that nothing happened or whether the outcome is uncertain. That distinction affects whether a retry is safe.

Describe the manual continuation route and the information needed to use it. Assign an owner to unattended failures and agree how they are visible. Test interruptions at different stages, including recovery after a service becomes available. Reconcile the final state so a task is not lost, repeated or left permanently pending. Keep fallback instructions close to the operating workflow rather than only in a development note.

A fallback and recovery decision sheet

Use a row per failure category. Confirm the proposed response with both the business owner and the technical operator.

• Failure point: input, dependency, processing step or downstream action that may fail.
• Known state: what has definitely completed and what remains uncertain.
• Automatic response: stop, retry, defer or reject, with conditions and limits.
• Manual response: responsible role, context provided and available continuation actions.
• Communication: useful user status, operator notification and escalation when unresolved.
• Reconciliation: how the team confirms the eventual outcome and prevents duplicate work.

Do not retry every failed action in the same way

A repeated read and a repeated payment instruction have different consequences. Identify actions that need duplicate protection or a status check before another attempt. Keep error messages useful enough for the operating team to distinguish rejection from uncertainty.

Avoid a manual fallback requiring information the system has discarded. Preserve the necessary context within the approved access and retention arrangements. A queue of failed tasks also needs ownership; making errors visible without assigning a response does not complete the recovery design.

Should a fallback always be automatic?

No. Some failures are better paused for a person, particularly where the next action could create an irreversible or duplicate outcome. Choose the response around the task’s consequences and the information available, then verify that the operating team can carry it out.

ILLUSTRATIVE PLANNING EXAMPLE

Example: an unavailable external service

An automated workflow sends a request to an external service that times out. Decide whether retrying is safe, how duplicate actions are prevented and when a person is notified. Provide enough context for the person to complete or cancel the task without starting again from an unexplained error message.

Test the fallback with the operating team. Record the retry limit, escalation owner and reconciliation step before increasing the workflow’s scope.

FURTHER READING

Official resources to explore

Explore the related official guidance below. The templates and examples are practical starting points to adapt to your own project.

• NIST AI Risk Management Framework Playbook