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.

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