[One Workflow] Add alertStates backend support for workflow connector#257363
Merged
talboren merged 2 commits intoelastic:mainfrom Mar 18, 2026
Merged
[One Workflow] Add alertStates backend support for workflow connector#257363talboren merged 2 commits intoelastic:mainfrom
talboren merged 2 commits intoelastic:mainfrom
Conversation
Add backend-only support for configuring which alert states (new, ongoing, recovered) trigger workflow execution. This is the first part of an intermediate release strategy — schema and adapter changes land first, UI follows in a subsequent PR. - Add AlertStates interface and optional alertStates to types/schema - Add resolveAlertStates helper with backward-compatible defaults (new: true, ongoing: false, recovered: false) - Filter alert groups by resolved states in buildActionParams - Merge new/ongoing/recovered alert arrays into flat event.alerts - Schema uses optional booleans with no defaults (safe for rollback) Supersedes elastic#256289 (closed) which included both backend and UI changes. Closes elastic/security-team#16239 Made-with: Cursor
talboren
added
release_note:skip
pmuellr
reviewed
Mar 17, 2026
| }): AlertEvent { | ||
| return { | ||
| alerts: params.alerts.new.data, | ||
| alerts: [ |
Contributor
There was a problem hiding this comment.
I'm surprised these are being collapsed into a single collection alerts, instead of keeping them in different collections. These are passed to the workflow? I guess there's likely enough info in the alert data itself to determine if it's new/ongoing/recovered, but since we already have them partitioned that way, not clear why we are sending them that way.
Contributor
Author
There was a problem hiding this comment.
@pmuellr this is the pattern workflows work by as of today (events.alerts) - without a clear distinguish between the state (we didn't have anything else besides the new alerts up until now :)).
We don't want to make people migrate the workflows (and we don't have anything automatic for that now), and as you said, the pattern currently works for people and there's a great way they can get the state of the alert from the alert itself.
pmuellr
approved these changes
Mar 18, 2026
Contributor
pmuellr
left a comment
pmuellr
left a comment
There was a problem hiding this comment.
ResponseOps changes LGTM
qn895
pushed a commit
to qn895/kibana
that referenced
this pull request
Mar 18, 2026
…elastic#257363) ## Summary Adds backend-only support for configuring which alert states (`new`, `ongoing`, `recovered`) trigger workflow execution. This is the **first part of an intermediate release strategy** — schema and adapter changes land first, with the UI to follow in a subsequent PR. - Adds `AlertStates` interface and optional `alertStates` field to the workflows connector types and schema (Zod + config-schema) - Adds `resolveAlertStates()` helper with backward-compatible defaults (`new: true, ongoing: false, recovered: false`) — existing rules continue to work without migration - Filters alert groups by resolved states in `buildActionParams` before building the alert event - Updates `buildAlertEvent` to merge `new`/`ongoing`/`recovered` alert arrays into a flat `event.alerts` array (preserves Liquid template compatibility) - Schema fields are optional with no defaults, ensuring safe rollbacks during serverless rolling upgrades **Why backend-only?** Per the intermediate release pattern for serverless, schema changes must land and be deployed before the UI that writes those fields. This ensures older nodes can validate objects during rolling upgrades and rollbacks. Supersedes elastic#256289 (closed), which included both backend and UI changes. The UI portion (alert state checkbox group in the rule action form) will follow in a separate PR. ### PR review feedback addressed from elastic#256289: - Removed index signature from `AlertStates` interface for stricter type safety - Made `AlertStatesSchema` strict (`.strict()`) to reject unknown keys - Extracted `resolveAlertStates()` helper to avoid duplicated default logic ## References Closes elastic/security-team#16239 Made with [Cursor](https://cursor.com)
jeramysoucy
pushed a commit
to jeramysoucy/kibana
that referenced
this pull request
Mar 26, 2026
…elastic#257363) ## Summary Adds backend-only support for configuring which alert states (`new`, `ongoing`, `recovered`) trigger workflow execution. This is the **first part of an intermediate release strategy** — schema and adapter changes land first, with the UI to follow in a subsequent PR. - Adds `AlertStates` interface and optional `alertStates` field to the workflows connector types and schema (Zod + config-schema) - Adds `resolveAlertStates()` helper with backward-compatible defaults (`new: true, ongoing: false, recovered: false`) — existing rules continue to work without migration - Filters alert groups by resolved states in `buildActionParams` before building the alert event - Updates `buildAlertEvent` to merge `new`/`ongoing`/`recovered` alert arrays into a flat `event.alerts` array (preserves Liquid template compatibility) - Schema fields are optional with no defaults, ensuring safe rollbacks during serverless rolling upgrades **Why backend-only?** Per the intermediate release pattern for serverless, schema changes must land and be deployed before the UI that writes those fields. This ensures older nodes can validate objects during rolling upgrades and rollbacks. Supersedes elastic#256289 (closed), which included both backend and UI changes. The UI portion (alert state checkbox group in the rule action form) will follow in a separate PR. ### PR review feedback addressed from elastic#256289: - Removed index signature from `AlertStates` interface for stricter type safety - Made `AlertStatesSchema` strict (`.strict()`) to reject unknown keys - Extracted `resolveAlertStates()` helper to avoid duplicated default logic ## References Closes elastic/security-team#16239 Made with [Cursor](https://cursor.com)
talboren
added a commit
to talboren/kibana
that referenced
this pull request
Mar 26, 2026
Add the UI portion of the alertStates feature — a "Run workflow for" checkbox group (New / Ongoing / Recovered alerts) in the rule action form, between the workflow selector and the action frequency switch. This is the second part of the intermediate release for elastic#257363: - Part 1 (merged): backend schema + adapter logic (elastic#257363) - Part 2 (this PR): UI to set alertStates on rule actions - Add AlertStates type and alertStates? to public WorkflowsActionParams - Render EuiCheckboxGroup with New/Ongoing/Recovered options - Use single editAction call in useEffect for initialization (addresses Copilot review feedback from elastic#256289) - Use "New alerts" terminology (not "Firing") per review feedback - Add 6 new tests for checkbox rendering, defaults, and toggling Closes elastic/security-team#16239 Made-with: Cursor
talboren
added a commit
that referenced
this pull request
Apr 14, 2026
…59770) ## Summary Adds a "Run workflow for" checkbox group (New / Ongoing / Recovered alerts) to the workflow connector rule action form, allowing users to configure which alert states trigger workflow execution. This is the **second part of the intermediate release** for alertStates support: - **Part 1 (merged):** Backend schema + adapter logic — #257363 - **Part 2 (this PR):** UI to set `alertStates` on rule actions ### Changes - Adds `AlertStates` type and optional `alertStates` to public `WorkflowsActionParams` - Renders `EuiCheckboxGroup` with **New alerts** / **Ongoing alerts** / **Recovered alerts** options between the workflow selector and the action frequency switch - Uses a single `editAction` call in `useEffect` for initializing both `summaryMode` and `alertStates` defaults (addresses [Copilot review feedback](#256289 (comment)) from #256289) - Defaults to `{ new: true, ongoing: false, recovered: false }` — existing rules continue to work without migration - Uses "New alerts" terminology (not "Firing") per [review feedback](#256289 (comment)) from @pmuellr ### Background The original PR #256289 included both backend and UI changes but was closed to follow the [intermediate release pattern](https://docs.elastic.dev/reops/developer-guide/best-practices-rules#upgrades-and-rollbacks) for serverless. The backend changes landed first in #257363, and this PR completes the feature by enabling the UI. ## References Closes elastic/security-team#16239 Made with [Cursor](https://cursor.com) --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds backend-only support for configuring which alert states (
new,ongoing,recovered) trigger workflow execution. This is the first part of an intermediate release strategy — schema and adapter changes land first, with the UI to follow in a subsequent PR.AlertStatesinterface and optionalalertStatesfield to the workflows connector types and schema (Zod + config-schema)resolveAlertStates()helper with backward-compatible defaults (new: true, ongoing: false, recovered: false) — existing rules continue to work without migrationbuildActionParamsbefore building the alert eventbuildAlertEventto mergenew/ongoing/recoveredalert arrays into a flatevent.alertsarray (preserves Liquid template compatibility)Why backend-only? Per the intermediate release pattern for serverless, schema changes must land and be deployed before the UI that writes those fields. This ensures older nodes can validate objects during rolling upgrades and rollbacks.
Supersedes #256289 (closed), which included both backend and UI changes. The UI portion (alert state checkbox group in the rule action form) will follow in a separate PR.
PR review feedback addressed from #256289:
AlertStatesinterface for stricter type safetyAlertStatesSchemastrict (.strict()) to reject unknown keysresolveAlertStates()helper to avoid duplicated default logicReferences
Closes elastic/security-team#16239
Made with Cursor