Alternative to "For Each" Activity in Flow Designer

[mrreddy534]

Hi Experts,I 've been struggling with this issue for the past two weeks and haven't found a proper solution yet.

Is there an alternative to the "For Each" activity in Flow Designer?

I have a Lookup Records action that retrieves multiple records, and I need to apply a Custom Action to each record individually. Currently, using For Each, but looking for a different approach to achieve the same functionality without using For Each.

Is there any alternative way to apply the custom action to each record?

[GopikaP]

Hi @mrreddy534 , in the custom action, there is an input type called 'Records' where you can refer the table also. Pass those records as inputs to the custom action. In the script of custom action, get the sys ids of those records by using this script - please refer - Using the output of "Look Up Records" action inside an custom action - Support and Troubleshooting. You can then use those sys IDs to continue your scripting.

[Murtaza Saify]

1. Use a Server-Side Script in a Custom Action

How It Works: Move the looping logic into a server-side script (e.g., Script Include or a script in a Flow Designer Custom Action) to process all records in bulk.

Steps:

1. Create a Custom Action:

   • In Flow Designer, add a Custom Action step.

   • Use a Script step to loop through the records with GlideRecord or GlideRecordSecure.

   javascript

   Copy

   (function execute(inputs, outputs) {
     var records = inputs.records; // Array of sys_ids from Lookup Records
     var gr = new GlideRecord('your_table');
     gr.addQuery('sys_id', 'IN', records.join(','));
     gr.query();
     while (gr.next()) {
       // Apply your custom logic here
       outputs.processed_records++; // Track progress
     }
   })(inputs, outputs);

2. Pass the Records:

   • Use the Lookup Records step to fetch records, then pass their sys_ids to the Custom Action as an array.

Pros:

• No visual "For Each" loop in Flow Designer.

• Faster server-side processing (avoids multiple Flow transactions).

Cons:

• Requires scripting knowledge.

• Limited debugging visibility in Flow Designer.

---

2. Trigger a Scheduled Job

How It Works: Use a Scheduled Script Execution to process records asynchronously.

Steps:

1. Create a Scheduled Job Script:

   • Navigate to System Definition > Scheduled Jobs.

   • Write a script to process records:

     javascript

     Copy

     (function execute() {
       var records = /* Fetch records (e.g., GlideRecord query) */;
       while (records.next()) {
         // Apply custom action logic
       }
     })();

2. Trigger the Job from Flow Designer:

   • Use the Action > Schedule Job step in Flow Designer to invoke the script.

Pros:

• Avoids Flow timeouts for large datasets.

• Asynchronous processing.

Cons:

• Delayed execution (not real-time).

• Requires managing job logs and errors separately.

---

3. Use Business Rules

How It Works: Trigger your custom action via a Business Rule when records are created/updated.

Steps:

1. Create a Business Rule:

   • Table: Your target table.

   • Trigger: After insert/update.

   • Condition: Identify records needing processing (e.g., current.template_applied == true).

   • Script:

     javascript

     Copy

     (function executeRule(current, previous) {
       // Apply custom action logic here
       current.setValue('field', 'value');
       current.update();
     })(current, previous);

2. Update Records in Flow:

   • Use Update Records in Flow Designer to trigger the Business Rule (e.g., set a flag field).

Pros:

• No loops needed; logic runs per record.

• Real-time execution.

Cons:

• Only works for records created/updated via Flow.

• Requires schema changes (e.g., flag fields).

---

4. Use IntegrationHub Parallel Processing

How It Works: Use IntegrationHub spokes (e.g., REST or Email) to process records in parallel.

Steps:

1. Create a Subflow for Single-Record Processing:

   • Design a subflow that processes one record.

2. Use the "Action For Each" Spoke:

   • In the main flow, use the Action For Each IntegrationHub spoke to invoke the subflow for each record.

Pros:

• Parallel execution (faster than sequential "For Each").

• No explicit loop in Flow Designer.

Cons:

• Requires IntegrationHub license.

• Complexity in error handling.

---

5. Batch Update via GlideAggregate/GlideRecord

How It Works: Use a single Update Records step with a query to batch-process records.

Steps:

1. Fetch Records:

   • Use Lookup Records with a query to filter target records.

2. Batch Update:

   • Use the Update Records step to apply field changes in bulk (if your custom action is a simple field update).

[mrreddy534]

@GopikaP @Murtaza Saify I appreciate your replies.

One more query, Is it possible to create a custom action to trigger a traditional workflow for all the records retrieved through the lookup action? (Without for each loop)

[Murtaza Saify]

Steps to Trigger a Workflow for All Records Retrieved Through a Lookup Action:

1. Retrieve Records Using Lookup Action:

   • Use a lookup action to retrieve the records from your data source (e.g., SharePoint list, Dataverse, SQL database, etc.).

   • This action will return an array of records.

2. Parse the Lookup Results:

   • Use a Parse JSON action to parse the array of records returned by the lookup action. This step is necessary if the lookup action returns data in JSON format.

   • Define the schema for the JSON output to ensure that the fields are correctly mapped.

3. Trigger Workflow for Each Record:

   • Instead of using a For Each loop, you can use the Apply to Each action implicitly by passing the array of records to a subsequent action that processes each record individually.

   • For example, you can use the HTTP action or a custom connector to call an API that triggers the traditional workflow for each record.

4. Bulk Processing:

   • If your workflow can handle bulk operations, you can pass the entire array of records to the workflow in a single call. This approach depends on the capabilities of the workflow you are triggering.

   • For instance, if the workflow is a Power Automate flow, you can design it to accept an array of records and process them in bulk.

5. Error Handling and Logging:

   • Implement error handling to manage any issues that arise during the processing of records.

   • Log the results of each workflow trigger for auditing and troubleshooting purposes.