[CoE Starter Kit - BUG] Request Orphaned Objects Reassigned (Parent) and Request Orphaned Objects Reassigned (Child) flows do not work in a "cooperation" about coe-starter-kit

[Jenefer-Monroe]

Hello, sorry having a little trouble following all the issues here.

The list of objects that are orphaned will be kept up to date with the "owner" being orphaned using this flow. CLEANUP - Admin | Sync Template v3 (Orphaned Makers)

Can you please make sure you have this turned on and that it is running regularly? It should run weekly.

Can you please run that to current and then see how many of your concerns still remain?

[JanetK12]

Hello, sorry having a little trouble following all the issues here.

The list of objects that are orphaned will be kept up to date with the "owner" being orphaned using this flow. CLEANUP - Admin | Sync Template v3 (Orphaned Makers)

Can you please make sure you have this turned on and that it is running regularly? It should run weekly.

Can you please run that to current and then see how many of your concerns still remain?

Hello @Jenefer-Monroe !
Thank you for your answer!
I have checked this flow, but it is turned on and runs successfully every week.
Could I clarify please what you meant with this question? -"Can you please run that to current and then see how many of your concerns still remain?" Or you meant that in case the flow was turned off and you wanted me to turn it on and then check?

However, not sure what to do next then as this flow was on and still is.

[Jenefer-Monroe]

In that check orphan flow we correct cases where the apps/flow is still marked orphaned even though the maker is not
Can you validate that you see this in the flow, I just looked at your Gov version and it could be you wont see this as you appear to be on the July 2023 version of the kit.

So while I agree that we probably should have done the same check in both flows, it would be a big change and I think this fix in the orphan flow covers it for the vast majority of cases.
Can you please validate your version and see if you have the above in the referenced check orphan flow?

[JanetK12]

Hi @Jenefer-Monroe !
Thank you for your answer!
I have checked the flow and these are the steps in the flow that I see

The Core Component solution version is 4.22
The things is that all CoE solutions in our environment are updated each 3 months, so all these flows as CLEANUP - Admin | Sync Template v3 (Orphaned Makers) need to be updated. However, we have a separate customization solution where we store, for example, these flows as Request Orphaned Objects Reassigned (Parent) and Request Orphaned Objects Reassigned (Child) flows, because there we added our customizations; that is why there is older solution used, and I posted the information as "Governance version 3.10" because the last copy of these two CoE flows that we took and added our customizations ~ were when it was Governance version 3.10.
However, these customizations are mostly about the branding icons, footer, tables look, some new messages , etc., so I do not think that the reason of the issues are because of the customizations. That is why wanted to investigate and understand.

[Jenefer-Monroe]

Gotcha. So what I don't understand then is, if this check orphan flow is running, then the two queries will be identical in most cases.

I wonder if its due to latency. With the June release (shipping today or tomorrow) we did change the flows such that all the child flows would run at the same time rather than waiting for response. I wonder if you had old child flows running? You wouldn't know this easily by looking at the run information. Can you please integrate the June release and let me know if you still see the issues?

[JanetK12]

Hello @Jenefer-Monroe !
Thank you again for your answer!

I will then most probably need to integrate the June release in some test environment as currently we are doing the April upgrade.

By the way, I wanted to inform that I noticed that it seems that because of this "issue" of the "makers is orphan", sometimes users receive empty tables with not data because if, lets say, that Parent flow collected the information that we have 5 orphaned flows and 5 orphaned apps; The maker of these items is the maker "A". With this information parent flow goes to the child flow and the child flow first of all checks who is the manager of this maker "A". The flow identified that the manager is "M". Then the flow checks who are all the makers that are assign to manager "M". And then the child flow proceeds to check exactly makers that are orphaned. But, if, let's say that manager "M" has not only maker "A" but also maker "B". Maker "A" is not orphaned, but maker "B" is orphaned. And then the child flow will not check maker "A" (the one who actually had these orphaned items and these items needed to be reassign). The child flow then proceeds to check only maker "B". But "B" has no items at all and because of that the empty table is send as the flow already started to run.

If I am not mistaken, I somehow have a feeling that sometime ago I raised the question in GiThub, maybe under some ticket, when we started receiving empty tables, and if I am not mistaken, the reason that we thought was because the parent flow started to repeatedly send the same requests to the child flow. I apologize if I am wrong and am confusing something, and if did not ask exactly this question.
But if that is also true, then maybe the second option is this one - regarding the "maker is orphan" as an example that I provided above?

[Jenefer-Monroe]

Thats why I had you check the Ophaned Maker flow above. In that flow, from your example, it would return Maker A's 5 apps and flows here and mark them as no longer orphaned.

Can you validate you have that filter in place as shown? And that in the loop it marks the object as shown here

[JanetK12]

Hello @Jenefer-Monroe !
Yes, here are the screenshots:

[Jenefer-Monroe]

Great. thank you. So in your example, this flow will mark Maker A's 5 apps and flows as no longer orphaned.
So perhaps this is the original theory of these child flows just all piling up and not get run in time. Which is the issue we fixed in June release.
Please do test out and return if you still have issues.

[JanetK12]

Hello @Jenefer-Monroe !
Thank you for your answer!
It seems that we will need to test the flows in the new version, yes. However, as currently we have only April upgrade, I am thinking how better to do that, whether to upgrade the separate env. for testing. But yes, once will be done will come back.

but could I clarify something regarding the V3 flow that needed to update these 5 records - so am I understanding that right that every V3 flow run needs to update the information about orphan/ not orphan (based on some filtering)? Because I am thinking that if yes, it needed to update the data, then why still the "Request Orphaned Objects Reassigned" flows do not "see" it? Or perhaps you mean that as the parent flow runs 30 days (because of the issue that child flows just all piling up and not get run in time, etc.), then these flows just do not receive info from the V3 flow in exactly this Parent's flow run? Because for the testing purposes I ran the V3 flow manually, so not like once in a week but more often, but still the same issue persists.

[Jenefer-Monroe]

Sorry I'm having trouble following you. My theory about the orphan flow is that its piling up, yes.
Please upgrade to the latest version of the kit, and run the setup wizard.

Use the setup wizard

Its highly recommended that you use the Setup Wizard to walk you through setup and upgrades. It will ensure all the new flows are turned on in the correct order, trigger things like population of the bookmarks screen and do other cleanup steps needed.
You should do this both for upgrades and clean installs.
To use it, first perform the import of the solution install or upgrade manually, then boot the app and walk through the screens.

[Jenefer-Monroe]

closing out as no further action for starter kit team