While developing the multi-discipline management profile in Autodesk PLM 360, I have been meticulously been trying to make every mistake possible. Here’s something that might help you as you move into customization.

First there is nothing wrong with the out of the box PLM 360. However if you desire to manage a little differently, then you’ll probably run into scripting. I’s not difficult to pick up, and there are numerous examples to copy and work with.

Building a Bridge

imageThis tip relates to how the PLM 360 database passes information. Each workspace is a collection of various types of data. Unfortunately there is no current method of querying data stored in separate workspace types using scripts. That means that if you are scripting in an Items and BOMs workspace, you cannot query data from the Project workspace. Therefore different workspaces can contain fields with the exact same Field ID, such as ‘CONTROL_ID’ field I have in four different workspaces.

There is however, a clever way to connect workspaces by adding a field with a ‘Linking Picklist’ type. This field then:

  • Displays the information picked
  • Creates an active link that users can  pick in order to jump to the linked workspace data
  • Creates a data tie between the current workspace and the other
  • Adding a Linking Picklist to the Workspace items creates a bridge that scripts can use to jump to the other workspace in order to extract data. What I want to discuss today is being very careful with your setup so that your scripts are as efficient as possible.

Efficient Scripting

I was cascading numbers from one workspace to another different workspace type. I had developed 3 separate scripts that do exactly the same thing. However, I realized why the PLM team used the same exact name for each workspace identifier – ‘NUMBER’. This way, any script designed to perform a task with a workspace identifier, could be used in any workspace.

What I did was go back and start over, and ensure that every new field, similar in function with other workspaces, has the same Field ID. Not the Field name you see labeled, but the Field ID that you don’t.

Then I was able to revise one script to perform exactly the same task in each existing (and potentially future) workspaces.


In the example below I got rid of three fields that had very specific names related to this workspace, yet did exactly the same job in other workspaces. By naming them the same across all workspaces, I can simplify scripts, and more easily remember the Field ID conventions.


You will notice when adding the fields to workspaces, that the Field ID name gets locked so that it cannot be changed once you create it. The Field names however can be changed as much as you like. When the fields are created, the Field Name, and Field ID are the same. It is recommended that you leave the field name as is until the troubleshooting and tuning is complete. Change these displayed names as a last step in the database cleanup.

In the example below, the Control ID is being built properly by the script now. This number was automatically cascaded in each workspace to develop a [Project]-[Section]-[Group] numbering convention.


Also notice the The PARENT display name will be changed to Parent Design Section, or something similarly more descriptive once all the development is complete.

Final Thoughts

I suspect that the PLM 360 database is a series of fields in the database instance, that are only tied by the workspace interface. This gives the user the ultimate creativity at the UI level, and protects the database from being torn up and corrupted. The flipside is the inability to query data collections remote, without a pre-specified link. Even with the link, there are limitations.

I believe that Autodesk is continuing to shape the PLM 360 product in order to make it the best platform for all of its customers. I also expect there to be a rocky road where trying to implement these types of functional improvements in an existing database platform. Autodesk does however surprise me on a regular basis.

In any case, Scott and I will continue to leverage the technology and ask for the obvious things that users need. Keep checking back for more of our management articles.