`: specifies the BPMN types the template can be applied to. The template will only be selectable for these types of elements in the modeler. Currently, element templates may be used on the following BPMN elements:
- - `bpmn:Activity` (including user tasks, service tasks, call activities, ad-hoc subprocesses, and others)
- - `bpmn:SequenceFlow` (for maintaining `condition`)
- - `bpmn:Process`
- - `bpmn:Event`
-- `elementType : Object`: If you configure `elementType` on a template, the element is replaced with the specified type when a user applies the template.
- - `value : String`: Is a required key. The BPMN element is changed to this type the template is applied.
- - `eventDefinition: String`: This key is used when templating an event. It can be ignored when templating any other element type. Supported values are:
- - `"bpmn:MessageEventDefinition"` use this value when you template a message event.
- - `"bpmn:SignalEventDefinition"` use this value when you template a signal event.
- - `"bpmn:TimerEventDefinition"` use this value when you template a timer event.
-
-Some properties require a specific BPMN type, and thus a specific value for `elementType`, to work correctly.
-For example, if the template sets `zeebe:calledDecision` on an element and `appliesTo` is set to `bpmn:Task`, the `elementType` must be set to `bpmn:BusinessRuleTask`.
-These constraints are checked based on the [element template schema](./template-metadata.md#validation-schema) by your editor (if it supports JSON schema) and by the modeler when it loads the templates.
-
-```json
-{
- ...,
- "appliesTo": [
- "bpmn:Task"
- ],
- "elementType": {
- "value": "bpmn:ServiceTask"
- }
-}
-```
-
-## Grouping properties: `groups`
-
-- `groups` is an optional key.
-
-You can define `groups` to organize custom fields into. The fields will be shown in their assigned group in the properties panel.
-You can also specify whether a group is expanded or collapsed by default. This helps you to highlight important fields and to reduce visual clutter.
-
-Groups can have the following attributes:
-
-- `id : String`: Unique identifier of the group
-- `label : String`: Label of the group
-- `tooltip : String`: Tooltip for the group (optional)
-- `openByDefault : Boolean`: Whether the group will be expanded in the properties panel (optional, default: `false`)
-
-A property can be assigned to a group by setting the [`group` key](./template-properties.md#grouping-fields-group) to the group's `id` value.
-
-```json
-{
- ...,
- "groups": [
- {
- "id": "definition",
- "label": "Task definition",
- "openByDefault": true
- },
- {
- "id": "request",
- "label": "Request payload"
- },
- {
- "id": "result",
- "label": "Result mapping"
- },
- {
- "id": "authentication",
- "label": "Authentication",
- "tooltip": "Optional authentication settings"
- }
- ],
- "properties": [
- ...
- ]
-}
-```
-
-## Deprecating a template: `deprecated`
-
-- `deprecated` is an optional key.
-
-Use `deprecated` to mark a [template as deprecated](https://github.com/bpmn-io/element-templates/blob/main/docs/LIFE_CYCLE.md#deprecation).
-
-:::info
-By deprecating an element template, you prevent its _future use_. Users will no longer see the template when choosing a template, changing an element's type, or creating a new element. Existing uses continue to work, with a deprecation hint shown in the modeler UI.
-:::
-
-The `deprecated` property can be an object or a boolean. If an object, it has the following attributes:
-
-- `message: String`: A message to display to the user
-- `documentationRef : String`: A link to documentation, i.e., to describe upgrade migration procedures
-
-This information allows users to make sense of the deprecation and understand how to migrate to an undeprecated template:
-
-```json
-{
- ...,
- "deprecated": {
- "message": "Migrate to My Other Custom Task",
- "documentationRef": "https://localhost/migrate-to-other"
- },
- ...
-}
-```
-
-When `deprecated` is a boolean (`true`), a deprecation hint appears in the properties panel without further help for the user:
-
-```json
-{
- ...,
- "deprecated": true,
- ...
-}
-```
-
-:::tip
-Review the [upstream documentation](https://github.com/bpmn-io/element-templates/blob/main/docs/LIFE_CYCLE.md#overview) to learn more about template evolution and the template lifecycle.
-:::
diff --git a/docs/components/modeler/using-web-and-desktop-modeler-together.md b/docs/components/modeler/using-web-and-desktop-modeler-together.md
index 3408f31cb35..432711e5ffa 100644
--- a/docs/components/modeler/using-web-and-desktop-modeler-together.md
+++ b/docs/components/modeler/using-web-and-desktop-modeler-together.md
@@ -66,9 +66,9 @@ Camunda recommends storing shared templates in a separate repository:
### Handling multiple template versions
-| Desktop Modeler | Web Modeler |
-| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Detects versions based on separate files. To support multiple versions, maintain different files with distinct names (e.g., `element-template-v1.json`, `element-template-v2.json`). Otherwise, templates may appear as [missing](/components/modeler/desktop-modeler/element-templates/using-templates.md#missing-templates). | Supports evolving a single template file. Simply update the file and [publish](/components/connectors/manage-connector-templates.md#manage-published-connector-templates) new [versions](/components/modeler/element-templates/defining-templates.md#template-versioning). |
+| Desktop Modeler | Web Modeler |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Detects versions based on separate files. To support multiple versions, maintain different files with distinct names (e.g., `element-template-v1.json`, `element-template-v2.json`). Otherwise, templates may appear as [missing](/components/modeler/desktop-modeler/element-templates/configuring-templates.md). | Supports evolving a single template file. Simply update the file and [publish](/components/connectors/manage-connector-templates.md#manage-published-connector-templates) new [versions](/components/modeler/element-templates/create/defining-templates.md#template-versioning). |
:::warning
@@ -89,6 +89,6 @@ Yes. Camunda recommends maintaining a dedicated version control repository for e
### How should I manage multiple versions of the same element template?
-In Desktop Modeler, each version of the element template must be present. Versions can be stored in a single file as a list of element templates or in separate files (for example, `element-template-v1.json` and `element-template-v2.json`). Otherwise, the template will appear as [missing](/components/modeler/desktop-modeler/element-templates/using-templates.md#missing-templates). Web Modeler, however, supports [versioning](/components/modeler/element-templates/defining-templates.md#template-versioning) in a single file and allows you to [publish](/components/connectors/manage-connector-templates.md#manage-published-connector-templates) new versions directly.
+In Desktop Modeler, each version of the element template must be present. Versions can be stored in a single file as a list of element templates or in separate files (for example, `element-template-v1.json` and `element-template-v2.json`). Otherwise, the template will appear as [missing](/components/modeler/desktop-modeler/element-templates/configuring-templates.md). Web Modeler, however, supports [versioning](/components/modeler/element-templates/create/defining-templates.md) in a single file and allows you to [publish](/components/connectors/manage-connector-templates.md#manage-published-connector-templates) new versions directly.
When referencing a dependency such as a form we recommend using a `versionTag` as your [binding type](/components/best-practices/modeling/choosing-the-resource-binding-type.md#supported-binding-types), as this option ensures that the right version of the target resource is always used.
diff --git a/docs/components/modeler/web-modeler/element-templates/best-practices.md b/docs/components/modeler/web-modeler/element-templates/best-practices.md
deleted file mode 100644
index 2e573b683f2..00000000000
--- a/docs/components/modeler/web-modeler/element-templates/best-practices.md
+++ /dev/null
@@ -1,170 +0,0 @@
----
-id: best-practices
-title: Best practices for custom-built element templates
-description: Learn the best practices for creating and managing custom-built element templates in Web Modeler.
----
-
-When creating custom-built element templates, consider the following best practices to ensure they are effective, user-friendly, and maintainable.
-
-:::note
-Connector templates are a specific type of [element template](/components/concepts/element-templates.md).
-:::
-
-## Naming, description, and icon
-
-### Sentence case
-
-Use sentence case when naming element and connector templates.
-
-For example:
-
-- ❌ GitHub Webhook Intermediate Catch Event connector
-- ✅ GitHub webhook intermediate catch event connector
-
-### Choosing a name
-
-Choose a clear, easily understandable name. Include the brand name if the template connects to a service or tool; otherwise, describe its main feature.
-The template's name and description appear in the Modeler element template list and properties panel.
-
-### Description
-
-Keep descriptions brief and clear. Explain what the template does and why it’s helpful in a couple of lines. Avoid technical jargon or complex language.
-
-## Icon
-
-- **Prefer SVG format:** Use SVG files for icons, as they are scalable without losing quality. If an SVG icon isn't available, PNG or JPEG format is acceptable, but may not display well.
-- **Size:** You can upload an image file with a maximum size of **8 KB**. If you need to use a PNG or JPEG icon, ensure it is **512x512** pixels. Icons appear as **18x18** pixels in the element on the modeling canvas, and as **32x32** pixels in the properties panel.
-- **Check for official logo:** If the template connects to a service or tool, look for an official logo on the service's or tool's website.
-- **License compliance:** Ensure icons have the appropriate license (Public Domain CC0 or Creative Commons CC BY) for commercial use.
-
-## Properties panel UI
-
-The element template defines interaction methods, visible and hidden entries, and mandatory fields, which are reflected in the Modeler properties panel UI. Follow these guidelines for a consistent user experience.
-
-### Property naming
-
-- Use readable property names instead of technical identifiers.
-- Use sentence case.
-- Align operation or property IDs with Java method naming conventions (IDs are referenced in the template code, not displayed).
-
-Example:
-
-- ID aligned with Java method: `addQueueItem`
-- Label:
- - ✅ Add queue item
- - ❌ addQueueItem
-
-### Property description
-
-- Ensure accuracy in property descriptions.
-- Use tooltips for brief explanations.
-- Link to relevant documentation for detailed explanations.
-
-Example:
-
-- ❌ "Your application's Client ID from the OAuth client."
-- ✅ "UIPath OAuth Client ID: Retrieve from UIPath external apps configuration."
-
-### Placeholders
-
-- Placeholders appear as lighter text inside input fields. Use them to indicate the expected format or example input.
-- Avoid placeholders that duplicate the label.
-- Ensure placeholders are understandable and helpful.
-
-### Variable naming
-
-Variables are not displayed in the properties panel but are referenced inside the template code.
-
-**General rule:** Use lower camel case (start lowercase, capitalize subsequent words). Avoid starting variables with underscores ("\_").
-
-Example:
-
-- ❌ \_MyTestVariable
-- ✅ myTestVariable
-
-**Exception for method-specific properties:** Underscores may separate the method indication from the property name.
-
-Example:
-
-- ✅ chatCompletion_apiVersion
-- ✅ completion_apiVersion
-
-### Versioning
-
-If you plan to make changes to your template over time and want to support [template evolution](https://github.com/bpmn-io/element-templates/blob/main/docs/LIFE_CYCLE.md#overview), include a version number property in your template, starting from 1. Templates with the same ID and different version values offer an upgrade path.
-
-```json
-{
- "$schema": "https://unpkg.com/@camunda/zeebe-element-templates-json-schema/resources/schema.json",
- "name": "My Connector",
- "id": "org.my.connector",
- "version": 1
-}
-```
-
-### JSON structure
-
-The JSON structure should mirror the visual presentation to maintain alignment with the UI order. This ensures groups and properties are organized accordingly, even if some elements are hidden.
-If you want to use a FEEL expression that references other variables, the properties defining those variables must be declared before the property where the FEEL expression is used.
-
-### Secret handling
-
-- Follow the rules of the system you’re adding to.
-- Do not save secret information in the JSON.
-- Use the connectors' [secret handling](/components/connectors/use-connectors/index.md#using-secrets).
-
-### Field types
-
-The following guidelines ensure templates are intuitive and designed to minimize errors. This helps to create a good user experience.
-
-#### Hidden vs. visible fields
-
-If certain values are static and do not require user input, prefill them. Hidden fields offer no additional benefit by being visible.
-
-**Hidden fields example:**
-
-- HTTP method
-- Static URL endpoint
-- Static header
-
-#### Required vs. optional
-
-- **Required:** Properties essential for the template to function. Without these, the template cannot operate.
-- **Optional:** Properties that are not mandatory but provide additional functionality.
-
-There are two mechanisms to define property behavior depending on whether a field is required or optional:
-
-- [**“Not empty” constraint**](/components/modeler/element-templates/template-properties.md#validating-user-input-constraints): Displays an error if the field is left empty.
-- [**Optional bindings**](/components/modeler/element-templates/template-properties.md#preventing-persisting-empty-values-optional): Does not persist empty properties in the BPMN XML.
-
- Use **optional bindings** when a property is not required and you want to avoid storing empty values in the BPMN XML. In most cases, required fields should use the "Not empty" constraint for validation.
-
-#### Mandatory FEEL vs. optional FEEL
-
-FEEL expressions should only be required when necessary. For straightforward inputs, expressions can be optional.
-More details: [FEEL editor support](/components/modeler/element-templates/template-properties.md#adding-feel-editor-support-feel).
-
-#### Free input vs. dropdown vs. constraints
-
-- Use a dropdown when selection options are predefined.
-- Use free input with constraints when there is a wide range of input possibilities.
-
-**Example:**
-
-```json
-{
- "label": "Priority",
- "id": "priority",
- "group": "input",
- "description": "The priority to apply to the queue item.",
- "value": "Low",
- "type": "Dropdown",
- "choices": [
- { "name": "Low", "value": "Low" },
- { "name": "Normal", "value": "Normal" },
- { "name": "High", "value": "High" }
- ],
- "binding": { "type": "zeebe:input", "name": "priority0" },
- "condition": { "property": "operationType", "oneOf": ["addQueueItem"] }
-}
-```
diff --git a/docs/components/modeler/web-modeler/element-templates/element-template-generator.md b/docs/components/modeler/web-modeler/element-templates/element-template-generator.md
deleted file mode 100644
index 0eacad9dbd5..00000000000
--- a/docs/components/modeler/web-modeler/element-templates/element-template-generator.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-id: element-template-generator
-title: Generate an element template
-description: Learn how to generate element or connector templates for easier creation of custom reusable elements.
----
-
-You can configure and automatically generate a custom element template in Web Modeler.
-
-### Best practices
-
-When creating custom-built element templates, consider the best practices outlined in [Best practices for custom-built element templates](best-practices.md) to ensure they are effective, user-friendly, and maintainable.
-
-## Generate a BPMN element template
-
-1. Select the Web Modeler project where you want to create the template. Camunda recommends storing element templates in root project folders, not process applications, to simplify template management and avoid unnecessary versioning overhead.
-2. Click **Create new**, then select **Element template** to open the **Create new element template** screen.
- 
-
-3. Select the template starting point:
- - **Call activity**: Start from a call activity template.
- - **Event**: Start from an event template.
- You can choose from predefined event templates, such as message event, timer event, signal event.
- - **Task**: Start from a task template.
- You can choose from predefined task templates, such as user task, service task, script task, and more.
- - **Blank**: Start from a blank template.
- A blank template includes only the basic properties shared by all BPMN elements and allows you to customize the template from scratch.
-
-Continue with [**Step 4**](#configure-the-template-details) in the Configure the template details section below.
-
-## Generate a connector template
-
-You can start from a blank template or import an existing API definition such as an [OpenAPI specification](https://swagger.io/resources/open-api/), [Swagger specification](https://swagger.io/resources/open-api/), or a [Postman collection](https://www.postman.com/collection/). For example, download a Postman collection as a YAML file, import it into the generator, and choose which methods to include in the generated template.
-
-To generate a connector template:
-
-1. Select the Web Modeler project where you want to create the template. Camunda recommends storing element templates in root project folders, not process applications, to simplify template management and avoid unnecessary versioning overhead.
-2. Click **Create new**, select **Element template**, and then choose the **Connector** tab.
- 
-
-3. Select the template starting point:
- - **From API definition**: Import an existing API definition file as a starting point. The **Import data source** section will appear below the template details.
- - **From blank**: Start from a blank template.
-
-Continue with [**Step 4**](#configure-the-template-details) in the Configure the template details section below.
-
-## Configure the template details
-
-4. In the **Configure template details** section, provide the following information:
- - **Name:** Enter a clear and descriptive name for the template. For example, include the brand name if the template connects to a service, or indicate its main feature.
- - **Description:** Describe the template’s main features and benefits.
- - **Icon:** Use a default BPMN symbol or upload a custom icon. Supported formats: SVG, PNG, JPEG. Maximum file size: 8 KB. Minimum dimensions: 512 × 512 pixels.
- - **Import from URL:** Enter the URL of the image and click **Import icon**.
- - **Upload file:** Drag and drop a file into the upload area, or click the link to select a file.
-
- :::note
- If you do not configure template details at this stage, a default name and BPMN symbol are assigned. You can edit them later.
- :::
-
-#### Only for connector templates: Import an API definition
-
-5. If you selected **From API definition**, the **Import data source** section appears.
- 1. Select the format to import (OpenAPI or Postman) and click **Import file**.
- 2. Import the API definition:
- - **Import file from URL:** Enter the API definition URL and click **Import icon**.
- - **Upload file:** Drag and drop a file into the upload area, or click the link to select a file.
-
- 3. After importing, select which actions to include from the generated list of supported methods.
- 
-
- :::info
- For more information on working with and configuring connector templates, see [Connector templates](/components/connectors/custom-built-connectors/connector-templates.md).
- :::
-
-6. Click **Create template** to generate the new template and open it in the [element template editor](/components/connectors/manage-connector-templates.md).
diff --git a/docs/components/modeler/web-modeler/element-templates/manage-element-templates.md b/docs/components/modeler/web-modeler/element-templates/manage-element-templates.md
deleted file mode 100644
index e4aaf0dc54d..00000000000
--- a/docs/components/modeler/web-modeler/element-templates/manage-element-templates.md
+++ /dev/null
@@ -1,156 +0,0 @@
----
-id: manage-element-templates
-title: Manage element templates
-description: Manage your element templates in Web Modeler.
----
-
-export const UploadIcon = () => Camunda 8 only
-
-You can create and manage [element templates](/components/concepts/element-templates.md) just as any other asset in a Web Modeler project.
-
-## Create an element template
-
-To create a new element template, follow the steps described in [Generate an element template](./element-template-generator.md).
-
-You will be taken to the **Element template editor** screen.
-In this screen, you can define the element template by writing the template JSON.
-The template editor supports you in writing the template by providing autocompletion, error highlighting, and a live preview.
-
-
-
-The components of the editor interface are as follows:
-
-- On the left, you find the **template JSON editor**. Here, you define the actual [template descriptor](/components/modeler/element-templates/defining-templates.md).
- The descriptor follows the [most recent element template schema](https://github.com/camunda/element-templates-json-schema).
-
- :::info
- Starting with 8.8, the following properties are not managed by Web Modeler anymore, and you can freely edit them:
- - `name`: Human-friendly name shown when selecting a template and in the properties panel after the template has been applied. The value can be different from the file name.
- - `id`: Identifier of the template. Changing this value creates a new template. We recommend setting a meaningful value (for example, "PaymentConnector", "CreateUserTemplate").
- - `version`: Integer-based version number. Combined with the `id`, it defines a unique template version. When [publishing](#publish-a-connector-template) a new version, you need to update the version number manually.
-
- The value of the `$schema` property is still fixed; manual changes will not be saved.
- :::
-
-- On the right, you observe the live **Visual Preview**. The live preview shows how the properties panel will look when you apply the template to an element. It automatically updates on every valid change, and reflects the latest valid state of the template. The preview allows you to interactively check your template before publishing it.
- You can also use the **Update JSON** button to update the template's JSON properties with the current input values from the visual preview.
-
-- In the upper right, you can **Add an icon** for your template. You can upload an image file with a maximum size of 8 KB. We recommend using squared SVG graphics. Icons appear as 18x18 pixels in the element on the modeling canvas, and as 32x32 pixels in the properties panel.
-
-On every valid change, the template is saved automatically. If there are errors in the JSON file, the template will not be saved. Ensure all [errors are resolved](#fixing-template-problems) for the template to save successfully.
-
-## Publish an element template
-
-After finalizing your element template, click **Publish to project** to activate it within the project context. In the modal that opens:
-
-- Update the version number if necessary. You don't need to change it for the initial version or if you have updated it already in the template editor.
- The value entered here is saved to the `version` property in the JSON.
-- Assign a distinct version name for effective version management.
-- Add a description to explain what changed since the previous version.
-
-
-
-Web Modeler checks the template for conflicts with already-published template versions.
-You cannot publish a new version if:
-
-- The template's ID is already used in a published version of a different template file.Modeler
diff --git a/docs/reference/announcements-release-notes/880/880-release-notes.md b/docs/reference/announcements-release-notes/880/880-release-notes.md
index 8351c4bc2e7..de0eb2188a6 100644
--- a/docs/reference/announcements-release-notes/880/880-release-notes.md
+++ b/docs/reference/announcements-release-notes/880/880-release-notes.md
@@ -668,7 +668,7 @@ In addition to bearer token authentication, you can now configure Web Modeler in
Web Modeler now provides a low-coder friendly UX for creating building blocks.
Whether you create an element template from scratch or from a task, you can quickly set and narrow down the properties so process developers using these templates can quickly and confidently wire building blocks together into an E2E process.
-Generate an element template
+Generate an element template
### Element template support for all tasks
@@ -680,7 +680,7 @@ You can now save any configured task as a reusable element template directly fro
- Edit templates to adjust input/output bindings, validation rules, categories, and more.
- Publish templates to your project or organization for reuse.
-Save tasks as element templates
+Save tasks as element templates
### Unlock element template fields
@@ -692,7 +692,7 @@ Element template management is now more flexible for developers and DevOps teams
- Template names and file names can be managed independently, and you can quickly import templates using copy and paste, git sync, or CI/CD pipeline.
- Safeguards now notify you of ID or version conflicts to prevent accidental overwrites when publishing templates.
-Manage element templates
+Manage element templates
### FEEL Copilot
@@ -838,7 +838,7 @@ You can now save any configured task as a reusable element template directly fro
- Edit templates to adjust input/output bindings, validation rules, categories, and more
- Publish templates to your project or organization for reuse
-See [save tasks as element templates](/components/modeler/web-modeler/element-templates/save-as-element-templates.md) for details.
+See [save tasks as element templates](/components/modeler/element-templates/about-templates.md) for details.
Additional support includes:
diff --git a/docs/reference/announcements-release-notes/890/890-release-notes.md b/docs/reference/announcements-release-notes/890/890-release-notes.md
index 4f108f662cf..bd266b21ac6 100644
--- a/docs/reference/announcements-release-notes/890/890-release-notes.md
+++ b/docs/reference/announcements-release-notes/890/890-release-notes.md
@@ -502,7 +502,7 @@ Web Modeler in 8.9 adds more reliable live collaboration with canvas locking and
Camunda 8.9 expands Web Modeler with broader event template support, email-based project invitations for all supported OIDC providers, and a simpler Self-Managed system architecture by folding the former `webapp` component into `restapi`. Additional 8.9 updates include embedded Tomcat for Self-Managed deployments and a SaaS endpoint for monitoring Web Modeler egress IP ranges.
- [Element templates in Modeler](/components/modeler/element-templates/defining-templates.md) [Element templates in Modeler](/components/modeler/element-templates/create/defining-templates.md) [Add users to projects](/components/modeler/web-modeler/collaboration/collaboration.md#add-users-to-projects) [Embedded web server](/self-managed/upgrade/components/880-to-890.md#embedded-web-server)
@@ -1310,7 +1310,7 @@ You can also create global event templates that:
- Standardize event configurations (for example, message names or payload structures).
- Help ensure consistency across teams and models.
-[Element templates in Modeler](/components/modeler/element-templates/defining-templates.md)
+[Element templates in Modeler](/components/modeler/element-templates/create/defining-templates.md)
#### Web Modeler: Invite users via email
@@ -1605,7 +1605,7 @@ Element templates now support reusable [BPMN signals](/components/modeler/bpmn/s
- The `bpmn:Signal#property` binding allows you to set the name of a `bpmn:Signal` referred to by the templated element.
- This binding is only valid for templates of events with `bpmn:SignalEventDefinition`.
-[Element template `bpmn:Signal` binding](/components/modeler/element-templates/template-properties.md#signal-name-bpmnsignalproperty)
+[Element template `bpmn:Signal` binding](/components/modeler/element-templates/create/template-properties.md)
#### Web Modeler: Embedded web server changed from Undertow to Tomcat (Self-Managed)
diff --git a/docs/reference/announcements-release-notes/890/whats-new-in-89.md b/docs/reference/announcements-release-notes/890/whats-new-in-89.md
index 1e88d788c7e..5c754c90234 100644
--- a/docs/reference/announcements-release-notes/890/whats-new-in-89.md
+++ b/docs/reference/announcements-release-notes/890/whats-new-in-89.md
@@ -308,7 +308,7 @@ The following usability improvements simplify collaboration and help teams keep
| Feature | Description |
| :-------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| [Element templates](/components/modeler/element-templates/defining-templates.md) | Create templates for message, signal, and timer events, and reuse and share templates across projects to standardize message names, payloads, and timer definitions. |
+| [Element templates](/components/modeler/element-templates/create/defining-templates.md) | Create templates for message, signal, and timer events, and reuse and share templates across projects to standardize message names, payloads, and timer definitions. |
| [Email invitations](/components/modeler/web-modeler/collaboration/collaboration.md#add-users-to-projects) | Invite new users to Web Modeler projects via email, regardless of OIDC provider, and use a consistent invitation flow across Keycloak, Entra ID, Okta, Auth0, and other providers. |
### Improved Self-Managed installation
diff --git a/docs/reference/glossary.md b/docs/reference/glossary.md
index cb671f60cc9..4eeee6e2120 100644
--- a/docs/reference/glossary.md
+++ b/docs/reference/glossary.md
@@ -73,6 +73,16 @@ For example, build an invoice-processing AI agent in Camunda with BPMN, using an
- [AI agents](/components/agentic-orchestration/ai-agents.md)
- [Build your first AI Agent](/guides/getting-started-agentic-orchestration.md)
+### Apply template/applied template
+
+To **apply a template** means to attach an [element template](#element-template) to a BPMN element in Modeler.
+Applying a template replaces the element’s properties panel with a UI defined in the template, and binds technical configuration (inputs, outputs, headers, authentication, version tags, and more) into the BPMN XML.
+
+An **applied template** refers to a BPMN element that already uses a template.
+In Web Modeler, applied templates can be **saved as a new template**, allowing reuse across projects.
+
+- [Using element templates](/components/modeler/element-templates/getting-started/using-templates-in-web-modeler.md)
+
### Audit log
The [audit log](../components/audit-log/overview.md) is a record of operations, including who performed them, when, and on which entities. Use the audit log to prove compliance, meet governance and regulatory requirements, maintain operational integrity and transparency, and troubleshoot issues.
@@ -151,7 +161,21 @@ The [connector runtime](/components/connectors/custom-built-connectors/connector
### Connector template
-A [connector template](/components/connectors/custom-built-connectors/connector-templates.md) is a type of element template used to configure connectors in Modeler. Templates define UI fields, metadata, and bindings required for connector operations. Modeler internally labels all templates as element templates, but connector templates are the subset specifically used to configure connectors.
+A **connector template** is a specialized type of [element template](#element-template) that configures a Camunda Connector.
+Connector templates define:
+
+- Input fields and validation
+- Authentication models
+- Output mappings
+- Runtime behavior bindings (for example `taskDefinition:type`)
+- UI organization and defaults
+
+Connector templates ensure consistent behavior and reduce modeling errors when using connectors such as HTTP, Slack, Kafka, or AI models.
+
+They follow the same schema as element templates but apply specifically to service tasks referencing a Connector.
+
+- [Element templates](/components/modeler/element-templates/about-templates.md)
+
### Context window
@@ -203,7 +227,16 @@ A BPMN element is part of a [process](#process), defining one part of its BPMN m
Use an element template to extend [Modeler](/components/modeler/about-modeler.md) with domain-specific diagram [elements](#element). The user edits such elements through a UI defined by the element template, and in the process configures BPMN element properties in simple and predictable ways. Element templates are used by [connectors](#connector) to create the connector-specific [element](#element) configuration.
-- [Element templates](/components/modeler/element-templates/about-templates.md)
+- The element(s) they apply to
+- The UI fields shown in the properties panel
+- How those fields bind to BPMN or Zeebe extension properties
+- Default values, constraints, and hidden technical fields
+- Compatibility and versioning
+
+Templates help modelers configure elements safely and consistently.
+Connector templates are a **subset** of element templates.
+
+- [About element templates](/components/modeler/element-templates/about-templates.md)
### Embedding (vector embedding)
@@ -576,6 +609,51 @@ This way, a [Camunda workflow](#workflow) can receive messages from an external
## T
+### Template metadata
+
+Metadata describes required and optional fields that identify a template and control how it behaves.
+Common metadata fields include:
+
+- `id`: Unique template identifier
+- `name`: Visible label in Modeler
+- `version`: Version number for upgrade paths
+- `appliesTo`: BPMN element types
+- `category`, `description`, `keywords`
+- `icon`: Template icon configuration
+- `engines`: Engine compatibility range
+
+- [Template metadata](/components/modeler/element-templates/create/template-metadata.md)
+
+### Template properties
+
+The **properties** section defines the fields that appear in the Modeler UI when the template is applied.
+
+Properties describe:
+
+- Data type (`String`, `Number`, `Boolean`, `Dropdown`, `Hidden`, etc.)
+- Default values
+- Validation rules
+- Binding (for example, `zeebe:input`, `zeebe:taskDefinition`)
+- Grouping and conditional visibility
+
+Properties define the interactive experience for the modeler.
+
+- [Template properties](/components/modeler/element-templates/create/template-properties.md)
+
+### Template dependencies
+
+Dependencies describe external resources or runtime components required for a template to function, such as:
+
+- Forms used by user tasks
+- DMN decisions
+- Subprocesses (call activities)
+- Job workers / connector runtimes
+- Secrets
+
+Dependencies must be available **at design time** (for template selection) and **at runtime** (for correct execution).
+
+- [Templates with dependencies](/components/modeler/element-templates/create/element-templates-with-dependencies.md)
+
### Temperature
A parameter that regulates the randomness or creativity of AI-generated text. Lower values result in more focused and predictable responses, while higher values lead to more creative and varied outputs.
diff --git a/sidebars.js b/sidebars.js
index d9de4be2b58..276f65a0f4a 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -544,20 +544,6 @@ module.exports = {
},
],
},
- {
- type: "category",
- label: "Element templates",
- link: {
- type: "doc",
- id: "components/modeler/web-modeler/element-templates/manage-element-templates",
- },
- items: [
- "components/modeler/web-modeler/element-templates/element-template-generator",
- "components/modeler/web-modeler/element-templates/using-templates-in-web-modeler",
- "components/modeler/web-modeler/element-templates/save-as-element-templates",
- "components/modeler/web-modeler/element-templates/best-practices",
- ],
- },
{
"AI features": [
"components/modeler/web-modeler/modeling/advanced-modeling/camunda-docs-ai",
@@ -625,7 +611,6 @@ module.exports = {
{
"Element templates": [
"components/modeler/desktop-modeler/element-templates/configuring-templates",
- "components/modeler/desktop-modeler/element-templates/using-templates",
],
},
{
diff --git a/versioned_docs/version-8.6/components/concepts/byok/aws-kms-setup.md b/versioned_docs/version-8.6/components/concepts/byok/aws-kms-setup.md
index 9a69e79de95..23e771f5d57 100644
--- a/versioned_docs/version-8.6/components/concepts/byok/aws-kms-setup.md
+++ b/versioned_docs/version-8.6/components/concepts/byok/aws-kms-setup.md
@@ -16,9 +16,10 @@ Learn how to configure encryption at rest for your Camunda 8 SaaS cluster using
| Technical familiarity | Some experience with the AWS Management Console, IAM roles, and AWS KMS. |
:::warning Important
+
- Deleting or disabling your AWS KMS key will make your cluster and data inaccessible. To understand how Camunda behaves if a key is disabled, deleted, or its policy is changed, see [key state behavior](/components/concepts/byok/key-state-behavior.md).
- Key management is fully customer-side in AWS KMS. Camunda cannot rotate keys.
-:::
+ :::
## Step 1: Create a Camunda 8 cluster
diff --git a/versioned_docs/version-8.7/components/concepts/byok/aws-kms-setup.md b/versioned_docs/version-8.7/components/concepts/byok/aws-kms-setup.md
index 0e876afbadd..8c8732f194b 100644
--- a/versioned_docs/version-8.7/components/concepts/byok/aws-kms-setup.md
+++ b/versioned_docs/version-8.7/components/concepts/byok/aws-kms-setup.md
@@ -16,9 +16,10 @@ Learn how to configure encryption at rest for your Camunda 8 SaaS cluster using
| Technical familiarity | Some experience with the AWS Management Console, IAM roles, and AWS KMS. |
:::warning Important
+
- Deleting or disabling your AWS KMS key will make your cluster and data inaccessible. To understand how Camunda behaves if a key is disabled, deleted, or its policy is changed, see [key state behavior](/components/concepts/byok/key-state-behavior.md).
- Key management is fully customer-side in AWS KMS. Camunda cannot rotate keys.
-:::
+ :::
## Step 1: Create a Camunda 8 SaaS cluster
diff --git a/versioned_docs/version-8.7/components/modeler/desktop-modeler/install-the-modeler.md b/versioned_docs/version-8.7/components/modeler/desktop-modeler/install-the-modeler.md
index d1284508a27..c67438ee521 100644
--- a/versioned_docs/version-8.7/components/modeler/desktop-modeler/install-the-modeler.md
+++ b/versioned_docs/version-8.7/components/modeler/desktop-modeler/install-the-modeler.md
@@ -4,6 +4,7 @@ title: Install Desktop Modeler
sidebar_label: Installation
description: "Learn how to install Camunda Desktop Modeler, a desktop application for modeling BPMN, DMN, and Forms and support building executable diagrams with Camunda."
---
+
import Tabs from "@theme/Tabs";
import TabItem from "@theme/TabItem";
@@ -27,15 +28,19 @@ To install [Desktop Modeler](./index.md) for Windows, macOS, and Linux, visit th
Ensure the installation is owned by `root` and accessible to all users of the machine by following the steps below.
1. Unpack the zip archive using the `tar` command:
+
```shell
cd /usr/bin
sudo tar xvfz ~/Downloads/camunda-modeler-5.41.0-linux-x64.tar.gz
```
+
2. Ensure the access permissions of the `chrome-sandbox` file are correct and create a link to this version:
+
```shell
sudo chmod 4755 camunda-modeler-5.41.0-linux-x64/chrome-sandbox
sudo ln -s camunda-modeler-5.41.0-linux-x64/camunda-modeler camunda-modeler
```
+
## Wire file associations
diff --git a/versioned_docs/version-8.8/components/modeler/desktop-modeler/install-the-modeler.md b/versioned_docs/version-8.8/components/modeler/desktop-modeler/install-the-modeler.md
index d1284508a27..c67438ee521 100644
--- a/versioned_docs/version-8.8/components/modeler/desktop-modeler/install-the-modeler.md
+++ b/versioned_docs/version-8.8/components/modeler/desktop-modeler/install-the-modeler.md
@@ -4,6 +4,7 @@ title: Install Desktop Modeler
sidebar_label: Installation
description: "Learn how to install Camunda Desktop Modeler, a desktop application for modeling BPMN, DMN, and Forms and support building executable diagrams with Camunda."
---
+
import Tabs from "@theme/Tabs";
import TabItem from "@theme/TabItem";
@@ -27,15 +28,19 @@ To install [Desktop Modeler](./index.md) for Windows, macOS, and Linux, visit th
Ensure the installation is owned by `root` and accessible to all users of the machine by following the steps below.
1. Unpack the zip archive using the `tar` command:
+
```shell
cd /usr/bin
sudo tar xvfz ~/Downloads/camunda-modeler-5.41.0-linux-x64.tar.gz
```
+
2. Ensure the access permissions of the `chrome-sandbox` file are correct and create a link to this version:
+
```shell
sudo chmod 4755 camunda-modeler-5.41.0-linux-x64/chrome-sandbox
sudo ln -s camunda-modeler-5.41.0-linux-x64/camunda-modeler camunda-modeler
```
+
## Wire file associations
diff --git a/versioned_docs/version-8.8/components/saas/byok/aws-kms-setup.md b/versioned_docs/version-8.8/components/saas/byok/aws-kms-setup.md
index 05b8ab97270..fd83079c906 100644
--- a/versioned_docs/version-8.8/components/saas/byok/aws-kms-setup.md
+++ b/versioned_docs/version-8.8/components/saas/byok/aws-kms-setup.md
@@ -16,9 +16,10 @@ Learn how to configure encryption at rest for your Camunda 8 SaaS Orchestration
| Technical familiarity | Some experience with the AWS Management Console, IAM roles, and AWS KMS. |
:::warning Important
+
- Deleting or disabling your AWS KMS key will make your cluster and data inaccessible. To understand how Camunda behaves if a key is disabled, deleted, or its policy is changed, see [key state behavior](/components/saas/byok/key-state-behavior.md).
- Key management is fully customer-side in AWS KMS. Camunda cannot rotate keys.
-:::
+ :::
## Step 1: Create a Camunda 8 SaaS Orchestration cluster