Find Matching Tasks between two Plans in Planner

[autodafey]

I have two Microsft Planner Plans.  A new plan that was copied from an old Plan.  The copy process allows for you to move a lot of things but it doesn't allow you to select Assignments.  The good part is that, in its current state, All of the buckets, labels, and task names are currently identical.  Which is what I want at the beginning of the plan.  What will change is the checklist items.

What I want to do is to have a Flow that can look at the old plan and add the assignees from the old plan to the identical task in the new plan.  Where I seem to be getting stuck is at the point where I should match the task IDs between the plans.  I think it should be a condition where Task Title is identical between the two plans, but that doesn't seem to work right.  Help!

[Anonymous]

Hello,

I'm following your logic and it seems like building a flow based on it should work.

Where is "Apply_to_each_2" in relation to your flow? 

The error seems to reference that second apply to each loop.

thanks,

Kyle

[autodafey]

That's where I kept getting stuck.  Apply to each Item ID makes sense to me.  But, it seems like it should be conditional on where the Task Title of the Old Plan (since that's where we have assignees) and the Task Title of the New Plan are identical.  Since the titles match but of course the Task IDs don't match.  When I try to put that in as a condition, it freaks out and gives me an error.

I deleted apply to each 2 after the error was generated.  Sorry, I just thought about that and before I screenshot it.

[Anonymous]

Hello,

The error is referencing a second "Apply to Each" loop, though (specifically, one named "Apply to Each 2"). 

The error does not seem to mention your condition, so I'm going to proceed assuming that the condition is not the immediate issue. 

I have a suggestion based on a hunch, and then if that doesn't work, I have a question and a request from you in order to help us further investigate this:

**Make sure that for whichever "list tasks" action (Old Plan or New Plan) you are referencing in the first Loop, you are referencing the OTHER "list tasks" in the second loop. I know that sounds basic, but it could be easily overlooked.**

If that isn't the issue, please address the below:

1. Is there still a loop in your flow called "Apply to Each 2"?

2. can you please provide a screenshot of the rest of your flow?

Respectfully,

Kyle

[Anonymous]

@autodafey 

Were you able to resolve the issue?

thanks,

Kyle

[autodafey]

Sorry, I just got back to working on this.  So, here's where I am.  I am back at the first apply to each (there is no second apply to each), where I have the Value of the new Plan's task IDs.  What do I do to get the assignees of the old task?  Do I even need a condition?  It seems like all that I need to do is to enumerate the assignees of that task.

[Anonymous]

@autodafey ,

I can't think of anyway to do it other than using two loops.

You have to loop through EACH of the new tasks (first loop) comparing the description of each task against the description of EACH of the old tasks (second loop; nested within the first).

Structurally it should look something like this:

Apply to Each new{

Apply to Each old{

if TitleNew equals TitleOld then{

Update a Task (be sure to update the Task ID of the NEW Task but reference the Dynamic Content for assignments from the OLD Task){

}

}

}

}

I hope this helps.

thanks,

Kyle

[autodafey]

I think I have it set up that way and just ran a test, but it's taking over two hours.  Is that usual?  Do I need anything on the no side of this condition?  I tried adding a terminate, but it wouldn't take it.

[Anonymous]

@autodafey ,

Check the output in your flow run history for the run that's taking a long time.

It will tell you how much time it spent on each step.

You don't need anything on the no side of the condition; if the condition evaluates as false (no), with nothing on that side, the flow just continues (either iterating to the next loop item or ending the flow).

thanks,

Kyle

[autodafey]

It like 0s, 2s, 1s, and then the final steps with the task updates has been sitting there for two hours.  Maybe some gateway condition for the loop is problematic?  There are about 480 tasks that it's updating, I just don't have a context for how long that takes.

[Anonymous]

Could you provide a screenshot of that output?

screenshots are very, very helpful in troubleshooting.

Descriptions are nice, screenshots are better.

It doesn't sound like the number of tasks is the issue if it's hanging on the "Update Task" action; it's happening on that first update task. (I'm assuming this since I can't see it)

It sounds like it's having an issue with actually updating that first task...have any of the tasks in the NEW plan had assignments added?

Also, it might be easier (and safer) to use a test plan while you're building your flow (unless it's no problem to recreate the plan that you're using in production) as you can have fewer items in it and you don't have to worry if the flow overwrites task information or otherwise makes the tasks unusable.

