[SEC-31367] Document Ticket Creation Rules for Automation Pipelines

[hugoqnc]

What does this PR do? What is the motivation?

Adds documentation for the new Ticket Creation Rules feature in Automation Pipelines (SEC-27479).

• New page content/en/security/automation_pipelines/create_ticket.md documenting how to create, test, and manage ticket creation rules for Jira and Case Management
• Two screenshots added: the lightning bolt indicator on automatically created tickets, and the broken rule error state
• Updated _index.md to add the new page to further_reading and add a use case section for ticket creation
• Updated side nav menu to include the new page

Preview

https://docs-staging.datadoghq.com/hugo.queinnec/ticket-creation-rules/security/automation_pipelines/create_ticket/

Merge instructions

Merge readiness:

• Ready for merge

Additional notes

[github-actions]

Preview links (active after the build_preview check completes)

New or renamed files

• https://docs-staging.datadoghq.com/hugo.queinnec/ticket-creation-rules/security/automation_pipelines/create_ticket

Modified Files

• https://docs-staging.datadoghq.com/hugo.queinnec/ticket-creation-rules/security/automation_pipelines/
• https://docs-staging.datadoghq.com/hugo.queinnec/ticket-creation-rules/security/automation_pipelines/mute
• https://docs-staging.datadoghq.com/hugo.queinnec/ticket-creation-rules/security/automation_pipelines/security_inbox
• https://docs-staging.datadoghq.com/hugo.queinnec/ticket-creation-rules/security/automation_pipelines/set_due_date

[alex147]

LGTM, just a single sentence that I find a bit confusing.

[janine-c]

Looks great! I made some suggestions about things like writing style and content ordering, and in one case some additional steps we might want to add, but nothing that's a big blocker 🙂 Feel free to ping me for any questions, any help implementing any of this, or for any additional review!

[janine-c]

If you wanted to, I think you could put these sections as subsections in the intro. I think it's helpful for users when they're deciding if they want to use a feature to get the nuance of how it works, and it helps if they can expect conceptual information to appear in one place in the doc. It's not terrible to have it at the end, but it does feel a little more tacked on than the "this is what this thing does!" expectation users already have about overviews.

[hugoqnc]

Thanks for the suggestion, I tried restructuring with those subsections in the intro, but I'm not fully convinced it works well. Those are fairly fine-grained implementation details that most users won't need to read before getting started. The other automation pipeline pages also follow the pattern of putting procedural steps first, which keeps things consistent. I've also kept a link from the rate limit step in the creation flow to the dedicated section, so users who need the detail can jump to it. Happy to revisit if you feel strongly, but I'd lean toward keeping the current structure.