## Summary Converting a work item to a type that does not include the `custom_fields` widget (e.g. using the `/convert_to_ticket` quick action, or `/type` targeting a type without custom fields) raises an internal server error and the conversion fails. ## Root cause When `WorkItems::UpdateService` processes a type change, `WidgetableService#initialize_callbacks!` iterates all widgets currently on the work item. For any widget not supported by the new type, it stamps `excluded_in_new_type: true` onto the callback params: ```ruby callback_params[:excluded_in_new_type] = true if new_type_excludes_widget?(widget, work_item.resource_parent) ``` This makes `callback_params` non-blank, so the guard that would skip the callback is bypassed and the callback is instantiated with `params = { excluded_in_new_type: true }`. `WorkItems::Callbacks::CustomFields#after_save` then immediately calls: ```ruby params.pluck(:custom_field_id) ``` `params` is a Hash, not the Array of field hashes the callback expects. ActiveSupport's `Enumerable#pluck` iterates the hash key-value pairs and tries to index each with `:custom_field_id` as if it were an integer position, raising: ``` Internal server error: no implicit conversion of Symbol into Integer ``` ## Why it only affects CustomFields Every other callback that can be excluded during a type change (weight, iteration, health_status, color, status, etc.) already guards against this with: ```ruby return if excluded_in_new_type? ``` `CustomFields#after_save` was missing this guard. ## Affected scenario The most direct trigger is `/convert_to_ticket` — the ticket type does not include `custom_fields` in its widget list. The same crash would occur for any type change where the source type has custom fields and the target type does not. ## Fix Add the standard `excluded_in_new_type?` early return to `CustomFields#after_save`. One line, consistent with the established pattern across all other callbacks. MR: (link MR)