[FR] [DaC] Add support for Kibana workflows

[eric-forte-elastic]

Pull Request

Issue link(s):

Resolves #6212

Summary - What I changed

Adds support for custom Kibana Workflows attached to detection rule actions. Previously, they were stripped every time rules were updated through the DaC CI/CD pipeline (kibana import-rules / kibana export-rules, import-rules-to-repo, export-rules-from-repo).

Kibana's Workflows connector uses the action type id .workflows and, like .cases, is registered as a system action (isSystemActionType: true).

1. .workflows was missing from the ActionTypeId literal in definitions.py, so any standalone action TOML carrying a workflow action failed validation on load.
2. _add_known_nulls injects frequency.throttle: null into every action. System actions do not accept a frequency, so Kibana rejected the action on import and dropped it — removing the attached Workflow. This is the same style of bug previously fixed for .cases in [Bug] CLI adds frequency field to system actions (.cases), causing import failure #5690.

Changes:

• Added .workflows to ActionTypeId so workflow actions validate.
• Added .workflows to SYSTEM_ACTION_TYPE_IDS so _add_known_nulls skips the frequency.throttle injection for it (mirroring the existing .cases handling).
• Added a regression test asserting a normal connector (.slack) still receives the throttle null while .cases and .workflows do not.

How To Test

This can be verified entirely locally with export-rules-from-repo or kibana import

1. Create a rule TOML with a .workflows system action:

[metadata]
creation_date = "2026/05/29"
maturity = "production"
updated_date = "2026/05/29"

[rule]
author = ["Elastic"]
description = "Sample rule with a .workflows system action."
from = "now-9m"
index = ["logs-endpoint.events.*"]
language = "kuery"
license = "Elastic License v2"
name = "Sample Workflow Action Rule"
risk_score = 21
rule_id = "a1b2c3d4-1111-2222-3333-444455556666"
severity = "low"
type = "query"
query = '''
process.name:test.query
'''

[[rule.actions]]
action_type_id = ".workflows"
id = "system-connector-.workflows"
group = "default"

[rule.actions.params]
subAction = "run"
[rule.actions.params.subActionParams]
workflowId = "34ea9729-e7a9-4a48-aac4-6c67d0bed2de"

2. Export the rule to an importable NDJSON:

❯ python -m detection_rules export-rules-from-repo -f sample_workflow_rule.toml -o exports/out.ndjson

█▀▀▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄   ▄      █▀▀▄ ▄  ▄ ▄   ▄▄▄ ▄▄▄
█  █ █▄▄  █  █▄▄ █    █   █  █ █ █▀▄ █      █▄▄▀ █  █ █   █▄▄ █▄▄
█▄▄▀ █▄▄  █  █▄▄ █▄▄  █  ▄█▄ █▄█ █ ▀▄█      █ ▀▄ █▄▄█ █▄▄ █▄▄ ▄▄█

WARNING: Rule path does not match required path: sample_workflow_rule.toml != sample_workflow_action_rule.toml
Exported 1 rules into exports/out.ndjson

3. Inspect the exported action in exports/out.ndjson.

   Previously, a frequency.throttle: null was injected, which Kibana rejects on import for a system action (the action, and thus the attached Workflow, is dropped):

    {
      "action_type_id": ".workflows",
      "frequency": {
        "throttle": null
      },
      "group": "default",
      "id": "system-connector-.workflows",
      "params": {
        "subAction": "run",
        "subActionParams": {
          "workflowId": "34ea9729-e7a9-4a48-aac4-6c67d0bed2de"
        }
      }
    }

   Now, the system action is left untouched (no frequency), so the Workflow is preserved:

    {
      "action_type_id": ".workflows",
      "group": "default",
      "id": "system-connector-.workflows",
      "params": {
        "subAction": "run",
        "subActionParams": {
          "workflowId": "34ea9729-e7a9-4a48-aac4-6c67d0bed2de"
        }
      }
    }

Checklist

• Added a label for the type of pr: bug, enhancement, schema, maintenance, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
• Added the meta:rapid-merge label if planning to merge within 24 hours
• Secret and sensitive material has been managed correctly
• Automated testing was updated or added to match the most common scenarios
• Documentation and comments were added for features that require explanation

Contributor checklist

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[github-actions]

Enhancement - Guidelines

These guidelines serve as a reminder set of considerations when addressing adding a feature to the code.

Documentation and Context

• Describe the feature enhancement in detail (alternative solutions, description of the solution, etc.) if not already documented in an issue.
• Include additional context or screenshots.
• Ensure the enhancement includes necessary updates to the documentation and versioning.

Code Standards and Practices

• Code follows established design patterns within the repo and avoids duplication.
• Ensure that the code is modular and reusable where applicable.

Testing

• New unit tests have been added to cover the enhancement.
• Existing unit tests have been updated to reflect the changes.
• Provide evidence of testing and validating the enhancement (e.g., test logs, screenshots).
• Validate that any rules affected by the enhancement are correctly updated.
• Ensure that performance is not negatively impacted by the changes.
• Verify that any release artifacts are properly generated and tested.
• Conducted system testing, including fleet, import, and create APIs (e.g., run make test-cli, make test-remote-cli, make test-hunting-cli)

Additional Checks

• Verify that the enhancement works across all relevant environments (e.g., different OS versions).
• Confirm that the proper version label is applied to the PR patch, minor, major.