Why bother with For Each at all

If you want your robot to touch lots of things without crashing into a wall of casting errors, mastering the UiPath For Each activity is mandatory. This article walks through using For Each and For Each Row for lists and DataTable automation. You will learn how to pick the right TypeArgument, avoid the modern art of exceptions, and log progress so your manager does not ask why the bot failed on a Tuesday.

Start smart with the right workflow and variables

Begin with a Sequence or a Flowchart and declare variables for the collection you plan to iterate. Use an array or a List for simple text lists. For spreadsheet or table work load the table first with a Build Data Table activity or a Read Range activity. That gives you a DataTable to feed into For Each Row or to filter before looping.

Pick the right activity and the right TypeArgument

Drag a For Each activity into your workflow when you have a generic collection such as an array or a List. Set the TypeArgument to the collection element type. For a list of text choose String. For lists of objects set the specific object type. If you are iterating rows use the For Each Row activity or set TypeArgument to DataRow in a For Each activity. Choosing the correct type prevents those cryptic casting errors that look like modern art.

What to do inside the loop

Use the item variable name supplied by the activity. For DataRow scenarios access columns like this row("ColumnName").ToString when you need a text representation. Use Assign activities to transform values and Click or Type Into activities to push data to applications. Pick descriptive variable names so future humans can understand the loop without summoning a séance.

Practical loop steps

1. Load data with Read Range or Build Data Table
2. Filter the DataTable first when possible to reduce work inside the loop
3. Use For Each Row for DataTable rows or For Each with TypeArgument DataRow
4. Within the loop use Assign, Click, Type Into, or custom logic
5. Log progress with Write Line or Log Message so you can debug like a human

Error handling and sensible skipping

Wrap risky actions inside a Try Catch block and handle specific exceptions. Set ContinueOnError only when skipping an error is an acceptable business decision. Otherwise handle the exception and log details. Proper logging helps trace unexpected data and keeps stakeholders from asking for a miracle.

Logging tips that actually help

• Write a message at loop start and loop end with item details
• Log errors with the row index or a unique identifier from the row
• Keep messages short and meaningful so you can grep them later

Common pitfalls and how to avoid them

• Wrong TypeArgument leads to invalid cast exceptions. Match types early
• Processing unfiltered tables wastes time and invites failures. Filter first
• Using vague variable names makes debugging a seven act tragedy. Name clearly
• Relying on ContinueOnError without logging hides the real problem

Wrap up with a clean finish

In short use For Each for collections and For Each Row for DataTable rows. Set a correct TypeArgument, filter data before looping, log progress, and catch exceptions with purpose. Follow these steps and your workflows will be less flirty with failure and more dependable for real world automation. Now go build something that works and enjoy the rare thrill of an unattended robot that actually finished its work.