Before
Engineers had to export or review installed software and operating systems, look up lifecycle dates product by product, and determine which team owned each affected system. They also had to identify affected configuration items, check for existing problems, and assemble remediation details before handing the work to support teams.
How it works
- Collect active inventory, ownership data, service dependencies, and existing lifecycle problems, then match software and operating-system versions to published lifecycle records.
- Classify each configuration item by support status, identify a viable newer cycle, determine the responsible team, and check whether the finding is already tracked.
- Create one grouped problem per eligible team, product, and lifecycle cycle, link the affected configuration items, and return a summary of created, existing, and uncovered findings.
Workflow details
- Inventory collection: The workflow reads active software installations, computer and server operating systems, support groups, service dependencies, and existing lifecycle problems from the configuration management database. Continuously updated or explicitly excluded software is omitted from the review.
- Lifecycle matching: It maps inventoried product names and versions to published lifecycle records, then classifies each configuration item as out of support, approaching end of support within the review horizon, under reduced support, current, unknown, or uncovered.
- Ownership and targeting: Responsible teams are determined from configuration ownership, service dependencies, and support groups. For affected components, the workflow identifies a newer cycle from the same product family that is expected to retain support for at least the configured minimum period.
- Problem creation: Eligible findings are grouped by team, product, and lifecycle cycle. Existing active problems with the same correlation key are not recreated; new problems include affected configuration items, exposure information, impact, urgency, remediation deadlines, and upgrade guidance.
- Results: The flow returns a summary of lifecycle status by product family, problems created or already tracked, linked configuration items, unknown cycles, and inventory that could not be matched to published records.
What changed
Lifecycle status, ownership, target-version guidance, exposure, priority, and deadlines are calculated in one review. The handoff changes from a manually assembled finding to a grouped ServiceNow problem already assigned to the responsible team and linked to the configuration items requiring remediation, while human teams retain responsibility for planning and executing upgrades or exceptions.
Work removed
Exporting inventory, repeatedly looking up lifecycle dates, mapping products and versions to lifecycle cycles, identifying responsible teams, compiling affected configuration-item lists, checking for duplicate open problems, and manually preparing problem records.
Expected outcome
Each eligible team, product, and lifecycle cycle is consolidated into one remediation problem rather than separate records for every affected configuration item; exact time savings are not measured.
