Hi,

For a true one-to-one relationship, I would not recommend maintaining two independent lookup fields unless you really need to store the reverse reference for reporting/integration purposes.

The cleaner approach is to keep a single source of truth:

License.Request Number -> Application

Then, on the Application page, display the related License through the page configuration rather than trying to populate Application.License Number automatically.

If you are using Freedom UI, the best fit is usually Multiple data sources. Add License as an additional/secondary data source on the Application page and configure the relation criteria using the existing lookup:

License.Request Number = current Application

After that, you can place the needed License fields directly on the Application page. This is the closest match for a real 1:1 UI, because the user sees License data as part of the Application page without duplicating the relationship.

Documentation:
https://academy.creatio.com/docs/8.x/no-code-customization/customization-tools/ui-and-business-logic-customization/multiple-data-sources

A Business Rule is not the right tool for this. Business rules are mainly for UI behavior, visibility, required fields, validation, etc. They do not automatically query a related child record and populate a reverse lookup.

A Business Process can do it, but only if you intentionally want to denormalize the data. In that case, you would need to handle all scenarios: License creation, changing the Application on the License, deleting/unlinking the License, and preventing more than one License per Application. Otherwise the two lookup fields can become inconsistent.

Hi Artem, 

in system settings you can turn on/off the logging for certain types of events - e.g. UseAdminSettingsLog, UseAdminEntitySchemaOperationLog...

I assume what you see is the possible Lookup Values for types of events, however if logging for them is turned off, then no records are created of this type you could see

Best, 
David

David Örnek,

thanks a lot! Does selected Default value checkbox mean that the event is included in the log, and if it isn't selected then vice versa?

Hi Artem,

The Audit log records themselves are stored in the SysOperationAudit table. The list of available audit event types is stored separately in the SysOperationType lookup/table.

This means that the values you see in the advanced filter are the available operation types from SysOperationType, but it does not necessarily mean that records for all of these types are currently being written to the audit log.

Whether a specific type of event is actually logged depends on the corresponding system setting.

Regarding the Default value checkbox in the system setting: if it is enabled, then this logging option is enabled and the corresponding event type should be included in the audit log when such an event occurs.

Hello,

Email signatures are configured individually for each mailbox and are not user-dependent by default. This means that if multiple users send emails from the same shared mailbox, the same signature will be applied regardless of which user sends the message.

At the moment, there is unfortunately no out-of-the-box functionality that allows signatures to be dynamically selected based on the user sending the email.

Regarding other ways of configuring emails. They can be sent using the "Send Email" element in a business process and dynamic case management. In such cas,e there are two possible ways regarding signatures:

• When an email is sent manually, the configured mailbox signature will be added automatically.
• When an email is sent automatically, the system sends the email template as configured, and the mailbox signature is not appended. If you would like a signature to appear in automatically sent emails, it should be included directly in the email template.

Hello,

This can be implemented using the MessageChannelService. To proceed, please import the Creatio DevKit SDK, choose the appropriate location in your code to handle subscription and unsubscription, and utilize the sdk.MessageChannelService accordingly.

Please note that this approach is supported starting from version 8.2.0 and later.

Basic subscription example:

handlers: /**SCHEMA_HANDLERS*/[
	{
		request: "crt.HandleViewModelResumeRequest",
		handler: async function (request, next) {
			const messageChannelService = new sdk.MessageChannelService();

			request.$context.MySubscription = await messageChannelService.subscribe(
				"TestSender",
				(message) => console.log(message.body)
			);

			return next?.handle(request);
		}
	},
	{
		request: "crt.HandleViewModelPauseRequest",
		handler: async function (request, next) {
			const subscription = await request.$context.MySubscription;
			subscription.unsubscribe();

			return next?.handle(request);
		}
	}
]/**SCHEMA_HANDLERS*/

Basic sending example:

handlers: /**SCHEMA_HANDLERS*/[
	{
		request: "crt.HandleViewModelInitRequest",
		handler: async (request, next) => {
			const messageChannelService = new sdk.MessageChannelService();

			const body = {
				// Some data
			};

			await messageChannelService.sendMessage(
				"TestSender",
				body,
				sdk.MessageChannelType.PTP
			);

			return next?.handle(request);
		}
	}
]/**SCHEMA_HANDLERS*/

Hi, thanks for the reply, but I believe your example is for the Web Creatio, while my question was about the mobile app :)

Hello,

Regarding the TS2304: Cannot find name 'setTimeout' error you’re encountering, there are two possible solutions:

• Install the @types/node package to include Node.js type definitions.
• Alternatively, you can use (globalThis as any).setTimeout() in place of setTimeout().

Either approach should resolve the issue.

Hi, thanks for the reply. I already had the @types/node package installed before, but the (globalThis as any).setTimeout workaround did the trick, thank you! Interestingly, it seems like the setTimeout function was added intentionally, since it doesn't exist in JavaScriptCore natively. However, I don't see clearTimeout there.

Hello Darshan Dev Prajapat,

You can use MessageChannelService instead of BroadcastChannel.

All you need to do is import the Creatio DevKit SDK, select the place to subscribe/unsubscribe (Pause/Resume or Init/Destroy events), and use the sdk.MessageChannelService. Available in version 8.2.0 and above.

Basic subscription example:

