In a newly published version, it would be helpful to highlight the changes made within a trigger (e.g., by color-coding newly added conditions, modified parameters, or greying out deleted conditions). This would allow users to quickly grasp the adjustments without having to compare the old and new versions, making the approval process more efficient.
Hey @dmatzke !
Thanks so much for the suggestion—this is a great idea. While it’s not exactly a new concept for us, it’s something we’ve been considering since the very beginning of the “compare app versions” feature.
I could totally see this making the approval process much more efficient. I’m curious about a few details to make sure we’d be hitting the mark:
-
Referenced Assets: Would you want this to also surface places where a referenced asset changed? For example, a trigger might look identical, but it’s referencing a connector function whose definition changed, leading to the app logic operating differently.
-
Change Priority: What types of changes do you care most about seeing—edits, deletes, or creates?.
-
Current Workflow: How are you managing this gap today?.
We’re always looking for ways to make these comparisons easier to digest, so your input here is invaluable.
Best,
Pete
Hi Pete,
Thank you very much for the quick response!
Below are a few brief comments on your questions:
Current workflow:
In fact, we manually compare the triggers of the new version with those of the old version to identify changes. This is both very time-consuming and prone to errors, as it’s easy to overlook something.
Change priority:
To achieve a comprehensive solution, there would need to be a practical approach for all three cases (deletion, creation, modification). However, the greatest value clearly lies in modifications, as it is very difficult to detect when, for example, a condition references a different variable after a change.
Referenced assets:
This is an interesting idea in principle, although I imagine it would be difficult to implement. Let’s take a simple example from our side: we now have over 1,000 work instructions that all use the same connector. If there is a change to the connector, this would be shown in every instruction—but only if the instruction itself is versioned accordingly. There could therefore be a significant time gap between the connector change and the instruction update, which makes it difficult to track changes later on. It would actually make more sense to have the option to version a connector and, before publishing the change, show in which instructions or apps this connector is used. This would also provide the opportunity to check whether the connector changes remain compatible with the existing logic int the apps.
I hope my comments provide some useful input.
Kind regards
Daniel