Why breaktriggerscopeinargument argument is created automatically?

Same issue here.

Has anyone observed if this bug is negatively impacting a workflow?

Unfortunately, this is still an issue.

Meanwhile UiPath fixes a bug that has not been fixed for half of a year now… You can use a PowerShell solution (I had to zip it as .ps1 files are not allowed here) I created for myself, as I quite often use the Break activity in my projects.

BreakTriggerRemoval.zip (589 Bytes)

All you have to do really, is run the script and pass the root folder of your project, it will then clear all the lines containing the Break Argument.


If you don’t want to run a script, you can also manually remove the arguments from the xaml by opening said file in a text editor, searching for “BreakTriggerScopeInArgument”, and removing the line in which the argument is found.

For example (based on Windows OS), you have Main.xaml and MyProcess.xaml. When you use an Invoke Workflow activity in Main.xaml that invokes MyProcess.xaml, it includes an extra input argument of BreakTriggerScopeInArgument that shouldn’t be there. First, close both Main.xaml and MyProcess.xaml from Studio so they are not currently being edited.

From your text editor of choice (I prefer robust text editors such as Sublime Text or Notepad++, but you can accomplish this with Notepad.exe as well), do a File > Open and select the offending MyProcess.xaml file from the project folder. Ctrl+F should initiate a Find function where you can paste in the target BreakTriggerScopeInArgument text, and it should find one instance near the top of the file.

Delete the entire row containing the BreakTriggerScopeInArgument argument, then save the file. Reopen Main.xaml in Studio, and the Invoke Workflow activity should no longer list the bogus argument anymore.

Hope this helps!

1 Like

I hope UiPath will fix this one day because it is very annoying. Yes we can remove it directly by opening xaml file but it appears again after some modifications… Time consuming.


I just realized I reported this also.

This worked for me. I just edited the affected .xaml file in a text editor and removed the BreakTriggerScopeInArgument from the list of arguments. saved the file and it was no longer there.

1 Like

I’m having the same issue, there is no UiPath answer for this yet.

can I catch the argument in a variable and not use said variable, in the meantime before uitpath fixes this ? or is that considered bad practice ?

Having this issue after inserting a Break activity into a workflow and then removing it. Searching the code outside of UiPath Studio doesn’t find anything but it still reappears in different forms throughout random files when doing Analys Project:

  • Argument BreakTriggerScopeInArgument does not respect naming conventions… (though there are no arguments of that kind in that file)

Finding this now by double clicking on the error message after Analyse Project, but there is no trace of that argument anywhere:
(Warning ST-NMG-002 Arguments Naming Convention Argument BreakTriggerScopeInArgument does not respect the set pattern ^in_(dt_)?([A-Z]|[a-z])+([0-9])*$ VCCV/VCCV_AddTransaction.xaml)

It seems it has been fixed in version 24.2

1 Like

Thanks. Hope so. I have 2023.10.4 still.

I also deleted the entire line in the XAML with a text editor. After that my project did compile and I had no further problems.