handlers: /**SCHEMA_HANDLERS*/[
	{
		request: "crt.HandleViewModelResumeRequest",
		handler: async function (request, next) {
			const messageChannelService = new sdk.MessageChannelService();

			request.$context.MySubscription = await messageChannelService.subscribe(
				"TestSender",
				(message) => console.log(message.body)
			);

			return next?.handle(request);
		}
	},
	{
		request: "crt.HandleViewModelPauseRequest",
		handler: async function (request, next) {
			const subscription = await request.$context.MySubscription;
			subscription.unsubscribe();

			return next?.handle(request);
		}
	}
]/**SCHEMA_HANDLERS*/

Basic sending example:

handlers: /**SCHEMA_HANDLERS*/[
	{
		request: "crt.HandleViewModelInitRequest",
		handler: async (request, next) => {
			const messageChannelService = new sdk.MessageChannelService();

			const body = {
				// Some data
			};

			await messageChannelService.sendMessage(
				"TestSender",
				body,
				sdk.MessageChannelType.PTP
			);

			return next?.handle(request);
		}
	}
]/**SCHEMA_HANDLERS*/

You can use the following channel types:

• MessageChannelType.PTP: The message will be sent to the same user who sent that message (client-side).
• MessageChannelType.BROADCAST: The message will be sent to all users (client-side).
• MessageChannelType.SERVER: The message will be sent to the server. In this case, only the server-side subscription will receive this message.

Eduard Dovydovskyi,

Hello Eduard Dovydovskyi,

Thanks for the suggestion! I tried MessageChannelService with crt.HandleViewModelResumeRequest/crt.HandleViewModelPauseRequest as shown, but I'm hitting the same root issue I had before switching to it: crt.HandleViewModelResumeRequest only fires on the very first time the sidebar opens, not on subsequent opens.

In my testing, the sidebar's view model is created once and never destroyed — closing the sidebar just hides it, it doesn't tear down/recreate the page instance. So Resume/Pause don't actually fire again on reopen, the way they would for normal page navigation. I confirmed this independently with console logs on Init/Resume/Pause/Destroy before trying MessageChannelService — only Init and Resume fired once each, on the first open, and nothing fired again on close/reopen.

Since MessageChannelService.subscribe is set up inside Resume in your example, the subscription itself is also only ever created once — which actually works fine for receiving subsequent messages (since the subscription stays alive), but doesn't help if the goal is to refresh/re-trigger something specifically tied to the reopen event itself.

Is this a known difference in sidebar lifecycle vs. regular page lifecycle? Is there a Resume/Pause-equivalent that's specific to the sidebar's open/close state rather than the view model's attach state? Or is the expectation that we just send a new message each time (via PTP) to a subscription that was set up once on first init/resume, rather than relying on the subscribe step itself re-firing?

For context, my actual use case: I need to pass different data into the sidebar's fields every time it's reopened with a different source record. Right now I'm sending the message right after crt.OpenSidebarRequest resolves and the sidebar's subscription (set up once on first load) picks it up fine — so the data delivery itself works. The only remaining friction is the very first open, since the subscription isn't registered yet at the moment the first message is sent (timing race). Would love to know if there's a "ready" signal or queuing behavior built into MessageChannelService for that case, or if I should keep handling it manually with a short retry/handshake.

Thanks

Hello,

You can enforce this entirely on the client side in Freedom UI. The two most reliable approaches are a save handler (crt.SaveRecordRequest) and a custom validator (inline error message as the user fills the form). You can use either of these

Example - Save handler (blocks the save)

handlers: /**SCHEMA_HANDLERS*/[
    {
        request: "crt.SaveRecordRequest",
        handler: async (request, next) => {
            const owner = await request.$context.Owner;
            const individuals = await request.$context.Individuals;

            if (owner && individuals && owner.value === individuals.value) {
                request.$context.executeRequest({
                    type: "crt.ShowDialogRequest",
                    $context: request.$context,
                    dialogConfig: {
                        data: {
                            message: "Owner and Individuals cannot be the same contact.",
                            actions: [
                                { key: "ok", config: { color: "primary", caption: "OK" } }
                            ]
                        }
                    }
                });
                return; // stops the save
            }
            return next?.handle(request);
        }
    }
]/**SCHEMA_HANDLERS*/

Custom Validator: Define a custom validator on either field in the ViewModelConfig, then trigger it via the attribute change request whenever either field's value changes.

• Using both is a common pattern: validator for live feedback, save handler as a safety net.

Hello,

As mentioned above, this functionality can be achieved by implementing custom logic within the crt.SaveRecordRequest handler, which allows you to prevent the data from being saved when necessary conditions are not met.

Alternatively, you may consider implementing a custom validator.
 

For your reference, the following articles may be helpful:

"handlers" schema section | Creatio Academy
Implement the validation of a field value on a page | Creatio Academy

Good day, Tanu,

The "Queued" status is not an outright sign of issues with delivery to the participant. 

Creatio sends emails to the addressee throught the ESP, but waits for an email response before changing the status.

The Queued status may mean one of the following:

- the delivery was completed, but the reply has not been returned by the provider

- the email was queued for delivery, but until it has been Delivered or "Bounced", it remains "Waiting to retry" on the ESP side. 
Seeing as "Waiting to retry" has no corresponding status on Creatio end, the recipient remains Queued.
Email Service Providers may retry delivery for up to 48 hours (ElasticEmail) and up to 72 hours (SendGrid).

- Longer periods of being Queued may point to complications with delivery or responses not being sent out by ESP.

Should you require a more in-depth analysis of Queued status, please contact us at support@creatio.com with an Id of the BulkEmail in question. 
It is best to do so no later than 7 days after the initial delivery, as this will allow us to examine the logs before they are overwritten.

Hope this helps!

How can we resolve this?