Skip to content

Update scheduled-events.md #10963

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
NielsKunst wants to merge 2 commits into
base: development
Choose a base branch
from
+16 −1
Open

Update scheduled-events.md #10963

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
614c786
Update scheduled-events.md
NielsKunst Apr 1, 2026
77c149c
Proofread
MarkvanMents Apr 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 16 additions & 1 deletion content/en/docs/refguide/modeling/resources/scheduled-events.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.<br/>⚠ 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 |
| --- | --- |
Expand Down Expand Up @@ -206,3 +206,18 @@ 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](#execution-properties) is tracked by using the name of the scheduled event, not by a unique identifier.

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:

* 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.

{{% 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.
Copy link
Copy Markdown
Collaborator

@MarkvanMents MarkvanMents Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really a good recommendation. It's a bit generic.
Surely it is better to say not to rename scheduled events but to create new ones?

{{% /alert %}}