From 614c7861b8a8a9aa4e4d3b3ad565e75769b29365 Mon Sep 17 00:00:00 2001 From: NielsKunst <112099042+NielsKunst@users.noreply.github.com> Date: Wed, 1 Apr 2026 15:56:57 +0200 Subject: [PATCH 1/2] Update scheduled-events.md Added this as result of this slack thread: https://mendix.slack.com/archives/CA82XPUQG/p1770300321312099 This could also be added to Mx10 and Mx9 documentation as it is unrelated from the Mx version. I asked in that slack thread for people to review it. --- .../modeling/resources/scheduled-events.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/content/en/docs/refguide/modeling/resources/scheduled-events.md b/content/en/docs/refguide/modeling/resources/scheduled-events.md index 090c665cb89..66dc09e17f8 100644 --- a/content/en/docs/refguide/modeling/resources/scheduled-events.md +++ b/content/en/docs/refguide/modeling/resources/scheduled-events.md @@ -206,3 +206,17 @@ If you want to implement complex interval patterns, such as running a scheduled 1. Perform the actions relating to the event only if the condition evaluates to true. This approach allows you to maintain flexibility in scheduling while keeping the logic centralized and easy to manage. + +### Renaming Scheduled Events and Deployment Behavior + +When a scheduled event is deployed to an environment, its enabled/disabled state is tracked by name, and not by a unique identifier. This applies to any deployment type. + +**What this means in practice:** +If you rename a scheduled event in your model (for example, from `SE_Current` to `SE_Old`) and then create a new scheduled event with the original name (`SE_Current`), the deployment platform will treat the new scheduled event as a continuation of the old one because the name matches. + +**As a result:** +* The new scheduled event (`SE_Current`) will inherit the enabled state of the previously deployed scheduled event that carried the same name. +* The renamed scheduled event (`SE_Old`) will be treated as a new, previously unseen event and will default to disabled. + +**Recommendation** +Be mindful of this behavior when renaming scheduled events and reusing names within the same application. If you rename a scheduled event and introduce a new one with the original name, verify the enabled/disabled states of all affected scheduled events after deployment to ensure they match your intentions. From 77c149c16c98f15e66d96798d08b4a23eaebbc47 Mon Sep 17 00:00:00 2001 From: Mark van Ments <35492184+MarkvanMents@users.noreply.github.com> Date: Thu, 2 Apr 2026 14:48:26 +0200 Subject: [PATCH 2/2] Proofread Clarified the tracking of enabled/disabled state for scheduled events by name and updated related recommendations. --- .../modeling/resources/scheduled-events.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/content/en/docs/refguide/modeling/resources/scheduled-events.md b/content/en/docs/refguide/modeling/resources/scheduled-events.md index 66dc09e17f8..c431cf525a7 100644 --- a/content/en/docs/refguide/modeling/resources/scheduled-events.md +++ b/content/en/docs/refguide/modeling/resources/scheduled-events.md @@ -23,7 +23,7 @@ Scheduled events can be tested locally, but they will not be run if your app is | Name | The name of the scheduled event. This name is recorded in the `System.ProcessedQueueTask` objects at runtime so you can identify when this scheduled event has been processed. See [Task Queues](/refguide/task-queue/) for additional information about this object.
⚠ For compatibility with legacy scheduled events, it is also stored in the `ScheduledEventInformation` objects but this is deprecated and will be removed in Mendix 11. | | Documentation | This field is for documentation purposes in the app model only. Its value is not visible to end-users and does not influence the behavior of your application. | -## Execution Properties +## Execution Properties{#execution-properties} | Property | Description | | --- | --- | @@ -209,14 +209,15 @@ This approach allows you to maintain flexibility in scheduling while keeping the ### Renaming Scheduled Events and Deployment Behavior -When a scheduled event is deployed to an environment, its enabled/disabled state is tracked by name, and not by a unique identifier. This applies to any deployment type. +When a scheduled event is deployed to an environment, its [enabled/disabled state](#execution-properties) is tracked by using the name of the scheduled event, not by a unique identifier. -**What this means in practice:** -If you rename a scheduled event in your model (for example, from `SE_Current` to `SE_Old`) and then create a new scheduled event with the original name (`SE_Current`), the deployment platform will treat the new scheduled event as a continuation of the old one because the name matches. +This means that if you rename a scheduled event in your model (for example, from `SE_Current` to `SE_Old`) and then create a new scheduled event with the original name (`SE_Current`), the deployment platform will treat the new scheduled event as if it is the old one because the name matches. + +This means that: -**As a result:** * The new scheduled event (`SE_Current`) will inherit the enabled state of the previously deployed scheduled event that carried the same name. -* The renamed scheduled event (`SE_Old`) will be treated as a new, previously unseen event and will default to disabled. +* The renamed scheduled event (`SE_Old`) will be treated as a new, previously unseen, event and will default to disabled. -**Recommendation** +{{% alert color="info" %}} Be mindful of this behavior when renaming scheduled events and reusing names within the same application. If you rename a scheduled event and introduce a new one with the original name, verify the enabled/disabled states of all affected scheduled events after deployment to ensure they match your intentions. +{{% /alert %}}