Component/Sequence/Workflow Name

Sorry I meant workflow/sequence :slight_smile:

No this doesn’t quite answer the question. We’re talking about being able to self-reference the workflow that you are in. So, for example, if your workflow is called Workflow.xaml you would be able to call that dynamically by referencing UiPath.WorkflowName or something to that effect.

Therefore every time you want to log a message or throw an exception you could start it with UiPath.WorkflowName + " bla bla bla" rather than having a variable called StringWorkflowName and having to update it every time you create a new workflow.

I don’t think that it’s a massive thing but it feels like something you should be able to do and in certain circumstances could be really useful.



Hey Denton! Small world indeed ;o)

That’s exactly why I want this. At the moment I have a variable name for a component (sequence) so when I log any messages I can add the component (sequence) name to the log. I also have to remember to update this variable each time I create a new component or rename an existing one. Not a game changer but would be a lot smarter if you were able to get an object returned (kind of like a trace stack) showing each sequence call with properties for current workflow/sequence and parent workflow/sequence and full stack path. Can make debugging a lot smarter and supporting for CoE a lot easier.


Current workflow name is by default logged under filename node in the log json:
13:37:57.9454 Trace {"message":"UiPath.Core.SelectorNotFoundException: Cannot find the UI element corresponding [...]r\n at UiPath.UiNodeClass.FindFirst(UiFindScope scope, String nodeID)\r\n at [...]","level":"Trace","timeStamp":"2017-02-07T13:37:57.9454027+01:00","windowsIdentity":"[...]","agentSessionId":"00000000-0000-0000-0000-000000000000","processName":"Test5","fileName":"TerminationTest","jobId":"e9da7713-174d-4495-b88a-aefc00435fa0"}

But it’s true it could come in handy, especially with exceptions, as they’d show the fileName for where they’re catched, not where they were thrown.
Having a call stack would be great too, especially for resuable workflows, where the path how it got there is sometimes as important as where the issue occurred.

What do you mean by logging properties, though? Argument values?

Either way - thumbs up, could be a useful addition.


I mean example properties I could access on the stack object. As for the filename you’re correct, just being able to get the information yourself means you can document your own messages to look for at CoE an be able to dictate the format of them

1 Like

Hi guys - any update on this?

My use-case is that I’d like to be able to save a screen-shot to a shared folder if I run into an exception - and would like to add the robot’s name or the flow name to the screenshot filename for some context, like: “[RobotName]-2017-07-11-12-16-33.png”

Why not using the environment variables machine and user?

1 Like

Many thanks - that’s exactly what I needed.

Hi Richard,

I would like to do exactly the same. Do you find a way to do this?

How can you access to Workflow Name or Sequence Name? Thanks :wink:

Nope :frowning:

1 Like

jiji … Me neither

I also want to retrieve name of workflow. I need that so that I can easily add comment on the very beginning and end of invoked workflow for instance. As logging is encouraged when building workflow, I hope this will be a help of everyone :slight_smile:

1 Like

It’s almost like you were reading my mind, cause I was doing the same thing today.
System.Environment.CurrentDirectory gives you the directory but I couldn’t find the workflow name.

I do know that you can get the Sequence name when an exception occurs by using an Invoke inside a Try/Catch with exception.Source in the Catch.

But for workflow name, I ultimately hardcoded it into my Start Log string. I will keep an eye if there is ever a solution presented though.

EDIT: also, a possible idea would be to use GetFiles with the CurrentDirectory and filter it by a keyword, like “MAIN” then that will give you the workflow filename.

1 Like

Nice idea Clayton,

Just thinking if you have component name as a variable you could then use that to determine the file name - assuming it’s identical.

Or does having that variable negate the need for obtaining the workflow name? I can’t remember a scenario where I needed it.


In each activity execution log entry there is a “filename” attribute which is the name of the parent xaml of this activity.


I would find it useful to have a general reflection API like one has in .NET / Java. In those environments, the use cases are broad because it is read (get) / write (invoke method) oriented. All of the logging use cases above would be solved. Off the cuff I could think of activities like GetCurrentActivityClass - which would have data for current activity name, id, …, GetCurrentWorkflowClass - return the first activity above in the graph that is a workflow item …

Mircea - it looks like much/all of the information is there internally, just a matter of making it reliably available.


Going through the thread, looks like we still don’t have a way to retrieve the xaml WorkflowName. Am i correct?

I am designing a custom activity and i don’t want studio user to specify the name of the workflow through properties. Instead i would like to get the name of the workflow that has that custom activity and report on it.

Did you guys find a way to achieve this?

Rammohan B.

I think i achieved what i wanted. Thanks to this post by @andrzej.kniola :slight_smile:

Rammohan B.

Hi, in this activity what did you use as input for “Root Name”
whatever I am inputting its giving me error as “Invalid L-Value expression”


Would be awesome to get workflow name but I think also an identifier for activity would be useful. All in all, similar to a bread-crumb trail of where something went wrong all the way from Main, down to the activity level. I think combining this idea with something like this (Activity Uid in case of application exception) would be great :slight_smile: