Idea Summary
CleWhen you merge a working copy into its main application, Diff and Merge lists every automation and REST Data Source synchronization as "Changed" if its enabled or disabled state is different. Their definitions don't have to change at all.
In practice that difference is almost always there. Importing an application disables all of its scheduled automations and REST syncs. A working copy also shares a parsing schema with main, so it has to keep those jobs disabled, or every job runs twice against the same data.
The result is a lot of noise on every merge. In our app, a two-page change showed 46 changed components: 2 pages, 25 automations, and 19 REST Data Sources. None of those automations or REST sources had been edited.
The noise is also risky. If a developer ticks one of those rows, the merge copies the disabled state into main and quietly switches off a production job. Nothing on the merge screen warns that this is going to happen.
Use Case
Teams that develop in working copies and merge into a live main application, particularly when both use the same schema. That's the normal working-copy setup, and it's exactly the case where these jobs have to stay disabled in the working copy.
Preferred Solution (Optional)
Any of these would fix it, and the first is the most important:
- Leave out the enabled/disabled state when deciding whether an automation or REST sync has changed, so a component only shows as "Changed" when its definition changed.
- When a merge does include one of these components, keep the target application's enabled state and don't copy it from the working copy.
- If the state is shown at all, show it separately from definition changes and warn before a merge would disable a job in the target application.