I'd love to see more robust script management. Ideally I'd like to see the ability to officially version or rev scripts. In addition to the Save button, you could add a button for Version. This would store the script in its current state with the appropriate verison number.
In addition, I'd like to review previous versions of the script and have the option of making a previous version the current version.
It would be very helpful to have following workflow features:
1) Export a workflow from one enviornment to Import to Other.
2) It would be nice to have export and import done with all dependencies like Permissions, scripts etc. if not then Import shall display messages for missing dependencies and allow import only if all dependencies are in place. Like the permissions, roles and scripts.
Also on the workflow summary there should be an option(button) for complete information where each Transistion information including Condition script, Validation Script, Action Script, all other selectable options along with Escalation setup.
This would give user to copy this information and version control/document it. Also it can be compared against other enviornment setup.
As of today it is very easy to miss a setting when you are copying your workflow from Dev to Prod.
Conditional form-building in a workspace with workflow. We would like to be able to change a form layout based on a classification. Classification is the capability where we get different fields in a form for different scenarios, for example, in pricing.
The pricing attributes necessary for a product for a price list effective period can change depending on the period or type of product. The actual pricing framework and calculation can change as frequently as every month or any ad hoc period as set by the pricing team.
Framework impacts to forms Ex) We work on about price list effective periods at the same time – the form would be different for a different pricing framework
Per Jared: This is not on the roadmap. The team needs to talk to he product manager responsible for classifications for the expected timeline. The workaround is that we would use a more complex form that needs to accommodate the superset of everything that might be needed. The workaround is not ideal.
When assigning Products to Release as a BOM, we see all Revisions of the Products in the revision control workspace. The tool seems to be smart and no matter which Rev you pick, when you look at the BOM as of a certain date, the right Rev is displayed. Is there a way to see Product without the Revs - last version only or name only? We would see Product#32 three times, for example, for sA, B, and C (future).
There are three workspace permissions to view items, historical releases and working versions. They work together as below.
It would be better if there was a way to limit users to only see the latest release and also working versions. We'd like to prevent users from getting older releases and yet still be able to edit working versions while creating new documents. This could be accomplished if "View Historical Releases" and "View Working Versions" were independent instead of working together.
View Historical Release
View Working Versions
Can see the current version
Can see the current version, and old versions
Can see the current version, old versions, and the working version
I would like the ability to generate an ECN on the part that is currently visible (to update a drawing for instance). The system should pull the next available ECN number and automatically place the part on the affected items list. The current process takes too many steps.
Evaluting the process of a physical Design Review meeting, we've identified a want for a Mass Checkout/In feature. Additionally, it would be nice to have the option to simply Mass Delete attachments. This would give the user the option to bypass the "history" functionality (which is very useful to "build" by replacing files with all the marked-up then updated versions) which becomes very time-consuming when dealing with large numbers of attached files.
A "real" solution might be to simply embrace full Design Review functionality and workflows in the varous Autodesk 360 products! .dwf(x) is your own file-type... why it always seems to be an afterthought, I don't understand.
For any design review process to work efficiently, we need attributes of the file (.dwf, for instance) that can be searched and sorted. It is desireable to know the approval status without opening the file (this is more about files that are created and/or exist on my computer)! Secondly, it could save a lot of file re-creation (and allow the re-use of the file to stop round-tripping from the cloud) if the .dwf (and .dwfx) document had the option of whether-or-not to print either Mark-ups, Stamps or both!!!!
Now, I must admit where a "cloud-only" mark-up/review/approval workflow falls apart (as of today)... it's for those of us who'd like to use the .dwf(x) as an "underlay", right under the sheet-to-be-corrected. This use of the marked-up .dwf(x) allows the Autocad/Inventor user to complete and track the tasks as they are done... in their native application! If Autocad/Inventor could open a cloud-based .dwf(x), edit it, then re-publish it... transparently... it would be easier to complete the Design Review process. This is more about the Design Review product than PLM360, but I'd think that Autodesk would like to have one solution, rather than the several vaguely-similar markup/review approaches they currently employ.
To summerize my suggestions;
Mass Checkout/In in PLM360
Cloud-ize all of Design Review for consistant use in all Autodesk 360 and off-the-shelf products
Add file attributes to .dwf(x) which indicate Approved status (if they don't exist)
Add the option of printing DR markups, stamps, both or neither (if it doesn't exist)
Add the ability to preserve mark-up and stamps upon recreation of .dwf(x) without creating another file (perhaps closing the open file as part of the "Republish Sheets" (in Inventor, for instance) process would allow the user to maintain one file... one file name... ? the current process won't over-write the open file but the Republish commands are unavailable after closing the underlay mark-up.)