Redirect to interface

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)

  Discussion posts and replies are publicly visible

Parents Reply Children
  • 0
    Certified Lead Developer
    in reply to ZAINAB

    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

  • 0
    Certified Lead Developer
    in reply to ZAINAB

    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

  • 0
    Certified Lead Developer
    in reply to ZAINAB

    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.