Search variables
diff --git a/versioned_docs/version-8.6/apis-tools/operate-api/specifications/sequence-flows-by-key.api.mdx b/versioned_docs/version-8.6/apis-tools/operate-api/specifications/sequence-flows-by-key.api.mdx
index 6d1356d49e..b378b45273 100644
--- a/versioned_docs/version-8.6/apis-tools/operate-api/specifications/sequence-flows-by-key.api.mdx
+++ b/versioned_docs/version-8.6/apis-tools/operate-api/specifications/sequence-flows-by-key.api.mdx
@@ -5,9 +5,9 @@ description: "Get sequence flows of process instance by key"
sidebar_label: "Get sequence flows of process instance by key"
hide_title: true
hide_table_of_contents: true
-api: eJzlVktv2zgQ/isET93WsZw2WwTGokAKOIXbogliFz0EOdDS2GYjkSo5ctYQ9N87Q0qOHyp297hoDhE5nPd8M+Naolp5Ob6Xt86m4P3UeFQmBfkwkLYEp1BbM83kWHr4UQG9XOf2yb/ffoKtHMhSOVUAgmMdtTR0IdbH8KYNHUuFazpn4FOnS1ZGRJIVdinKaFLozuZAOjKiHZA9dBUMpE/XUCg5riVuS1atDcIKHLEurSsURtLbC9k0DyzuS2s8eJZ4PRrx59D0rErZJsmnllQZZJaXyUv+nBhTzqkQCULh9+genTYrMkl/A3nRZ2dqNirXmeCAwOOhPVWWuU5DahNKwiKH4tV3z3I9TtjFd0hZAXFSQVDH6ChlWPl/zMyb15JcLChktYKeELhMbfb7HiPhNHB60ZgzaeKcdbLLxJvTTFxbt9BZBubf5fx/Fe7Fabh3seDApfe2cikIY1EsbWWy3wMFf/b1w9XtVOwFLCAI/Ab5IKKHtHIat2FELkA5cGc8Isf3D82gphTYRw3h9nA8KT8Aim7wiiVP3r7BKRZbEWcuzeK15Wm9gpAcnr5jmWzOk1bmrJPxSU0iTdJpPwvaJXvrNt08r1xO4nXMfjNOknptPTbjurQOG2LeKKcVVSqknN9i5ZeqyjnVuU1VHsjHgc3XIPiBNwaHhHRnjETrQ84y2zhUdzm6HPVqYtZfaHlGzrOeNWLZqycy92oK+6Wr5Iz5YtBd9Z6XRqnjbmyX4c3t5O5qPjmbTWaz6c2XbjG2cuThPiJ2WloXg0N8j0yy477uwPzx2zwAT5ulDeItAG/C7gZxWy2oqTiU04CtUGEZ0gf1BoQymUhtUebA4+sYZHwSnVpqJlFYo9Ey9IMkOlsxEtbWIrdD7G1SzW5FIHFQnlD09PQ0TFVBE1ENySAngZwEWtzM2+btc0sZHAlnNvU7aW3DPXGwBMcwTlpFPmGtDOQY7PlwNBxFVHkslNkz9F977CCLu4Ih/I1JmSsqbtO6XLf9dy8353FSHXYg0cZR5VETEtJiL93Lul4oD19d3jRMJjYXBsdz64VGzbTnM3X+UuUeTpzcjVn54q79ifWH+PXPsN6YOnybbWj8vOIbHQNww/+G5plcg8oIqexVfLkikJW4J8Orn7tpN6w+TOb0rCpO1i6hR4gPCntd+Ot9YBBz+wjm3c4h5Cu71DQ/ARnwu5g=
+api: eJzlVt1v2zYQ/1eIe9o6xnLabCiEYUAKOIXXYQmSFH0I/EBTZ5uNRCrkyZkh6H8fjpSc2Fax7XGoX2R+3O/ufvfFFkitA+QPcOOdxhDmNpCyGmEhwdXoFRln5wXkEPCpQavxqnTP4cPuE+5AQq28qpDQM0YLVlUIOTzGM2Mhh1rRBiQUGLQ3NYNBDp9wJ9xK1EmlMINOCR6fGuOxgJx8gxKC3mClIG+BdjVDG0u4Rg8SVs5XitLWLxfQdQsWD7WzAQNLvJ1O+XOo+q7RrBMkaGcJLfGVN9kb/pwoU96r6AlhFV7tB/LGrqHjn4SLMT1zu1WlKQQ7hIEO9am6Lo2O1Ga1d8sSq5++BpYbMcItv6JmgNpzQMgk7wIpasI/MvPuLXQSKgxBrXHEBQ5Tz/7YYdo4dVwCGSp5a+a98zAw8e6UiSvnl6Yo0P47zv9X7l6cunubAo4c+uAar1FYR2LlGlt8H1nw81g9XN7MxSuHBUaB74CPTkJA3XhDu9gil6g8+jNukfnDopMtaOceDcbV4rhTfkQSQ+MVK+68Y41TLHci9dwKaeO4W68xksPdN4dse571MmeDTMjaR9x12YB+FtGBrfXboZ83voQc2sR+l2dZu3GBurytnacOJGyVN2pZJvL5LEV+pZqSqS6dVmXcPnbsfoOCD3hisEu0QcE5krRPmGXWcQj3fvp+OorEV7+B8pI5LzgbonoUJ10eRYrzZYjkHd9LTg/RexkatUmzsR+G1zez28v72dnd7O5ufv3nMBh7uU4eZMQepTcxGsTrdAmG21dDMv/+5T4mnrErF8X7BLyOsxvFTbMsjWZXTh12QsVhKJQms0WhbCG0q+oSuX0dJxn/EwPsynlROWvIcepHSfKu4UzYOEdcDqm2lY4xTInEToU8y56fnydaVY0t1ES7ikkojUYbIo89b3/0O/JIuHA67KWNi+vM4wo9p3HWA4WMUTmRk7Pnk+lkmrIqUKXsK0X/tcYOWNwHjPAvyupSGctaosltX38PsD1PneqwAkFCniCPinAh+1p6gLZdqoCffdl1vP3UoI+N46X0YqEWJvD/AvKVKgOeGLlvs/DDbf/E+lF8+xk26tOQ33YXC79seAUyvvbSm69bdBI2qAr00ap0cqk11vRKhkc/V9O+WX2c3YME1TBZe0KPMj4Cjprw64d4Qdy7R7S/7Q0iXrJJXfc3GfC7mA==
sidebar_class_name: "get api-method"
-info_path: docs/apis-tools/operate-api/specifications/operate-public-api
+info_path: versioned_docs/version-8.6/apis-tools/operate-api/specifications/operate-public-api
custom_edit_url: null
hide_send_button: true
---
diff --git a/versioned_docs/version-8.6/apis-tools/operate-api/specifications/xml-by-key-1.api.mdx b/versioned_docs/version-8.6/apis-tools/operate-api/specifications/xml-by-key-1.api.mdx
index e9df1fff30..434048b759 100644
--- a/versioned_docs/version-8.6/apis-tools/operate-api/specifications/xml-by-key-1.api.mdx
+++ b/versioned_docs/version-8.6/apis-tools/operate-api/specifications/xml-by-key-1.api.mdx
@@ -5,9 +5,9 @@ description: "Get decision requirements as XML by key"
sidebar_label: "Get decision requirements as XML by key"
hide_title: true
hide_table_of_contents: true
-api: eJzlVm1v0zAQ/iuWP/FSmu4FhCqEtIluKhtsWotAqibkJtfWW2IH2+moovx37uwka9cg+Ir40vrl7rm3584puRNLy4cz/gFiaaVWN/CjkAYyUM7y2x7XORjh8GKc8CH/maWnmwvYfD/gPZ4LIzJwYAig5Ao3KHIPG7yTCpe5cCtcJ2BjI3MCwUPUZnrBktoeM9sGe7zeojFnCuhxG68gE3xYcrfJCV8qB0swKLrQJhMuHL055lV1S+o218qCJY3DwYD+du1PijgGS6ZijVDKeWz46SIMjtZ7Fq0zUi0Rv6p6/LgLc6zWIpWJjwWs28UWeZ7K2Ocwyo2ep5C9vLOk12FLz+8gJgCUxMw7GSKxTrjC/jELR4ccXcwwPLGEjgioLgil4u7LcLAfN95Il9LRyBht2kwc7WfiTJu5TBJQuzl4Eb3498M93g/3JhQcqPRWFyYGprRjC12o5P9gweuufji5HrOtgBl4hf8gH3hoIS6MdBs/E+cgDJhXNBOHs9uqV2IK9L0Ev7t9OhrPwXXPRSYs+/bpks03LIxXHLsrTQN5CT4tNGiHPFofRIlJohKFKj/OyB2zbiZ0YXDA8TKktxpGUbnS1lXDMtfGVSi8FkYKLIXPKd2F0i5EkVIuUx2L1B8/9Xy6AkYX9AbQdHe4JxIE631KI9nYhXs7eDvoRCLR36A8UuMRZ+Vc3okThDuR/GPRlGpCciHopjxtuUUuL3zK6+ft6np0czIdvZqMJpPx1efmqav10MPtkrcotYveIdoHId5InzVs/fh16pkl1UJ79ZphV/4VBnZdzLFrKJT9gDUT/mXDPyfXwIRKWKyzPAWaT9g5/rKhOq1YA4vdwjKtpNPEba/pjC6ICSutHfE9NC9Ck1uBSBSURRY9PDz0Y5HhyBN9NEhJQCcBX2GSrfN2WZ/0nignOratttR+HxlYgAH0MqqBbESoROQQ7EF/0B8EVlmXCbVl6O+baCd/ban8p0CeCixrVTtb1g0242v67sEWw99hAKEuQyqFZpnxspwLC19MWlV0jK+D8a3/2Fu+ExNpaY0dvBCphT1f2kHJn9UfZMlz9ocvp07/GxarjW/vtKAdLj09/W+FY4mvQCTIR3It3JwglXK3pdN+IVHjtOPnfDRFGVFQdtoMPiG3R+30492pF2BTfQ/qfeuVoy35VVW/APihoiw=
+api: eJzlVm1v2zYQ/ivEfVo71nLarCiEYUCKuUWWdgliFy0QGANNnW02EqmSlBND4H8vjpSUONbQfR36SeLLPXf33AuvBS82DvIb+BOlcsroa/zWKIsVau9gycHUaIVXRp8XkMN9Vb7dX+D+nxPgUAsrKvRoCaAFLSqEHG5xDxyUhhxq4bfAoUAnraoJBHK4wD0za1Z0+ph9rJBDtywg97ZBDk5usRKQt+D3NeEr7XGDFjisja2ET1uvTyGEJYm72miHjiReTqf0OdQ/b6RER6qk0R61j9h477P7qqT/I43OW6U3EEIIHE7HMM/1TpSqiL6g84fYoq5LJSOHWW3NqsTq16+O5EZ0mdVXlARQW2Leq+SJ88I37ocsvHoJgUOFzokNjnhAcXFeaDl+mDaO/ebglS9pa2atsQMTr46ZeGfsShUF6kMOnmfP///unh67e50CjhR6ZxorkWnj2do0uvg5suC3sXo4uzpnjxxmGAV+Aj4CB4eyscrvY09cobBoX1BPzG+WgbcgjblVGFfLp63xPfrxvsiEY18+fmCrPUvttUK/NdSQNxhpoUabQ7Y7yQpbZO0t7kNsZ2SO3fUdurEl5NAmekOeZe3WOB/ytjbWB+CwE1aJVZnYpbMU2rVoSuKyNFKUcfup5YstMjqgN4C6u98ioyRI2idEI+k4hHszfTMdRaKr/4LykBoPOFvv61GcdHkUKT4WfajmdC853YdnCLeo1UWkvHveLq9m12eL2Yv5bD4/v/y7f+o6ucAPQj6gdCZGg2idLkF/+12frX99XsTMUnptoniXYZfxFUZ21axKJcmVY4cNE/FlY0J6tUMmdMGkqeoSqT/V1sTDPtXpj/Wwa2NZZbTyhnI7SnprGsqErTGe8j0Vr5AxhimRyCmXZ9nd3d1EiqrRhZhIUxEJpZKoXeSx4+1Dt8OfCBdGukFambjOLK7RopaYdUAuI1RK5OTsyWQ6maascr4S+pGi/15EB/wNoYqjQF0KpQk/Gtt2BXYDO5p7Cku9PU8gVGVL3hXLDbTtSjj8ZMsQaPtbgzaW/kNtxUoslKP/AvK1KB0e2TI0SvilG8iKZ+wHk9Oo/X0W630s77KhFfA4paVZLSwDhy2KAm00LZ2cSYm1fyQzTEhUOEP7eT9bAAfREDsDg0+SO6KO2vH723iBLcwt6j8Gqzwtya4QvgP4oaIs
sidebar_class_name: "get api-method"
-info_path: docs/apis-tools/operate-api/specifications/operate-public-api
+info_path: versioned_docs/version-8.6/apis-tools/operate-api/specifications/operate-public-api
custom_edit_url: null
hide_send_button: true
---
diff --git a/versioned_docs/version-8.6/apis-tools/operate-api/specifications/xml-by-key.api.mdx b/versioned_docs/version-8.6/apis-tools/operate-api/specifications/xml-by-key.api.mdx
index a4d4935afc..a00d32b6d3 100644
--- a/versioned_docs/version-8.6/apis-tools/operate-api/specifications/xml-by-key.api.mdx
+++ b/versioned_docs/version-8.6/apis-tools/operate-api/specifications/xml-by-key.api.mdx
@@ -5,9 +5,9 @@ description: "Get process definition as XML by key"
sidebar_label: "Get process definition as XML by key"
hide_title: true
hide_table_of_contents: true
-api: eJzlVltv0zAU/iuWn7h0TccGQhFCGqJDg8GmtQikaQ9uctp6S+xgO92qKP+dc+wkXdtweUW8tL6c853bd45TcScWlsfX/NLoBKx9D3OppJNa8ZsB1wUYQZuzlMf8Ic/erT/Bmg94IYzIwYEh3Yor3KDAnb+TCpeFcEtcp2ATIwuPF3PUZXrOimCKpRtbA27gRykNoB1nShhwmywhFzyuuFsXBC6VgwUYFJ1rkwsXjl4d87q+IXVbaGXBksaL0Yj+to1PyoSson6iEUo5jw0PLsK4aL1n0Toj1QLx63rAj/swz9RKZDJl5DxYt40tiiKTiU9fhCHPMsif31rS67GlZ7eQEABKYtKdDJFYJ1xp/5iFoxccXcwxPLGAngioKAilkv7LcLAfN95Il9HR2Bhtukwc7WfiVJuZTFNQ2zl4Fj3798M93g/3KhQcqPRWlyYBprRjc12q9P9gwcu+fji5PGOPAmbgFf6DfOChhaQ00q39QJyBMGAOaCDG1zf1oMIU6DsJfnezOxc/gOsZikxY9v3zOZutWRisOHCXmgbxAnxOaMTGPFodRo3ywUbZRhUq1X62kW9m1c7q0uC041XIdR1HUbXU1tVxVWjjahReCSMF1sUnmO5CneeizCixmU5E5o93w5gugdEFvQY05x3uiRHB+pBySja24V6PXo96kUj0Fygbnmxwls4VvThBuBfJvxxt3SYkF4Jua9XVXhQyvHvNQ3dxOb46mY4PJuPJ5OziS/voNXro4eP6dyiNi94h2gch3kqfttT9+G3qaSbVXHv1hm4X/jUGdlnOsIUolP2ANRP+mcM/J1fAhEpZovMiAxpWLcla3tOKtbDYOizXSB9NRPeazuiSmLDU2hH5QycjNLkViERBWWTR/f39MBE5zj8xRIOUBHQS8Ekm2SZv583JYEc51YnttKX2+8jAHAygl1EDZCNCJSKHYA+Ho+EosMq6XKhHhv6yo7aS19XJfxQUmcCa1o2nVdNt13x1GMbRbr/haRxAqeWQV6FzrnlVzYSFryarazrGd8P4obBpNN+WqbS0xvaei8zCnm/dCOVPrppPpafsdx9UvcG0fFZr3+hZSTtceqL63xqnFV+CSJGZ5Fe4OUFSFe6RTvfhRC3UDaYP4ynKiJJS1aVzh+YetdePN++8AJvqO1BvO68cbcmvuv4JhPioRg==
+api: eJzlVm1v2zYQ/ivEfdo6xnLabCiEYUCKuUXWbgliDxsQ+ANNnW02EqmSlBND4H8fjpTk2NZevg79JPHlnrt77o0teLFxkD/AnTUSnfsZ10orr4yGJQdToxW0uCkgh+eqfLf/iHvgUAsrKvRoSbYFLSqEHB7jmdKQQy38FjgU6KRVdcTL4SPumVmzOqlixUEXB4tfGmWxgNzbBjk4ucVKQN6C39cErrTHDVrgsDa2Ej5t/XAFISxJ3NVGO3Qk8Xo6pc+x8nkjSStwkEZ71D5i47PPnquS/s80Om+V3kAIIXC4GsO80TtRqoKR8ej8Mbao61LJSF9WW7MqsfrusyO5EV1m9RklAdSWSPcqeeK88I37VxbevIbAoULnxAZHPKCgOC+0HD9MG+d+c/DKl7Q1s9bYgYk350y8N3aligL1MQevslf/f3evzt29TwFHCr0zjZXItPFsbRpdfB1Z8P1YPVzf3bAXDjOMAl8BH4GDQ9lY5fexIa5QWLQX1BDzh2XgLUhjHhXG1fK0L35AP9IUmXDsz18/sdWepcZaod8aasQbjJxQi80h211mnfDFQdhl7SPuQ+xtZJvd9b26sSXk0CauQ55l7dY4H/K2NtYH4LATVolVmaimsxTntWhKIrY0UpRx+9SNxRYZHdA0oD7vt8goI5L2CXFKOo7h3k7fTkeR6OrfoBzy5ICz9b4exUmXR5Hi5OjjNqd7yek+VkPsRa3S3OsG3e3d7P56MbuYz+bzm9vf+qHXyQV+FP8BpTMxGkTrdAn62+/71P3lj0VMM6XXJop36XYbpzGyu2ZVKkmunDtsmIhjjgnp1Q6Z0AWTpqpLpGbVJ1mf9/THeti1sawyWnlDiR4lvTUNZcLWGE/JnypZyBjDlEjklMuz7OnpaSJF1ehCTKSpiIRSSdQu8tjx9qnb4SfChZFukFYmrjOLa7SoJWYdkMsIlRI5OXs5mU6mKaucr4R+oeg/VtQReUOc4qOgLoXSBB4tbbtqe4DdZWpHp/UGHPIESiW35F3lPEDbroTD320ZAm1/adDGpnAotFiWhXL0X0C+FqXDM9uGFgrf3HdPpW/ZPz2oRp3p81nvY6GXDa2Ax5dber+FZeCwRVGgjXalk2spsfYvZIaHE5XQ0Jg+zBbAQTRE1UDnSZpH1FE7fnwXL7CFeUT902CVpyXZFcJfhPioRg==
sidebar_class_name: "get api-method"
-info_path: docs/apis-tools/operate-api/specifications/operate-public-api
+info_path: versioned_docs/version-8.6/apis-tools/operate-api/specifications/operate-public-api
custom_edit_url: null
hide_send_button: true
---
From 9640251dc553cfa9ef174d361082e669807ab968 Mon Sep 17 00:00:00 2001
From: Giuliano Rodrigues Lima <91879848+grlimacan@users.noreply.github.com>
Date: Thu, 12 Dec 2024 08:56:48 +0200
Subject: [PATCH 18/26] chore: remove OpenSearch warnings (#4750)
* chore: Remove Optimize OpenSearch warnings
* chore: Implementing suggestions from review
* chore: Implementing suggestions from review
---
.../backup-restore/optimize-backup.md | 42 +++++++++----------
.../advanced-features/import-guide.md | 28 +++++++------
.../shared-elasticsearch-cluster.md | 4 --
.../system-configuration-platform-7.md | 8 ++--
.../configuration/system-configuration.md | 8 ----
.../optimize-deployment/install-and-start.md | 4 --
.../advanced-features/import-guide.md | 28 +++++++------
7 files changed, 58 insertions(+), 64 deletions(-)
diff --git a/docs/self-managed/operational-guides/backup-restore/optimize-backup.md b/docs/self-managed/operational-guides/backup-restore/optimize-backup.md
index fd86d993ec..2215873da0 100644
--- a/docs/self-managed/operational-guides/backup-restore/optimize-backup.md
+++ b/docs/self-managed/operational-guides/backup-restore/optimize-backup.md
@@ -11,20 +11,20 @@ This release introduces breaking changes, including the utilized URL.
For example, `curl 'http://localhost:8092/actuator/backups'` rather than the previously used `backup`.
:::
-Optimize stores its data over multiple indices in Elasticsearch. To ensure data integrity across indices, a backup of Optimize data consists of two Elasticsearch snapshots, each containing a different set of Optimize indices. Each backup is identified by a positive integer backup ID. For example, a backup with ID `123456` consists of the following Elasticsearch snapshots:
+Optimize stores its data over multiple indices in the database. To ensure data integrity across indices, a backup of Optimize data consists of two ElasticSearch/OpenSearch snapshots, each containing a different set of Optimize indices. Each backup is identified by a positive integer backup ID. For example, a backup with ID `123456` consists of the following snapshots:
```
camunda_optimize_123456_3.9.0_part_1_of_2
camunda_optimize_123456_3.9.0_part_2_of_2
```
-Optimize provides an API to trigger a backup and retrieve information about a given backup's state. During backup creation Optimize can continue running. The backed up data can later be restored using the standard Elasticsearch snapshot restore API.
+Optimize provides an API to trigger a backup and retrieve information about a given backup's state. During backup creation Optimize can continue running. The backed up data can later be restored using the standard ElasticSearch/OpenSearch snapshot restore API.
## Prerequisites
The following prerequisites must be set up before using the backup API:
-1. A snapshot repository of your choice must be registered with Elasticsearch.
+1. A snapshot repository of your choice must be registered with ElasticSearch/OpenSearch.
2. The repository name must be specified using the `CAMUNDA_OPTIMIZE_BACKUP_REPOSITORY_NAME` environment variable, or by adding it to your Optimize [`environment-config.yaml`]($optimize$/self-managed/optimize-deployment/configuration/system-configuration/):
```yaml
@@ -48,13 +48,13 @@ POST actuator/backups
### Response
-| Code | Description |
-| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
-| 202 Accepted | Backup process was successfully initiated. To determine whether backup process was completed refer to the GET API. |
-| 400 Bad Request | Indicates issues with the request, for example when the `backupId` contains invalid characters. |
-| 409 Conflict | Indicates that a backup with the same `backupId` already exists. |
-| 500 Server Error | All other errors, e.g. issues communicating with Elasticsearch for snapshot creation. Refer to the returned error message for more details. |
-| 502 Bad Gateway | Optimize has encountered issues while trying to connect to Elasticsearch. |
+| Code | Description |
+| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
+| 202 Accepted | Backup process was successfully initiated. To determine whether backup process was completed refer to the GET API. |
+| 400 Bad Request | Indicates issues with the request, for example when the `backupId` contains invalid characters. |
+| 409 Conflict | Indicates that a backup with the same `backupId` already exists. |
+| 500 Server Error | All other errors, e.g. issues communicating with the database for snapshot creation. Refer to the returned error message for more details. |
+| 502 Bad Gateway | Optimize has encountered issues while trying to connect to the database. |
### Example request
@@ -96,8 +96,8 @@ GET actuator/backup
| 200 OK | Backup state could be determined and is returned in the response body (see example below). |
| 400 Bad Request | There is an issue with the request, for example the repository name specified in the Optimize configuration does not exist. Refer to returned error message for details. |
| 404 Not Found | If a backup ID was specified, no backup with that ID exists. |
-| 500 Server Error | All other errors, e.g. issues communicating with Elasticsearch for snapshot state retrieval. Refer to the returned error message for more details. |
-| 502 Bad Gateway | Optimize has encountered issues while trying to connect to Elasticsearch. |
+| 500 Server Error | All other errors, e.g. issues communicating with the database for snapshot state retrieval. Refer to the returned error message for more details. |
+| 502 Bad Gateway | Optimize has encountered issues while trying to connect to the database. |
### Example request
@@ -135,8 +135,8 @@ Possible states of the backup:
- `COMPLETE`: The backup can be used for restoring data.
- `IN_PROGRESS`: The backup process for this backup ID is still in progress.
-- `FAILED`: Something went wrong when creating this backup. To find out the exact problem, use the [Elasticsearch get snapshot status API](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/get-snapshot-status-api.html) for each of the snapshots included in the given backup.
-- `INCOMPATIBLE`: The backup is incompatible with the current Elasticsearch version.
+- `FAILED`: Something went wrong when creating this backup. To find out the exact problem, use the [Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/current/get-snapshot-status-api.html) / [OpenSearch](https://opensearch.org/docs/latest/api-reference/snapshots/get-snapshot-status/) get snapshot status API for each of the snapshots included in the given backup.
+- `INCOMPATIBLE`: The backup is incompatible with the current ElasticSearch/OpenSearch version.
- `INCOMPLETE`: The backup is incomplete (this could occur when the backup process was interrupted or individual snapshots were deleted).
## Delete backup API
@@ -154,10 +154,10 @@ DELETE actuator/backups/{backupId}
| Code | Description |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| 204 No Content | The delete request for the associated snapshots was submitted to Elasticsearch successfully. |
+| 204 No Content | The delete request for the associated snapshots was submitted to the database successfully. |
| 400 Bad Request | There is an issue with the request, for example the repository name specified in the Optimize configuration does not exist. Refer to returned error message for details. |
| 500 Server Error | An error occurred, for example the snapshot repository does not exist. Refer to the returned error message for details. |
-| 502 Bad Gateway | Optimize has encountered issues while trying to connect to Elasticsearch. |
+| 502 Bad Gateway | Optimize has encountered issues while trying to connect to ElasticSearch/OpenSearch. |
### Example request
@@ -167,22 +167,22 @@ curl --request DELETE 'http://localhost:8092/actuator/backups/123456'
## Restore backup
-There is no Optimize API to perform the backup restore. Instead, the standard [Elasticsearch restore snapshot API](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/restore-snapshot-api.html) can be used. Note that the Optimize versions of your backup snapshots must match the currently running version of Optimize. You can identify the version at which the backup was taken by the version tag included in respective snapshot names; for example, a snapshot with the name`camunda_optimize_123456_3.9.0_part_1_of_2` was taken of Optimize version `3.9.0`.
+There is no Optimize API to perform the backup restore. Instead, the standard [Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/current/restore-snapshot-api.html) / [OpenSearch](https://opensearch.org/docs/latest/api-reference/snapshots/restore-snapshot) restore snapshot API can be used. Note that the Optimize versions of your backup snapshots must match the currently running version of Optimize. You can identify the version at which the backup was taken by the version tag included in respective snapshot names; for example, a snapshot with the name`camunda_optimize_123456_3.9.0_part_1_of_2` was taken of Optimize version `3.9.0`.
:::note
Optimize must NOT be running while a backup is being restored.
:::
-To restore an existing backup, all the snapshots this backup contains (as listed in the response of the [create backup API request](#example-response)) must be restored using the Elasticsearch API.
+To restore an existing backup, all the snapshots this backup contains (as listed in the response of the [create backup API request](#example-response)) must be restored using the restore API.
To restore a given backup, the following steps must be performed:
1. Stop Optimize.
-2. Ensure no Optimize indices are present in Elasticsearch (or the restore process will fail).
-3. Iterate over all Elasticsearch snapshots included in the desired backup and restore them using the Elasticsearch restore snapshot API.
+2. Ensure no Optimize indices are present in the database (or the restore process will fail).
+3. Iterate over all ElasticSearch/OpenSearch snapshots included in the desired backup and restore them using the restore snapshot API mentioned above.
4. Start Optimize.
-Example Elasticsearch request:
+Example request:
```shell
curl --request POST `http://localhost:9200/_snapshot/repository_name/camunda_optimize_123456_3.9.0_part_1_of_2/_restore?wait_for_completion=true`
diff --git a/optimize/self-managed/optimize-deployment/advanced-features/import-guide.md b/optimize/self-managed/optimize-deployment/advanced-features/import-guide.md
index f23cda4b3b..451ba66436 100644
--- a/optimize/self-managed/optimize-deployment/advanced-features/import-guide.md
+++ b/optimize/self-managed/optimize-deployment/advanced-features/import-guide.md
@@ -14,17 +14,17 @@ In general, the import assumes the following setup:
- A Camunda engine from which Optimize imports the data.
- The Optimize backend, where the data is transformed into an appropriate format for efficient data analysis.
-- [Elasticsearch](https://www.elastic.co/guide/index.html), which is the database Optimize persists all formatted data to.
+- [Elasticsearch (ES)](https://www.elastic.co/guide/index.html) or [OpenSearch (OS)](https://opensearch.org/), which serves as the database that Optimize uses to persist all of its formatted data.
The following depicts the setup and how the components communicate with each other:
![Optimize Import Structure](img/Optimize-Structure.png)
-Optimize queries the engine data using a dedicated Optimize REST-API within the engine, transforms the data, and stores it in its own Elasticsearch database such that it can be quickly and easily queried by Optimize when evaluating reports or performing analyses. The reason for having a dedicated REST endpoint for Optimize is performance: the default REST-API adds a lot of complexity to retrieve the data from the engine database, which can result in low performance for large data sets.
+Optimize queries the engine data using a dedicated Optimize REST-API within the engine, transforms the data, and stores it in its own database such that it can be quickly and easily queried by Optimize when evaluating reports or performing analyses. The reason for having a dedicated REST endpoint for Optimize is performance: the default REST-API adds a lot of complexity to retrieve the data from the engine database, which can result in low performance for large data sets.
Note the following limitations regarding the data in Optimize's database:
-- The data is only a near real-time representation of the engine database. This means Elasticsearch may not contain the data of the most recent time frame, e.g. the last two minutes, but all the previous data should be synchronized.
+- The data is only a near real-time representation of the engine database. This means the database may not contain the data of the most recent time frame, e.g. the last two minutes, but all the previous data should be synchronized.
- Optimize only imports the data it needs for its analysis. The rest is omitted and won't be available for further investigation. Currently, Optimize imports:
- The history of the activity instances
- The history of the process instances
@@ -47,7 +47,7 @@ This section gives an overview of how fast Optimize imports certain data sets. T
It is very likely that these metrics change for different data sets because the speed of the import depends on how the data is distributed.
-The import is also affected by how the involved components are set up. For instance, if you deploy the Camunda engine on a different machine than Optimize and Elasticsearch to provide both applications with more computation resources, the process is likely to speed up. If the Camunda engine and Optimize are physically far away from each other, the network latency might slow down the import.
+The import is also affected by how the involved components are set up. For instance, if you deploy the Camunda engine on a different machine than Optimize and Elasticsearch/OpenSearch to provide both applications with more computation resources, the process is likely to speed up. If the Camunda engine and Optimize are physically far away from each other, the network latency might slow down the import.
### Setup
@@ -135,7 +135,7 @@ During execution, the following steps are performed:
2. Map entities and add an import job
3. [Execute the import](#execute-the-import).
1. Poll a job
- 2. Persist the new entities to Elasticsearch
+ 2. Persist the new entities to the database
### Start an import round
@@ -175,33 +175,37 @@ First, the `ImportScheduler` retrieves the newest index, which identifies the la
#### Map entities and add an import job
-All fetched entities are mapped to a representation that allows Optimize to query the data very quickly. Subsequently, an import job is created and added to the queue to persist the data in Elasticsearch.
+All fetched entities are mapped to a representation that allows Optimize to query the data very quickly. Subsequently, an import job is created and added to the queue to persist the data in the database.
### Execute the import
Full aggregation of the data is performed by a dedicated `ImportJobExecutor` for each entity type, which waits for `ImportJob` instances to be added to the execution queue. As soon as a job is in the queue, the executor:
- Polls the job with the new Optimize entities
-- Persists the new entities to Elasticsearch
+- Persists the new entities to the database
The data from the engine and Optimize do not have a one-to-one relationship, i.e., one entity type in Optimize may consist of data aggregated from different data types of the engine. For example, the historic process instance is first mapped to an Optimize `ProcessInstance`. However, for the heatmap analysis it is also necessary for `ProcessInstance` to contain all activities that were executed in the process instance.
-Therefore, the Optimize `ProcessInstance` is an aggregation of the engine's historic process instance and other related data: historic activity instance data, user task data, and variable data are all [nested documents](https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html) within Optimize's `ProcessInstance` representation.
+Therefore, the Optimize `ProcessInstance` is an aggregation of the engine's historic process instance and other related data: historic activity instance data, user task data, and variable data are all nested documents ([ES](https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html) / [OS](https://opensearch.org/docs/latest/field-types/supported-field-types/nested/)) within Optimize's `ProcessInstance` representation.
:::note
-Optimize uses [nested documents](https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html), the above mentioned data is an example of documents that are nested within Optimize's `ProcessInstance` index.
+Optimize uses nested documents ([ES](https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html) / [OS](https://opensearch.org/docs/latest/field-types/supported-field-types/nested/)), the above mentioned data is an example of documents that are nested within Optimize's `ProcessInstance` index.
-Elasticsearch applies restrictions regarding how many objects can be nested within one document. If your data includes too many nested documents, you may experience import failures. To avoid this, you can temporarily increase the nested object limit in Optimize's [index configuration](./../configuration/system-configuration.md#index-settings). Note that this might cause memory errors.
+Elasticsearch and OpenSearch apply restrictions regarding how many objects can be nested within one document. If your data includes too many nested documents, you may experience import failures. To avoid this, you can temporarily increase the nested object limit in Optimize's [index configuration](./../configuration/system-configuration.md#index-settings). Note that this might cause memory errors.
:::
Import executions per engine entity are actually independent from another. Each follows a [producer-consumer-pattern](https://dzone.com/articles/producer-consumer-pattern), where the type specific `ImportService` is the single producer and a dedicated single `ImportJobExecutor` is the consumer of its import jobs, decoupled by a queue. So, both are executed in different threads. To adjust the processing speed of the executor, the queue size and the number of threads that process the import jobs can be configured:
+:::note
+Although the parameters below include `ElasticSearch` in their name, they apply to both ElasticSearch and OpenSearch installations. For backward compatibility reasons, the parameters have not been renamed.
+:::
+
```yaml
import:
# Number of threads being used to process the import jobs per data type that are writing
- # data to elasticsearch.
+ # data to the database.
elasticsearchJobExecutorThreadCount: 1
- # Adjust the queue size of the import jobs per data type that store data to elasticsearch.
+ # Adjust the queue size of the import jobs per data type that store data to the database.
# A too large value might cause memory problems.
elasticsearchJobExecutorQueueSize: 5
```
diff --git a/optimize/self-managed/optimize-deployment/configuration/shared-elasticsearch-cluster.md b/optimize/self-managed/optimize-deployment/configuration/shared-elasticsearch-cluster.md
index 7025397992..bb01105678 100644
--- a/optimize/self-managed/optimize-deployment/configuration/shared-elasticsearch-cluster.md
+++ b/optimize/self-managed/optimize-deployment/configuration/shared-elasticsearch-cluster.md
@@ -18,10 +18,6 @@ The following illustration demonstrates this use case with two Optimize instance
Changing the value of `*.settings.index.prefix` after an instance was already running results in new indexes being created with the new prefix value. There is no support in migrating data between indexes based on different prefixes.
:::
-:::note
-Not all Optimize features are supported when using OpenSearch as a database. For a full list of the features that are currently supported, please refer to the [Camunda 7](https://github.com/camunda/issues/issues/705) and [Camunda 8](https://github.com/camunda/issues/issues/635) OpenSearch features.
-:::
-
\* Elasticsearch index prefix settings path: `es.settings.index.prefix`
\* OpenSearch index prefix settings path: `opensearch.settings.index.prefix`
![Shared Elasticsearch Cluster Setup](img/shared-elasticsearch-cluster.png)
diff --git a/optimize/self-managed/optimize-deployment/configuration/system-configuration-platform-7.md b/optimize/self-managed/optimize-deployment/configuration/system-configuration-platform-7.md
index e5491a96ae..dd3eddf077 100644
--- a/optimize/self-managed/optimize-deployment/configuration/system-configuration-platform-7.md
+++ b/optimize/self-managed/optimize-deployment/configuration/system-configuration-platform-7.md
@@ -64,16 +64,18 @@ REST API endpoint locations, timeouts, etc.
| import.data.user-task-worker.metadata.maxPageSize | 10000 | The max page size when multiple users or groups are iterated during the metadata refresh. |
| import.data.user-task-worker.metadata.maxEntryLimit | 100000 | The entry limit of the cache that holds the metadata, if you need more entries you can increase that limit. When increasing the limit, keep in mind to account for that by increasing the JVM heap memory as well. Please refer to the "Adjust Optimize heap size" documentation. |
| import.skipDataAfterNestedDocLimitReached | false | Some data can no longer be imported to a given document if its number of nested documents has reached the configured limit. Enable this setting to skip this data during import if the nested document limit has been reached. |
-| import.elasticsearchJobExecutorThreadCount | 1 | Number of threads being used to process the import jobs per data type that are writing data to elasticsearch. |
-| import.elasticsearchJobExecutorQueueSize | 5 | Adjust the queue size of the import jobs per data type that store data to elasticsearch. If the value is too large it might cause memory problems. |
+| import.elasticsearchJobExecutorThreadCount\* | 1 | Number of threads being used to process the import jobs per data type that are writing data to the database. |
+| import.elasticsearchJobExecutorQueueSize\* | 5 | Adjust the queue size of the import jobs per data type that store data to the database. If the value is too large it might cause memory problems. |
| import.handler.backoff.interval | 5000 | Interval in milliseconds which is used for the backoff time calculation. |
| import.handler.backoff.max | 15 | Once all pages are consumed, the import scheduler component will start scheduling fetching tasks in increasing periods of time, controlled by "backoff" counter. |
| import.handler.backoff.isEnabled | true | Tells if the backoff is enabled of not. |
| import.indexType | import-index | The name of the import index type. |
-| import.importIndexStorageIntervalInSec | 10 | States how often the import index should be stored to Elasticsearch. |
+| import.importIndexStorageIntervalInSec | 10 | States how often the import index should be stored to the database. |
| import.currentTimeBackoffMilliseconds | 300000 | This is the time interval the import backs off from the current tip of the time during the ongoing import cycle. This ensures that potentially missed concurrent writes in the engine are reread going back by the amount of this time interval. |
| import.identitySync.includeUserMetaData | true | Whether to include metaData (firstName, lastName, email) when synchronizing users. If disabled only user IDs will be shown on user search and in collection permissions. |
| import.identitySync.collectionRoleCleanupEnabled | false | Whether collection role cleanup should be performed. If enabled, users that no longer exist in the identity provider will be automatically removed from collection permissions. |
| import.identitySync.cronTrigger | `0 */2 * * *` | Cron expression for when the identity sync should run, defaults to every second hour. You can either use the default Cron (5 fields) or the Spring Cron (6 fields) expression format here.
For details on the format please refer to:
- [Cron Expression Description](https://en.wikipedia.org/wiki/Cron)
- [Spring Cron Expression Documentation](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/scheduling/support/CronSequenceGenerator.html)
|
| import.identitySync.maxPageSize | 10000 | The max page size when multiple users or groups are iterated during the import. |
| import.identitySync.maxEntryLimit | 100000 | The entry limit of the user/group search cache. When increasing the limit, keep in mind to account for this by increasing the JVM heap memory as well. Please refer to the "Adjust Optimize heap size" documentation on how to configure the heap size. |
+
+\* Although this parameter includes `ElasticSearch` in its name, it applies to both ElasticSearch and OpenSearch installations. For backward compatibility reasons, the parameter has not been renamed.
diff --git a/optimize/self-managed/optimize-deployment/configuration/system-configuration.md b/optimize/self-managed/optimize-deployment/configuration/system-configuration.md
index 22b7c67c0e..97342e0223 100644
--- a/optimize/self-managed/optimize-deployment/configuration/system-configuration.md
+++ b/optimize/self-managed/optimize-deployment/configuration/system-configuration.md
@@ -186,10 +186,6 @@ Define a secured connection to be able to communicate with a secured Elasticsear
These settings are only relevant when operating Optimize with OpenSearch.
-:::note
-Not all Optimize features are supported when using OpenSearch as a database. For a full list of the features that are currently supported, please refer to the [Camunda 7](https://github.com/camunda/issues/issues/705) and [Camunda 8](https://github.com/camunda/issues/issues/635) OpenSearch features.
-:::
-
#### Connection settings
This section details everything related to building the connection to OpenSearch.
@@ -236,10 +232,6 @@ Define a secured connection to be able to communicate with a secured OpenSearch
| -------------------------------- | ------------- | ------------------------------------------------------------------------ |
| opensearch.backup.repositoryName | "" | The name of the snapshot repository to be used to back up Optimize data. |
-:::note
-The backup functionality is not yet supported for OpenSearch.
-:::
-
### Email
Settings for the email server to send email notifications, e.g. when an alert is triggered.
diff --git a/optimize/self-managed/optimize-deployment/install-and-start.md b/optimize/self-managed/optimize-deployment/install-and-start.md
index 2c99ebde0e..a514fe0b8b 100644
--- a/optimize/self-managed/optimize-deployment/install-and-start.md
+++ b/optimize/self-managed/optimize-deployment/install-and-start.md
@@ -89,10 +89,6 @@ After that, [configure the database connection](./configuration/getting-started.
#### Getting started with the Optimize Docker image
-:::note
-Not all Optimize features are supported when using OpenSearch as a database. For a full list of the features that are currently supported, please refer to the [Camunda 7](https://github.com/camunda/issues/issues/705) and [Camunda 8](https://github.com/camunda/issues/issues/635) OpenSearch features.
-:::
-
##### Full local setup
To start the Optimize Docker image and connect to an already locally running Camunda 7 as well as Elasticsearch instance you could run the following command:
diff --git a/optimize_versioned_docs/version-3.14.0/self-managed/optimize-deployment/advanced-features/import-guide.md b/optimize_versioned_docs/version-3.14.0/self-managed/optimize-deployment/advanced-features/import-guide.md
index f23cda4b3b..451ba66436 100644
--- a/optimize_versioned_docs/version-3.14.0/self-managed/optimize-deployment/advanced-features/import-guide.md
+++ b/optimize_versioned_docs/version-3.14.0/self-managed/optimize-deployment/advanced-features/import-guide.md
@@ -14,17 +14,17 @@ In general, the import assumes the following setup:
- A Camunda engine from which Optimize imports the data.
- The Optimize backend, where the data is transformed into an appropriate format for efficient data analysis.
-- [Elasticsearch](https://www.elastic.co/guide/index.html), which is the database Optimize persists all formatted data to.
+- [Elasticsearch (ES)](https://www.elastic.co/guide/index.html) or [OpenSearch (OS)](https://opensearch.org/), which serves as the database that Optimize uses to persist all of its formatted data.
The following depicts the setup and how the components communicate with each other:
![Optimize Import Structure](img/Optimize-Structure.png)
-Optimize queries the engine data using a dedicated Optimize REST-API within the engine, transforms the data, and stores it in its own Elasticsearch database such that it can be quickly and easily queried by Optimize when evaluating reports or performing analyses. The reason for having a dedicated REST endpoint for Optimize is performance: the default REST-API adds a lot of complexity to retrieve the data from the engine database, which can result in low performance for large data sets.
+Optimize queries the engine data using a dedicated Optimize REST-API within the engine, transforms the data, and stores it in its own database such that it can be quickly and easily queried by Optimize when evaluating reports or performing analyses. The reason for having a dedicated REST endpoint for Optimize is performance: the default REST-API adds a lot of complexity to retrieve the data from the engine database, which can result in low performance for large data sets.
Note the following limitations regarding the data in Optimize's database:
-- The data is only a near real-time representation of the engine database. This means Elasticsearch may not contain the data of the most recent time frame, e.g. the last two minutes, but all the previous data should be synchronized.
+- The data is only a near real-time representation of the engine database. This means the database may not contain the data of the most recent time frame, e.g. the last two minutes, but all the previous data should be synchronized.
- Optimize only imports the data it needs for its analysis. The rest is omitted and won't be available for further investigation. Currently, Optimize imports:
- The history of the activity instances
- The history of the process instances
@@ -47,7 +47,7 @@ This section gives an overview of how fast Optimize imports certain data sets. T
It is very likely that these metrics change for different data sets because the speed of the import depends on how the data is distributed.
-The import is also affected by how the involved components are set up. For instance, if you deploy the Camunda engine on a different machine than Optimize and Elasticsearch to provide both applications with more computation resources, the process is likely to speed up. If the Camunda engine and Optimize are physically far away from each other, the network latency might slow down the import.
+The import is also affected by how the involved components are set up. For instance, if you deploy the Camunda engine on a different machine than Optimize and Elasticsearch/OpenSearch to provide both applications with more computation resources, the process is likely to speed up. If the Camunda engine and Optimize are physically far away from each other, the network latency might slow down the import.
### Setup
@@ -135,7 +135,7 @@ During execution, the following steps are performed:
2. Map entities and add an import job
3. [Execute the import](#execute-the-import).
1. Poll a job
- 2. Persist the new entities to Elasticsearch
+ 2. Persist the new entities to the database
### Start an import round
@@ -175,33 +175,37 @@ First, the `ImportScheduler` retrieves the newest index, which identifies the la
#### Map entities and add an import job
-All fetched entities are mapped to a representation that allows Optimize to query the data very quickly. Subsequently, an import job is created and added to the queue to persist the data in Elasticsearch.
+All fetched entities are mapped to a representation that allows Optimize to query the data very quickly. Subsequently, an import job is created and added to the queue to persist the data in the database.
### Execute the import
Full aggregation of the data is performed by a dedicated `ImportJobExecutor` for each entity type, which waits for `ImportJob` instances to be added to the execution queue. As soon as a job is in the queue, the executor:
- Polls the job with the new Optimize entities
-- Persists the new entities to Elasticsearch
+- Persists the new entities to the database
The data from the engine and Optimize do not have a one-to-one relationship, i.e., one entity type in Optimize may consist of data aggregated from different data types of the engine. For example, the historic process instance is first mapped to an Optimize `ProcessInstance`. However, for the heatmap analysis it is also necessary for `ProcessInstance` to contain all activities that were executed in the process instance.
-Therefore, the Optimize `ProcessInstance` is an aggregation of the engine's historic process instance and other related data: historic activity instance data, user task data, and variable data are all [nested documents](https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html) within Optimize's `ProcessInstance` representation.
+Therefore, the Optimize `ProcessInstance` is an aggregation of the engine's historic process instance and other related data: historic activity instance data, user task data, and variable data are all nested documents ([ES](https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html) / [OS](https://opensearch.org/docs/latest/field-types/supported-field-types/nested/)) within Optimize's `ProcessInstance` representation.
:::note
-Optimize uses [nested documents](https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html), the above mentioned data is an example of documents that are nested within Optimize's `ProcessInstance` index.
+Optimize uses nested documents ([ES](https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html) / [OS](https://opensearch.org/docs/latest/field-types/supported-field-types/nested/)), the above mentioned data is an example of documents that are nested within Optimize's `ProcessInstance` index.
-Elasticsearch applies restrictions regarding how many objects can be nested within one document. If your data includes too many nested documents, you may experience import failures. To avoid this, you can temporarily increase the nested object limit in Optimize's [index configuration](./../configuration/system-configuration.md#index-settings). Note that this might cause memory errors.
+Elasticsearch and OpenSearch apply restrictions regarding how many objects can be nested within one document. If your data includes too many nested documents, you may experience import failures. To avoid this, you can temporarily increase the nested object limit in Optimize's [index configuration](./../configuration/system-configuration.md#index-settings). Note that this might cause memory errors.
:::
Import executions per engine entity are actually independent from another. Each follows a [producer-consumer-pattern](https://dzone.com/articles/producer-consumer-pattern), where the type specific `ImportService` is the single producer and a dedicated single `ImportJobExecutor` is the consumer of its import jobs, decoupled by a queue. So, both are executed in different threads. To adjust the processing speed of the executor, the queue size and the number of threads that process the import jobs can be configured:
+:::note
+Although the parameters below include `ElasticSearch` in their name, they apply to both ElasticSearch and OpenSearch installations. For backward compatibility reasons, the parameters have not been renamed.
+:::
+
```yaml
import:
# Number of threads being used to process the import jobs per data type that are writing
- # data to elasticsearch.
+ # data to the database.
elasticsearchJobExecutorThreadCount: 1
- # Adjust the queue size of the import jobs per data type that store data to elasticsearch.
+ # Adjust the queue size of the import jobs per data type that store data to the database.
# A too large value might cause memory problems.
elasticsearchJobExecutorQueueSize: 5
```
From 7760eeea0a62ba38965af06a6d9cbb6be6742447 Mon Sep 17 00:00:00 2001
From: gbetances089
Date: Thu, 12 Dec 2024 10:01:06 +0100
Subject: [PATCH 19/26]
task(c8run)-update-guides-after-8.6.6-and-alpha2-release (#4753)
---
docs/guides/react-components/_install-c8run.md | 2 +-
docs/self-managed/setup/deploy/local/c8run.md | 2 +-
.../version-8.6/guides/react-components/_install-c8run.md | 2 +-
.../version-8.6/self-managed/setup/deploy/local/c8run.md | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/docs/guides/react-components/_install-c8run.md b/docs/guides/react-components/_install-c8run.md
index 3047dee787..520996f22c 100644
--- a/docs/guides/react-components/_install-c8run.md
+++ b/docs/guides/react-components/_install-c8run.md
@@ -11,7 +11,7 @@ If no version of Java is found, follow your chosen installation's instructions f
### Install and start Camunda 8 Run
-1. Download the [latest release of Camunda 8 Run](https://github.com/camunda/camunda/releases/tag/8.7.0-alpha1) for your operating system and architecture. Opening the .tgz file extracts the Camunda 8 Run script into a new directory.
+1. Download the [latest release of Camunda 8 Run](https://github.com/camunda/camunda/releases/tag/8.7.0-alpha2) for your operating system and architecture. Opening the .tgz file extracts the Camunda 8 Run script into a new directory.
2. Navigate to the new `c8run` directory.
3. Start Camunda 8 Run by running `./start.sh` (or `.\c8run.exe start` on Windows) in your terminal.
diff --git a/docs/self-managed/setup/deploy/local/c8run.md b/docs/self-managed/setup/deploy/local/c8run.md
index 7684e4269f..881836191e 100644
--- a/docs/self-managed/setup/deploy/local/c8run.md
+++ b/docs/self-managed/setup/deploy/local/c8run.md
@@ -36,7 +36,7 @@ If no version of Java is found, follow your chosen installation's instructions f
## Install and start Camunda 8 Run
-1. Download the [latest release of Camunda 8 Run](https://github.com/camunda/camunda/releases/tag/8.7.0-alpha1) for your operating system and architecture. Opening the .tgz file extracts the Camunda 8 Run script into a new directory.
+1. Download the [latest release of Camunda 8 Run](https://github.com/camunda/camunda/releases/tag/8.7.0-alpha2) for your operating system and architecture. Opening the .tgz file extracts the Camunda 8 Run script into a new directory.
2. Navigate to the new `c8run` directory.
3. Start Camunda 8 Run by running `./start.sh` (or `.\c8run.exe start` on Windows) in your terminal.
diff --git a/versioned_docs/version-8.6/guides/react-components/_install-c8run.md b/versioned_docs/version-8.6/guides/react-components/_install-c8run.md
index ee83da5d46..50fb42c079 100644
--- a/versioned_docs/version-8.6/guides/react-components/_install-c8run.md
+++ b/versioned_docs/version-8.6/guides/react-components/_install-c8run.md
@@ -11,7 +11,7 @@ If no version of Java is found, follow your chosen installation's instructions f
### Install and start Camunda 8 Run
-1. Download the [latest release of Camunda 8 Run](https://github.com/camunda/camunda/releases/tag/8.6.5) for your operating system and architecture. Opening the .tgz file extracts the Camunda 8 Run script into a new directory.
+1. Download the [latest release of Camunda 8 Run](https://github.com/camunda/camunda/releases/tag/8.6.6) for your operating system and architecture. Opening the .tgz file extracts the Camunda 8 Run script into a new directory.
2. Navigate to the new `c8run` directory.
3. Start Camunda 8 Run by running `./start.sh` (or `.\c8run.exe start` on Windows) in your terminal.
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/local/c8run.md b/versioned_docs/version-8.6/self-managed/setup/deploy/local/c8run.md
index 1eb1b655df..de44b09632 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/local/c8run.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/local/c8run.md
@@ -36,7 +36,7 @@ If no version of Java is found, follow your chosen installation's instructions f
## Install and start Camunda 8 Run
-1. Download the [latest release of Camunda 8 Run](https://github.com/camunda/camunda/releases/tag/8.6.5) for your operating system and architecture. Opening the .tgz file extracts the Camunda 8 Run script into a new directory.
+1. Download the [latest release of Camunda 8 Run](https://github.com/camunda/camunda/releases/tag/8.6.6) for your operating system and architecture. Opening the .tgz file extracts the Camunda 8 Run script into a new directory.
2. Navigate to the new `c8run` directory.
3. Start Camunda 8 Run by running `./start.sh` (or `.\c8run.exe start` on Windows) in your terminal.
From ccdafa96f627bdb09e3a29a5fccb7c47478a0996 Mon Sep 17 00:00:00 2001
From: Ingo Richtsmeier
Date: Thu, 12 Dec 2024 10:53:07 +0100
Subject: [PATCH 20/26] More explicit description how to apply the DNS changes
(#4747)
* More explicit description how to apply the DNS changes
* tech writer edits
---------
Co-authored-by: Cole Garbo
Co-authored-by: Mark Sellings
---
.../self-managed/setup/deploy/amazon/amazon-eks/dual-region.md | 3 ++-
.../self-managed/setup/deploy/amazon/amazon-eks/dual-region.md | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/docs/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md b/docs/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md
index 68aa8a6c4d..137adb9efe 100644
--- a/docs/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md
+++ b/docs/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md
@@ -233,7 +233,8 @@ kubectl --context $CLUSTER_1 apply -f https://raw.githubusercontent.com/camunda/
```
3. The script will retrieve the IPs of the load balancer via the AWS CLI and return the required config change.
-4. As the script suggests, copy the statement between the placeholders to edit the CoreDNS configmap in cluster 0 and cluster 1, depending on the placeholder.
+4. The script prints the `kubectl edit` commands to change the DNS settings of each cluster inline. Copy the statement between the placeholders to edit the CoreDNS configmap in cluster 0 and cluster 1, depending on the placeholder.
+ An alternative to inline editing is to create two copies of the file `kubernetes/coredns.yml`, one for each cluster. Add the section generated by the script to each file. Apply the changes to each cluster with e.g. `kubectl --context cluster-london -n kube-system apply -f file.yml`. Replace the `context` parameter with your current values.
Example output
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md
index 49af2c274a..15670e7721 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/dual-region.md
@@ -233,7 +233,8 @@ kubectl --context $CLUSTER_1 apply -f https://raw.githubusercontent.com/camunda/
```
3. The script will retrieve the IPs of the load balancer via the AWS CLI and return the required config change.
-4. As the script suggests, copy the statement between the placeholders to edit the CoreDNS configmap in cluster 0 and cluster 1, depending on the placeholder.
+4. The script prints the `kubectl edit` commands to change the DNS settings of each cluster inline. Copy the statement between the placeholders to edit the CoreDNS configmap in cluster 0 and cluster 1, depending on the placeholder.
+ An alternative to inline editing is to create two copies of the file `kubernetes/coredns.yml`, one for each cluster. Add the section generated by the script to each file. Apply the changes to each cluster with e.g. `kubectl --context cluster-london -n kube-system apply -f file.yml`. Replace the `context` parameter with your current values.
Example output
From 688013ba2deb274b4d1e81c80d5c9a495511f1e7 Mon Sep 17 00:00:00 2001
From: Mark Sellings
Date: Thu, 12 Dec 2024 10:33:30 +0000
Subject: [PATCH 21/26] Announcements for 8.7 release (#4679)
* Initial setup
* Initial structure
* Initial content updates
* Edits
* Edit intro
* Edit following meeting
* TW edits
* Restructure announcements
* TW edits
* Remove headings
* Changes to APIs
* Add Manual installation section
* Announcements landing page format
* Fix formatting
* Badges CSS
* Landing page edits
* TW edits
* Add camunda Exporter from PR 4715
* added Separated Ingress removal
* Tasklist announcement
---------
Co-authored-by: Ahmed AbouZaid <6760103+aabouzaid@users.noreply.github.com>
---
docs/reference/announcements.md | 453 +++---------------
docs/reference/announcements/850.md | 188 ++++++++
docs/reference/announcements/860.md | 182 +++++++
docs/reference/announcements/870.md | 183 +++++++
docs/reference/img/doc-icon.png | Bin 0 -> 213 bytes
.../img/harmonized-indices-schema.png | Bin 0 -> 163835 bytes
.../reference/img/target-camunda-exporter.png | Bin 0 -> 55175 bytes
sidebars.js | 14 +-
src/css/custom.css | 33 ++
9 files changed, 675 insertions(+), 378 deletions(-)
create mode 100644 docs/reference/announcements/850.md
create mode 100644 docs/reference/announcements/860.md
create mode 100644 docs/reference/announcements/870.md
create mode 100644 docs/reference/img/doc-icon.png
create mode 100644 docs/reference/img/harmonized-indices-schema.png
create mode 100644 docs/reference/img/target-camunda-exporter.png
diff --git a/docs/reference/announcements.md b/docs/reference/announcements.md
index adbeb28643..da89278137 100644
--- a/docs/reference/announcements.md
+++ b/docs/reference/announcements.md
@@ -1,420 +1,119 @@
---
id: announcements
title: "Announcements"
-description: "Important announcements including deprecation & removal notices"
+description: "Important announcements for upcoming and past Camunda 8 releases that customers should be aware of, including deprecation & removal notices."
---
-## Camunda 8.7
-
-Release date: TBD
-
-End of maintenance: TBD
-
-### Southeast Asia now available for SaaS customers
-
-SaaS customers can now create orchestration clusters in the [Singapore (asia-southeast1) region](/reference/regions.md), ensuring lower latency and improved processing speed for organizations operating in southeast Asian countries.
-
-## Camunda 8.6
-
-Release date: 8th of Oct 2024
-
-End of maintenance: 14th of April 2026
-
-### License key changes
-
-With the 8.6 release, Camunda 8 Self-Managed requires a license key for production usage. For additional details, review the [blog post on licensing updates for Camunda 8 Self-Managed](https://camunda.com/blog/2024/04/licensing-update-camunda-8-self-managed/).
-
-Review the following documentation for your components for more information on how to provide the license key to each component as an environment variable:
-
-- [Console](/self-managed/console-deployment/configuration.md#environment-variables)
-- [Zeebe](/self-managed/zeebe-deployment/configuration/configuration.md#licensing)
-- [Operate](/self-managed/operate-deployment/operate-configuration.md#licensing)
-- [Tasklist](/self-managed/tasklist-deployment/tasklist-configuration.md#licensing)
-- [Optimize]($optimize$/self-managed/optimize-deployment/configuration/system-configuration-platform-8#licensing)
-- [Identity](/self-managed/identity/deployment/configuration-variables.md#license-configuration)
-- [Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#licensing)
-
-To configure with Helm, visit the [Self Managed installation documentation](/self-managed/setup/install.md).
-
-:::note
-Camunda 8 components without a valid license may display **Non-Production License** in the navigation bar and issue warnings in the logs. These warnings have no impact on startup or functionality, with the exception that Web Modeler has a limitation of five users. To obtain a license, visit the [Camunda Enterprise page](https://camunda.com/platform/camunda-platform-enterprise-contact/).
-:::
-
-### Zeebe Java client
-
-Starting with 8.7, the Zeebe Java client will become the new Camunda Java client. This transition brings a new Java client structure designed to enhance the user experience and introduce new features while maintaining compatibility with existing codebases.
-
-The primary goal of those changes is to enable users to interact with Camunda clusters with one consolidated client rather than multiple. The `CamundaClient` will replace the `ZeebeClient`, offering the same functionality and adding new capabilities. If you need to continue using the old `ZeebeClient`, you can use the version 8.6 artifact without any issues with newer cluster versions as the client is forward-compatible.
-
-:::note
-The Zeebe Java client will not be developed further and will only receive bug fixes for as long as version 8.6 is officially supported.
-:::
-
-#### Key changes
-
-- **New package structure**:
- - Package `io.camunda.client`: This package contains the new `CamundaClient` and all the features slated for release in version 8.7.
-- **Properties and environment variables refactoring**:
- - All old Java client property names will be refactored to more general ones. For instance, `zeebe.client.tenantId` will become `camunda.client.tenantId`.
- - Similarly, environment variables will be renamed following the same concept: `ZEEBE_REST_ADDRESS` will become `CAMUNDA_REST_ADDRESS`.
-- **Artifact ID change**:
- - The `artifactId` will change from `zeebe-client-java` to `camunda-client-java`.
-
-### Deprecation: Zeebe Go client & CLI client (zbctl)
-
-The Zeebe Go Client and CLI client (zbctl) will be [officially deprecated](https://camunda.com/blog/2024/09/deprecating-zbctl-and-go-clients/) with the 8.6 release as part of our efforts to streamline the Camunda 8 API experience. This client and CLI utility will not be released starting with Camunda 8.6, will no longer receive new features, and will be transitioned to a community-maintained status.
-
-The documentation of the Zeebe Go Client and CLI client (zbctl) moved to the [community clients section](/apis-tools/community-clients/index.md).
-
-### Camunda 8 SaaS - Required cluster update
-
-:::caution
-By **August 30th, 2024** all automation clusters in Camunda 8 SaaS must be [updated](/components/console/manage-clusters/manage-cluster.md#update-a-cluster) to the following versions at a **minimum**:
-
-- **8.2+gen27**
-- **8.3+gen11**
-- **8.4+gen7**
-- **8.5+gen2**
-
-:::
-
-auth0 announced an End-Of-Life for one of the functionalities that is being utilized by previous automation clusters. The new versions are not using this functionality anymore. This update ensures your cluster will work seamlessly after auth0 deactivates the feature in production.
-
-You minimally need to take the following [update](/components/console/manage-clusters/manage-cluster.md#update-a-cluster) path:
-
-- 8.0.x -> 8.2+gen27
-- 8.1.x -> 8.2+gen27
-- 8.2.x -> 8.2+gen27
-- 8.3.x -> 8.3+gen11
-- 8.4.x -> 8.4+gen7
-- 8.5.x -> 8.5+gen2
-
-If you do not update the cluster by August 30th 2024, we will update the cluster for you. **Without an update, you would lose access to your cluster.**
+Important changes and updates for Camunda 8 releases that customers should be aware of, including deprecation & removal notices.
-Camunda 8 Self-Managed clusters are not affected by this.
-
-### Support for Amazon OpenSearch for Optimize
-
-This release extends the OpenSearch features supported by Optimize. Full support is committed for the next release in January 2025.
-
-### Supported environment changes (OpenJDK, ElasticSearch, Amazon OpenSearch)
-
-Version changes are made to supported environments:
-
-- OpenJDK minimum version raised to 21+ in Operate
-- ElasticSearch minimum version raised to 8.13+
-- Amazon OpenSearch minimum version raised to 2.9+
-
-To learn more about supported environments, see [supported environments](/reference/supported-environments.md).
-
-### Connectors
-
-#### Deprecation: None start event element templates for Kafka, RabbitMQ, Amazon SQS, and Amazon SNS inbound Connectors
-
-The [none start event](/components/modeler/bpmn/none-events/none-events.md#none-start-events) element templates for the out-of-the-box Kafka, RabbitMQ, Amazon SQS, and Amazon SNS inbound Connectors have been deprecated in Camunda Modeler.
-
-Users can no longer select these templates when creating a new none start event element in Camunda Modeler. Existing none start event elements with these templates will continue to work as expected, but users are encouraged to migrate to the [message start event](/components/modeler/bpmn/message-events/message-events.md#message-start-events) element templates for these Connectors.
-
-Message start event element templates are better suited for the message-based communication these Connectors provide, and offer more flexibility and features compared to the none start event element templates, such as the ability to define a message ID and a correlation key for idempotency. Read more in the [inbound Connectors documentation](/components/connectors/use-connectors/inbound.md) and the [messaging concepts documentation](/components/concepts/messages.md#message-uniqueness).
-
-#### Breaking changes in the Connector SDK
-
-The `void correlate(Object variables)` method in the `InboundConnectorContext` interface has been removed, following the deprecation in 8.4.0. Use the `CorrelationResult correlateWithResult(Object variables)` method instead.
-
-The `CorrelationResult` record has been changed compared to the previous versions:
-
-- `CorrelationResult.Success` now contains a `ProcessElementContext` that represents the element that was correlated. Compared to the previous version, where the correlated element was returned directly, this change allows accessing element properties after correlation for user-controlled post-correlation actions.
-- `CorrelationResult.Failure` now provides the `CorrelationFailureHandlingStrategy` that defines how the failure should be handled.
-
-An example of how to use the new `CorrelationResult` can be found in the [Connector SDK documentation](/components/connectors/custom-built-connectors/connector-sdk.md#inbound-connector-runtime-logic).
-
-### Flow control enabled by default in SaaS
-
-Flow control is now enabled by default in Camunda 8.6 SaaS. This change ensures the cluster is protected from excessive load and can maintain a stable state.
-
-These new configuration defaults are tailored to the cluster size and optimized for a stable performance. However, the cluster might reject requests if the load is too high with this change. The error message for this is `Failed to write client request to partition X, because the write limit is exhausted`. If the error persists, this may be a sign of underlining issues, or a need to adjust the cluster size.
-
-For more information on how to configure flow control for a Self-Managed cluster, visit the [flow control documentation](/self-managed/operational-guides/configure-flow-control/configure-flow-control.md).
-
-### Camunda 8 Self-Managed
-
-#### Helm chart - Separated Ingress deprecation
-
-The separated Ingress Helm configuration for Camunda 8 Self-Managed has been deprecated in 8.6, and will be removed from the Helm chart in 8.7. Only the combined Ingress configuration is officially supported. See the [Ingress guide](/self-managed/setup/guides/ingress-setup.md) for more information on configuring a combined Ingress setup.
-
-#### Helm chart - `global.multiregion.installationType` deprecation
-
-The `global.multiregion.installationType` option is used in failover and failback scenarios. This option in the Helm chart has been deprecated in 8.6, and will be removed from the Helm chart in 8.7. `global.multiregion.installationType` was replaced with a set of API endpoints called while following the ([dual-region operational procedure](/self-managed/operational-guides/multi-region/dual-region-ops.md))
-
-#### Helm chart - Elasticsearch nodes number
-
-The default value of Elasticsearch deployment pods has changed from 2 to 3, and an affinity setting has been added to avoid scheduling Elasticsearch pods on the same Kubernetes worker.
+## Camunda 8.7
-### Camunda Optimize artifact and Docker tag separation
+Camunda 8.7 is scheduled for release on 11 February, 2024.
-Starting with Camunda 8.6, the Camunda Optimize artifact has been split into two distinct versions, and versioning between Camunda 7 and Camunda 8 is no longer interchangeable:
+
+
-- **Before Camunda 8.6**: Versions like `8.x` and `3.x` (used for Camunda 7) could sometimes be used interchangeably.
-- **From Camunda 8.6 onwards**: `8.6 != 3.14`. Each version corresponds strictly to its platform:
- - **Camunda 7**: Uses the `3.x` versioning scheme and the `latest` Docker tag.
- - **Camunda 8**: Uses the `8.x` versioning scheme and the `8-latest` Docker tag.
+**[8.7 Announcements](/reference/announcements/870.md)**
-#### Action required:
+
+
-- **Camunda 7 Users**: Continue using `3.x` versions and the `latest` Docker tag.
-- **Camunda 8 Users**: If you haven't already done so, update your configurations to use `8.x` versions and the `8-latest` Docker tag.
+- [API updates](/reference/announcements/870.md#api-updates-saasself-managed)
+- [Identity management updates](/reference/announcements/870.md#identity-management-updates-saasself-managed)
+- [Installation and deployment updates](/reference/announcements/870.md#installation-and-deployment-updates-self-managed)
+- [Camunda Java client and Camunda Spring SDK](/reference/announcements/870.md#camunda-java-client-and-camunda-spring-sdk-self-managed)
-Make sure to update your Docker configurations accordingly to ensure compatibility.
+
+
-### New base path for Operate and Tasklist web applications
+## Camunda 8.6
-We are introducing a new base path for both the Operate and Tasklist **web applications**. This change applies to both Self-Managed and SaaS environments.
+Camunda 8.6 was released on 8 October, 2024.
-#### For Self-Managed
+
+
-- The new base path for Operate is `/operate`, and for Tasklist, it is `/tasklist`.
-- For a [Separated Ingress](/self-managed/setup/guides/ingress-setup.md?ingress=separated) configuration:
- - for Operate, the full URL will be `{operate-host}/operate`. Any calls to `{operate-host}` will automatically be redirected to `{operate-host}/operate`
- - for Tasklist, the full URL will be `{tasklist-host}/tasklist`. Any calls to `{tasklist-host}` will automatically be redirected to `{tasklist-host}/tasklist`.
-- For a [Combined Ingress](/self-managed/setup/guides/ingress-setup.md?ingress=combined) configuration:
- - for Operate, the full URL will be `{common-host}/{operate-contextPath}/operate`. Any calls to `{common-host}/{operate-contextPath}` will be automatically redirected to `{common-host}/{operate-contextPath}/operate`.
- - for Tasklist, the full URL will be `{common-host}/{tasklist-contextPath}/tasklist`. Any calls to `{common-host}/{tasklist-contextPath}` will be automatically redirected to `{common-host}/{tasklist-contextPath}/tasklist`.
+**[8.6 Announcements](/reference/announcements/860.md)**
-#### For SaaS
+
+
-- The full URL for Operate is now structured as `https://{region}.operate.camunda.io/{clusterId}/operate`.
-- The full URL for Tasklist is now structured as `https://{region}.tasklist.camunda.io/{clusterId}/tasklist`.
-- Any calls to `https://{region}.operate.camunda.io/{clusterId}` will be redirected to `https://{region}.operate.camunda.io/{clusterId}/operate`.
-- Any calls to `https://{region}.tasklist.camunda.io/{clusterId}` will be redirected to `https://{region}.tasklist.camunda.io/{clusterId}/tasklist`.
+- [License key changes](/reference/announcements/860.md#license-key-changes)
+- [Zeebe Java client](/reference/announcements/860.md#zeebe-java-client)
+- [Deprecation: Zeebe Go client & CLI client (zbctl)](/reference/announcements/860.md#deprecation-zeebe-go-client--cli-client-zbctl)
+- [Camunda 8 SaaS - Required cluster update](/reference/announcements/860.md#camunda-8-saas---required-cluster-update)
+- [Support for Amazon OpenSearch for Optimize](/reference/announcements/860.md#support-for-amazon-opensearch-for-optimize)
+- [Supported environment changes](/reference/announcements/860.md#supported-environment-changes-openjdk-elasticsearch-amazon-opensearch)
+- [Connectors](/reference/announcements/860.md#connectors)
+- [Flow control enabled by default in SaaS](/reference/announcements/860.md#flow-control-enabled-by-default-in-saas)
+- [Camunda 8 Self-Managed](/reference/announcements/860.md#camunda-8-self-managed)
+- [Camunda Optimize artifact and Docker tag separation](/reference/announcements/860.md#camunda-optimize-artifact-and-docker-tag-separation)
+- [New base path for Operate and Tasklist web applications](/reference/announcements/860.md#new-base-path-for-operate-and-tasklist-web-applications)
-:::note
-**API URLs** for both Operate and Tasklist remain **unchanged**.
-:::
+
+
## Camunda 8.5
-Release date: 9th of April 2024
-
-End of maintenance: 14th of October 2025
-
-### Updated SaaS URLs
-
-We will simplify the URL for Camunda 8 SaaS from cloud.camunda.io ([console.cloud.camunda.io](https://console.cloud.camunda.io/)) to camunda.io ([console.camunda.io](http://console.camunda.io/)).
+Camunda 8.5 was released on 9 April, 2024.
-On or around July 9th, users will be directed to the new URLs. Both URLs will continue to be active for at least 18 months so navigation from supported versions of components like Operate is still possible.
+
+
-Internal allowlisting or active rules for [cloud.camunda.io](http://cloud.camunda.io/) must be transitioned to the new [camunda.io](http://camunda.io/) URL. This change primarily affects Console and Modeler. During sign up, users will be briefly redirected through [accounts.cloud.camunda.io](http://accounts.camunda.io/), which will also be updated.
+**[8.5 Announcements](/reference/announcements/850.md#camunda-85)**
-### Syntax changes in Helm chart
+
+
-A Camunda Helm chart upgrade is not possible from v9.x.x to v10.0.0 or v10.0.1. Instead, upgrade directly to v10.0.2+.
+- [Updated SaaS URLs](/reference/announcements/850.md#updated-saas-urls)
+- [Syntax changes in Helm chart](/reference/announcements/850.md#syntax-changes-in-helm-chart)
+- [Support for Amazon OpenSearch](/reference/announcements/850.md#support-for-amazon-opensearch)
+- [Known limitations](/reference/announcements/850.md#known-limitations)
+- [Changes in supported environments](/reference/announcements/850.md#changes-in-supported-environments)
+- [New generation naming scheme](/reference/announcements/850.md#camunda-saas-new-generation-naming-scheme)
+- [Removal of Web Modeler's beta API](/reference/announcements/850.md#removal-of-web-modelers-beta-api)
+- [Serialization of timestamp values in management API](/reference/announcements/850.md#zeebe-850-breaks-serialization-of-timestamp-values-in-management-api-self-managed-only)
-The Camunda Helm chart v10.0.0 has major changes in the values file structure. Some keys in the values file have been changed. For compatibility, the keys are deprecated in the Camunda release cycle 8.5 and will be removed in the Camunda 8.6 release (October 2024).
-
-Follow the [upgrade instructions](/self-managed/setup/upgrade.md#helm-chart-1002+) to upgrade from Camunda Helm chart v9.x.x to Camunda Helm chart v10.x.x.
-
-### Support for Amazon OpenSearch
-
-With the 8.5 release, Optimize is now also compatible with [Amazon OpenSearch](https://aws.amazon.com/de/opensearch-service/) 2.5+. Note that using Amazon OpenSearch requires [setting up a new Camunda installation](/self-managed/setup/overview.md). A migration from previous versions or Elasticsearch environments is not supported.
-
-### Known limitations
-
-This release contains the following limitations:
-
-- In **Optimize `8.5.0`**
- - **Limitation**
- - **Description:** OpenSearch support in Optimize is limited to data import and the raw data report.
- - **Reference:** n/a
- - **Mitigation:** Optimize can be installed and used in production with limited reporting functionality. Optimize imports all process data generated by Zeebe. All reporting functionality as described in the docs will be delivered with upcoming patches.
-- In **Console `8.5.x`**
- - **Limitation**
- - **Description:** Custom OIDC provider support for Console is not supported
- - **Reference:** https://github.com/camunda/issues/issues/784
-
-### Changes in supported environments
-
-- Raised minimum Go version to 1.21 for the Zeebe Go client
-
-### Camunda SaaS: New generation naming scheme
-
-With the April release, the generation naming scheme in Camunda 8 changed and no longer includes the patch version.
-
-The new naming scheme used for all Camunda SaaS generations created after April 2024 is `Camunda .+gen`, where `N` is incremented with every atomic change to the component version set. Existing generations will not be renamed.
-
-For patch releases to existing generations, `N` is set to the latest patch level plus 1. For example, when `Camunda 8.4.5` is the current generation name, the following patch will be released as `Camunda 8.4+gen6`.
-
-This was done to decouple the generation name from the particular patch level of the components it contains, as some component versions like Connectors are decoupled from other components.
-
-You will learn about the particular component patch version changes in the update dialogue to the latest generation available. The following screenshot shows a sample update from `Camunda 8.5+gen1` to `Camunda 8.5+gen2`, where only the Connectors patch version changed.
-
-![New Generating naming sample showing an update dialogue from 8.5+gen1 to 8.5+gen2](img/generation-naming-scheme-sample.png)
-
-Note that the actual values shown in this screenshot don't correspond to any actual generations and only serve as an example.
-
-### Removal of Web Modeler's beta API
-
-The Web Modeler beta API has been removed. The API was deprecated in 8.3 and is no longer available in 8.5. Use the [Web Modeler v1 API](/apis-tools/web-modeler-api/index.md) instead.
-For a migration guide, see the [Web Modeler API documentation](/apis-tools/web-modeler-api/index.md#migrating-from-beta-to-v1).
-
-### Zeebe 8.5.0 breaks serialization of timestamp values in management API (Self-Managed only)
-
-Zeebe 8.5.0 was released with [a new bug](https://github.com/camunda/camunda/issues/17347) that breaks serialization of timestamp values in management APIs, such as [backup](/self-managed/operational-guides/backup-restore/backup-and-restore.md) and [cluster scaling](/self-managed/zeebe-deployment/operations/cluster-scaling.md).
-Timestamps which were previously serialized as `ISO8061` strings are now serialized as integer values.
-
-Until a fix is delivered in 8.5.1, workarounds include not deserializing timestamp values from affected APIs, or deserializing them as integers.
+
+
## Camunda 8.4
-Release date: 9th of January 2024
-
-End of maintenance: 9th of July 2025
-
-:::caution
-The [form linking](/components/modeler/web-modeler/advanced-modeling/form-linking.md#using-the-link-button) feature is impacted by an [issue](https://github.com/camunda/camunda/issues/16311) where the wrong forms can get linked with new user task instances, effectively corrupting the user task instance. If you make use of this feature and run either `8.4.0`, `8.4.1` or `8.4.2`, we urge you to update to the newest `8.4.3` patch that includes the required fix.
-
-Follow the instructions in the [form linking](/components/modeler/web-modeler/advanced-modeling/form-linking.md#known-issues-with-linked-forms) documentation to resolve this issue.
-:::
-
-### Versioning changes in Helm chart
-
-As of the 8.4 release, the Camunda 8 **Helm chart** version is decoupled from the version of the application. The Helm chart release still follows the applications release cycle, but it has an independent version. (e.g., in the application release cycle 8.4, the chart version is 9.0.0).
-
-For more details about the applications version included in the Helm chart, review the [full version matrix](https://helm.camunda.io/camunda-platform/version-matrix/).
-
-### Dockerfile numeric ID
-
-The Dockerfile now uses a numeric user ID instead of a non-numeric user.
-This will allow the Helm users to use `runAsNonRoot=true` without the need to explicitly set the ID in the Helm `values.yaml` file.
-
-### Deprecated in 8.4
-
-The [Zeebe configuration properties for Camunda Identity](../self-managed/zeebe-deployment/configuration/gateway.md#zeebegatewayclustersecurityauthenticationidentity)
-were deprecated in `8.4`. Please use the dedicated Camunda Identity properties or the [corresponding environment variables](../self-managed/identity/deployment/configuration-variables.md#core-configuration).
-
-### Versioning changes in Elasticsearch
+Camunda 8.4 was released on 9 January, 2024.
-As of the 8.4 release, Camunda is compatible with Elasticsearch 8.9+ and no longer supports older Elasticsearch versions. See [supported environments](/reference/supported-environments.md).
+
+
-### Support for Amazon OpenSearch
+**[8.4 Announcements](/reference/announcements/850.md#camunda-84)**
-As of the 8.4 release, Zeebe, Operate, and Tasklist are now compatible with [Amazon OpenSearch](https://aws.amazon.com/de/opensearch-service/) 2.5.x. Note that using Amazon OpenSearch requires [setting up a new Camunda installation](/self-managed/setup/overview.md). A migration from previous versions or Elasticsearch environments is currently not supported.
+
+
-:::info
-The Helm charts are not yet prepared with the OpenSearch configurations as templates/pre-filled. The Helm charts can still be used to install for OpenSearch, but some adjustments are needed beforehand. Refer to the [Helm deployment documentation](/self-managed/setup/install.md) for further details.
-:::
+- [Versioning changes in Helm chart](/reference/announcements/850.md#versioning-changes-in-helm-chart)
+- [Dockerfile numeric ID](/reference/announcements/850.md#dockerfile-numeric-id)
+- [Deprecated in 8.4](/reference/announcements/850.md#deprecated-in-84)
+- [Versioning changes in Elasticsearch](/reference/announcements/850.md#versioning-changes-in-elasticsearch)
+- [Support for Amazon OpenSearch](/reference/announcements/850.md#support-for-amazon-opensearch-1)
+- [Known limitations](/reference/announcements/850.md#known-limitations-1)
-### Known limitations
-
-This release contains the following limitations:
-
-- In **Operate `8.4.0`**
- - **Bug**
- - **Description:** Instance migration always points to the latest process version
- - **Reference:** https://github.com/camunda/issues/issues/567
- - **Mitigation:** Bug is planned to be fixed with upcoming `8.4.1` release
- - **Bug**
- - **Description:** Backwards migration over multiple versions does not work
- - **Reference:** https://github.com/camunda/issues/issues/568
- - **Mitigation:** Bug is planned to be fixed with upcoming `8.4.1` release
-- In **Camunda HELM `9.0.x`**
- - **Limitation**
- - **Description:** The existing Helm charts use the Elasticsearch configurations by default and are not yet prepared with the OpenSearch configurations as templates/pre-filled. The Helm charts can still be used to install for OpenSearch, but some adjustments are needed beforehand.
- - **Reference:** n/a
- - **Mitigation:**
- 1. Refer to our [docs for the installation](/self-managed/setup/install.md#components-installed-by-the-helm-charts), the docs include guidance about necessary adjustments of the Helm chart configuration.
- 2. The OpenSearch configuration in Helm charts will be provided in one of our future Helm releases.
-- In **Connectors `8.4.x`**
- - **Missing feature**
- - **Description:** Custom OIDC provider support for Connectors is missing
- - **Reference:** https://github.com/camunda/issues/issues/569
- - **Mitigation:**
- 1. Feature is planned to be delivered with an upcoming patch release. Please see [issue](https://github.com/camunda/issues/issues/569) for latest progress.
- 2. [Disable Connectors component](/self-managed/setup/guides/connect-to-an-oidc-provider.md#configuration) when configuring a custom OIDC provider.
+
+
## Camunda 8.3
-Release date: 10th of October 2023
-
-End of maintenance: 9th of April 2025
-
-:::caution
-For existing clusters we recommend updating to `8.3.1` directly and not `8.3.0` due to issues in data migration of Operate, Tasklist, and Optimize that could prolong the migration or even blocking it from finishing.
-:::
-
-:::caution Breaking change
-
-### Zeebe Docker image now runs with unprivileged user by default
-
-The default user in the Zeebe Docker image changed from root to an unprivileged user with the UID 1000. This was done to provide stronger compliance with the [OWASP recommendations on Docker Security](https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html#rule-2-set-a-user).
-
-Please refer to the [Update 8.2 to 8.3](/self-managed/operational-guides/update-guide/820-to-830.md) guide.
-:::
-
-:::info
-The update from `8.2.x` to `8.3.x` performs a migration for nearly all entities stored in Operate, Tasklist, and Optimize to support [multi-tenancy](/self-managed/concepts/multi-tenancy.md). Therefore, migration may take longer.
-:::
-
-### Deprecated in 8.3
-
-[Web Modeler's beta API](/apis-tools/web-modeler-api/index.md) was deprecated in 8.3 and will be removed in 8.5.
-Use `v1` instead, see [migration hints](/apis-tools/web-modeler-api/index.md#migrating-from-beta-to-v1).
-
-### Versioning changes in Elasticsearch
-
-As of the 8.3 release, Camunda is compatible with Elasticsearch 8.8+ and no longer supports Elasticsearch 7.x. See [supported environments](/reference/supported-environments.md).
-
-### Versioning changes in Helm chart
-
-[Helm charts versioning](/self-managed/setup/overview.md) changed in July 2023.
-
-Starting from July 2023 (v8.2.8), the Camunda 8 **Helm chart** version follows the same unified schema
-and schedule as [Camunda 8 applications](https://github.com/camunda/camunda-platform).
-
-Before this change, the Camunda 8 **Helm chart** version only followed the minor version.
-
-## Camunda 8.2
-
-Release date: 11th of April 2023
-
-End of maintenance: 8th of October 2024
-
-[Release notes](https://github.com/camunda/camunda-platform/releases/tag/8.2.0)
-[Release blog](https://camunda.com/blog/2023/04/camunda-platform-8-2-key-to-scaling-automation/)
-
-### Update from Web Modeler 8.2 to a later minor version
-
-Web Modeler versions 8.2.7 to 8.2.12 are affected by [camunda/issues#677](https://github.com/camunda/issues/issues/677).
-
-If you are using one of these versions, you should first update to Web Modeler 8.2.13 (or a subsequent patch version) before upgrading to a later minor version (8.3 or higher).
-
-If your current version of Web Modeler is 8.2.6 or earlier, you may directly upgrade to a later minor version.
-
-### Do not update to Camunda 8.2.22
-
-:::caution
-Zeebe release `8.2.22` suffers from [camunda/zeebe#16406](https://github.com/camunda/camunda/issues/16406), which results in a Zeebe broker being unable to start if at least one DMN model is deployed. We urge users to skip this release and update to `8.2.23` right away.
-:::
-
-### Do not update from Camunda 8.1.X to 8.2.6
-
-An issue in the Operate 8.2.6 patch was discovered after it was published on June 8th.
-
-You should not update directly from 8.1.x to 8.2.6 (it will require manual intervention as indices break), you either first update to 8.2.5 then 8.2.6 or straight from 8.1.x to 8.2.7.
-
-To prevent this entirely we removed the Operate 8.2.6 artifacts from this release.
-
-As Camunda 8.2.7 was already released on Tuesday Jun 13th, you can just update to 8.2.7 directly, skipping 8.2.6.
+Camunda 8.3 was released on 10 October, 2023.
-### OpenSearch 1.3.x support
+
+
-- Operate version 8.2+ support OpenSearch 1.3.x. However, 8.2.x patches will only be released on the OS 1.3 branch until end of 2023 given that OS 1.3 maintenance period ends by then. We recommend customers to go to 8.4.x which supports OS 2.5+.
+**[8.3 Announcements](/reference/announcements/850.md#camunda-83)**
-### Optimize and Helm chart compatibility
+
+
-For Optimize 3.10.1, a new environment variable introduced redirection URL. However, the change is not compatible with Camunda Helm charts until it is fixed in 3.10.3 (and Helm chart 8.2.9). Therefore, those versions are coupled to certain Camunda Helm chart versions:
+- [Deprecated in 8.3](/reference/announcements/850.md#deprecated-in-83)
+- [Versioning changes in Elasticsearch](/reference/announcements/850.md#versioning-changes-in-elasticsearch-1)
+- [Versioning changes in Helm chart](/reference/announcements/850.md#versioning-changes-in-helm-chart-1)
-| Optimize version | Camunda Helm chart version |
-| --------------------------------- | -------------------------- |
-| Optimize 3.10.1 & Optimize 3.10.2 | 8.2.0 - 8.2.8 |
-| Optimize 3.10.3+ | 8.2.9 - 8.2.22 |
-| Optimize 8.2.7+ | 8.2.23+ |
+
+
diff --git a/docs/reference/announcements/850.md b/docs/reference/announcements/850.md
new file mode 100644
index 0000000000..4f8342a214
--- /dev/null
+++ b/docs/reference/announcements/850.md
@@ -0,0 +1,188 @@
+---
+id: announcements-850
+title: "8.5 - 8.3 Announcements"
+description: "Important announcements including deprecation & removal notices for the Camunda 8.5, 8.4, 8.3, and 8.2 releases."
+---
+
+Important changes and updates for the Camunda 8.5, 8.4, and 8.3 releases are summarized below.
+
+## Camunda 8.5
+
+| Release date | End of maintenance | Release notes |
+| :----------- | :----------------- | :--------------------------------------------------- |
+| 9 April 2024 | 14 October 2025 | [8.5 release notes](/reference/release-notes/850.md) |
+
+### Updated SaaS URLs
+
+We will simplify the URL for Camunda 8 SaaS from cloud.camunda.io ([console.cloud.camunda.io](https://console.cloud.camunda.io/)) to camunda.io ([console.camunda.io](http://console.camunda.io/)).
+
+On or around July 9th, users will be directed to the new URLs. Both URLs will continue to be active for at least 18 months so navigation from supported versions of components like Operate is still possible.
+
+Internal allowlisting or active rules for [cloud.camunda.io](http://cloud.camunda.io/) must be transitioned to the new [camunda.io](http://camunda.io/) URL. This change primarily affects Console and Modeler. During sign up, users will be briefly redirected through [accounts.cloud.camunda.io](http://accounts.camunda.io/), which will also be updated.
+
+### Syntax changes in Helm chart
+
+A Camunda Helm chart upgrade is not possible from v9.x.x to v10.0.0 or v10.0.1. Instead, upgrade directly to v10.0.2+.
+
+The Camunda Helm chart v10.0.0 has major changes in the values file structure. Some keys in the values file have been changed. For compatibility, the keys are deprecated in the Camunda release cycle 8.5 and will be removed in the Camunda 8.6 release (October 2024).
+
+Follow the [upgrade instructions](/self-managed/setup/upgrade.md#helm-chart-1002+) to upgrade from Camunda Helm chart v9.x.x to Camunda Helm chart v10.x.x.
+
+### Support for Amazon OpenSearch
+
+With the 8.5 release, Optimize is now also compatible with [Amazon OpenSearch](https://aws.amazon.com/de/opensearch-service/) 2.5+. Note that using Amazon OpenSearch requires [setting up a new Camunda installation](/self-managed/setup/overview.md). A migration from previous versions or Elasticsearch environments is not supported.
+
+### Known limitations
+
+This release contains the following limitations:
+
+- In **Optimize `8.5.0`**
+ - **Limitation**
+ - **Description:** OpenSearch support in Optimize is limited to data import and the raw data report.
+ - **Reference:** n/a
+ - **Mitigation:** Optimize can be installed and used in production with limited reporting functionality. Optimize imports all process data generated by Zeebe. All reporting functionality as described in the docs will be delivered with upcoming patches.
+- In **Console `8.5.x`**
+ - **Limitation**
+ - **Description:** Custom OIDC provider support for Console is not supported
+ - **Reference:** https://github.com/camunda/issues/issues/784
+
+### Changes in supported environments
+
+- Raised minimum Go version to 1.21 for the Zeebe Go client
+
+### Camunda SaaS: New generation naming scheme
+
+With the April release, the generation naming scheme in Camunda 8 changed and no longer includes the patch version.
+
+The new naming scheme used for all Camunda SaaS generations created after April 2024 is `Camunda .+gen`, where `N` is incremented with every atomic change to the component version set. Existing generations will not be renamed.
+
+For patch releases to existing generations, `N` is set to the latest patch level plus 1. For example, when `Camunda 8.4.5` is the current generation name, the following patch will be released as `Camunda 8.4+gen6`.
+
+This was done to decouple the generation name from the particular patch level of the components it contains, as some component versions like Connectors are decoupled from other components.
+
+You will learn about the particular component patch version changes in the update dialogue to the latest generation available. The following screenshot shows a sample update from `Camunda 8.5+gen1` to `Camunda 8.5+gen2`, where only the Connectors patch version changed.
+
+![New Generating naming sample showing an update dialogue from 8.5+gen1 to 8.5+gen2](../img/generation-naming-scheme-sample.png)
+
+Note that the actual values shown in this screenshot don't correspond to any actual generations and only serve as an example.
+
+### Removal of Web Modeler's beta API
+
+The Web Modeler beta API has been removed. The API was deprecated in 8.3 and is no longer available in 8.5. Use the [Web Modeler v1 API](/apis-tools/web-modeler-api/index.md) instead.
+For a migration guide, see the [Web Modeler API documentation](/apis-tools/web-modeler-api/index.md#migrating-from-beta-to-v1).
+
+### Zeebe 8.5.0 breaks serialization of timestamp values in management API (Self-Managed only)
+
+Zeebe 8.5.0 was released with [a new bug](https://github.com/camunda/camunda/issues/17347) that breaks serialization of timestamp values in management APIs, such as [backup](/self-managed/operational-guides/backup-restore/backup-and-restore.md) and [cluster scaling](/self-managed/zeebe-deployment/operations/cluster-scaling.md).
+Timestamps which were previously serialized as `ISO8061` strings are now serialized as integer values.
+
+Until a fix is delivered in 8.5.1, workarounds include not deserializing timestamp values from affected APIs, or deserializing them as integers.
+
+## Camunda 8.4
+
+| Release date | End of maintenance |
+| :------------- | :----------------- |
+| 9 January 2024 | 9 July 2025 |
+
+:::caution
+The [form linking](/components/modeler/web-modeler/advanced-modeling/form-linking.md#using-the-link-button) feature is impacted by an [issue](https://github.com/camunda/camunda/issues/16311) where the wrong forms can get linked with new user task instances, effectively corrupting the user task instance. If you make use of this feature and run either `8.4.0`, `8.4.1` or `8.4.2`, we urge you to update to the newest `8.4.3` patch that includes the required fix.
+
+Follow the instructions in the [form linking](/components/modeler/web-modeler/advanced-modeling/form-linking.md#known-issues-with-linked-forms) documentation to resolve this issue.
+:::
+
+### Versioning changes in Helm chart
+
+As of the 8.4 release, the Camunda 8 **Helm chart** version is decoupled from the version of the application. The Helm chart release still follows the applications release cycle, but it has an independent version. (e.g., in the application release cycle 8.4, the chart version is 9.0.0).
+
+For more details about the applications version included in the Helm chart, review the [full version matrix](https://helm.camunda.io/camunda-platform/version-matrix/).
+
+### Dockerfile numeric ID
+
+The Dockerfile now uses a numeric user ID instead of a non-numeric user.
+This will allow the Helm users to use `runAsNonRoot=true` without the need to explicitly set the ID in the Helm `values.yaml` file.
+
+### Deprecated in 8.4
+
+The [Zeebe configuration properties for Camunda Identity](/self-managed/zeebe-deployment/configuration/gateway.md#zeebegatewayclustersecurityauthenticationidentity)
+were deprecated in `8.4`. Please use the dedicated Camunda Identity properties or the [corresponding environment variables](/self-managed/identity/deployment/configuration-variables.md#core-configuration).
+
+### Versioning changes in Elasticsearch
+
+As of the 8.4 release, Camunda is compatible with Elasticsearch 8.9+ and no longer supports older Elasticsearch versions. See [supported environments](/reference/supported-environments.md).
+
+### Support for Amazon OpenSearch
+
+As of the 8.4 release, Zeebe, Operate, and Tasklist are now compatible with [Amazon OpenSearch](https://aws.amazon.com/de/opensearch-service/) 2.5.x. Note that using Amazon OpenSearch requires [setting up a new Camunda installation](/self-managed/setup/overview.md). A migration from previous versions or Elasticsearch environments is currently not supported.
+
+:::info
+The Helm charts are not yet prepared with the OpenSearch configurations as templates/pre-filled. The Helm charts can still be used to install for OpenSearch, but some adjustments are needed beforehand. Refer to the [Helm deployment documentation](/self-managed/setup/install.md) for further details.
+:::
+
+### Known limitations
+
+This release contains the following limitations:
+
+- In **Operate `8.4.0`**
+ - **Bug**
+ - **Description:** Instance migration always points to the latest process version
+ - **Reference:** https://github.com/camunda/issues/issues/567
+ - **Mitigation:** Bug is planned to be fixed with upcoming `8.4.1` release
+ - **Bug**
+ - **Description:** Backwards migration over multiple versions does not work
+ - **Reference:** https://github.com/camunda/issues/issues/568
+ - **Mitigation:** Bug is planned to be fixed with upcoming `8.4.1` release
+- In **Camunda HELM `9.0.x`**
+ - **Limitation**
+ - **Description:** The existing Helm charts use the Elasticsearch configurations by default and are not yet prepared with the OpenSearch configurations as templates/pre-filled. The Helm charts can still be used to install for OpenSearch, but some adjustments are needed beforehand.
+ - **Reference:** n/a
+ - **Mitigation:**
+ 1. Refer to our [docs for the installation](/self-managed/setup/install.md#components-installed-by-the-helm-charts), the docs include guidance about necessary adjustments of the Helm chart configuration.
+ 2. The OpenSearch configuration in Helm charts will be provided in one of our future Helm releases.
+- In **Connectors `8.4.x`**
+ - **Missing feature**
+ - **Description:** Custom OIDC provider support for Connectors is missing
+ - **Reference:** https://github.com/camunda/issues/issues/569
+ - **Mitigation:**
+ 1. Feature is planned to be delivered with an upcoming patch release. Please see [issue](https://github.com/camunda/issues/issues/569) for latest progress.
+ 2. [Disable Connectors component](/self-managed/setup/guides/connect-to-an-oidc-provider.md#configuration) when configuring a custom OIDC provider.
+
+## Camunda 8.3
+
+| Release date | End of maintenance |
+| :-------------- | :----------------- |
+| 10 October 2023 | 9 April 2025 |
+
+:::caution
+For existing clusters we recommend updating to `8.3.1` directly and not `8.3.0` due to issues in data migration of Operate, Tasklist, and Optimize that could prolong the migration or even blocking it from finishing.
+:::
+
+:::caution Breaking change
+
+### Zeebe Docker image now runs with unprivileged user by default
+
+The default user in the Zeebe Docker image changed from root to an unprivileged user with the UID 1000. This was done to provide stronger compliance with the [OWASP recommendations on Docker Security](https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html#rule-2-set-a-user).
+
+Please refer to the [Update 8.2 to 8.3](/self-managed/operational-guides/update-guide/820-to-830.md) guide.
+:::
+
+:::info
+The update from `8.2.x` to `8.3.x` performs a migration for nearly all entities stored in Operate, Tasklist, and Optimize to support [multi-tenancy](/self-managed/concepts/multi-tenancy.md). Therefore, migration may take longer.
+:::
+
+### Deprecated in 8.3
+
+[Web Modeler's beta API](/apis-tools/web-modeler-api/index.md) was deprecated in 8.3 and will be removed in 8.5.
+Use `v1` instead, see [migration hints](/apis-tools/web-modeler-api/index.md#migrating-from-beta-to-v1).
+
+### Versioning changes in Elasticsearch
+
+As of the 8.3 release, Camunda is compatible with Elasticsearch 8.8+ and no longer supports Elasticsearch 7.x. See [supported environments](/reference/supported-environments.md).
+
+### Versioning changes in Helm chart
+
+[Helm charts versioning](/self-managed/setup/overview.md) changed in July 2023.
+
+Starting from July 2023 (v8.2.8), the Camunda 8 **Helm chart** version follows the same unified schema
+and schedule as [Camunda 8 applications](https://github.com/camunda/camunda-platform).
+
+Before this change, the Camunda 8 **Helm chart** version only followed the minor version.
diff --git a/docs/reference/announcements/860.md b/docs/reference/announcements/860.md
new file mode 100644
index 0000000000..91b5380bde
--- /dev/null
+++ b/docs/reference/announcements/860.md
@@ -0,0 +1,182 @@
+---
+id: announcements-860
+title: "8.6 Announcements"
+description: "Important changes and updates for the Camunda 8.6 release including deprecation & removal notices."
+---
+
+Important changes and updates for the Camunda 8.6 release are summarized below.
+
+| Release date | End of maintenance | Release notes |
+| :------------- | :----------------- | :--------------------------------------------------- |
+| 8 October 2024 | 14 April 2026 | [8.6 release notes](/reference/release-notes/860.md) |
+
+## License key changes
+
+With the 8.6 release, Camunda 8 Self-Managed requires a license key for production usage. For additional details, review the [blog post on licensing updates for Camunda 8 Self-Managed](https://camunda.com/blog/2024/04/licensing-update-camunda-8-self-managed/).
+
+Review the following documentation for your components for more information on how to provide the license key to each component as an environment variable:
+
+- [Console](/self-managed/console-deployment/configuration.md#environment-variables)
+- [Zeebe](/self-managed/zeebe-deployment/configuration/configuration.md#licensing)
+- [Operate](/self-managed/operate-deployment/operate-configuration.md#licensing)
+- [Tasklist](/self-managed/tasklist-deployment/tasklist-configuration.md#licensing)
+- [Optimize]($optimize$/self-managed/optimize-deployment/configuration/system-configuration-platform-8#licensing)
+- [Identity](/self-managed/identity/deployment/configuration-variables.md#license-configuration)
+- [Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#licensing)
+
+To configure with Helm, visit the [Self Managed installation documentation](/self-managed/setup/install.md).
+
+:::note
+Camunda 8 components without a valid license may display **Non-Production License** in the navigation bar and issue warnings in the logs. These warnings have no impact on startup or functionality, with the exception that Web Modeler has a limitation of five users. To obtain a license, visit the [Camunda Enterprise page](https://camunda.com/platform/camunda-platform-enterprise-contact/).
+:::
+
+## Zeebe Java client
+
+Starting with 8.7, the Zeebe Java client will become the new Camunda Java client. This transition brings a new Java client structure designed to enhance the user experience and introduce new features while maintaining compatibility with existing codebases.
+
+The primary goal of those changes is to enable users to interact with Camunda clusters with one consolidated client rather than multiple. The `CamundaClient` will replace the `ZeebeClient`, offering the same functionality and adding new capabilities. If you need to continue using the old `ZeebeClient`, you can use the version 8.6 artifact without any issues with newer cluster versions as the client is forward-compatible.
+
+:::note
+The Zeebe Java client will not be developed further and will only receive bug fixes for as long as version 8.6 is officially supported.
+:::
+
+### Key changes
+
+- **New package structure**:
+ - Package `io.camunda.client`: This package contains the new `CamundaClient` and all the features slated for release in version 8.7.
+- **Properties and environment variables refactoring**:
+ - All old Java client property names will be refactored to more general ones. For instance, `zeebe.client.tenantId` will become `camunda.client.tenantId`.
+ - Similarly, environment variables will be renamed following the same concept: `ZEEBE_REST_ADDRESS` will become `CAMUNDA_REST_ADDRESS`.
+- **Artifact ID change**:
+ - The `artifactId` will change from `zeebe-client-java` to `camunda-client-java`.
+
+## Deprecation: Zeebe Go client & CLI client (zbctl)
+
+The Zeebe Go Client and CLI client (zbctl) will be [officially deprecated](https://camunda.com/blog/2024/09/deprecating-zbctl-and-go-clients/) with the 8.6 release as part of our efforts to streamline the Camunda 8 API experience. This client and CLI utility will not be released starting with Camunda 8.6, will no longer receive new features, and will be transitioned to a community-maintained status.
+
+The documentation of the Zeebe Go Client and CLI client (zbctl) moved to the [community clients section](/apis-tools/community-clients/index.md).
+
+## Camunda 8 SaaS - Required cluster update
+
+:::caution
+By **August 30th, 2024** all automation clusters in Camunda 8 SaaS must be [updated](/components/console/manage-clusters/manage-cluster.md#update-a-cluster) to the following versions at a **minimum**:
+
+- **8.2+gen27**
+- **8.3+gen11**
+- **8.4+gen7**
+- **8.5+gen2**
+
+:::
+
+auth0 announced an End-Of-Life for one of the functionalities that is being utilized by previous automation clusters. The new versions are not using this functionality anymore. This update ensures your cluster will work seamlessly after auth0 deactivates the feature in production.
+
+You minimally need to take the following [update](/components/console/manage-clusters/manage-cluster.md#update-a-cluster) path:
+
+- 8.0.x -> 8.2+gen27
+- 8.1.x -> 8.2+gen27
+- 8.2.x -> 8.2+gen27
+- 8.3.x -> 8.3+gen11
+- 8.4.x -> 8.4+gen7
+- 8.5.x -> 8.5+gen2
+
+If you do not update the cluster by August 30th 2024, we will update the cluster for you. **Without an update, you would lose access to your cluster.**
+
+Camunda 8 Self-Managed clusters are not affected by this.
+
+## Support for Amazon OpenSearch for Optimize
+
+This release extends the OpenSearch features supported by Optimize. Full support is committed for the next release in January 2025.
+
+## Supported environment changes (OpenJDK, ElasticSearch, Amazon OpenSearch)
+
+Version changes are made to supported environments:
+
+- OpenJDK minimum version raised to 21+ in Operate
+- ElasticSearch minimum version raised to 8.13+
+- Amazon OpenSearch minimum version raised to 2.9+
+
+To learn more about supported environments, see [supported environments](/reference/supported-environments.md).
+
+## Connectors
+
+### Deprecation: None start event element templates for Kafka, RabbitMQ, Amazon SQS, and Amazon SNS inbound Connectors
+
+The [none start event](/components/modeler/bpmn/none-events/none-events.md#none-start-events) element templates for the out-of-the-box Kafka, RabbitMQ, Amazon SQS, and Amazon SNS inbound Connectors have been deprecated in Camunda Modeler.
+
+Users can no longer select these templates when creating a new none start event element in Camunda Modeler. Existing none start event elements with these templates will continue to work as expected, but users are encouraged to migrate to the [message start event](/components/modeler/bpmn/message-events/message-events.md#message-start-events) element templates for these Connectors.
+
+Message start event element templates are better suited for the message-based communication these Connectors provide, and offer more flexibility and features compared to the none start event element templates, such as the ability to define a message ID and a correlation key for idempotency. Read more in the [inbound Connectors documentation](/components/connectors/use-connectors/inbound.md) and the [messaging concepts documentation](/components/concepts/messages.md#message-uniqueness).
+
+### Breaking changes in the Connector SDK
+
+The `void correlate(Object variables)` method in the `InboundConnectorContext` interface has been removed, following the deprecation in 8.4.0. Use the `CorrelationResult correlateWithResult(Object variables)` method instead.
+
+The `CorrelationResult` record has been changed compared to the previous versions:
+
+- `CorrelationResult.Success` now contains a `ProcessElementContext` that represents the element that was correlated. Compared to the previous version, where the correlated element was returned directly, this change allows accessing element properties after correlation for user-controlled post-correlation actions.
+- `CorrelationResult.Failure` now provides the `CorrelationFailureHandlingStrategy` that defines how the failure should be handled.
+
+An example of how to use the new `CorrelationResult` can be found in the [Connector SDK documentation](/components/connectors/custom-built-connectors/connector-sdk.md#inbound-connector-runtime-logic).
+
+## Flow control enabled by default in SaaS
+
+Flow control is now enabled by default in Camunda 8.6 SaaS. This change ensures the cluster is protected from excessive load and can maintain a stable state.
+
+These new configuration defaults are tailored to the cluster size and optimized for a stable performance. However, the cluster might reject requests if the load is too high with this change. The error message for this is `Failed to write client request to partition X, because the write limit is exhausted`. If the error persists, this may be a sign of underlining issues, or a need to adjust the cluster size.
+
+For more information on how to configure flow control for a Self-Managed cluster, visit the [flow control documentation](/self-managed/operational-guides/configure-flow-control/configure-flow-control.md).
+
+## Camunda 8 Self-Managed
+
+### Helm chart - Separated Ingress deprecation
+
+The separated Ingress Helm configuration for Camunda 8 Self-Managed has been deprecated in 8.6, and will be removed from the Helm chart in 8.7. Only the combined Ingress configuration is officially supported. See the [Ingress guide](/self-managed/setup/guides/ingress-setup.md) for more information on configuring a combined Ingress setup.
+
+### Helm chart - `global.multiregion.installationType` deprecation
+
+The `global.multiregion.installationType` option is used in failover and failback scenarios. This option in the Helm chart has been deprecated in 8.6, and will be removed from the Helm chart in 8.7. `global.multiregion.installationType` was replaced with a set of API endpoints called while following the ([dual-region operational procedure](/self-managed/operational-guides/multi-region/dual-region-ops.md))
+
+#### Helm chart - Elasticsearch nodes number
+
+The default value of Elasticsearch deployment pods has changed from 2 to 3, and an affinity setting has been added to avoid scheduling Elasticsearch pods on the same Kubernetes worker.
+
+## Camunda Optimize artifact and Docker tag separation
+
+Starting with Camunda 8.6, the Camunda Optimize artifact has been split into two distinct versions, and versioning between Camunda 7 and Camunda 8 is no longer interchangeable:
+
+- **Before Camunda 8.6**: Versions like `8.x` and `3.x` (used for Camunda 7) could sometimes be used interchangeably.
+- **From Camunda 8.6 onwards**: `8.6 != 3.14`. Each version corresponds strictly to its platform:
+ - **Camunda 7**: Uses the `3.x` versioning scheme and the `latest` Docker tag.
+ - **Camunda 8**: Uses the `8.x` versioning scheme and the `8-latest` Docker tag.
+
+### Action required:
+
+- **Camunda 7 Users**: Continue using `3.x` versions and the `latest` Docker tag.
+- **Camunda 8 Users**: If you haven't already done so, update your configurations to use `8.x` versions and the `8-latest` Docker tag.
+
+Make sure to update your Docker configurations accordingly to ensure compatibility.
+
+## New base path for Operate and Tasklist web applications
+
+We are introducing a new base path for both the Operate and Tasklist **web applications**. This change applies to both Self-Managed and SaaS environments.
+
+### For Self-Managed
+
+- The new base path for Operate is `/operate`, and for Tasklist, it is `/tasklist`.
+- For a [Separated Ingress](/self-managed/setup/guides/ingress-setup.md?ingress=separated) configuration:
+ - for Operate, the full URL will be `{operate-host}/operate`. Any calls to `{operate-host}` will automatically be redirected to `{operate-host}/operate`
+ - for Tasklist, the full URL will be `{tasklist-host}/tasklist`. Any calls to `{tasklist-host}` will automatically be redirected to `{tasklist-host}/tasklist`.
+- For a [Combined Ingress](/self-managed/setup/guides/ingress-setup.md?ingress=combined) configuration:
+ - for Operate, the full URL will be `{common-host}/{operate-contextPath}/operate`. Any calls to `{common-host}/{operate-contextPath}` will be automatically redirected to `{common-host}/{operate-contextPath}/operate`.
+ - for Tasklist, the full URL will be `{common-host}/{tasklist-contextPath}/tasklist`. Any calls to `{common-host}/{tasklist-contextPath}` will be automatically redirected to `{common-host}/{tasklist-contextPath}/tasklist`.
+
+### For SaaS
+
+- The full URL for Operate is now structured as `https://{region}.operate.camunda.io/{clusterId}/operate`.
+- The full URL for Tasklist is now structured as `https://{region}.tasklist.camunda.io/{clusterId}/tasklist`.
+- Any calls to `https://{region}.operate.camunda.io/{clusterId}` will be redirected to `https://{region}.operate.camunda.io/{clusterId}/operate`.
+- Any calls to `https://{region}.tasklist.camunda.io/{clusterId}` will be redirected to `https://{region}.tasklist.camunda.io/{clusterId}/tasklist`.
+
+:::note
+**API URLs** for both Operate and Tasklist remain **unchanged**.
+:::
diff --git a/docs/reference/announcements/870.md b/docs/reference/announcements/870.md
new file mode 100644
index 0000000000..472bfe0d35
--- /dev/null
+++ b/docs/reference/announcements/870.md
@@ -0,0 +1,183 @@
+---
+id: announcements-870
+title: "8.7 Announcements"
+description: "Important changes and updates for the Camunda 8.7 release including deprecation & removal notices."
+---
+
+Important changes and updates for the Camunda 8.7 release are summarized below.
+
+| Scheduled release date | Scheduled end of maintenance | Release notes | Blog |
+| :--------------------- | :--------------------------- | :--------------------------------------------------- | :---------------------------------------------------------------------------------------------- |
+| 11 February 2025 | 11 August 2026 | [8.7 release notes](/reference/release-notes/870.md) | [Announcing Camunda 8.7](https://camunda.com/blog/2024/11/camunda-8-7-releasing-february-2025/) |
+
+- [API updates](#api-updates-saasself-managed)
+- [Identity management updates](#identity-management-updates-saasself-managed)
+- [Installation and deployment updates](#installation-and-deployment-updates-self-managed)
+- [Camunda Java client and Camunda Spring SDK](#camunda-java-client-and-camunda-spring-sdk-self-managed)
+
+## API updates SaaSSelf-Managed
+
+The 8.7 release includes API updates to support the move to a [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md) unified experience.
+
+### Camunda 8 REST API updates
+
+- New Query endpoints (with advanced search filtering) will be added for process entities (processes, decisions, user tasks, and forms). These will replace the component APIs (Tasklist, Operate) going forward.
+- New endpoints will allow you to manage and query users and resource permissions in an orchestration cluster.
+- All the Camunda 8 REST API endpoints will support resource-based authorizations to enable fine-grained permissions.
+- API terminology is aligned so technical assets have an identical, easily-understood, descriptive property name.
+
+### Deprecated: Operate and Tasklist v1 REST APIs
+
+The deprecation process for the [Operate](/apis-tools/operate-api/overview.md) and [Tasklist](/apis-tools/tasklist-api-rest/tasklist-api-rest-overview.md) REST APIs starts with the 8.7 release. You can begin migrating to the [Camunda 8 REST API](/apis-tools/camunda-api-rest/camunda-api-rest-overview.md) for querying to prepare for this change.
+
+- Version 8.7, 8.8: These APIs are available, but not recommended for new implementations.
+- Version 8.9: These APIs will be deprecated and removed.
+
+### Deprecated: Job-based User Tasks querying
+
+As `Job-worker` user tasks will be deprecated in Camunda 8.9, Camunda recommends you start using `Camunda User Tasks` (formerly known as `Zeebe User Task`) in your process definitions.
+
+- Version 8.7, 8.8: `Job-worker` user tasks are available for querying, but Camunda modelers automatically apply the `Camunda user task` and show a warning message for each job worker user task.
+- Version 8.9: `Job-worker` user tasks will be deprecated. With Camunda 8.9 and later, customers can use the `Job-worker` implementation of user tasks as standard jobs with headers to enable open architecture and composable solutions.
+
+### Deprecated: Zeebe gRPC API endpoints
+
+With the 8.7 release, Camunda announces the deprecation of several [Zeebe gRPC](/apis-tools/zeebe-api/grpc.md) endpoints for removal in 8.9.
+
+- Key gRPC endpoints necessary for high-throughput and low-latency applications remain available with 8.7.
+- The final list of retained gRPC endpoints will be confirmed with the 8.7 release.
+- Selected endpoints will remain active, with others scheduled for removal in the 8.9 release.
+
+### Deprecated: Tasklist GraphQL API
+
+With the 8.7 release, the deprecated [Tasklist GraphQL API](/apis-tools/tasklist-api/tasklist-api-overview.md) will be removed from the product.
+
+
+
+## Identity management updates SaaSSelf-Managed
+
+The [Identity service](/self-managed/identity/what-is-identity.md) is enhanced to deliver greater flexibility, control, and security for both Self-Managed and SaaS users. These updates are part of our broader effort to streamline the platform’s architecture.
+
+### Cluster-level identity management
+
+Identity settings will be configured at the orchestration cluster level, allowing each cluster to have unique OIDC configurations. This cluster-specific setup empowers organizations to assign different identity providers (IdPs) across clusters, offering improved control over permissions and user group mappings, resulting in a more streamlined and efficient configuration experience.
+
+For SaaS customers, identity management in Camunda 8.7 remains consistent with Camunda 8.6, allowing the attachment of a single IdP per organization. However, cluster-level identity capabilities are provided for SaaS as well as Self-Managed. This means that user groups, roles, and access permissions can now be managed at the cluster level, giving SaaS customers the same granular access control as in Self-Managed environments.
+
+### Decoupling from Keycloak Self-Managed
+
+Built-in Keycloak integration in Self-Managed is removed, allowing customers to use any compatible IdP.
+
+- Keycloak remains fully supported as an external option.
+- OpenID Connect (OIDC) remains the standard for seamless integration with chosen IdPs.
+
+### Resource-based permissions
+
+Resource-level permissions are introduced for process definitions and web applications.
+
+- Admin users retain full access, but regular users must be granted specific permissions to perform actions/view resources.
+- For organizations that build custom front-ends and access Camunda via API, users with API permissions can still access process data through the V2 API.
+
+
+
+## Installation and deployment updates Self-Managed
+
+Camunda 8.7 introduces a streamlined architecture, consolidating core components such as Zeebe, Operate, and Tasklist into a single deployable unit. Enhanced deployment options are also included, such as new Kubernetes Helm guides, deployment reference architectures, and improved support for professional developers with Camunda 8 Run.
+
+You can download the alpha release of the unified package from the Camunda GitHub repository, either as an executable Java application (Camunda Orchestration Core) or a Docker image.
+
+### Helm charts
+
+If you are using the recommended Camunda 8 deployment option (Helm charts), the upgrade path from version 8.6 to 8.7 will be straightforward by chaninging the values file to the new syntax. Updated Helm charts will be provided to support the upgrade to the new streamlined architecture.
+
+New migration guides will also be provided to support you when migrating from a previous Camunda version.
+
+:::caution
+Additional upgrade considerations are necessary for deployments that use custom scripts, such as Docker containers, manual installations, or custom-developed Kubernetes deployments. For these deployments, customers can either continue to deploy with their original 8.6 topology and upgrade each component independently, or adopt our Helm Chart approach for the upgrade, which allows for unifying the deployment into a single JAR or container executable.
+:::
+
+#### Separated Ingress removal
+
+With Camunda 8.7, Helm chart supports only the Combined Ingress setup where all Camunda components run on the same Ingress object and same hostname.
+
+The following Helm chart values have been removed:
+
+```yaml
+connectors.ingress
+console.ingress
+identity.ingress
+operate.ingress
+optimize.ingress
+tasklist.ingress
+webModeler.ingress
+zeebeGateway.ingress
+```
+
+### Manual installation
+
+For organizations that do not use cloud-native platforms such as Kubernetes or container services, we will publish a reference architecture that provides guidance on implementing Camunda production clusters on VM-based systems, using Amazon Web Services (AWS) EC2 as an example.
+
+The architecture will include details on optimal instance sizing, network configurations, and security best practices, to ensure robust performance and reliability.
+
+### Camunda Exporter
+
+A new Camunda Exporter brings the importer and archiving logic of web components (Tasklist and Operate) closer to the distributed platform (Zeebe). The index schema is also being harmonized.
+
+#### Harmonized index schema
+
+Camunda is harmonizing our index structure and usage.
+
+- This removes unnecessary duplications over multiple indices due to the previous architecture.
+- With this change, several Operate indices can and will be used by Tasklist.
+- New indices have been created to integrate Identity into the system.
+
+![Harmonized indices schema](../img/harmonized-indices-schema.png)
+
+#### Camunda Exporter
+
+The exporter can consume Zeebe records (mostly events created by the engine), aggregate data, and store the related data into shared and harmonized indices.
+
+- Data is archived in the background, coupled to the exporter but without blocking the exporter's progress.
+- Indices can be located in either ElasticSearch (ES) or Opensearch (OS). Our web components (Tasklist and Operate) then use the new harmonized indices to show data to the user.
+
+The following diagram shows a simplified version of this work.
+
+![Camunda Exporter diagram](../img/target-camunda-exporter.png)
+
+- For example, Tasklist and Operate Importers are still required for old data to be imported, but the Camunda exporter writes all new data into ES/OS. After old indices are drained, importers can be turned off.
+- The archiver, which takes care of the archiving of completed process instances, will be moved into the Zeebe system as well, to reduce the installation complexity and provide a better scaling and replication factor (based on partitions).
+- This helps achieve a streamlined architecture, and improves platform performance and stability (especially regarding ES/OS).
+- A new separate component covers the migration, which will be part of the single application but can also deployed separately. It will adjust the previous Operate indices to make them more harmonized and usable by Tasklist.
+
+
+
+## Camunda Java client and Camunda Spring SDK Self-Managed
+
+With the Camunda 8.7 release, Camunda Java client and Camunda Spring SDK replace the Zeebe Java client and Zeebe Spring SDK. This allows you to use a single consolidated client to interact with Camunda clusters.
+
+The `CamundaClient` replaces the `ZeebeClient`, offering the same functionality and adding new capabilities.
+
+:::note
+
+- If you need to continue using the old `ZeebeClient`, you can use the version 8.6 artifact without any issues with newer cluster versions as the client is forward-compatible.
+- The Zeebe Java client will not be developed further and only receives bug fixes while version 8.6 is officially supported.
+
+:::
+
+### Key changes
+
+| Change | Description |
+| :---------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| New package structure | Package `io.camunda.client`: Contains the new `CamundaClient` and all 8.7 features. |
+| Refactored properties and environment variables | All old Java client property names are refactored to more general ones. For example, `zeebe.client.tenantId` to `camunda.client.tenantId`.
Similarly, environment variables are renamed following the same concept: `ZEEBE_REST_ADDRESS` to `CAMUNDA_REST_ADDRESS`.
|
+| Artifact ID change | The `artifactId` changes from `zeebe-client-java` to `camunda-client-java`. |
+
+## Southeast Asia region for SaaS customers SaaS
+
+SaaS customers can now create orchestration clusters in the [Singapore (asia-southeast1) region](/reference/regions.md), ensuring lower latency and improved processing speed for organizations operating in southeast Asian countries.
diff --git a/docs/reference/img/doc-icon.png b/docs/reference/img/doc-icon.png
new file mode 100644
index 0000000000000000000000000000000000000000..26cc92e510276c423441cad876759ee22ba66603
GIT binary patch
literal 213
zcmeAS@N?(olHy`uVBq!ia0vp^0wB!61|;P_|4#%`k|nMYCBgY=CFO}lsSJ)O`AMk?
zp1FzXsX?iUDV2pMQ*D5X$~|2iLn>}1B`gpyI3$sjl*Hul%1(egA+VgWLpFYI)z`)e
zjPDz}BqoY79R2Uin{XhFL%65$Y>CPPj-}t7bq|>^$Tvv!T@?^h`cmIe)!eus`=Y4O
z;5=%&hs&Oafo2$Wf5dkexesjza#W
zwEDSoWZ-k>E=OOz2s|OYP)Y*+-FKGJb=I(hI=h)TnxA|A#?I9Ik-V*mg}J)9$r}%c
zU*=-x&Ru+Bsj2I%tE?nqW@pP~Lh8fiZfg&WK6g$`(%s&~%-Y=fk*T?bB}|-g6V<@@
z$nuRiqYl3^x3c{U^S72SJsr(8JXJK!Jgv=y-!Mu_JQ8yk0SMTdJDWUmx3z&eiMWe1
z{-!Ged?!5yGd}v=#o1b%@h_%ym0vx2VdrT6NSKR<(~O&&_mQA5mx+Lh0H3gckO{{l
zUT)r}U~WDzw*V&(j|e}n2si(uzdww?gpO~ZBI?qze@_Rr#2Mc@JKKwZ!ESDDTyA_^
zc8(Tc9${f&FgGulmzNXh!Rh1yb2f43ggG(&LqXcy$;{Ex-r3R)_J~B$#MI8kS)37I
z_ODgg+W(6z%<1o)0`?5-ZekDS;o>H(>Yt9v%Kz)GwzmK3?c}U({vZ7QPYF9|df1zT
z)y@y1JYD#{~ris;a8n+uJ!gISL92-@kwN@$q@_;)S)fwVIk*
zeSLjhU7d!8Mtpqy)YO!clG6VEet&;|et!PY(2%dMZ(3SfOH0er(h>v$IXpbv+S)qX
z+iDowHZn45Z*QNTo_2C_@|&+LD=TXl--%d4+uPd{iNu40gMfg5y}iA`!9h42-rCyQ
z+1W`T5Ed5~y}Z1B{rdI!^XK*T_2S~Kx-@SWhYinCmQ&U-485S01
zUp!Y^Tl*|(bZl%4hr_wJxHvjG#>K@|S63$_B&4UO$HvBHWo4mIsOIM8_wV12jEv0B
z&wu>*5re^mgoMn^&7sj~e}Dgyk`g;RyUEE(KR>^ysHmo@9pjVNq2DFpBM9zM`ZVo
ze~k|q=so9zo36AIapv{M3_fpx*Y9FdQCfu9ecAZ?I_$OE6SV^a>)(M6^qw_glKeo2
z@9p-|e|Vf;KD4De)Fd#Ho{V+t-7-BGTR^J#IFA8+nd<9&B?U-te(K#Fl)=LXQ0a0j
zNQ<>j17k;Y`&Z+Q#UcveHMiqwz?KaDO?h`b%{Q?AL|D}WNxln4*9oan!$Rfr4#9sD
ziCcMWI?>fPP&?a|_d`u$-7owQ7jW(O+~?{zb}FTvL}TbkHr;swTZ#J_RBEw6|ZoZu*kRZk=(Pk&%z<2!`G%Gbd7fM
znGq|$3Px^Wovm?_^0=OPNn^42;*KgK+}!9gcwwrVb{Es<-*D9ZC#74}hWufeD6-AJ
z=An#1|9rG_d)YzQpYBzpWsCmQW`eOMeUQ)m9-Srw9Z7nA0zn%sdQJ?vsOV*kFyQO^
zJ%@eT#?~;m>ap?9rmBQpR7Y1SC=*5)Aq9yMYu>O*y8}3OsVFvO`zST%Ohk^Yp75NL
z*3mf3Tzof|`Jq`bFwNG+x5e-P3*$h1nv;a$*z}WrNGNaABwloCz3=N_r?Y2*4`nFw
zxF{b@kUUKVl{pbp^$KqsO>`|zGTeafVOGk|4B4HG!d#eMVL^)Stt8G-et}PSP&$rk
zG4MscvPB7VE35%?-}75aS;zWID$!7B(HLSKS|VnqrlS)xacW=If-#qN9}^ds5DBeM?(67luQLNkOdByhdN080@~h)rT+-oIVA*iGcC5XS
zshVnc(dmmfho%j8TP&(p5{tz}=e1vOa&~P!4|LS(*B07*vo`_q#Ak`Y9Tx6pX>)oL
zslobT65T6Ex6U9Bm;Me}P?>R<&!*+%aISSspi%2f(v|=5Xol?#(?8-#>LbHn0
z=ex@9?BRS$i8%72m1|zE9XZ?iLr(2OW8zwDEOz&RncNp&n(xWX@bS^zYYj+Ts!WWo
zi}MU?kP;1O-Dv*Y%opKn_q}{thG^>Va|bt?{f6Tfn$WXtnLXGidDk|fmt3Eol`QP9KbQq|-u&@>rYmF^lrleyWKWaT1t_%BECndIlC0fU
z7dJEC>#8_O8@bM3Jq>(?ycy%sE!TPB4qv=I(gq?LUqWntDVZkid>?^3JmyY7agKtD
zJWFV!dR8EMMXi}WR{bI6l9f!q*Dj6o;O;eAhDY=@+gY;QNsSW}8*^!B7*Bf;xR0Sc
z0Xq?JNgc4Ym~D)gXYZOJXdP*QNa~E<(>eUyZQe9w#;kprR>$AHokR>J8^Ooh9o^Wk
zBC4M-)#u#29)YeIfU<4hK?H9|D!trPf((c^cUO2^0{EInc5W!qc(pI5E||j|YT_bI
ziykY>9hv5U5g}Yf_kVhe2U_5Kmum+NI%eod_su2^kK5bH9kc~(aNhZQU-Rw{=>w@5
zMUM3jGosxx^rL?=O0AR+?vQLJ(Alu(IJGf?)
zkWVsl@;FDf&&LaNk3DIR-yRR7N}l(;ZM|0f`C~L~P)Uf}Z?ogX5f)EdC%T06c7{e`
z3e83Q^k`;~ERt$!*U)iL(z}WCQs{f_`8AKbJ;i-$c3cv1
z%ylLJ>(djnD!Qfd1^MW=`VX(XVE0CDVJ07gDi9?A?Z8F7E0FnN`7VkFio>D(x3T$odz
zHtSerlDOdK?!Cy3Q_GEkCl{S%ND}nv8b9c_XE==nTIb$@e>c!1gMIEVC*VK7_X)k0bul9
zh*CoZI(Fd~^5KsrF@A8#<_NmeDaw}
zUKsO9KdY`^a-JU0Ku1`3lvM921p5e{I|skDg>jfh%JnsxhpftZy5ddqj=;p#>~e7Z
z^Q4La8xhsO%(6Uiw3$_iS2<=Pv{qPjirX66!mIsK`YPY9eW8x}B8qEKx7$tb2zP7B
zrAVMXhX~EOVTaP{`ayXa=VFn#_1VCGF>J!ftb4rgE*L%E6=&>gz$5$D+&r5|rw^g7
zf=ft!3>@t~FtJ_9j~QE^>iV%MaX@ct^@?0nY*}G`6`A37EK`+q?ENGqvVvk22_55cvL;2{Xh}Xa9%2rk1kHU(jJo9ureIAgE0RcC>kLl)p&>4_8i|hv60<>Mf
zzc>HW`f>}t8&z#ZzFBbg_?=yhw1{rBz@FDakrNudRPODN>NjTu!lxAdjL!P>$W23Hxn=(u1sG=|YxxItgkTSU_~4z87DBG%5FUPKug<9~WD
z5RASjvSOIE?w~P&>cw;9f#dPvrl*}=JN0?>mZ9zyhjX@@`XRxR4SRcxDE^&GwO2`Y
z4=vP!=pE$*EspxV@$|mJizt~N&`>36?o56ygBmoJc1-_Rv|=@L>&7zFLfrkGTqQDT
zsKKlA@^RV=rM=-QHOFYX-m0dGy$F)_uBM02eW-mGw;MSbEpB1m2Afdjmp|Bf?R8s6^tW0L8#+S
z_^64+3cpVc#n%?ye$RoqA8>?PchD);E$MySut6CiwXoUg=uP0FY01RX!yd`&j#=LL
z0lM$PZ$YdN-FD6{pW}WASCdej@*>u=9?JRFt7!_3uEk8$*!HE%H^>(0*PAV0aX~TZ
zti#1l{M%3jT=k9&h{>e=1id7y&9N8u&}K)oCyA%5*^xEu9%cZX=^@&%32sQlfRb9;
zH59s)HaE`KuS9zhn2epiy>UgO2@#MD@4c=~CHK&M%%`)yf`>cQ_^H!Lud>A(?Qwjk
ztpo4>P`!BWUDXswBd1QHaAzB%xnhf#ImjLOSaZxwS^7e}8yC)~_m$q2FZV@WbX+K^
zG=zY2-^C29nYVj8(*81pz+vWuQ~{KW_ld|Xe=i-mkmhKTB-KFU;z-&9{lVLObz8oi
zNf)8h)B3c0_KtC5((WpoRP95cy$5*a$%V{<9pkSpas0GfE?>Q3x58?n)<&BTwv@+`
zB`oi&{sFKy1|paKwYrUQWRUPyg!k6xo|-z$Fo%`syxGANkteYl*+QwzT++(eCPTrY
ze2_IGssO#&0}Q4YJq-M-Nd_mAz08!57D@LNPBk^ifL@>3VeUFJj%9)+ERZ~In4MEU
z&2Vx*NcjpeYI|!Z(&*55)}nA02Se&)W664S-O**lq$Yx1*T5Xd21b2*SLC^UO%Ud@xWn
zmInCY<`nfTkh(8n;7Yke)AWyC2Q3-nfC~h7Xd83a5`NjnIy|@X5;D#x?R#QBcDH*C
zuJMsDl$~?
z6A(xjuC(BHBET|=z-@Ak);pMwb|K&eFD<<%1yvRmvPY%`4pQxhngP`BwG@3HJJQ0*
zwlMfvB#JIC?rdlsQ?!Pxx`-ae`LT5jft1U>*&vd?7f7ZFH`K|BbdzLY1GLTa$>ISuo9@6v;Njf@OxUfXfnknxD_4`{NPS|=Q
zG}YByyz2wsy7I@_RGKQkkdLb3$BLCz+6;c=^fchkAQv8|&dG;-irYf6LBuH$!A@Fnixuq=!(Q**%
z_oF>6YUZ#}CnK$5*Nk6tpEU>dqb51Vk_`HI(o$y*JM9qz1D|NvM?npDQ#+Jw
zIAd0i5P7D)QoEjE1M+|#;xVkA9^X!22y@7>glX5-t5fvwpS=Ejna6SaaHTz+@8EY#
zyBOy8fn$1B(Q4QD=GPi748;>WH#Q1FiE(kc=g&opdtc;XWo}d#r_*zC#
z$D$opuy94W;B(P|!Z!zr1olb~3fiuZi|kHojTOCU_g{&l`5U?1qTRZS{6aGUBau
zq?d2DTXbGxHe0;0xb+XHW3)8})S3>KIC#>TcZAdMX|_w#W8c}ADXSXB<-uD95Ma_qF9);Kd9Y39z3S|cEO8PYq7<5{|5G%nf8CYIsfsez4!ImGya2dcLFnOc
z5;_)IIVoq(`4)bfscg(Id_9{9EH%1yK4^|WJMOR_tNT~BjoDqE+iIuogU8~Qkyan%
zMsmLJ(mmun=7{p578vFGNT2tme3?ZaSFFhP~I19)66|vOK%_n0{<+
z`5P6sMDmxbR$PS!qr37jI(9YJ5E5ML6rwI?t@SHwMr7n-6C(m2ZubVKBsiDU$;NP3
zs6B-o&x95NHV;JJ8^>`>hJM?;UTx&v-+mMm1AcgorFbxr?9Yac)24E#19Bh#-H4cd
z8AZZH;fHNFh2@7zKxD}>pNsE;EIHc+VGeqQJn?@kr}Ao
z2*(dGMnuV^ZDC3N4%)muba=@%*XY3xoejbCCulG6I^W2g7b;^d0}wGBZ^3}V0MW5_
zZWbAOA*gWTMsxy?>~R&mpYow6Y?R2^{%PWtlUWAp>^684Ne7*3doO)HZFM^CBrvb)4Mv=038)o0iDMo$noN)xW(4LRu0e@IFWB-RN6hcMe
zIh(y~MmJZ#;tCI;UikZ~_po;io%}TQ0=$k~l;ZQ-Tv$cQ
zHI{{F<)zSe^~AmS!sT*0%j0GP4v
zAw)?Y!4u9?OYZVHn2~iT&s@BCtoClL{F{O>-MCM?EyrSrXU5r63a#SMPXeto)Ii&o?`P)MK5AC2op%Wu?wYm1|
zkziL!FRf6p>{JaW?Bh&ohsgXEMs~eDI=ssck@rOc66uzIp0qYX!cRtH0Mo1(Xurb@
zvJ-GV2F9Mx!lvLuTW#pK1we2l>kZ6QbhWQ1na4tq9{iL1>bb3WxWh+n=7dX99oR>ojtOpR1I&rHhgv1_kU5^e(%5{t)DxN#T_jgfNOy|
ztBeSwe`bD;?o7e?23->@+s|gDH{xjPHX?|`RBFB*xV{<7A3u77<44kALKU^kX@5xf1c%yB5-NEzhxGT~laVx%*oi<_gI97JD|U#cp?Qu1?H-H4
zVA-3?$O5V3WsaDonwcA8@cxF*B{jIiaSsBvGEq1*YCBr*ITp@bwDYb#v}0obD6(Vg
za^R0jrYuP7*7x_5OhzRpRVyP~tNn!|_ZQj4M=EWJ6B9rBn!A{2vmWZT{FFKOZfFI$
zJ}Gt^%U&z+Ry)d7<5PK@&l@dqYSXON^29f>*!v7Bb1*N58|pAOr|wX4hqSQ)wkA**
z8Q$X*9lO;TcdESDPi~}D?J5E3aQI6dt|A=ji|j<{I-#7t1qucZc)`tt|PVON7RtuCHJ&hYL6IB&Lm!_kpj@=u*2{(@a#%Xo06FtrR-j^vZz?Ej7}O
zauLbq*3LF|To`BKHtHQCv|d@LV2k(zbOi@=$K(j}?^xl;GK}t`8DNiWr;qfeHq|l@F+m
z1uiZ`?(OD6#nfh4_$S3Rys*38a(mswN)
z`+05INq2tW#0uHwVRs!CmExmijQ4-opoR4AB4$F`3|)s^w|B2BXy<$^@k?0fA=P$Y4$<{s_Np!`^h&9qTqwrwC)7`N
z<>XbtT+Js0T=)Clv**+mS=rBo`e)P>vB|AFLbT?RXoYp+EsjE6Rz*{86((zMpdu?=
zjAmyzgGh=QtOvP1jnothy_cfn`#Z9Z4gf<-@h6Yi@iM^XeFx!X=;io$Pon>hB;$}0
zur~x86n+bMyCnnfZJi!?w75m;>)wRcl`v_n!Mi!NENX@DlODdq&-~Z;_CLYhe;dsu
z#f<+?qG)hiD6-(%*gWFP4XSCF64HRAG-d`
zV`4BsOXIG1?wM1s-%@c*S=
zTyLnh(bI#i#L
z8zbiE21y^jgXA`le6sC;3L90j-QC=7CYJ-^}9GgqlFCk}d
zD?CQxlwiU9o$M;~h4_WD)5Gla)Rp7ISZ|kqfHc2{(0>Bb5qEPme!baFJlXy!hgkNr
zrdv$y9v{k}BbSD{13RoirqWEnN4RtbD;s*HQ+F8MmUmmy^mVCfO
zYYBR&jug@-a6n`d1gP(<(FggePO(UT(_8xz)#d0#_9>hEj`LNA2@d17x6wdc95__5
zL(`ld%zh;!$pmwWX*{sHnr{yYhJ$U79afIvcGt`pzdViBH_p9uv
zX~ej5LV3TZ>h+uZd911UM#T{OA!$&BDdVmp+SF*deS
ztkQ~+2NV)fj88^C`j&F(B+XxD5ZLN!0t^qp{A}PJ51h3%(>tAhjxe0SLgFJJj1JdFwl9{A`+%B+f0SUeY
zV^4mzXRzK-V2E5S^QtK*k}>gT^}~c_6d-JXTuI@$Vp!z3-s9#MM!k&%DpZ!%gq5mf
z`}h}U)Hi;anR=W<5ofNFjKcb&36H4GtEM>b
zm}Wj9=mw+@7K=|Z>=s!uuzf(^iztOc<6fRwYmO=LYPN$?t~&HSFiqXZKoao*m9Jg(
zbMbx4GR6{PtbP>ehb9ob+K{Ri_=wI(O=B-XDnGp8whBeZ&yJ7O`eX;YpEg5We-RF^
zM`)%!%tKh52Dv>1tTxG^n;iiOz6~$a`&yvf>BhsHGKT2z@+A!4Az>>k8u_JHU2n{W
zKwiEHOBn|Kd3wv`3kBtCunEVq(GE8~j%G)V?f0Ao0K|GD6EMTikjs)Tg+Wxl8CAM%
z>hm>qy_U$gFfe^ltJ>3VMW>+{a%fS<^z?nL+1Y8J)wB8Fi1#>MKk(#il0O)FfH^zo
zZVk9Mfb?yiW{I%;<9Pw*0z0J5@__