Also, Also: Screenshots.

thanks,

Kyle

[autodafey]

Here's what I see.  I can't enumerate the third one because it's greyed out.

[Anonymous]

@autodafey,

You weren't able to expand it at all?

Normally you can expand the loops and see how much time each action within them took...

Is the flow still showing as running?

thanks,

Kyle

[autodafey]

Yes, to both.  It shows as running and I can't expand it.  Maybe that's because the first step is failing, as you suggested.

[Anonymous]

Also,

It would be helpful to see the flow in edit mode (see your nested loops, condition, update task, etc).

i'm really flying in the dark trying to construct an idea in my head of your flow based on your descriptions. the problem with that is that Power Automate isn't running the flow that i'm building in my mind, it's running what you have.

thanks,

Kyle

[autodafey]

I stopped it since it seems like it's just not running normally.  Here's the expanded top part of the conditional section:

[Anonymous]

@autodafey ,

Okay, so the two loops inside of the condition: did you put them there or were they auto generated when you picked dynamic content?

you shouldn't need those two loops, and if they were auto-generated, you might need to use an "Items()" expression to pull the "AssignedTo" value out of the current Old Plan item and the "TaskID" value out of the current New Plan item. Current depends on where the flow is in each loop.

at four levels of nesting, with 480 items, your flow is having to iterate 480*480*480*480 = 53,084,160,000 times (technically less, since the condition won't always evaluate as true...but it's still a lot). That actually may be why it's hanging up. not completely sure...but I do know what you shouldn't need those two lower loops.

thanks,

Kyle

[Anonymous]

@autodafey ,

Check out this thread for a good explanation on how to use expressions to pull information out of the JSON output of a Flow action block: Here 

However, here you will be using an expression called "Items()" that is used to reference the current item that a loop that the flow is inside. The help text in the "Items()" expression is very helpful and pretty straightforward if you know what information you want out of the current item.

You can look at the output (from Flow Run History) of the Get Tasks actions earlier in your flow to see how to reference the TaskID and Assignee data that you want.

thanks,

Kyle

[autodafey]

I took it out and tried to make it look exactly like your first window.  It forced this one additional apply to each under the condition.  Maybe that makes the difference.  I'm running it now.

[Anonymous]

@autodafey ,

What's going to happen running it the way you have it in the screenshot (assuming that "Update a task" is passing in the current "TaskID" from "Apply to Each - Item ID of the New Plan") is the Flow is going to iterate through every task in your Old Plan (again, as it is already doing that in "Apply to each - ItemID from the Old Plan") and, each time, change the assignee to the new plan task to whoever the assignee is for the Old Plan, until it gets to the end of the Old Plan, leaving the assignee as whoever the assignee is for the last task in the Old Plan. It will do this for each of your new plan tasks; and you'll end up with every one of your new plan tasks assigned to whoever is assigned to the LAST old plan task.

to illustrate:

Old plan has 4 tasks with ID's 1-4

New plan has 4 tasks with ID's A-D

Assignees: X, Y, and Z

Task 1 is assigned to X

Task 2 is assigned to Y, Z

Task 3 is assigned to Z

Task 4 is assigned to X, Z

First loop starts with Task A 

Second loop starts with Task 1; Condition evaluates to TRUE as 1 and A have the same Title

Third loop starts with Task 1

Task A has assignee updated to X

Third loop continues with Task 2

Task A has assignee updated to Y, Z

Third loop continues with Task 3

Task A has assignee updated to Z

Third loop continues with Task 4

Task A has assignee updated to X, Z

Second loop continues with Task 2 which fails the condition

Second loop continues with Task 3 which fails the condition

Second loop continues with Task 4 which fails the condition

First loop continues with Task B

Second loop starts with Task 1 which fails the condition

Second loop Continues with Task 2; Condition evaluates to TRUE as 2 and B have the same Title

Third loop starts with Task 1

Task B has assignee updated to X

Third loop continues with Task 2

Task B has assignee updated to Y, Z

Third loop continues with Task 3

Task B has assignee updated to Z

Third loop continues with Task 4

Task B has assignee updated to X, Z

And so on....

As you can see, all of the new tasks are going to end up assigned to X, Z.

Items() is most likely the way to go.

thanks,
Kyle