What is best practice for arguments on .xaml files?

Is it better to Initialize a variable on a Main sequence and pass it as In/Out argument on a lower level sequence, or to only declare it on the main sequence, but initialize it on the lower level sequence, and pass it as an Out argument? or is it indiffirent?

Im not sure if there is a best practice around it(rather naming has a best practice of prefix with in_ or out_).
I think it totally depends on the scope of usage.

If you are getting the value in a lower level you can bring it back as an out argument to a local main variable.
If you are getting it in main and want to use it in a lower level you create a local main variable and pass it to lower as an in argument.
More like a method/function call which is doing something for you and can have a return parameter. or just a call for independent processing without any input params.

If you are getting it and using it only in lower level then no need to do anything in main and vice-versa.

Lets see what other have to say :slight_smile:

Hi @m.landos

Here are my thoughts on this, because I believe there really is a wrong way to handle variables and arguments.

I’m going to assume by “sequence” you mean workflow file, so we don’t get confused.
Your Main workflow should not have any arguments at all, unless it is being called as a shared Main by various projects. And, if you do use the Main as a shared workflow file then there really should only be one argument so it knows which project or customer that will be processed so it can use the correct settings and process flow.

So, basically, anything that is called/invoked from the Main should have arguments in the workflow file. If the value is only being “read” by the invoked workflow then it should be an “IN” argument. If the value is only being “returned” back to the Main then it should be an “OUT” argument. And, if the value is being “changed” where it needs to be both read and returned again, then it should be an “IN/OUT”. As @nadim.warsi mentioned, using a naming convention to identify arguments from variables is good practice, such as (in_Variable1, out_Variable2, or io_Variable3)

Then, in the Invoke Workflow File activity inside the Main that calls your “lower level” workflow, you should use variables from the “Variables” pane, since there should not be any Arguments in the Main.

Now, there is an additional tip here when working with Arguments in your lower level workflows. Sometimes, you bring in an argument and it needs to be manipulated or formatted differently within that workflow before it starts. What you can do is utilize variables in this case. Essentially, Arguments are initialized first when the workflow starts, then Variables are initialized second, so if you have an in argument, for example in_Variable1, you can change it in the variables to one called variable1 with default value like If(IsDate(in_Variable1), CDate(in_Variable1), Now). So this tip can be useful sometimes, but doesn’t necessarily need to be used that much to be honest.

One more thing, avoid invoking workflow files inside of other invoked workflow files, unless they are library type componennts (like updating or logging info). The best process flows are one where you can see the entire process in a simple view, like if you need to embed yourself into many other workflows to understand the process, then it’s not organized well.

So in summary,
Initialize the variables in the Main as a Variable and only if they are global settings that you would like to potentially change, or if the value is one that is needed for multiple workflows or for the Main to process. Initialize the variables in the lower level workflows as Variables if they will only be used within that one component, and initialize them as Arguments if they come from a global setting or will be used in other workflow components.

Hopefully, I didn’t ramble on too much, and it’s actually simpler than I probably made it out to be. :thinking: