Patch attempts

A patch attempt joins one asset to one catalog entry. That link is the center of the operational record. It lets a Patch Operator tell whether a particular asset is scheduled, installing, verified, failed or rolled back for that patch. The attempt name helps people find the work; the linked asset and patch establish exactly what the result concerns.

An attempt begins in Scheduled. When work starts, the operator records the start date and moves it to Installing. On completion, the operator records the completion date and chooses the outcome that reflects the work. Verified means the team has checked the result. Failed and rolled back remain visible outcomes for follow-up. A new attempt may be needed after a failure; the earlier result should still explain what happened.

• Scope. The asset and patch references make each attempt specific.
• Timing. Start and completion dates frame the actual installation work.
• Outcome. The status distinguishes scheduled work from completed verification and exceptions.

Agree who creates attempts, who records outcomes and what evidence your team uses before marking an installation Verified. Define the handoff from a reviewed change to the Patch Operator so the operator knows the intended service window and rollback approach. The scheduled dates live on the change record, while actual execution dates live on the attempt. Review those records together during an operating cycle.

Suppose a patch is planned for two assets under the same service. Create a separate attempt for each asset. One may reach Verified while the other reaches Failed. Keeping the attempts separate lets the Service Owner assess actual service exposure without turning one successful installation into a claim about every device in the service.

Use a real catalog entry and a specific asset tag. Start one scheduled attempt, record its start and completion, then review the resulting status. Repeat with a failed attempt and confirm it remains available in the exception view. For a rollback, check that the outcome is marked rolled back and the change reviewer can see that result beside the affected service’s change record.

The team should also check an attempt with the wrong asset selection before work begins. Correcting that link early matters because incident follow-up and service impact depend on identifying the actual asset. If a disruption occurs, the Incident Responder records an incident for the affected asset and service and follows the incident path.

• Scheduled patch attempts — Find work ready for the operator’s next installation cycle.
• Failed patch attempts — Review attempts that need investigation or another plan.
• Patch attempt workboard — Compare work across its recorded states without hiding exceptions.

Follow installation and verification or respond to service impact.