Redirect to interface

The error is happening because you're trying to use ac!error.body in the Data Outputs tab of your User Input Task, but Activity Class parameters (ac!) aren't available in User Input Tasks - they only exist in Script Tasks and other system nodes. In User Input Tasks, you can only map rule inputs (ri!) from your interface to process variables (pv!).
To fix this, remove the ac!error.body reference from your Data Outputs tab. Instead, capture the error in a Script Task or Integration node before the User Input Task, save it to a process variable there, then pass that process variable to your interface as a rule input. This way, you're only mapping ri! values to pv! values in the Data Outputs, which is the correct approach.

Issue is I don't see ac!error.body in data output tab itself .Attached above screenshots of the same

Can you share expression code where it's being used in UIT?

Why are you using this expression?

ac!error does not have body.

Instead try using ac!error.message

I don't have any expression in output of my 2nd UIT ...I'm not sure who is it coming from generate documentation



I only have it as input

It's showing under output tab in documentation.

Can you validate process?




It might be a cache issue. Close the Process Model and open it again, Validate the process, then publish the process again?

I have removed the input itself then it is not throwing the error  

Now, Do you have any issues with this process?

In 2nd UIT , after I remove the invalid Emails and then resubmit the form it is going to integration but again it is going to 2nd UIT with 1st entered details (which includes invalid emailaddress). 

Can you please suggest an approach to achieve this functionality

The issue is that your corrected form data from the 2nd UIT isn't being saved back to the process variables, so the integration keeps using the original invalid data. In your 2nd UIT's Data Outputs tab, you need to configure mappings for all form fields - map ri!GASR_Requests to pv!GASR_Requests, ri!emailOutput to pv!emailOutput, and any other relevant fields to their corresponding process variables.
This ensures that when users fix the invalid emails and resubmit, the corrected values overwrite the original process variables before the integration executes again. Without these output mappings, the process retains the first submission's data, causing the loop you're experiencing.

Shubham Aware  Is it a good approach to design the process model like this because after fixing the invalidemails the process will goes through the same path again so in case if we want to debug then the monitoring shows the process like in the screenshot only right . same flow executing again & again not sure how many times 

Your current approach creates confusing process history with duplicate node executions that are hard to debug. Better approach: After the 2nd UIT, route backwards directly to the integration node instead of going through the entire flow again. This creates a clear loop pattern showing retry attempts.
Alternatively, use a subprocess for the integration+retry logic, keeping the main process clean.
The current design makes it impossible to track which iteration you're viewing and wastes resources executing the same nodes multiple times.

Your current approach creates confusing process history with duplicate node executions that are hard to debug. Better approach: After the 2nd UIT, route backwards directly to the integration node instead of going through the entire flow again. This creates a clear loop pattern showing retry attempts.
Alternatively, use a subprocess for the integration+retry logic, keeping the main process clean.
The current design makes it impossible to track which iteration you're viewing and wastes resources executing the same nodes multiple times.