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

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.

Shubham Aware  If i redirect 2nd UIT to direct integration then it will not ask because form is not submitted. 





 do I need to add the integration and remaining flow in the subprocess? Can you please how can design subprocess 
Even for the second integration if any errors again redirect to same form then correct the details again call to integration

For the subprocess approach, move everything from "Call EmailIntegration" through "Call Reconciliation" (the red box in your image) into a subprocess.
Your main process becomes simply:
Start -> 1ST UIT -> Call Subprocess -> End.
Inside the subprocess, design the flow as:
Integration -> XOR (check error) -> If error: 2ND UIT -> loop back to Integration; If success: continue to remaining nodes and end.
Configure the subprocess to receive GASR_Requests and emailOutput as input parameters, and ensure the 2ND UIT's Data Outputs update these subprocess variables before looping back to integration. This design keeps your main process clean with single executions while the subprocess handles all retry logic internally, making process monitoring much clearer as you'll see one subprocess instance with its internal iterations rather than confusing duplicate nodes.

For the subprocess approach, move everything from "Call EmailIntegration" through "Call Reconciliation" (the red box in your image) into a subprocess.
Your main process becomes simply:
Start -> 1ST UIT -> Call Subprocess -> End.
Inside the subprocess, design the flow as:
Integration -> XOR (check error) -> If error: 2ND UIT -> loop back to Integration; If success: continue to remaining nodes and end.
Configure the subprocess to receive GASR_Requests and emailOutput as input parameters, and ensure the 2ND UIT's Data Outputs update these subprocess variables before looping back to integration. This design keeps your main process clean with single executions while the subprocess handles all retry logic internally, making process monitoring much clearer as you'll see one subprocess instance with its internal iterations rather than confusing duplicate nodes.

Is it possible to start without startnode ?After 2nd UIT if it will go back to integration then how can it create a new subprocess instance again

Yes, subprocesses can start without a start node - they begin wherever the parent process flow enters (EmailIntegration). When 2ND UIT loops back to EmailIntegration, it does NOT create a new subprocess instance - it continues in the same one. That's the key benefit: one subprocess instance handles all retries internally until it completes through success or reaches max attempts. This avoids the multiple duplicate executions problem.

If it is not creating a new subprocess instance again will it be difficult to monitor the instance in case of any error as it will be reiterating through the same steps

No, it's easier to monitor. In one subprocess instance, you see all retry attempts chronologically with timestamps. This is much clearer than having duplicate nodes scattered across the main process. You open one subprocess and see the complete retry story in order, rather than trying to figure out which duplicate node belongs to which attempt.