Why breaktriggerscopeinargument argument is created automatically?

I have used break activity to break the loop after that breaktriggerscopeinargument argument was created automatically, how to avoid this, or what value needs to be passed in breaktriggerscopeinargument argument.

Thanks in Advance

7 Likes

@Sankaraveni_Murugan

There would not be anythign created liek that…please restart UiPath and check or try in another xaml

cheers

Tried this, but that issue was not solved

1 Like

Hi @Sankaraveni_Murugan

When using the “Break” activity in UiPath, the “BreakTriggerScopeInArgument” argument is automatically created to indicate which loop or iteration the break activity should terminate. By default, it is set to Nothing (null) in UiPath Studio. If you want to avoid the creation of this argument or provide a specific value, you can follow these steps:

  1. Add the “Break” activity to your workflow to break out of a loop.
  2. Open the Properties pane for the “Break” activity.
  3. Expand the “Output” section.
  4. In the “BreakTriggerScopeInArgument” field, you can either delete the argument or provide a specific value.

Thanks!!

4 Likes

Thanks for the answer. Got understanding. But I am not able to see the properties panel for the “Break” Activity.

2 Likes

Hi @Sankaraveni_Murugan

Try this-

  1. Instead of Break activity use a condition within the loop to check for the desired condition that should trigger the loop termination.
  2. When the condition is met, use the Exit Loop activity to exit the loop and continue with the subsequent activities.

Thanks!!

I was wondering the same thing myself. I have a loop in my process that has a break in it because it’s required, and when I published it, I see this argument in Orchestrator:

But there is no such argument defined in my process.

1 Like

nonsense. It’s very critical bug. It need to be fixed urgently.

12 Likes

I managed to get it removed by opening the source XAML file with text editor and deleting the entire line. But the project still will not compile.

Also, it appeared after nothing changed except a string argument literal initializer. Did not change anything else, and UiPath Studio just put this in there and kiboshed the entire project.

This is definitely a bug with Studio, and it’s going to waste several hours for me to copy everything over to a new project to get it working again.

3 Likes

i am able to solve it by creating a new .xaml file and invoke it , yes you need to copy past every thing form your old .xaml file to New

2 Likes

I have the same issue. What a nasty bug - even after removing the “break” activity altogether the argument is stubborn and reappears even when you delete it. Can’t make the exact argument in the flow either because it “exists” somewhere.

Seems like copy pasting the whole flow in a new .xaml is the only option…

3 Likes

I was able to edit Main.xaml and find/delete the line containing that argument. Re-opening the project and publishing it didn’t show that arg.

Hi,

This is quite frustrating to have to do every time a break is used in a component.
Is this in UiPath’s issue log to fix? its been happening for months now.

1 Like

This is also happening for us. Any word from UiPath on this issue?

Hi @dhananjay.suresh and All,

Could you please provide how does it looks like in Main.xaml to look for it too?
Regards,

Hello, any update from UiPath ?

This is so annoying to open the xaml and remove the argument manually,
Even worse now as I want to implement some governance and force my custom roles from workflow analyzer, it will restreint possibility for developer to publish because this triggers an Error with unused variable

This argument showed up in my workflow after I added the Break activity and googling for it lead me there…

Its a bug, Sometime it happens, sometimes it doesnt. Try to ignore it if possible. Someday UiPath team will see and fix, i hope haha

I came also accross this issue recently and reported as a bug to UiPath.
Fortunately I was able to rearrange the workflow to avoid “Break” activity.

Cheers

Also have this issue in a workflow. Manually deleted this argument, the next day when reoping the workflow it was back there. Definitely a bug.