Probably the only way to do that currently is with some CSS. The following CSS will work for that on the contact page: 

crt-communication-options#ContactCommunicationOptions a {
    pointer-events: none !important;
    cursor: initial !important;
    color: initial !important;
    text-decoration: none !important;
}

Ryan

Thanks, @Ryan Farley, for the quick suggestion. However, clicking the phone icon is still triggering the browser’s default application to open.

Hello,

At the moment, there is no OOTB functionality for automatic retention or cleanup policy for the Change Log in Creatio.

By default, the change log is expected to be periodically cleared manually. To do so, use the instructions from the following article:
https://academy.creatio.com/docs/8.x/setup-and-administration/administr…

However, we have registered this idea and forwarded it to our R&D team for further review and implementation in future releases.

Have a great day!

Both are equivalent. When checking if a lookup (in your case Contact is a lookup on System Administration Object) is equal to some Id, Creatio will be checking the lookup's Id against that parameter. So both are equivalent, so I guess Creatio simplifies it when saving.

Hello,

This behavior is expected. At this level of the BPM, Contact and Contact.Id are effectively the same. The system automatically resolves the primary key (Id) for the Contact object, so explicitly specifying .Id is not required.

When the process is saved, the designer simplifies the reference and displays it as Contact, since the identifier is implicitly assumed. Functionally, there is no difference in execution or behavior between selecting Contact.Id and Contact in this context.

So the disappearance of .Id after saving does not indicate an issue and does not affect how the process works.

Hello.

To obtain the Creatio installation files for local deployment, please contact the support team directly at support@creatio.com.

Instructions on how to deploy the local instance are available here:
https://academy.creatio.com/docs/8.x/setup-and-administration/category/on-site-deployment

Best regards,
Antonii

Hello,

In this scenario, the most effective approach is to separate permission management by role type. For roles like Y, where all users should have access to records without additional conditions, standard object-level record permissions can be used without any changes.

For role X, where access must be limited to specific users within the same role based on certain conditions, permissions should be managed exclusively through a business process. The process can be triggered on record creation (and, if required, on record update) and grant access only to the users who meet the defined criteria.

To avoid unintended access, the X role should not be included in the object-level record permissions. This is important because object-level permissions are recalculated whenever role settings change, which is what currently causes all existing records to become visible to all users in role X. When access is granted through a business process, it is not revoked during permission recalculation, and users retain only the access explicitly assigned by the process.

With this approach, adding or modifying roles no longer requires re-running processes for all existing records. Access remains controlled and consistent, and only the intended users within role X will have permissions to the relevant records.

Hello.

I recommend checking the following points:

– Verify whether the application was deployed in accordance with the official deployment instructions and whether all required settings were configured correctly:
https://academy.creatio.com/docs/8.x/setup-and-administration/category/on-site-deployment

– After that, open the browser’s developer tools, reproduce the issue, and review the Console and Network tabs for any errors. This should help identify where the problem occurs.

– Additionally, review the application logs and analyze any recorded errors. Information about log storage locations is available in the following article:
https://academy.creatio.com/docs/8.x/dev/development-on-creatio-platform/development-tools/logging/nlog

By default, logs are stored in C:\Windows\Temp\Creatio for applications deployed on Windows, or in the Creatio application directory when deployed on Linux.

Best regards,
Antonii.

Hello,

The standard Autonumber field in Creatio is limited to a static prefix combined with a sequential counter and does not support dynamic components such as the current date. For this reason, the required format cannot be achieved using the basic autonumber settings alone.

To implement such a format, a custom mechanism is required. This is usually done by generating the value at record creation time using a business process or custom logic that determines the current date, maintains a sequential counter, and assembles the final value before saving it to the field.

Alternatively, the same result can be achieved by implementing autonumbering in the same way it is done for out-of-the-box sections such as invoices, cases, or contracts. In these sections, numbering is generated using an autonumber mask handled by platform logic rather than a simple object field setting. Replicating this approach for a custom object also requires development effort, but it allows full control over the number format and behavior, including dynamic elements.