Transferring Realized Changes Between Change Actions

You may have one or more reasons to transfer realized changes from one change action to another. For example, you can transfer an object to a fast track change or you may want to independently reject the change. Realized changes that your transfer can be unconfigured objects (and their associated activities) or configured change-specific activities. For the purpose of the rules below, the 'original' and 'target' are, respectively, the change actions from which and to which you transfer a realized change.

Required Access Roles:

  • App-specific: The user who transfers a realized object must be either the owner or change coordinator for the original CA. The user must also be the owner of the target CA if the target is new. If the target is an existing CA, the user can be either the owner or the change coordinator.
Note: Before you can transfer realized changes, your administrator must turn off change-based collaboration.
Transferred realized changes or change activities remain listed in the original CA. The list indicates the CA to which each realized change was transferred and the reason for the transfer. Click the name of the target CA for additional information.
  • When you transfer a top-level realized object, its properties and status are also transferred.
  • If multiple operations reference the object, the status may show as a dependency in the target CA. For example, if a configured object is a realized change and the original CA (called CA1) has more than one activity (Create, Add Usage, etc.), you can transfer one of the activities to a target CA, such as CA2. After the transfer, CA1 and CA2 are dependent on one another.
  • If you transfer all realized changes, the original CA can be canceled or reused. The original CA will list the realized changes as transferred.
  • For unconfigured objects that are under strict change-required, a change action is shown. After the transfer, the objects remain under strict change-required and the target CA is shown.
  • The original and target change actions must be in either the 'Draft' or 'In Work' state (but are not required to be in the same state).
  • When one activity on an instance is transferred, all the activities of that instance under the parent are transferred.
  • Child components, whether configured or unconfigured, must be transferred with their parent for late release.
  • An unconfigured parent can be transferred for late release. Its children may be ready for release using the original CA and then consumed to build the product with the target CA. An unconfigured parent cannot be transferred for early release.
  • The parent and its activities for an unconfigured structure must be transferred together.
  • The configuration contexts of the original CA and of the target CA must match; otherwise, an error will occur.
  • Configured activities can be transferred for 'Early’ or 'Delayed' completion.
  • The activity for a configured structure can be transferred by itself as long as the transfer respects change stacking.
  • You need to be assigned the Change Management (CHG) license to transfer realized change objects or activities.

Before you begin: You need two change actions, one of which includes one or more realized changes to transfer.
  1. Open the CA that includes one or more realized changes to transfer.
  2. Select the Realized Changes tab.
  3. Select the Multi-Selection Mode command in the tab toolbar.
  4. In the Realized Changes list, select one or more:
    • Realized change objects. You can select a realized change if the change is unconfigured.
    • Activities under the Changes heading for the object. You can select only activities (not the realized change object) if the object is configured.
      Note: If you select an activity for an instance of an object, all activities for that instance are selected for transfer.
  5. In the Realized Change tab toolbar, select Transfer and select either of:
    • Transfer to New Change Action
    • Transfer to Existing Change Action
  6. Depending on your choice, either select an existing CA or create a new one.
  7. Enter a reason for the transfer:
    • Early Completion - This option requires that the target CA must be complete before the original CA.
    • Delayed Completion - This option requires that the target CA must be complete after the original CA.

    The transfer reason that you can select depends on the entity that you transfer:

    Transfer Entity Configured Objects Unconfigured Objects
    Root object Early or Delayed Delayed
    Child object Early Early
    Add Usage child Early or Delayed Not Applicable
    Note: The system creates a dependency between the target CA and original CA. Your selection determines which CA is dependent on the other.

  8. Complete the rest of the fields, and close the slide-in.

After the transfer, expand the activities list to see the transfer details.