docs(modeler): conditional events

[giorgionaps]

Description

Created a new doc for conditional events with examples

When should this change go live?

• This is a bug fix, security concern, or something that needs urgent release support. (add bug or support label)
• This is already available but undocumented and should be released within a week. (add available & undocumented label)
• This is on a specific schedule and the assignee will coordinate a release with the Documentation team. (create draft PR and/or add hold label)
• This is part of a scheduled alpha or minor. (add alpha or minor label)
• There is no urgency with this change (add low prio label)

PR Checklist

• The commit history of this PR is cleaned up, using {type}(scope): {description} commit message(s)

• My changes are for an upcoming minor release and are in the /docs directory (version 8.9).
• My changes are for an already released minor and are in a /versioned_docs directory.

• I added a DRI, team, or delegate as a reviewer for technical accuracy and grammar/style:
  • Engineering team review
  • Technical writer review via @camunda/tech-writers unless working with an embedded writer.

[github-actions]

👋 🤖 🤔 Hello, @giorgionaps! Did you make your changes in all the right places?

These files were changed only in docs/. You might want to duplicate these changes in versioned_docs/version-8.8/.

• docs/components/concepts/conditions.md
• docs/components/modeler/bpmn/conditional-events/assets/conditional-events.png
• docs/components/modeler/bpmn/conditional-events/conditional-events-new.md
• docs/components/modeler/bpmn/conditional-events/conditional-events.md

You may have done this intentionally, but we wanted to point it out in case you didn't. You can read more about the versioning within our docs in our documentation guidelines.

[christinaausley]

Nice work! I have given your original doc a technical review, but felt like the lengthier bits of text could be broken into something slightly more readable/consolidated. There are of course many ways to do this, and I wanted to largely leave it up to you, so I created a new file conditional-events-new.md which can be seen in the deploy environment.

In this new file, I've broken up larger chunks of text into a tabbed approach and consolidated things a bit. Feel free to take a look, and you can replace the original conditional-events.md file with this if you want (you'll just need to remove the "new" portion added to the filename, ID, and page title). If you want to go a different direction, you can of course just delete this new file.

[giorgionaps]

Nice work! I have given your original doc a technical review, but felt like the lengthier bits of text could be broken into something slightly more readable/consolidated. There are of course many ways to do this, and I wanted to largely leave it up to you, so I created a new file conditional-events-new.md which can be seen in the deploy environment.

In this new file, I've broken up larger chunks of text into a tabbed approach and consolidated things a bit. Feel free to take a look, and you can replace the original conditional-events.md file with this if you want (you'll just need to remove the "new" portion added to the filename, ID, and page title). If you want to go a different direction, you can of course just delete this new file.

@christinaausley thank you so much for taking the time to reorganize the info, I will take a look at that file & see what's best to use here 🙌

[barmac]

🏅 Proper nesting is crucial to make the code readable.

[barmac]

Note that we don't support variableEvents for process start event for a reason: There is no process instance in which the events related to the variable could happen yet. Variable events only make sense for an existing process instance.

[barmac]

✅ from my side

[github-actions]

🚧 The preview environment for the commit bf380e2 is being built. This usually takes 8-10 minutes.