We've started to deploy several Product Solutions from Skyline (TAG, TxEdge etc.) and I'm making changes to the Low-Code Apps. The changes are nearly always adding new pages or additional automation actions rather than editing the deployed GQIs or features but I'm aware that should Skyline update the app I will have to re-merge our bespoke features in some way.
I'm wondering now if I should be creating 2 Apps, keeping ours and Skyline's separate (which wouldn't be ideal as we'd prefer to keep everything in 1 place) or if there's going to be a way in the future of deploying an app while keeping our changes untouched. I feel like that's probably unlikely and a rebuild of some kind would be needed each time. Of course we also have no idea how often they'll be updated by Skyline etc.
Has anyone any thoughts on situations like this? I'm trying to keep from going too far in one direction that could cause a lot of rework in the future.
Thanks
Hi Ross,
This is a very valid concern, and it's actually one of the reasons why we'd love to hear about the customizations you're making.
If you find yourself regularly adding pages, actions, or workflows to one of our solutions, it's worth reaching out to us. Understanding what's missing helps us identify gaps in the product and determine whether those additions could be valuable for other customers as well. In some cases, what starts as a local customization can evolve into a supported feature of the solution.
Looking ahead, we're actively evolving the architecture of our Product Solutions with exactly this challenge in mind. Our direction is to provide a stable and robust backend layer while making it easier to build thin, customer-specific frontends on top. This allows different teams and organizations to tailor the user experience to their own needs while continuing to benefit from the same underlying data model and business logic. It also reduces the impact of future solution updates on customer-specific UI customizations.
For the time being, if the changes are generic and could benefit others, I would strongly recommend discussing them with Skyline first. If they are highly specific to your organization, it is still possible to implement them, but I would recommend carefully documenting those changes and planning to reapply or validate them during future upgrades.
One thing I would be cautious about is building dependencies on internal implementation details, such as reverse engineering solution scripts or ad hoc data sources that are not part of the supported extension model. Those internals may evolve between releases, which can make upgrades significantly more difficult.
So in short: share feedback with us whenever possible, keep customizations well documented, and know that we're actively working towards an architecture that better separates customer-specific experiences from the core solution logic.
Kind Regards,
Jarno
Hope you're fine, Ross
Subscribing to see what's the recommended approach — perhaps exploring an Application Package (https://docs.dataminer.services/develop/TOOLS/ApplicationPackages/CreatingApplicationPackages.html) might cover this use case and make future updates easier to manage – haven't used this yet, at the bottom there is a link to the LCA editor:
https://github.com/SkylineCommunications/Low-Code-App-Editor
HTH