Detecting issues: Maintenance Notifications
Every maintenance process in P4 starts with detecting a problem.
In most cases, this first signal is a Maintenance Notification.
Maintenance Notifications capture the fact that something might be wrong —
not yet how it will be fixed, by whom, or when.
You do not need to fully understand maintenance planning or execution yet.
At this stage, the goal is simple: get issues into the system in a controlled way.
What is a Maintenance Notification?
A Maintenance Notification is the entry point into maintenance.
In simple terms:
it records a potential issue with equipment,
it signals that maintenance attention may be required,
it creates visibility — not yet work.
A Maintenance Notification typically contains:
affected Equipment,
short description of the issue,
type (e.g. corrective, breakdown),
optional priority,
optional media (photos, video, audio).
At this stage:
no technician is required to start work,
no maintenance order exists yet,
no execution is running.
This separation is intentional.
Think of it as:
Maintenance Notification = problem detected
Maintenance Order = work approved and ready to be executed
Why Maintenance Notifications exist
Maintenance Notifications separate detection from execution.
This separation allows you to:
collect issues from multiple sources (operators, sensors, inspections),
validate issues before sending technicians to work,
avoid unnecessary or duplicate maintenance work,
keep full traceability from issue detection to resolution.
Without Maintenance Notifications:
every issue becomes an order immediately,
planners lose control over priorities,
reporting becomes noisy and unreliable.
For Getting Started, assume this rule:
Every maintenance issue should start as a Maintenance Notification.
When do you need a Maintenance Notification?
You need a Maintenance Notification whenever:
an operator notices abnormal behavior,
a technician spots a potential issue during inspection,
a machine shows warning signs,
a sensor or measuring point exceeds a threshold,
an issue is suspected but not yet fully evaluated.
You typically do not need a notification when:
work is clearly defined and must start immediately
(these cases may go directly to a Maintenance Order).
In practice:
most organizations start with many notifications,
only a subset becomes actual maintenance work.
This is healthy and expected.
How Maintenance Notifications are created
Maintenance Notifications can be created from several places in P4.
All methods create the same object — only the entry point differs.
1. From Production Control (Maintenance Notifications overview)
This is the most common way for planners and key users.
Typical use:
reviewing reported issues,
logging problems reported verbally or by email,
managing the notification backlog.
Creation is manual and explicit:
you decide what enters the maintenance system.
2. From Shopfloor View (operator perspective)
Operators can create Maintenance Notifications directly from the shopfloor.
Typical use:
machine behaves unexpectedly during production,
visible damage, leakage, noise, vibration,
issue discovered during normal operation.
This method:
lowers the barrier to reporting issues,
ensures problems are captured early,
keeps operators involved without giving them planning responsibility.
3. Automatically from Measuring Points
Some notifications are created automatically.
Typical triggers:
temperature exceeds limit,
pressure drops below threshold,
counter reaches defined value.
In these cases:
the system detects the issue,
a Maintenance Notification is created automatically,
no manual action is required to detect the problem.
Automation does not skip control —
it only replaces manual detection.
What happens after a Maintenance Notification is created?
After creation, a Maintenance Notification:
appears in the Maintenance Notifications list,
receives a status (typically Created),
waits for evaluation.
At this stage:
no technician is yet working on it,
no execution data is recorded,
nothing is “late” or “blocked”.
The next steps are:
assignment to technician or team,
conversion to a Maintenance Order,
or rejection if the issue is not valid.
All of this happens in the next phase of the maintenance flow.
Understanding Maintenance Notification statuses (high level)
A Maintenance Notification moves through a simple lifecycle:
Created – issue recorded, not yet processed
Assigned / Assigned to Team – responsibility defined
In Process – maintenance execution started (via order)
Resolved – issue fixed
Rejected – issue deemed invalid or irrelevant
Do not overthink statuses at this stage.
Their purpose is visibility, not control.
Common first mistakes (and why they happen)
Creating Maintenance Orders directly for every issue
This removes the decision layer and overloads technicians.
Using notifications as work logs
Notifications describe problems, not the work itself.
Ignoring notifications without rejecting them
Unprocessed notifications slowly turn into noise.
Expecting maintenance to start automatically
A notification signals a problem — it does not start work.
These mistakes are normal during first use and usually disappear once the flow is understood.
What you should be able to do now
After completing this step, you should:
understand the role of Maintenance Notifications,
know when to create a notification,
understand the difference between detection and execution,
be able to create a Maintenance Notification from at least one entry point.
Next step
From Notification to Work: Maintenance Orders
This is where detected issues turn into real maintenance work.