As your company grows and changes, Fusion Lifecycle may need to change as well. Maybe the workflow for a process has changed. If items are in a particular workflow state, and that state is removed from the workflow, guess what happens to those records? Correct! Those records are left with no transition path, or more plainly an orphan. As painful as it may seem, your only recourse is to roll the record back to the previous state, then transition to the next available state. Not always the best scenario, but sometimes we must do it anyway.
You might ask yourself why we really care about orphaned records? It's because IF they have an associated workflow they can have a significant negative impact on tenant performance, particularly in the refresh of Outstanding Work on the home page. When you click the refresh button for Outstanding Work, Fusion Lifecycle walks through all records checking to see if the user has any workflow to perform. This also includes running any condition scripts to see if you are eligible to perform a particular workflow transition.
We also have to deal with records that no longer have context. A great example of this use case is:
- A new NPI record is created and spawns numerous related task records.
- The user removes any unwanted linked tasks from the NPI's project management tab.
- The user moves the NPI through its workflow to completion.
Any guesses as to what ever became of those tasks that were removed? Can we assume that when we clicked the handy little "x" that all is well in PLMland? Your tenant is not as healthy as you might hope. When a linked task is removed from the project management tab, it's just that. Removed. Not deleted. So, we end up with a task that's no longer related to or assigned to any parent record.
Enter Utility Scripting -
Here's where a little scripting can be a huge help. Your first step is to identify the breadth of the problem. How many records are we dealing with.
To get a picture of the number of records affected we start with a custom report on the parent workspace, in my example 'NPI'.
We create a report on the NPI workspace, filtering for Canceled or Completed records.

Notice the OR operator that's available when you use the Advanced option. The report result will be a listing of all closed or canceled records. Next we create a report on our tasks workspace filtering for any record in an Open state and that will prompt us for a record number when we run it.

Now all we have to do is select each record in turn and deal with them individually.
This of course all depends on "what" needs to be done with each record. How confident are you that your report filters are capturing all use cases? Do you need to physically examine each record to verify it's safe to delete or move to complete?
If you're dealing with a manageable number of orphaned records you might chose to just manually retiring the record either by deleting it or moving it to a completed state. If you're number is slightly larger, and you shy away from hundreds of mouse clicks you might explore crafting an on-demand script or two that condense those operations into a click or two per record. If you're staring in amazement at 1000's of records you probably want to invest the time in writing some heavier duty scripting using PowerShell as the driver to collect the reports, merge the data and finally repeatedly calling your Action Script to fix each record.
I hope I haven't described your worse case scenario in tenant maintenance, but we all know that sometimes users don't do what we wish they would or for some other reason things don't go as planned. At the very least I hope my example has demonstrated a systematic way to address the all to common problem of orphaned records.
If you're not currently a Fusion Lifecycle user and would like to know how it might benefit your company please visit our PLM page. Or, if you have Fusion Lifecycle and are looking for a partner to help with development or consulting, check out our service offerings.