Introduction to iterators walkthrough

The purpose of this walkthrough exercise is to demonstrate how some iterator modules or modules that act as iterators, such as Read Related Records, will pass through multiple bundles to the rest of your scenario. In this scenario, we count the number of tasks within a project and then perform some random math to reiterate how iterators behave. For this practice exercise, you’ll want to have the Northstar Fashion Exhibitor’s Booth project pulled up in your test drive instance so you can use that Workfront ID for the project.

Let’s start by creating a new scenario and calling it Introduction to Iteration. For our Trigger Module, we’ll use the Read a Record Workfront Module.

For the record type, choose Project.

From the outputs, choose the ID, Name, and Description.

For the ID, we’re going to copy the ID from that previous project Northstar Fashion Exhibitors Booth, and paste it into the ID field.

Next, we want to look at all the tasks within that project by using a Read Related Records Module.

For the record type, we’re going to choose Project yet again.

And for the parent record ID, we can pull the ID from our Trigger Module.

Finally, for collection, let’s find the tasks.

For outputs, let’s choose the ID, Name, Description, Number of Children, Number of Open Issues, and Work.

Go ahead and click OK, and then let’s run the scenario once to see the outputs.

Clicking into the Execution Inspector for our first module, I see that I have one bundle input, the project that we selected, and we have multiple bundle outputs. If I scroll down, I can see that in that project, there are a total of 28 tasks. In the next video, we’ll add some modules to count and then process some information for all of the tasks within this project.

Let’s start by renaming our first two modules. My first Trigger Module, I can rename Find Workfront Projects.

My second module, I’ll rename Read Project Tasks.

Now, to reiterate the fact that the Read Related Records Module is behaving as an iterator, let’s add the Increment Function Module after the Read Related Records.

For Reset a Value, go ahead and leave it as Never and click OK. We can rename this module Count the Number of Tasks.

To show how after an iterator, each bundle is processed separately, let’s add the Set Variable Module.

For the variable name, we can just call it Random Math.

For my variable value, I’ll take the number of open op tasks or the number of open issues on each task and subtract from it the number of open children. Go ahead and click OK. I’ll rename this last module Random Math, and run the scenario.

Opening the Execution Inspector for my set variable and expanding on, say, Operation 7, I can see that my Random Math produced a result of negative seven meaning there were probably no open issues but seven children. Expanding into other sections, I may find zeros or other numbers, but the point is for each of the tasks produced from our Read Related Records Iterator Module, we performed 28 executions. These 28 bundles will continue to be processed throughout my scenario if I continue building it if I don’t add an aggregator to close the loop. -