軟件發布記錄是其它基于狀態的記錄類型的一個父記錄，它向發布經理提供了發布的一個全局的視圖，但是我確信，你正在問自己，怎樣管理一個詳細視圖呢?
更深入一步進入過程，我們可以產生兩個額外的基于狀態的記錄類型，事件(Incident) 和工作請求(Work Request)記錄。
事件記錄類型可被規類為缺陷、問題、風險、變更請求等等，由于這些不同的分類，事件記錄類型有一個相當復雜的狀態轉換矩陣：
.jpg)
圖4. 事件記錄
事件記錄類型獲取描述信息、標題(一個簡短描述)、所有人名稱、優先級、嚴重度，以及相關軟件發布記錄、相關事件記錄和相關工作請求。
當一個事件記錄進入了 Slotted 狀態，那么它一定跟軟件發布記錄是相關聯的。
經常從用戶那里聽到的一個抱怨是，他們什么時候需要重新創建一個記錄，因為把當前記錄拷貝和粘貼到新的記錄上是十分單調乏味的工作，雖然工作很簡單但是很可能出錯，比如粘貼一個值到一個錯誤的字段或者忘記將值從原始記錄拷貝到新的記錄。解決這個問題的辦法是給用戶一個不用拷貝和粘貼可以克隆記錄的方法。這樣不僅創建了一個記錄，并用來自原始記錄的數據在板上進行組裝，同時還在兩個記錄之間創建了一個鏈接。這個克隆記錄的代碼可以通過下面參考資源部分中 Shmuel Bashan 的 developerWorks 文章中得到。
developerWorks 上的代碼必須分散到不同腳本中與各種事件類型一起操作。第一個腳本 clone_record.zip)是確定用戶想要克隆的事件記錄類型，它然后將執行適當的附加腳本來克隆這個記錄。
使用 ClearCase/UCM/ClearQuest 實現集成的一個局限性是一個記錄只能分配到一個項目/流程/視圖，并且一次只能一個人對它進行操作。然而，很可能有同時有好幾個人操作一個變更或者他們可能在世界的不同地方，在不同的工作流程中對同一個變更進行操作。
為了克服這種局限性，你可以執行工作請求記錄類型。工作請求記錄類型是一個可以運用統一變更管理(UCM)包的基于狀態的記錄類型。
這個工作請求記錄的創建必須來自于事件記錄內部，因為許多數據元素是直接從事件記錄拷貝到這個工作請求記錄的，并且這兩個記錄后來是相互連接的。這個工作請求記錄幾乎是可任意使用的，它內部有一個非常短的生命周期，因為用戶不需要輸入很多數據，這個工作請求可以很容易地被創建、分配、繼續操作，然后關閉。一旦開發者完成了編碼變更，通過了代碼評審，單元測試變更的記錄將結束。它將提醒事件管理者，這個記錄即將進入下一個狀態。
