Two files attached with this post for implementation purpose. I found that Out of the box, there isn't an Active flag, but there is a Status field. We use Retired and filter that status out from fields so users can't choose a Retired CI.
The CI's that have been decommissioned will not be deleted from the CMDB. This is to ensure we maintain the prior history of CMDB CI's.
Instead we can run a Business Rule that sets the state of the CI to "Retired" on decommission.
- Identify the steps in your asset retirement/decommission process. This is entirely separate from any tool.
- Identify any supporting documentation you need to save/track as part of the process.
- Determine how you want to track the overall retirement process. In the Asset course, we use a Change Request to manage the overall process and create tasks to manage the steps in the process.
- Determine the appropriate method(s) to begin the process. We use a related link, but you could look at other ways, too, such as a catalog request.
- Select a location to attach the certificate. We attach it to the Asset record in the course, but it could potentially be on a contract record with the disposal vendor and the asset could be associated with the contract.
From a technology standpoint, you could do this from either direction, but when it comes to asset related processes, it is best done from the Asset record, but as you state, that does not always make sense. Let me elaborate with a visual of the lifecycle:
The red portion of this diagram represents the Asset portion of the lifecycle. When you are making any changes in that portion of the lifecycle, it makes sense that those State changes are initiated against the Asset record. This includes moving from In stock to In use and even back into stock when a device is decommissioned.
The blue represents the operational aspects of the lifecycle. For state changes where something remains In use from the asset perspective, it certainly makes more sense to just be updating the Status of the CI and not even touch the Asset state if you do not need to. An exception might be if you transition something back to a "stockroom" for repair or maintenance.
All this being said, if you get your processes set up properly, you do not end up touching the State/Status of the Asset or CI unless it is from an exception standpoint. Then the updates become driven by the workflow. Then you end up tracking the process instead of managing states.
Take a break fix example. If your technician cannot access the Asset information, make a UI Action (button, link, context menu) from the CI record (or better yet, the Incident record) to pull the device back to a stockroom for repair. Identify what the process looks like here and that tasks that go into it. Put it in a workflow. Include steps in the workflow that update State on the Asset accordingly. Then you are focused on the the process you need to track to get the work done, and State/Status is updated as part of that process.
