Quality Notification Not Triggering Follow-Up Action

Reported as 'we logged the defect but nothing happened' or 'the notification sat there with no task created' or 'we closed the complaint and the vendor was never asked for an 8D report'. Sometimes the complaint is narrower: the action box on the notification screen shows no buttons at all, or shows buttons that are greyed out. Quality engineers describe it as the system used to create a task automatically when this code was entered, and now it does not, or as this only fails for one plant or one notification type while the rest behave normally. Nobody suspects configuration at first; it is read as a process failure, someone forgot to raise the follow-up manually, until the same code combination fails to trigger anything on a second and third notification.

In order of frequency:

Work from the notification outward, not from configuration inward.

Pull notifications for the affected notification type and coding over a date range and compare the coding tab against the action log: notifications where the code has no corresponding entry in the action log confirm a missing catalog assignment or rule, not a one-off user error. Cross-check against notifications with the same code that did trigger an action; a difference in partner data or user status between the two groups usually isolates the cause without needing to touch configuration first.

If the code lacks an action assignment, that is a catalog data change: add the response/action to the code in the catalog, no transport required, but confirm the same code is not shared across plants where the action should not fire. If the task determination rule is missing or inactive, that is customizing requiring a transport; document the exact rule (notification type, code, condition) before opening the change request. If a partner is missing, that is a data correction on the notification itself, add the partner and reprocess, but check why the notification was created without it since the creation source (inspection lot, complaint entry) may be omitting it structurally. If the user status is blocking the transaction, decide whether the status profile is wrong (config, transport) or the notification genuinely should not be actionable at that status (no fix needed). If the action box is off for the notification type, that is a customizing switch, transport it alongside a review of why it was off in the first place rather than assuming it was accidental.

The reflex is to create the follow-up manually, raise the task, the purchase order, or the vendor communication by hand outside the notification and mark the notification as processed. This clears the immediate complaint but breaks the link between the notification and its follow-up in reporting; the notification will show no linked objects, corrective action tracking and vendor quality metrics will undercount, and the same code will still fail to trigger anything on the next notification because nothing about the underlying catalog or rule gap was touched.

Owned by the QM configuration team, in coordination with whoever maintains the defect and cause catalogs for the plant. The handover note should include the notification number, the exact code entered, the expected action, whether the action fired for the same code elsewhere, and the current user status of the notification, so the fix can be scoped to catalog data, task determination customizing, or master data without a second round of reproduction.