When alerts and actions are exported their secrets and API keys are intentionally excluded from the export. As such, when these saved-objects are imported, it will require additional effort from the end-user to make these alerts and actions active. The end-user will be warned of this additional requirement per #84977, but we'd like to perform additional logic on export so that these alerts and actions are explicitly marked as disabled. Performing this custom logic on export is safer than doing so on import, because if it fails on import the user will potentially only have some of their saved-objects persisted.
This will also allow us to work-around some of the limitations incurred from using saved-object references to model a composition relationship as originally discussed in #82064. For example, when a case is export we'd like to use the custom logic hook to automatically include the related comments, etc.
When alerts and actions are exported their secrets and API keys are intentionally excluded from the export. As such, when these saved-objects are imported, it will require additional effort from the end-user to make these alerts and actions active. The end-user will be warned of this additional requirement per #84977, but we'd like to perform additional logic on export so that these alerts and actions are explicitly marked as disabled. Performing this custom logic on export is safer than doing so on import, because if it fails on import the user will potentially only have some of their saved-objects persisted.
This will also allow us to work-around some of the limitations incurred from using saved-object references to model a composition relationship as originally discussed in #82064. For example, when a case is export we'd like to use the custom logic hook to automatically include the related comments, etc.