Redirect to interface

Question

Hi All, 
 
 My requirement is if any error comesup then it has to redirect to the same interface to modify the form and then resubmit the form again . IN the 2nd interface (which is same as 1st) I'm getting the below error .can someone please help. An error occurred while evaluating expression: Error.message:AC!error.body (Invalid index: Cannot index property 'body' of type Text into type IntegrationError) (Data Outputs)

Harsha Sharma · Answer

Can you try the following to rule out error.body existence in process model as well. Go to Process Documentation and search (ctrl+f) error.body or just body and see if you find something. For Documentation go to Tools->Generate Documentation

Harsha Sharma · Answer

First check the input node then expand the error variable. there check the saveinto config of message input. 
 Also check the output tab on UIT if any configuration is there.

Shubham Aware · Answer

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.

Shubham Aware · Answer

Could you follow below step and share screenshot if possible of search result. Step 1) Open PM -> Go to Tools -> Click Generate Documentation Step 2) Search " AC!error.body " or "ac!error.body" (Whatever field is erroring out search that) Share searched result.

Shubham Aware · Answer

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

Harsha Sharma · Answer

Hi Zainab Given the screenshots of 2nd UIT node seems correct, the documentation showing the ac!error.message in output is weird. I generally in such cases reconfigure the node and see if it resolves. 
 So pull a fresh UIT node from the pallete and configure the interface from scratch, let the ac be created and then re configure the saveInto values. Then replace this new node with the existing 2nd UIT node. Sometimes just refreshing the configurations can help in weird issues like this. So try reconfiguring a fresh UIT node and then publish he model. Check documentation after publishing for the culprit ac!error.message existence

Shubham Aware · Answer

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?

Shubham Aware · Answer

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 · Answer

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 · Answer

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.

Shubham Aware · Answer

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.