Activated "Change Management - Standard Change Catalog" plugin and custom Change workflows brokeDescription<!-- div.margin{ padding: 10px 40px 40px 30px; } table.tocTable{ border: 1px solid; border-color:#E0E0E0; background-color: rgb(245, 245, 245); padding-top: .6em; padding-bottom: .6em; padding-left: .9em; padding-right: .6em; } table.noteTable{ border:1px solid; border-color:#E0E0E0; background-color: rgb(245, 245, 245); width: 100%; border-spacing:2; } table.internaltable { white-space:nowrap; text-align:left; border-width: 1px; border-collapse: collapse; font-size:14px; width: 85%; } table.internaltable th { border-width: 1px; padding: 5px; border-style: solid; border-color: rgb(245, 245, 245); background-color: rgb(245, 245, 245); } table.internaltable td { border-width: 1px; padding: 5px; border-style: solid; border-color: #E0E0E0; color: #000000; } .title { color: #D1232B; font-weight:normal; font-size:28px; } h1{ color: #D1232B; font-weight:normal; font-size:21px; margin-bottom:-5px } h2{ color: #646464; font-weight:bold; font-size:18px; } h3{ color: #000000; font-weight:BOLD; font-size:16px; text-decoration:underline; } h4{ color: #646464; font-weight:BOLD; font-size:15px; text-decoration:; } h5{ color: #000000; font-weight:BOLD; font-size:13px; text-decoration:; } h6{ color: #000000; font-weight:BOLD; font-size:14px; text-decoration:; } ul{ list-style: disc outside none; margin-left: 0; } li { padding-left: 1em; } --> Symptoms After activating the "Change Management - Standard Change Catalog" plugin (com.snc.change_management.standard_change_catalog), custom Change workflows are no longer working as expected Release Jakarta Patch 9c Cause When the above plugin was activated, the "Change Management - Core" plugin was also activated, which added three new Change types to the user's system (other than their previously utilized custom types).Now, there are identically named entries for two of the three Change types (two "Standard" and two "Normal" sys_choice records, all of which are active = true). Resolution After a thorough investigation, no issue was found with the design or functionality of the user's custom "Standard Change" workflow.In fact, a workflow successfully attaches to a Change Request when either the non-current/non-OOB "Standard" Change type or the current OOB "Standard" Change type is used.The only time an issue arises is when both "Standard" sys_choice Change types are active = true. This is the when the unexpected behavior is experienced.When one or the other is deactivated, there is no issue. The user just needs to be sure that the desired active = true sys_choice Change type is the same as selected in the relevant Workflow's conditions.