Okay, I see where the misunderstanding is.
You are not using the Bug object. You are using Bug_Fields, which is different.
The Bug object is an API construct that provides manipulative functionality. Notice that the API documentation refers to the "Field" property of the Bug object, not the Bug_Fields object.
The *_Fields objects available through workflow code give you the ability to access the database fields for the related object. The *_Fields objects generally do not manipulate the data in any way. They simply directly access the field.
Having said that, if I insert this statement into Bug workflow code
msgbox Bug_Fields("BG_SUBJECT").Value
what is displayed is the Name of the folder rather than the ID. The database reference says the field stores an integer ID for the selected folder. But apparently this is a case where Bug_Fields interprets the actual value and supplies you with the value displayed in the corresponding UI field, rather than the raw value stored in the database field.
So, an option at this point is to not use Bug_Fields, but instead get an actual Bug object that points to your bug. Unfortunately, your bug has to have already been saved in order to get a Bug object that points to it. That would mean you couldn't set your user field in the Bug_New workflow. You would have to wait until after you saved the new defect, so your custom code would have to go in the _AfterPost routine.
And, you would need to put custom code into the _FieldChange workflow, in case a user changed the value of the Bug Subject field. I assume you would want to change the value in the user defined field in that case.
The following code works to display the SubjectNode path you were trying to get, if you add the code to Bug_AfterPost.
dim objBugFact dim objBug set objBugFact = TDConnection.BugFactory set objBug = objBugFact.Item(Bug_Fields("BG_BUG_ID").Value) msgbox objBug.Field("BG_SUBJECT").Path set objBugFact = nothing set objBug = nothing
Hope this helps.