Revision History
| Rev # | Date | Description |
|---|---|---|
| 1.0 | Jan 2022 | Document created. |
| 1.1 | Nov 2024 | Document updated and validated for 3DEXPERIENCE 2024X FD04 |
Note
All SolidPractices are written as guidelines. It is a strong recommendation to use these documents only after properly evaluating your requirements. Distribution of this document is limited to Dassault Systèmes SolidWorks employees, VARs, and customers that are on active subscription. You may not post this document on blogs or any internal or external forums without prior written authorization from Dassault Systèmes SolidWorks Corporation.
This document was updated using 3DEXPERIENCE 2024X FD04. If you have questions or need assistance in understanding the content, please get in touch with your designated reseller.
Acknowledgments
This document was authored by GoEngineer and reviewed by Dassault Systèmes SolidWorks Corporation.
Preface:
The 3DEXPERIENCE platform Change Action (CA) manages revisions when an Engineer, or a SOLIDWORKS Designer, makes a change or releases a part, assembly, drawing or supporting documentation.
When you use a change action to revise a design, you increment the revision level of each object along with its modified components and documentation. The Change Execution widget shows all the realized changes for that change action.
A Change Action formally records all modifications made to an object. Its automation enforces an approval workflow, ensuring that the Change Action adheres to the organization’s established approval process. The automation can generate a new revision (when applicable), and once approved, the Change Action’s automation promotes the object(s) to the Released Maturity State. A Change Action provides a clear record of who requested, implemented, and approved the changes. This enhances traceability and minimizes the risk of non-compliance during the change process.
Your Feedback Requested
We would like to hear your feedback and suggestions for new topics. After reviewing this document, please take a few minutes to complete a brief survey. Your feedback helps us create the content that directly addresses your challenges.
Revisions in 3DEXPERIENCE
- Understanding What Revisions Are in the 3DEXPERIENCE Platform
Differences between a revision and a version
The 3DEXPERIENCE platform requires you to select the Revise command when you want an additional iteration of your content. When saving to 3DEXPERIENCE, it overwrites the current In-Work Revision. It does not create a new version on each 3DEXPERIENCE save.
Options for Revisions
3DEXPERIENCE platform out of the box has two revision options each with a second variant. The primary can be either Numeric or Alpha. If you require the Numeric option, you can start at 1 or 0. If you select the Alpha option, you can have straight alpha that is, A, B, C.. Or you can begin with -, A, B, C and this scheme also skips I, O, Q, S. X, and Z.
The standard Revision increments following a release of a document, part or file. The item typically begins in an In Work state, promotes to Frozen and then promotes to Released. Settings within the Permission Rules control when you can create new revisions and at what lifecycle.
Select the Revision Scheme in the Lifecycle And Collaboration Configuration. There are three revision behaviors:
- Primary
- Primary and secondary
- Primary and secondary for 3DEXPERIENCE content with SOLIDWORKS master
Primary
This revision format only shows the primary revision. For example, A, B, C.
The primary revision increments every time you create a revision, independent from the maturity state of the object.
This is the recommended Revision scheme.
Primary and secondary
In this revision format, a secondary revision displays after the primary revision in the [REVISION.#] format.
The primary revision increments every time you create a revision from the Released content. The secondary revision resets to 1. This identifies major changes.
The secondary revision increments every time you create a revision from non-Released content.
For example, the names of the new revisions of In-Work or Frozen maturity states are A.1, A.2, A.3, until Released. A revision of the Released content named B.1 follows the same revision naming rules.
Primary and secondary for 3DEXPERIENCE content with SOLIDWORKS master
In this revision format, a secondary revision displays after the primary revision before the minor revision [REVISION _#.# ]. The behavior of the primary and secondary in this scheme is similar to the primary and secondary format.
When you enable either the primary or secondary revision options and you promote a revision after revising it, you create the next revision from the latest revision. The case illustrated below results in an incremented secondary revision instead of an incremented primary revision.
3DEXPERIENCE Release Lifecycle
Using Bookmarks with Change Actions
There are advantages when you use bookmarks with a CA. If there is a group of objects that you must add to a CA, you can drag them from a bookmark to the CA.
Collaborative Space Access Rules
Collaborative Spaces allow users to perform actions within each space based on their given role. Roles dictate what each user can do inside the collaborative space. This section outlines the role relationship with Change Actions.
The two main roles available in a Collaborative Space are:
- Author
- Leader
The Author role allows a user to author new content and change the maturity state of an object. The Leader role allows a user to do everything an Author can and release objects.
When using change actions, you must have the Leader role in the collaborative space from which you created the change action in order to complete the CA. If you do not have the Leader role, you cannot complete a CA. Authors can move the CA to In Approval but cannot fully complete the CA.
What is a Change Action?
A Change Action (CA) is the formal documentation authorizing the release of changes made to objects within 3DEXPERIENCE. You can generate Change Actions (CAs) from Change Requests, Change Orders and Issues or as a stand-alone Change Action. Anyone assigned the Collaborative Industry Innovator Role can create Change Actions while the Change Manager role can create a Change Request and Change Order.
Why Use Change Actions?
Change actions can involve many different processes and systems to complete. The process to complete a change action outside of the 3DEXPERIENCE platform is manual. This is true whether you do it through email, network folders, phone calls, multiple systems or a combination of those methods. There is room for error and little visibility to those involved or affected making it a very cumbersome and unreliable process in most environments. The 3DEXPERIENCE platform allows for all facets of the change action to take place in one single platform with ultimate visibility and flexibility.
Using change actions within the 3DEXPERIENCE platform allows all members of the change action to:
- Collaborate.
- Make changes in a single environment.
- Store data in a single environment.
- Use an automated process with approvals to complete the lifecycle of a change action to an object.
Using the Change Action Process in the 3DEXPERIENCE platform ensures traceability. The change action maintains all signatures, documents and metadata about the documents surrounding the change and is the authority to release the content.
Creating a Change Action
Change actions (CA) have a variety of origins depending on an individual’s role and the purpose of the CA.
Creating a Stand-Alone Change Action Using the Change Execution Widget
Use the Change Execution widget to create a stand-alone CA.
An Approver typically is someone different from the Assignee and is one or more individuals who are responsible to approve the changes defined in the CA. To complete the CA, one of the listed approvers must have a Leader Role in the Collaborative Space that the CA resides in.
An Informed User is the person to notify when the CA completes. The user can select how you notify them. An Informed User does not have an active role in the completion of the CA. This user is only listed for notification purposes.
When you create a Change Action, attach a Proposed Change to the CA. The Proposed Change tab lists the objects for the CA. The Proposed object tab can contain the component or document to change as well as documentation directing what to change or create.
When adding objects to the Proposed Change tab, the Operation selection prompts you for Revision, New Branch or Modify. In the Activity selection, your options are: No Activity, Modify or Change Maturity to Release.
The Operation field is what you are trying to accomplish in the CA. The Activity field is how the CA affects the object listed in the Proposed Change tab as the CA processes.
The Operation attributes Revision and New Branch are specific attributes within an object. If you choose the Modify Operation, you most likely change the design of the object. The Operation attribute just describes what the user wants to do with the CA and the Proposed Change object. The Operation attribute does not indicate what to do; it is only a data point.
After you choose the Operation attribute, choose your Activity. The Activity attribute is the actual Activity that happens to the Operation you select. If you make changes to the object but do not want any activity to occur on the object, select No Activity. If you want to modify the object, select Modify. Below are the numerous options and their results of each combination selected.
Operation: Revision
Activity: No Activity
Result: The CA creates and completes, but the Proposed Object does not change.
Operation: Revision
Activity: Change Maturity to: Obsolete
Result: Not selectable because a Revision cannot have a maturity state change.
Operation: Revision
Activity: Modify
Result: The CA creates and a new Revision creates and automatically releases for the Proposed Object.
Operation: New Branch
Activity: No Activity
Result: The CA creates and completes but the Proposed Object does not change.
Operation: New Branch
Activity: Change Maturity to: Obsolete
Result: Not selectable because a New Branch cannot have a maturity state change.
Operation: New Branch
Activity: Modify
Result: The CA creates and completes with a Branch change.
Operation: Modify
Activity: No Activity
Results: The CA creates and completes but the Proposed Object does not change.
Operation: Modify
Activity: Modify
Results: The CA creates and completes with a change to the Proposed Object.
Operation: Modify
Activity: Change Maturity to: Obsolete
Results: The CA creates and the maturity state of the Proposed Object changes.
Change actions can contain one or many proposed changes.
Processing a Change Action
Objects in the Realized Changes must be in a Frozen state to promote the CA to In Approval. If the object is not in a Frozen state, ensure that you put it into a Frozen state to be able to move forward with the CA lifecycle.
When a CA is in the In Work state, the Assignee can work under the CA on the tasks needed to complete the proposed change. After you complete all tasks for the change, the Assignee promotes the CA to the In Approval state.
Creating Change Actions from Issues
You create Change Actions for several different reasons and uses. If you create an Issue within the platform, each Issue can have Change Actions created within it to resolve an Issue.
When you are within an Issue, you can select the Change Action icon from the Issue Management widget.
When you create the CA from the Issue, the Members, Name and Description of the Issue all transfer to the CA. In addition, the Reported Against object also transfers to the CA as the Proposed Change. Make sure that the appropriate members are in the original Issue and the appropriate objects are in the Reported Against attribute. This ensures that all required information transfers to the new Change Action.
From there, follow the normal process as a stand-alone change action and proceed with closing out the CA.
When you create a change action from an Issue, you have the option to save the Change Action as Draft. Then you can access the Change Action from the Change Execution widget.
Creating New Revisions
When you have a released object and want to create a new revision for that object, you can do so using the Change Action Object.
- After you create a Change Action, you start it in a Draft state. This allows you to add appropriate Members and Proposed Changes.
After the Author or Owner of the change action reviews and confirms all proposed changes, go to the Members tab. Add the appropriate members to the CA, so there is an Assignee and an Approver.
After the Assignee finishes their work on the object, they must change the maturity state of the Realized Change object to Frozen. There are two options to change the maturity state of the Realized Change.
The first option is to access the Collaborative Lifecycle tools from within SOLIDWORKS (outlined in the Working Under a Change Action section).
The second option is to open the Collaborative Lifecycle widget while in the web. Search for the Realized Change object. When you promote the maturity state, verify that the object you selected is in the In Work state and is the correct revision. In both cases, you must have the Work Under active on the appropriate CA.
Working under a Change Action
Creating a CA from within SOLIDWORKS
From SOLIDWORKS, you can use the right pane window to create a Change Action, within the Change Execution widget, to capture part, assembly or drawing creation or modification. You did the same process in the Web Client.
Before working under the CA, you must promote the maturity state from Draft to In Work.
The user can work under a change action regardless of whether there is a Proposed Change within the CA or not.
After the object within the CA moves to a Frozen state, the CA populates a Realized Change. The realized change object modifies or changes maturity states (whatever you chose for the operation when you created the CA), after the CA is processed to the Complete state.
Transferring Realized Changes
If you have other licensing (Change Management option), you can transfer Realized Changes to another CA for an early or delayed release or you can cancel a particular change.
Best Practices When Using Change Actions
Refresh Change Execution often
A Change Action’s automation requires indexing to update the object’s revision, Maturity State and/or Change Required status. Displaying the updated information is not instantaneous as the warning message indicates. Refresh the Change Execution app several times to view the indexed data.
To prevent errors in the approval stage, ensure all the objects in Realized Changes are in the Frozen Maturity State.
NOTE: If the administrator enables the Change Action Auto Freeze functionality, an object will automatically be set to Frozen once the Change Action is promoted to In Approval, provided the Change Action has one or fewer Assignees.
Use Change Assessment
Using the Change Assessment command when adding components to the Proposed Changes Tab identifies other related objects that may be impacted by the change. The affected items can be added to the Proposed Changes Tab, ensuring they are included in the Change Action. This will provide insight into the other objects that will be affected, helping to reduce errors by enabling a thorough assessment of the impact across related components.
Demote the Change Action to In Work
If an error does occur while approving a Change Action, for instance, if child components are not in the target maturity state, the Approval Task and Change Action will still complete despite the error. To resolve this, demote the Change Action to In Work, promote the child components to Frozen, and then set the Change Action back to In Approval. A new Approval Route will be generated, allowing the Change Action to proceed as usual.
Turn off the Work Under
Ensure that you turn off the work under immediately following the final step of the change action process. This prevents adding any unrelated objects to the realized changes on the CA.
Ignore and Move Objects from a Change Action
There may be circumstances where you’ve inadvertently added objects to a Change Action. For traceability, you cannot delete or remove objects from Realized Changes. You have the option to Move or Ignore the object in Realized Changes.
If the modifications resolve a different problem, the object can be Moved to another Change Action. The Move operation will relocate the object from Realized Changes to another (existing or create new) Change Action’s Realized Changes Tab.
If the object is unrelated to the Change Action, or if you want to keep certain objects unchanged while implementing modifications to others, an object can be Ignored. The Ignore operation will exclude the object from Realized Changes and the object will not be acted upon by the Change Action’s automation.
With both the Move and Ignore operations, the objects are not removed from the Change Action, they are essentially hidden in the Tracked view. The objects can be viewed in the Ignored or Moved view, depending on the operation.
When a Change Action is approved, the Change Action’s automation is launched, and the Change Action completes. If changes are rejected, it indicates the modifications are unsatisfactory, however the Change Action is still warranted and remains active. In cases where a Change Action is no longer warranted, for instance, if the approver deems the modifications are too costly to implement, the Change Action can be Canceled to end the process.
Turn ON/OFF Change Required as needed
When an object is added to the Realized Changes Tab or is Released through a Change Action, it acquires the Change Required status. Change Required means that any revisions or lifecycle changes to the object must now occur through a Change Action. This ensures that all modifications, reviews, and approvals are tracked systematically as part of the change management process.
The Change Required setting can be turned ON proactively, manually enabled, to ensure changes to an object are captured, tracked and documented through a Change Action.
Leaders in the Collaborative Space can turn OFF the Change Required setting, allowing the object to be modified and progressed through its lifecycle without needing a Change Action.
The Change Required setting is located in the Change Tab within the object’s Information Panel. The Change Tab also displays the related Change Action(s) and the change history for traceability. This provides a clear record of the Change Action, who approved, when, and any comments, capturing all activity for accountability throughout the change process.
