Move item from product to library upon release

[fwadlinger]

We are just setting up Intralink 9.1, amd my management wants to set up our process so that while a design is in prototype, it will be kept in a product context, but once released, it will be put in a library of similar parts/assemblies. Is there an easy way to make this happen automatically upon promotion/ state change. My thought is that it might be part of a workflow?

Crossposted on MCADCentral.com Data mangement forum.

[MikeLockwood]

Good example of specifying the mechanics of what to do with the tool rather than the desired business result, which is to manage access.

No need to move the data. Instead:

- Manage access to the data via permissions by state

- Control what allows the state change to happen via a workflow assignment

- Automate the state change using a workflow robot in the same workflow

The workflow could be tied to the product data (Parts, Documents) itself, but better to be in the Promotion and/or Change Management workflow(s).

Also - In general, Product and Library contexts are identical except for the End Items table in Product Contexts (from the Details tab), allowing top-level access to and navigation to all End Items in that Product line. Libraries by definition are for items that are not specific to an End Item.

[avillanueva]

If you are using a release vehicle like a change notice or promotion
notice, add a step to the workflow there. I would avoid adding a
workflow per item tagged to its released state lifecycle.

[fwadlinger]

Thanks, Mike/Antonio.

From Mike: "No need to move the data."

I am aware, but I am picking my battles, and this seems to be a minor concession. If not, please advise. We do use a fair percentage of our parts and subassemblies in multiple products, so it has some merit.

I was intending to put this in the promotion workflow as it will happen with each item, but, being new, I would bow humbly(LOL) for a good example of something similar.

[MikeLockwood]

Not a super important one if "picking battles" in the grand scheme of things, but relatively lots of effort for little value.

At least consider moving to a folder within the current Product which has different Access control (easy to set up -requires a domain for the subfolder) rather than to a Library. Try hard to keep the correct data in Products vs. Libraries.

[RussPratt]

As Mike says, there are better alternatives. Then question indicates that you have a core missunderstanding of the purpose of Products v. Libraries. But, you can do it. However, be carefull that you think everything through if you go this route.

First consideration:

• You're using Product for Development


• Library for Released archiving


• Now, when you need to create a new Revision of that Released object, are you going to want to move the new Rev back to a Product, complete the dev, and then move it back to the Library again?

Think these things through carefully. A lot of extra activity for no business value.

Russ

[JeffZemsky]

To add to Russ' comments -



This type of philosophy (moving the data) is born of file based storage
- when using network storage the only way to control access and
visibility is by moving it from folder to folder. With a PDM system you
can control those much more reliably, easily and without customization
just by using Lifecycles. This is one of the primary reasons for
investing in PDM tools.



It sounds like some more education is needed on what the tool can
provide and some PDM foundation concepts.



This is actually a battle I would look into as you are going to set
yourself up for lots more work down the road to maintain this rather
than leveraging OOTB tools and capabilities.

[mdebower]

I will throw my 2 cents in here too. My company migrated from a file based "system" to Windchill, and did exactly this, and it has caused a heck of a mess. Not so much with the files themselves, after all, Windchill will let you find them no matter where they are for the most part, but with team memberships, and different lifecycles between Products and Libraries and other things.

One of the unintended consequences is that the team membership for the library has mushroomed, and modification permissions had to be given to a much larger group than would otherwise be necessary. This leads to more mistakes and inconsistencies in the data.

Also if you use Change Management, who is going to be the change admins for a library that contains parts from different groups inside engineering? We have had to include 4-5 people in the change admin role because of this, when it should of only been one. This leads to extra emails and confusion and work.

Now I am trying to clean this up and can see that it will be a lot of work. I wish we had started out on the right path to begin with.

-marc
CAD / PLM Systems Manager