Managing PDM Checkout Objects
PDM checkout objects are a type of shared object.
Checking out an object from PDM to a project creates a project-specific version of the object.
Checking out a PDM object to a project is not a separate or unique action; you use the same Add to Project action as when creating a Shared object .
Project team members can edit the project-specific object version and later send it back to PDM.
You can check out a PDM object to several projects simultaneously.
* 
If an object has been checked out from PDM to multiple projects, it is possible to send only one version back to PDM.
The source object is locked in PDM until the project work is complete.
To unlock the source object, you can perform one of the following actions:
Undo PDM Checkout—Deletes all project-specific versions of the object and unlocks the source object in PDM.
Send to PDM—The project-specific version replaces the current PDM object version as a new iteration. The source object is either unlocked or checked out again depending on the selections you make in the Collect Objects and Set Options table.
* 
The PDM object folder location, team template, and life cycle template are unaffected by the project-specific version.
The following example illustrates a typical PDM checkout scenario:
1. A context manager uses the Add to Project action to check out a product object to a project.
The part is now available from the project folder and is locked in the product context. This allows users within the project to modify the object while avoiding conflicts with any work simultaneously performed in the PDM environment.
2. Once added to a project, individual project team members can check out and modify the project-specific version of the PDM object.
Parts, CAD documents, and dynamic documents can also be checked out and downloaded to an individual user workspace. From the workspace, you can launch the appropriate tools to modify the object.
3. When their work is complete, the project members check in the object to the project. Project work is not visible in the source product or library until the object is sent back to PDM.
4. When development work in the project is complete, a manager uses the Send to PDM action to replace the source version with the project version.
The part is unlocked in the product context and team members can now incorporate the revised part into their product work.
For a more detailed use case example using multiple design scenarios, see Use Case Example for PDM Checkout.
PDM Checkout State
Sent to PDM
The object was originally checked out from PDM and has been updated to include work performed in the project context. The latest version is shared back to the project.
Deprecated
At one point, the object was checked out to the project and at least one other project at the same time. Since then, the other project has used the Send to PDM action to update the source object.
Deprecated objects cannot be sent to PDM.
Project members can continue to check out and check in deprecated objects.
Deprecated objects still appear in the Folder Contents table of the project.
It is possible to add a deprecated object as a child of a new object or different PDM checkout object. However, when you send the parent to PDM, you cannot send the deprecated child. Instead, the deprecated child is replaced by the latest PDM version of its source.
If the deprecated object is associated with another project object, then that association is maintained. However, if you want to send the associated object to PDM, then you must first remove the association.
Abandoned
At one point, the object was in the Deprecated state. Since then, a user has performed the Convert to Share action on the object.
The latest version of the source PDM part is shared back to the project.
Project members can still view abandoned objects, but can no longer perform a checkout to modify the object.
Abandoned objects only appear in the Folder Contents table when the view is set to All - including hidden objects.
Was this helpful?