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,

In this scenario, the recipient information should be taken from the related email message records rather than only from the Activity record itself. The Activity with type “Email” can be used to identify the email, but to build a proper “reply all” scenario, the process would need to read the corresponding Email Message object data, including the sender, To, and CC recipients, and then determine the required recipient list for the outgoing message.

However, sending an email directly as a reply into the same existing email thread, so that it behaves exactly like a normal threaded email with the full conversation history and mail headers preserved, is not supported by out-of-the-box business process tools.

Using the standard “Send email” process element, it is possible to send a new email and, if needed, manually include the previous email content in the body/template. However, this does not create a true technical reply in the original email thread in the same way as replying from an email client would.

To achieve the expected behavior, additional development would be required in the business process, for example by using a Script task or a custom process element. The custom logic would need to read the original Email Message, prepare the outgoing message, populate the required recipients, include the previous email body if needed, and set the necessary email/threading parameters so that the message is processed as a reply rather than as a completely new email.

Therefore, the requirement is achievable, but not only by standard no-code business process configuration. It requires custom development.

Hello,

The recommended approach to obtain the business process instance ID is to create a script task, as you mentioned, and retrieve the value directly from the context.

At present, there is no alternative recommended solution for this requirement.