There are a few things you can check for this.
1. Are the other incidents closed? If so, the OOTB action will not touch them.
2. The action may not be correctly configured. I found that in some cases, the actions the business rules are configured to fire for each child doesn't actually exist.
Verify it still has a valid action tied to it. If you see a RecID, then it's probably busted since it's not resolving the action name.
The documentation itself is a bit outdated as they moved away from the 'Resolution Details' tab with 2017.3. So that doesn't even normally exist anymore.
Creating the action should be simple enough. Make sure you enter all the required fields for a resolved item.
Looking at the documentation:
The system updates the fields in the linked incidents with the values that you entered for the master incident. For the linked incidents, it also adds the text ***Resolved through master incident number*** in the Resolution field on the Resolution Details tab.
$("***Resolved through master incident " + ToString([Incident#.MasterIncident]IncidentNumber) + "***")
Edit the rule to use the new notification:
Select the action you just created:
yes you were right, I only had the id in the run for child configuration.
But if I already have linked incidents and then change the status of the master to resolved, nothing happens with the linked incidents.
It works if the master Incident is already resolved and I link new incidents.
Dont I need some trigger on the status "Resolved"?
"Update Master's Related Incidents" and "Update Master's Related Incident Resolution" trigger with IsRelatedIncidentUpdate
so it would only work if I set the options before saving my resolution.
If I have an active master incident and check the two options "Declare as Master Incdent" and "Update Related Incident"
link some active incidents
set the Master incident to Resolved and add the resolution
nothing happens with the linked incidents as isRelatedIncidentupdate did not change.
So that is why my idea was to trigger on the Satus. Which works for the above case but I dont konw if anything else does not work then
It should be working if you fixed the quick action. The "Update Master's Related Incidents" BR suffers the same problem of no actual quickaction. It has the same trigger as the other one, sans the 'On initialize' option. These are really both set to trigger at the same time, had the quick actions actually exist.
The 'OOTB' resolution action has three conditions (both rules actually have the same triggers):
1. IsRelatedIncidentsUpdate is set to true
2. IsMasterIncident is True
3. The childfold returns more than zero for Child incidents that aren't closed.
So it doesn't even check the status of the master incident is resolved. You could always add that to the conditional clause. I'd suggest you do that so the actions are independent.
$(Status == "Resolved" && IsMasterIncident &&
$(Status != "Closed")) >
The quickaction should actually exist as a part of the package, it seems like the ID got updated and the package never referenced the new ID.
<QuickAction FRS_ID="26dca280-c90b-4ec3-9f06-816a11969808" CLR_Type="MetaDataDefinition.Revisions.R1.UpdateObjectActionMetaData" ObjectType="Incident#" DisplayName="Copy Resolution from Master to Related Incident">
If you have an action called "Copy Resolution from Master to Related Incident," set the BR to use that action as that is the expected action. So you shouldn't need to create your own action.
Same with the other business rule...
<QuickAction FRS_ID="b29ed4ae-9bd5-4430-9037-e84253aad482" CLR_Type="MetaDataDefinition.Revisions.R1.UpdateObjectActionMetaData" ObjectType="Incident#" DisplayName="Copy from Master to Related Incidents">
Thanks for your patients
It works now when I set the "update Related Incident" while writing the Resolution and then save.
I could tweak the readonly of that to become editable like the Resolution, or hide it altogether and set it to true with status Resolved.
But first I will have a look at the 2017.3 update due in march (I think)