T38.2: Auxiliary Tools and Transitions

Overview

The reassign transition allows CCR ownership to be transferred from one person to another. This is an essential operational tool because team members change roles, go on leave, or workload rebalancing may be needed. Unlike most transitions that move a CCR through workflow states, reassign returns the CCR to its current state after changing the owner.

Reassigning the Owner

To reassign a CCR to a different owner within the same responsible organization: 1. Click the "reassign" link at the top of the CCR (visible alongside help, merge, clone, changeSpec, and cancel links) 2. The Perform Transition reassign dialog appears, showing the current state and a return to that state 3. Select the new Owner from the drop-down list, which shows all users in the responsible organization 4. Use the "Assign to Me" link to quickly select yourself as the new owner 5. Optionally add Transition Notes to explain why the reassignment is happening 6. Click the "reassign" button to complete the transition

Reassigning the Responsible Organization

InterSystems employees have additional capability through Advanced Reassign:

• Click "Advanced Reassign" in the reassign dialog to change the Responsible Organization field from a text display to a drop-down menu
• Select a new Responsible Organization from the drop-down
• Select a new owner from that organization
• This is useful when a CCR was initially created under the wrong organization or when responsibility shifts between organizations

Key Rules

• Any user from the current responsible organization can reassign a CCR at any time -- it is not restricted to the current owner
• The new owner must be someone within the same responsible organization (unless using Advanced Reassign)
• Only InterSystems employees can change the responsible organization via Advanced Reassign

---

Peer Review Routing Rules

When a CCR transitions into a peer review state, the system determines the default value for the Next Peer Reviewer field by evaluating a set of rules in order: 1. Route to the primary architect for that ResponsibleOrg + System combination, if one is assigned 2. Route to the secondary architect for that ResponsibleOrg + System, if the CCR was authored by the primary architect AND a secondary architect is assigned 3. Route to the default peer reviewer for that user, if one is configured on the User Details page 4. Route to the user's manager (only for InterSystems employees) 5. Remains with the user who transitioned the CCR into the XXXX_Pending_Peer_Review state (this user still cannot passPeerReview their own CCR)

The owner can always change the default value to anyone else from the Responsible Organization before confirming the transition.

System Architects

Systems can have users designated as architects. There are two kinds:

• Primary Architect: Acts as the default peer reviewer for all CCRs owned by their organization for that System. Configured on the System Details page under Architect Controls.
• Secondary Architect: Peer reviews all CCRs that the primary architect transitions to XXXX_Pending_Peer_Review state. This ensures the primary architect's own work also receives peer review.

Architects receive highlight email notifications for all CCRs (e.g., when CCRs are opened, moved to a new phase, or closed). Architects receive all peer reviews by default and can disable remaining peer reviews in two ways: by editing the CCR Details Pane, or by checking "Bypass Remaining Peer Reviews" during the passPeerReview transition.

Default Peer Reviewer per User

To configure a default peer reviewer for a specific user: 1. Navigate to Menu > Users 2. Select the organization 3. Select the user 4. Set the "Default Peer Reviewer" field to the desired reviewer 5. Click Save

This is particularly useful when multiple teams work on the same System and architects cannot be configured per team (only per responsible organization for a system). Setting default peer reviewers per user allows team-level routing.

Peer Review Workflow Strategies

Different strategies can be applied depending on the project phase:

• Standard peer review (default): Every CCR is peer reviewed in every environment. Provides the most thorough coverage with no configuration required.
• Architect with peer review bypass: CCRs are routed to the architect for all reviews. The architect can "Bypass Remaining Peer Reviews" at any time, even when not in a peer review state. Useful for shortening the workflow for low-risk CCRs after the initial review passes.
• BASE-Only peer review: Only the BASE environment requires peer review. Configured by selecting "Peer Review BASE Only" under System Advanced Controls. Useful during mid-phase of new projects to get a second set of eyes before production.
• No peer review: All peer reviews are bypassed. Configured by selecting "Bypass Peer Reviews" under System Advanced Controls. Should only be used during early BASE-only phase when speed is critical and a broken change will not put anything at risk. Once other environments are introduced, peer review should be re-enabled.

Peer Review Models

Different models provide different benefits when configuring default peer reviewers:

