Problem Mgmt Multiple Changes Related to Problem

[sgmartin]

We're just getting into Problem Management in Jakarta and the person leading this has requested we provide the ability to link a problem to multiple Change Requests.   In fact, multiple CRs to a single Problem Task.   His take is that a Task could require multiple CRs to resolve.   I know there is a field on the form to link a Problem to a CR, but that is only one.   Like the Incident tab where you can link multiple Incidents to a single Problem, we would need a new tab for Change Requests.   I would like to convince him to add the multiple CRs to the Problem and not the Tasks.   Then if I have a new tab for CR, I can show them in a list and possible show what Task they would be for.

How is that tab in the Problem form configured and how can I add another tab for Change?

[kristenankeny]

If you're looking to show the changes related to the problem tasks under a problem, then you can build a new relationship. You would query from change, the parent is problem, and then your script would identify any change with a relationship with a problem task where the parent is the current problem. That query will need to first find your problem tasks under the problem, then you would need to find the changes related to that - this is where it really depends on how your developer related your change and problem tasks - did he generate a custom M2M table to relate them or is the problem task the "parent" on the change.

[sgmartin]

I was first trying to understand how Incidents are related to Problems and then maybe mimic that for Change, but I can't find how the 2 tabs (Incidents and Problem Tasks) get configured on the form.   I've looked at the Relationships that are currently configured and don't see anything there.   On the Problem table there is a field for Related Incidents and that only contains a count of the number of related Incidents.   That would be fine for this, but still looking to add a 3rd tab to my Problem form for Change.

[kristenankeny · Accepted solution]

Ah, anytime there is a relationship defined between records, the system makes it available in "Configure>Related Lists". This means, because Incident has a field called "Problem", on Problem there is also a related list available to show all incidents where the current problem is in that field. You create Relationships when you want to create more complex logic to look up records. For example, you could create a relationship (that will result in a "Related List" available to you on the form) to show you all problem tasks for the problem and apply that to incident. That would look like this:

then I can add that related list to my incident form so I can see the tasks under the "Problem":

In the case of Problem, out of box it has a many-to-one relationship with Change. (A change can be for many problems, but a problem can only have one change). It sounds like your developer created a relationship between Problem Task (child of problem) and Change. If that's the case, then you'll have to figure out how they defined that relationship so you can write a script like above. However, if he created the relationship between Problem and Change, then the related list is created automatically and you should be able to find it as "Change Requests" (not the parent one) when you select Configure > Related Lists on the Problem form.

[sgmartin]

Bingo!!!!

That explains quite a bit.   Like Incident, I'll probably need to add a field to Change to keep the Problem that it's associated with and also create the related list based on that field in Problem.  

Thank you.