Hi; We start testing incoming mail synchronization to manage in Creatio communication from customer. We use Exchange listener put on Kubernetes to get mails from designated mailbox. From time to time exchangelistener restarted and lose connection with mailbox and we have to synchronize it again manually Is there any mechanism to check if connection is established and if not recreate it?
Thank you for reaching out regarding the Exchange Listener connection issue.
Currently, we do not have a ready-made monitoring tool that automatically detects a lost connection and recreates it for the Email Listener. However, there is a general mail diagnostics page available in your environment that you can use to check the connection status manually:
You can use this page to verify whether the listener is currently connected to the mailbox, which should help reduce the need for manual troubleshooting each time.
That said, we understand that an automatic health-check and reconnect mechanism would be valuable, especially since the listener running on Kubernetes can lose its connection unexpectedly. We will log this as a feature request/idea for our development team to consider for a future improvement.
Putting together Landing Pages. I am trying to make the landing page have an empty drop down when the person first goes to the page. The designer I see on my end is pictured below. Despite it being required, users can also select "select a value." I deleted the NULL value and that did not work.
Why can't some schema types be exported individually from packages like you can with source code and client code schemas? E.g. data bindings can't be individually exported from a package to apply them quickly to other environments, and instead you either need to export the entire package/app that include them, or use some workaround like creating a new temporary package, moving the data binding into it, and then exporting that. It would make life simpler if these schemas could all be exported and imported individually for things like applying hotfixes and synchronising environments. The schemas wouldn't even need to be automatically installed, just added to the package with the status symbol to indicate that the data/SQL script etc needed to be installed.
Data binding schemas are not self-contained like source code/client module schemas, they're pointers to specific DB rows plus their relational dependencies, so a lone export risks missing foreign keys or breaking install order. Full package export sidesteps that by keeping the whole dependency graph intact.
That's true of C# code schemas and client schemas too, which can refer to other C# code and objects, and something which Creatio as a platform is already capable of handling and informing the user of any issues about once the schema is imported, plus with database referential integrity protections in place as a backstop. This doesn't seem like a real issue, certainly not one to reduce the functionality that is useful for developers.
The distinction you have noticed comes down to how these schema types are structured internally.
Source code schemas and Freedom UI, client schemas, are stored as discrete metadata objects. Each one has its own unique identifier, its own file within the package structure, and its own entry in the version control log. This one-to-one structure is what allows the platform to export and import them individually.
Data bindings and SQL scripts do not share this same structure. Data content is stored as rows across various application tables, such as lookups, system settings, and translations, linked to a package only through tagging tables, and often dependent on related records in other tables through master-detail relationships or foreign keys. SQL scripts, in turn, are stored as an ordered batch, with installation status tracked at the package level rather than per individual script. Neither of these has a native, single-object identity in the way source code and client schemas do, so the platform has no built-in mechanism to export just one data binding or script while guaranteeing that its dependencies are included alongside it.
This is why the current workaround, moving the specific item into a temporary package and exporting that package instead, is effectively the only way to give it the package-level identity required for individual export.
Thanks Antonii, but if that's the case, how come when working in file system mode, the Data and SqlScripts directories can be so self-contained? And why couldn't they be treated as similarly self-contained for the purpose of exporting & reimporting? Potentially with warning messages if there are unmet dependencies for SQL Scripts.
It seems like Data schemas (which are just a copy of the actual data in the database to be used for transferring to other environments) should be the simplest to be able to export & import, since the database can handle much of the referential integrity issues of related data trying to be installed when the referred record(s) do not exist already being done by the database and reported by the config section in Creatio.
Anyway, I guess it sounds like things aren't going to change, and so we're left in a situation where we either need to copy data between environments using SQL directly against the database or use the workaround, potentially having to create new packages directly in Prod for the purposes of moving some data back down into lower envs; neither of which is appealing.
