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?

Hello,

We reviewed the described behavior and found that the value is most likely being converted to a Date type at some point in the process. When this occurs, the time portion is removed, and the value is saved as 12:00 AM (midnight).

To preserve both the date and time, we recommend using a DateTime expression and adding the required number of days with the AddDays method instead of using date-only arithmetic.

Please try the following expression: [#Registration date#].AddDays(Convert.ToDouble([#SLA days#]))

This approach adds the SLA days to the original DateTime value while preserving the time component.

Hi Satyam,

Yes, this can be achieved, but you need to handle both actions in one custom flow.

The recommended approach would be:

1. Generate the printable report using a business process or custom backend service.
2. Save/attach the generated report to the record’s attachment object, for example ContactFile, AccountFile, or the relevant {Object}File schema.
3. After the file is created and you have the generated file record Id, trigger the browser download using FileService/Download/{EntityFileSchemaName}/{fileId}.

For uploading/attaching a file manually, Creatio provides POST /FileApiService/UploadFile, where you need to pass parameters such as entitySchemaName, parentColumnName, and parentColumnValue.

So the key point is: do not only call the download service directly. First generate/save the report as a file attachment, then use the generated file Id to download it for the user.

If this needs to happen from a Freedom UI button, the button can call a custom service or process, wait for the generated attachment file Id, and then open the download URL in the browser.

smit suthar,

Hi,

Thank you for the detailed explanation.

I understand the overall approach, but I'm still a bit unclear on some of the implementation details in Creatio.

Would it be possible for you to elaborate on the following points:

1. In the case of a Freedom UI button, what would be the recommended way to wait for the file creation and then trigger the download automatically?
2. If possible, could you provide a simple end-to-end example (Business Process or Freedom UI implementation) demonstrating the complete flow?

A more detailed example would help me understand how these pieces fit together in practice.

Thank you for your help.

Hello,
Could you please provide the steps to reproduce the configuration of this filter? Additionally, could you specify which API you are using and how you received the following message:
Discarded: it is not a unlimited field... NcsJsonField?
Thank you in advance.

Hi Grant

You’re hitting this because a Creatio remote module is not a fully standalone Angular app.

`npm start` tries to bootstrap modules that are normally provided by Creatio runtime (including `sdk_remote_module_package`), so outside Creatio you get:

`Remote entry with name 'sdk_remote_module_package' does not exist`.

Short answer:

• Can you run it fully local without Creatio? Usually no (not in a practical way for real component behavior).
• The component depends on Creatio runtime (`crt`, designer context, requests, etc.).

Fast development workflow
1. Run Angular build in watch mode:
  `npm run build -- --watch`
2. Auto-copy `dist/...` to your package `Files/src/js/<YourRemoteModule>`
3. Compile only your package (not full configuration):
  `clio compile-package <YourPackage> -e <YourEnv>`
4. Hard refresh Designer (`Ctrl+F5`)

This is the fastest stable loop today for remote module development.
 

Regards,

Julio Falcón

NCS.JulioFalcon,

Thank you :)

Hello,
In order to call your service inside the mobile handler, you need to use tools like XMLHttpRequest . With it, you can call any http link, including any service you need. It can also be used to get the system setting value if you configure a specific service that will return it.
As for logs inside the handler, I don't know if Logger.console is dependent on OS, but it definitely works on Android. Perhaps you are just searching the logs in the wrong place?
 

Hi, thanks for the reply.
Inside the handler I'm using the fetch API. Generally, making requests works - I can query the Creatio instance and the requests are visible in Request.log. The problem is that they are unauthenticated. No cookies are sent with the request, so the server has no way to identify the specific user. From within the handler itself, I was also unable to read any information about the current user. I tried hardcoding authentication as Supervisor, but it seems like the Cookie header is being ignored and I keep getting a 302 redirect to the login form.

Hello,

Our academy has excellent relevant articles on these topics. 
Leaving you the links for your convenience
Dashboards basics | Creatio Academy
Customize Word reports | Creatio Academy

Have a nice day!

Hello,

At the moment, deployment of the Creatio application within a Kubernetes cluster is being reviewed by our R&D team.

Currently, official documentation for this deployment scenario is still in progress, and there is no confirmed timeline available for its publication yet.

Once additional information becomes available, we will be happy to share updates with you.