The system-defined WorkOrderStateMachineAutomatic cannot be extended, so adding a new state like “Aborted” or extra transitions is not supported.
As a wokraround, you can model the aborted concept outside of the system state machine. A common approach is to add a custom attribute (for example IsAborted with an optional AbortReason) or a custom enum/state machine (such as WorkOrderCustomStatus = Active / Aborted / …) on the WorkOrder. When an abort is required, you set this custom status and use it in your UI and logic (filters, button visibility, validations) to prevent further processing. If the platform or underlying system provides a cancel/abort API, you can call it via a microflow and then move the WorkOrder to the closest allowed terminal state (e.g. Cancelled or Closed). Otherwise, you can still reliably block downstream automation by checking the custom “aborted” flag in all relevant flows.