• Peer programming: Two experienced colleagues assigned as each other's default peer reviewer; useful for cross-training
• Mentor/mentee: A senior person as default reviewer of a junior person and vice versa; allows the senior to instruct and the junior to learn from the senior's work
• Round robin: Colleagues assigned in a cycle where each reviews and is reviewed by a different person; promotes broader collaboration within a team
• Hub and spoke: A central person assigned as default peer reviewer for all teammates; useful when multiple teams work on a System and a single primary architect will not suffice
• Different reviewers per phase: Multiple people verify change and documentation across environments; reduces mistakes and increases cross-training (no CCR configuration tools to fully automate this option)

Peer Review Documents

Peer Review Checklist Documents can be configured to display during the passPeerReview transition:

• Documents describe best practices for completing peer review (for reference only; no interactive checkboxes)
• Collapsed by default in the transition dialog
• The default checklist for the user is autoselected, but other documents can be selected
• Created via Menu > Peer Review Docs > Add New Document
• One organization can have multiple peer review documents (e.g., separate documents for technical vs. application reviews)
• Default documents can be set at three levels with this order of precedence: User > System > Organization

---

What Merge Does

Merging CCRs combines two or more changes into a single change. When you merge two CCRs, the system will:

• Append all fields from the source (aka "Merged From") CCR to the target (aka "Merged To") CCR
• Associate items in Perforce for the source CCR with the target CCR
• Create pointers between the source and target CCRs for traceability
• Transition the source CCR to a terminal "Merged" state in the MERGED phase

How to Perform a Merge

The "merge" link is available at the top of every active CCR, alongside help, clone, reassign, changeSpec, and cancel. To perform a merge: 1. Open the source CCR (the one to be merged into another) 2. Click the "merge" link 3. Specify the target CCR number 4. Confirm the merge operation

Merge Requirements

A CCR can only be merged into another CCR if:

• Both CCRs are in the same state -- so neither CCR skips a state in the workflow
• Both CCRs are against the same System -- to keep Perforce items in the same branch
• Both CCRs are for the same organization -- this is implied by being on the same System

Note that both CCRs do NOT need to have the same owner or be in the same CCR Tier.

Interpreting Merge Results

After a successful merge:

• The source CCR shows a "Merged" status and is in the MERGED phase, which is a terminal endpoint
• The target CCR now contains the combined content from both CCRs
• The source CCR retains a pointer to the target CCR for audit and traceability purposes
• The target CCR continues through its normal workflow with the consolidated changes

Critical Warning

Merging CCRs is a non-reversible action. Even InterSystems Support cannot "unmerge" CCRs to return them to their original state. Always verify the correct source and target CCRs before performing a merge.

---

When to Cancel a CCR

The cancel transition is used when a change is no longer needed and should be permanently removed from the workflow. Important guidelines:

• Never use cancel to resolve CCR progression errors -- use markIntegrationFailed or markValidationFailed instead
• Always cancel CCRs that are no longer needed, regardless of what phase they are in
• Even if changes were only made in the BASE environment, fully back out the changes before cancelling
• Abandoned CCRs (left active but not progressed) will cause problems over time

Cancel Workflow

The cancel transition initiates a two-step workflow within the CANCELLED phase:

Step 1 -- Cancel transition:

• Clicking "cancel" moves the CCR to the Backing_Out state in the CANCELLED phase
• During this state, the team must completely back out the change from all environments according to the backout plan
• All code changes, configuration changes, and other modifications must be reverted

Step 2 -- markCANCELComplete transition:

• Once the backout plan has been fully executed and all changes have been removed from all environments, perform the markCANCELComplete transition
• This moves the CCR to the Cancelled state, which is a terminal endpoint
• The Cancelled state makes clear that all changes have been successfully backed out

Interpreting Cancel Results

After completing the full cancel workflow:

• The CCR shows a status of "Cancelled" in the CANCELLED phase
• This is a terminal state -- the CCR cannot be reopened or progressed further
• The CCR history retains a full audit trail of all transitions including the cancel and markCANCELComplete
• If the change is needed again in the future, a new CCR must be created (or a clone of the original can be used as a starting point)

Important Considerations

• Cancel is available at any point in the CCR lifecycle, not just past the BASE phase
• Always follow the backout plan thoroughly during the Backing_Out state before marking the cancel as complete
• The cancel transition is available from the links at the top of every active CCR

---