Why do Navigate OOTB apps expect an assumed data model to be able to work?

[avillanueva]

Example would be Download Drawing Bundle app. You can specify Parts or CAD doc numbers from which it navigates links to find drawings. Its hit or miss and since it never seems 100% accurate, users cannot rely on it.  Can you publish the assumptions or data model it follows so that customers might see where their data links are broken? Or make it flexible to align to how customers manage their data. How about just providing list of drawings (or docs!) to retrieve directly?

[ehartman]

We have a multi-release approach for what we're calling modernization of our View Apps. Download Drawing Bundle falls into the category of View Apps from our standpoint. We're focused on two key goals as part of the modernization - modernize the look and feel of the apps with our Navigate Components and modernize the underlying APIs to use Windchill Rest Services. Download Drawing Bundle is coming up on our priority list soon so I will take this feedback as part of planning and can see what our R&D teams suggest. 

In general, the Navigate View Apps as they are designed to work directly OOTB so they rely heavily on the standard Windchill data model. 

I suggest you connect with Preeti Gupta as well from Johnson & Johnson as her team has built a custom app to download documents using almost the same format as our OOTB Download Drawing Bundle App!