Hi Harvey,

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.

Prabhath Surya,

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.

Hi Manal,

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.

 

Hi Mohamed,

Thank you for the detailed description and the logs.

The blocking issue is a duplicate column in the inheritance chain. UsrEntity_Agent is a child object that inherits from Contact, and the columns UsrIDExpiryDate, UsrIDIssuanceDate, and UsrAgentNationalID are defined both on the parent and directly on UsrEntity_Agent. This is exactly what the validation message reports:

Property conflict in 'UsrEntity_Agent': property 'UsrIDExpiryDate' already exists.

This conflict is what stops source code generation. A duplicate property definition like this can happen because:

- the same column exists on both the parent object and the child object in the inheritance chain,
- a back-reference property generated from a lookup collides with an existing column,
- two different packages define the same column in different layers.

To resolve it, remove or rename the duplicated columns so that each is defined only once in the chain. Then run Generate source code for all schemas, followed by Compile All.

Hi Andrii

Thank you for your effort and for the detailed explanation of the root cause behind the compilation error. Your clarification helped us understand why the source code generation is failing.

At the moment, I am unable to edit or rename these columns from the Creatio configuration. Could you please provide the recommended steps to resolve this issue? Specifically, I would appreciate guidance on how to rename or remove the duplicated columns in the inheritance chain.

If there is a recommended approach or any additional tools or configurations required to perform this safely, please let me know.

Hello.

To resolve this issue, you will need to navigate to the Configuration section and locate the specific replacing object where the duplicated column was originally added. Within an inheritance chain, a column can typically only be renamed or removed directly at the level where it was originally introduced, rather than from a parent or a different replacing object further down the chain. 

Once you have located the correct replacing object, please check whether the package containing it is currently locked. If it is locked, you will need to unlock it for a hotfix before you are able to make any changes. This is a standard safeguard within Creatio to prevent unintended modifications to packages that are not meant to be actively edited.

After unlocking the package, you can proceed to rename or remove the duplicated column directly on that object. Once the change has been made, we would also recommend regenerating the source code for the affected schemas and recompiling the application, to ensure that the change is properly reflected throughout the entire inheritance chain and that the compilation error no longer occurs.

Best regards,
Antonii.

Dear Antonii,

Thank you for your guidance.

I followed the recommended steps and unlocked the package for a hotfix. After that, I renamed the duplicated columns as follows:

• UsrIDExpiryDate → UsrIDExpiryDate2
• UsrIDIssuanceDate → UsrIDIssuanceDate2
• UsrAgentNationalID → UsrAgentNationalID2

After applying these changes, I regenerated the source code for the schemas, and the generation completed successfully.

However, when I ran Compile All Packages, I encountered a new set of compilation errors related to the Change object. The errors indicate circular base type dependencies and generic type constraint issues. The reported errors are:

ChangeSchema.Change.cs
- Circular base type dependency involving 'Change' and 'Change_Change_Creatio' (CS0146)
- Circular base type dependency involving 'ChangeSchema' and 'Change_Change_CreatioSchema' (CS0146)
- The type 'TEntity' cannot be used as type parameter 'TEntity' in 'BaseEntity_LocalMessageEventsProcess<TEntity>' (CS0311)

ChangeSchema.Custom.cs
- Circular base type dependency involving 'Change_Change_Creatio' and 'Change_Custom_Customer' (CS0146)
- Circular base type dependency involving 'Change_Change_CreatioSchema' and 'Change_Custom_CustomerSchema' (CS0146)
- The type 'TEntity' cannot be used as type parameter 'TEntity' in 'Change_ChangeEventsProcess<TEntity>' (CS0311)

ChangeSchema.Release.cs
- The type 'TEntity' cannot be used as type parameter 'TEntity' in 'Change_CustomEventsProcess<TEntity>' (CS0311)
- Circular base type dependency involving 'Change_Custom_Customer' and 'Change' (CS0146)
- Circular base type dependency involving 'Change_Custom_CustomerSchema' and 'ChangeSchema' (CS0146)

It appears that the original duplicate column issue has been resolved, but another issue related to the inheritance hierarchy of the Change object is now preventing the compilation from completing.

Could you please advise on the next steps to resolve these new compilation errors?

Thank you for your support.

Antonii Viazovskyi,

Antonii Viazovskyi,

Hello!

Please go through the following steps:

1. Verify submissions are being created — check whether submission records exist at all. Go to the Submissions section and filter by recent dates. If no records appear, the issue is with the form-to-submission pipeline (form configuration, hidden fields, or required field validation).
2. Check UTM-to-Campaign matching — for submissions to appear under a specific Ad Campaign, the system must match UTM values to the campaign record. The utm_campaign value passed in the URL must exactly match either the Campaign Name or Campaign ID configured in the Digital Ads application. Any mismatch (even a space or capitalization difference) will prevent linking.
3. Confirm Lead Sources and Lead Channels lookups — the system uses lookup tables to resolve UTM values. The Lead channels lookup must contain a record with a Channel code matching your utm_medium value (e.g., cpc, paid). The Lead sources lookup must contain a record with a Source code matching your utm_source value (e.g., facebook, google). If these aren't configured, source attribution won't work.
4. Check the business process — verify that the "Populating Contact with Submitted Form's Data" business process is active. Go to System Designer → Process log and check for any errors related to this process.

Could you please confirm: are submission records being created at all (even without campaign attribution)? 
What exact utm_campaign value is being passed in the URL? What is the corresponding Campaign Name/ID in the Digital Ads application?

The submissions are being created. The ad campaign is listed as "Devoted to Educators" in Creatio:

Alona Dolya,

Thanks for your help. I posted in a separate post the answer to your questions. 

Matt 

Hello,

The Actual Response Time field is populated automatically the first time the case status changes. For example, this occurs when the case status is changed to "In Progress." This field is read-only and cannot be edited manually.

The calculation of the Actual Response Time field on the Case object is performed by the SLM package within the embedded process.

Please see the attached screenshot for reference.

The only way to change this behavior is through additional custom development. Unfortunately, we do not have an example of such an implementation. However, we have registered a request with the responsible R&D team to review the possibility of providing an OOTB option to customize this logic in a future implementation.


Best regards,
Malika

 

Hi Malika,

thanks for the reply,

I cannot see the screen shot for some reason, can you resend it so that I can at least get a clue on a possible implementation alternative?
 

Cheers
Luis

Luis Tinoco Azevedo,

Hello 

I am re-attaching screenshot below: 

Thanks, 

for some reason me and the rest of the people here in the office still don't see it.

But I guess the question is if it possible to disable the automatic calculation of the actual response time on status change

so that it can be calculated via a custom process?
Thanks