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.
Thanks for reaching out. To confirm whether a case's lifecycle stage has actually changed, you can check a few places:
The case page itself - open the case and look at the progress bar at the top. The highlighted stage shows the case's current status.
The case's history - on the case page, there's a history/timeline section that logs each stage change along with the date and time it happened, so you can see the full sequence of transitions.
The case's activity feed – status and stage changes are also posted as system messages here, which gives you another way to cross-check the timeline.
If you're checking something more specific, could you share a bit more detail about what you mean by "replaced" (for example, a particular stage, a notification you expected, or something else)? That'll help point you to the right place.
For a closer look, please reach out to support@creatio.com with a full description of the issue, including the case record in question and any screenshots you have. Our support team can dig into it directly.
You can retrieve the Case Lifecycle and then build a condition based on it within the business process. Here is how:
First, read the case whose lifecycle you need to evaluate. Then add a Read data element on the "Case Lifecycle" object to retrieve the relevant records - either all of them by selecting "Read a collection of records", or a specific one (for example, the latest) by selecting "Read the first record in the selection":
Once the lifecycle records are retrieved, add an Exclusive gateway (OR) and configure its conditional flows to evaluate the data you need (for example, the case status). This lets the process follow one branch if the condition is met and another if it is not.
Let me know if this answers your question, or clarify what you meant by "replaced" case lifecycle.
