DEV Community: Toni Petov

Interop.io & io.Connect Glossary

Toni Petov — Thu, 04 Dec 2025 15:19:39 +0000

If you are new to io.Connect and the interop.io ecosystem you may wonder what some of the acronyms and nicknames you see are. I tried to put together a glossary to help:

Acronyms & shorthand

IOCD - shorthand for io.Connect Desktop.
IOCB - shorthand for io.Connect Browser.
ENV‑REG - The “environment‑region” folder name in user paths (e.g., UserData/DEMO-INTEROP.IO). You’ll see it in examples like .../UserData/<ENV>-<REG>/apps.
BBG - Bloomberg adapter namespace (e.g., T42.BBG.*); shows up in method names if you use the Bloomberg integration.
FDC3 - an open interoperability standard for financial services , building apps for the trading/analysis desktop. It’s created and governed in FINOS and promoted across the industry as a common way for apps to discover each other
GD - Legacy shorthand for Glue Desktop / Glue42 Desktop (today: io.Connect Desktop ). Can still appear in method namespaces (T42.GD.*), query params (?gd), or some repo names. Glue42 was the previous name of the product that evolved into io.Connect Desktop after the merge with Finsemble , that formed interop.io in 2023.
T42 - Legacy namespace/prefix you can see in method names, logs, etc. It comes from the name Tick42 (the company behind Glue42 ) that merged with Finsemble.
FSBL (Finsemble) - The other company that merged into interop.io. Finsemble was (and is) also the name of the company’s desktop interop platform.

Platform building blocks

Interop‑enable an app - To “interop-enable” an app means wiring it to io.Connect so that the latter can launch/manage it and the app can talk to others. Give it the client library (auto-inject via system.json → windows.autoInjectAPI or import) and initialize to get the io object. This enables apps to discover each other, share context, and hand off tasks without brittle one-offs or copy/paste, so workflows move smoothly across windows.
App Stores - Where app definitions come from. Can be local folders, REST, or io.Manager. IOCD loads all defined stores on startup.
io.Connect Gateway - The message bus that carries inter‑app and app↔platform messages (WebSockets by default).
App Definition - A JSON file that describes an app (name, type like window/exe/node, URL or path, sizing, etc.). Place it under the user apps folder to make the app launchable from IOCD.
Launchpad / Launcher - The built‑in UI navigation sidebar that lists apps and lets users start them.
Application Adapters - Prebuilt integrations (Excel, Outlook, Bloomberg, Salesforce, etc.) that expose those apps’ actions to your interop‑enabled apps.
IODesktop() - The JavaScript factory function you call to initialize the io.Connect API inside an app. Returns the io object.
Polyfill (Finsemble) - a compatibility layer in the Finsemble Seed that lets Finsemble projects run on io.Connect Desktop (IOCD)

If there’s anything I’ve missed, please post below so we can add it.

1 post - 1 participant

Read full topic

How to Build Interop That People Actually Use

Toni Petov — Wed, 26 Nov 2025 00:37:55 +0000

In Part 1, I covered the planning work that prevents disasters before you write a single line of code: identifying the right workflows, understanding integration complexity, and establishing governance. Now let’s talk about execution - how to actually build interop that scales and gets adopted.

Because once you move from planning to building, the stakes change completely, and this is where technical decisions compound. It’s not just whether your integrations work, but whether they’re maintainable, whether users trust them, and whether the architecture you choose today becomes technical debt tomorrow.

Keep Architecture Simple

Architecture is inherently complex. We’re solving problems across systems that were never meant to talk to each other. But sometimes, it’s not just complex, it’s complicated. And there’s a difference.

The extra complication usually comes from things we inherit like legacy systems, rushed timelines, or designs that worked in one context but don’t scale. You might build something that works perfectly for one business unit, then replicate it everywhere without thinking holistically. So again, you end up with a patchwork of siloed mini-projects that don’t play well together.

The Micro Frontend Trap

Take micro frontends as an example. They can be powerful when used wisely. But too often, teams slice their UI into dozens of tiny apps, each with its own state, services, and dependencies. Or worse, they overload the UI layer, using it as a caching layer or even a mini backend.

At first, it feels productive. Things ship faster. Components are reusable. Everything’s “decoupled.”

Fast-forward six months or a year and you’ve got ten teams coordinating versioning, dependency conflicts, inconsistent user experiences, and performance issues.

That’s when complexity stops being useful and starts being a liability.

Start Simple, Expand with Confidence

Here’s the rule for interop-heavy environments: start with the cleanest, most minimal architecture that meets requirements. Fewer moving parts mean fewer places for things to break. It’s always easier to add complexity later when you have a real reason than to untangle a mess after everything’s in production.

Build iteratively:

Phase 1: Get the basics working. Two apps sharing context. One workflow functioning end-to-end.

Phase 2: Users try it. What works? What doesn’t? Refine based on feedback.

Phase 3: Add more applications and workflows systematically. Each addition builds on lessons learned.

Phase 4: Now you have real usage data. Optimize where it actually matters.

This reduces risk and provides feedback early enough to make meaningful changes.

Design for Humans, Not Just Systems

You can have flawless architecture, perfect data flows, and APIs that communicate beautifully. Five applications syncing context behind the scenes, messages flowing, events firing exactly as designed.

And users may still use it the wrong way and even cause support burden.

Why? Because technical integration is not the same thing as usability.

What Users Need

Visibility: Users need to see what’s happening. When context is shared, show it. When data is syncing, indicate it. When an action triggers multiple apps, make it clear what’s connected.

This doesn’t mean cluttering the interface. It means providing appropriate feedback at the right moments like visual indicators when apps are linked, brief confirmations when context is shared, clear status when something is loading.

Control: Nothing kills adoption faster than a system that feels like it’s driving itself. Give users the ability to see what apps are connected, disconnect when needed, trigger actions manually when automatic isn’t right, and undo when things go wrong.

Clarity: Design interactions that make sense in the user’s mental model, not the system’s technical model.

Bad: “App has raised intent fdc3.ViewChart for instrument context”

Good: “Opening chart for AAPL”

Users don’t think in terms of “intents” and “context objects.” They think in terms of clients, securities, portfolios, orders. Your UX should speak their language.

UX Is the Delivery Mechanism

When you’re building interop, don’t stop at making it work. Make it clear. Build for confidence and control. Integration is powerful, but if users can’t see what happened, understand why it happened, or control it when they need to, they’ll misuse or abandon it.

Design matters because at the end of the day, you’re solving for humans.

Golden Rules

Here’s what separates successful interop implementations from failed ones:

1. Focus on workflows, not technology

Integrate because it solves problems, not because you can.

2. Start simple, avoid analysis paralysis

The simplest architecture that works is usually the right architecture. Complexity is costly. Don’t try to design the perfect system on paper.

3. Establish clear governance

Structure enables speed. Chaos slows everyone down.

4. Design for humans first

If users can’t understand and control it, they won’t use it.

5. Iterate gradually

Avoid big-bang rollouts and analysis. Phased approaches reduce risk and enable learning.

6. Think about performance and compliance from day one

These aren’t things you add later. They’re foundational.

The Bottom Line

Interop isn’t just about APIs and windows linking together. It’s about creating a system that people trust, that scales, and that actually solves problems.

The difference between success and failure isn’t usually the technology, but whether you kept architecture manageable, designed for how humans actually work, and built iteratively with real feedback.

Catch up on Part 1:

If you haven’t already, I recommend you to check out the first article, where we explored, setting goals, strategy and governance. Let us know if you’re interested in discussing real-world use cases and diving deeper into what we’ve seen working before (and what to better avoid).

Have you hit other obstacles that we didn’t cover? Were there things that didn’t go according to plan, but worked in the end? Any surprising user stories or neat workarounds you can share?

Read full topic

Performance considerations for desktop interop systems

Toni Petov — Tue, 25 Nov 2025 08:24:36 +0000

Tips for troubleshooting bottlenecks and optimizing resource usage

Optimization of performance in desktop interop deployments impacts end-user productivity and reduces the total cost of operation. Here at interop.io, we’ve identified five key factors that influence performance in real-world desktop environments.

1. Disk footprint

Desktop interop systems like io.Connect Desktop are typically installed as launchable applications on end users’ computers or VDIs. The amount of disk space required for installation varies depending on the specific feature set in use. For instance, the inclusion of various adapters (e.g, Office Adapter) increases the required disk space. System logging also requires adequate disk space. The parameters of io.Connect’s log rotation (zipping and then removing old files) can be adjusted as necessary to ensure that systems never run low on disk space.

Free Trial vs. Production size

Note that trial versions of io.Connect Desktop have larger disk footprint than production versions. This is because the trial version includes io.Connect Desktop’s full suite of adapters and libraries. We optimize this size when configuring your production installer.

2. Memory footprint

The amount of memory used by a desktop system depends on 4 factors:

Baseline system memory. This is the memory required by the system’s core components and service layers. This is a fixed amount which cannot be optimized.
App memory requirements. This is the most important factor. Each app that is launched inside the desktop will have its own memory requirements. This memory usage is typically independent of the underlying platform. For instance, an app running in a Chrome tab will use the same amount of memory running in an io.Connect window.
System overhead per app. The desktop system will add additional memory for each running app. This includes the cost for running the underlying rendering engine (e.g. chromium instances, webview2 instances) as well as the desktop system’s own memory requirements (such as client-side APIs that are resident in the app, e.g. via preloads). This overhead is typically the same in Chrome and io.Connect.
Systemwide heap. App usage of features such as stored contexts, application configs, etc will result in some memory growth at the system level. The exact amount depends both on the behaviors of apps as well as the heuristics of the system itself. This memory is usually small unless very large contexts or extensive lists of apps are used.

It is important to note that overall memory requirements of the desktop don’t impact end-user experience until memory requirements overshoot the hardware’s capacity, at which point hardware systems can slow down due to memory swapping. Some VDI systems can fail outright when memory requirements are exceeded. Modern hardware typically provides 16GB and 32GB options at low cost. VDI systems with these capacities can cost $200 - $400 per month, per end user.

Greedy memory allocation

A key understanding when evaluating memory usage is that modern operating systems use a “greedy” approach to allocating memory. App memory may swell in size as the operating system determines the app’s needs, and the OS will not necessarily reclaim that memory until it is needed. In a system with 32GB of memory, it may be the case that the operating system rarely needs to reclaim memory, and so a large app like io.Connect or Chrome may be observed to have very high memory usage, even though much of this memory is not “active”.

Considerations

A key value proposition of desktop interop is the ability to run multiple apps at once in a “composed” view. Such a view can be a layout (multiple windows organized across one or more monitors) or a workspace (multiple apps organized into frames within a single window). With more windows comes a requirement for more memory, each app requiring its own heap as well as the memory requirements of the underlying rendering engine (Chromium). For large layouts across multiple monitors, this can result in a claim for several gigabytes of memory.

Individual app consumption

It is important to understand the memory requirements of the individual apps that will be running simultaneously on the screen. For instance, an app that requires 400MB of memory running in a browser tab might never seem to cause any problems. But once released within io.Connect, users can decide to open several copies of the same app (now that they can organize these copies side-by-side), which then multiplies the amount of memory required. Optimizing memory usage of your business apps may therefore be necessary when system resources are constrained.

3. CPU and networking overhead

In much the same way as a browser does, the bulk of CPU usage is generally from the applications that reside within the desktop. A desktop system does add some CPU and networking overhead via its own underlying processes, most of which occur only during system startup. Some overhead occurs when client APIs are used within the application space. For instance, applications that share context must exchange that context via the system’s services. Those services will use CPU to process and communicate. Generally, the overhead of such systems is low, but in some cases can become noticeable, such as when exchanging large chunks of data, when adding large numbers of app configs, or when saving and restoring complex layouts.

Delays due to overloaded CPU or network can negatively impact end-user experience. Typically, such situations are remedied through tweaks to API usage or through revisions to app architecture.

See how to check an app’s CPU and memory usage in the logs - Examining logs in practice

4. Window launch latency

What causes launch latency

Whenever an app is launched, a “renderer” must be instantiated to contain the app. Each of these renderers is its own Chromium instance, launched at the operating system level and observable in task manager. Once the renderer is launched, it immediately loads the app (e.g. downloading its HTML and JavaScript from a network), compiles (V8 engine), and then runs it. The app itself then may have its own initialization process, eventually resulting in display of its contents to the end user (e.g. React rendering). This overall process is essentially the same in interop.io as it is when opening a URL into a new browser tab in Chrome.

To the end-user, latency is a question of perception. The end user subconsciously measures latency as the time between when they click to launch an app until the time that the app is visible and interactive. As developers, we must break down this experience into individual steps for optimization:

Time from click to launching of the renderer
Time from launch of the renderer to running of application code
Time from running application code to the app being ready for interaction

Of these, the first step involves the menu itself responding to the end user, and then the desktop system’s internal relays which trigger the launch of a renderer. This first step generally occurs quickly (but should not be ignored.)

The second step (launching a renderer) depends on the performance of the underlying platform architecture as well as the operating system itself. The amount of time depends in some part on the underlying hardware as this is a CPU-intensive moment. Restoration of a layout may involve launching many apps simultaneously, which can take longer even on powerful systems, particularly if the apps themselves are complex and therefore contending for CPU resources. This is akin to restoring Chrome with dozens of tabs open. Multi-core systems are essential to delivering a better user experience.

See how to track Layout restoration in the logs here - Examining logs in practice

Optimizing time to interactive (TTI) and first contentful paint (FCP)

In the third step, the applications themselves must be optimized for quick display. It is common to optimize web apps for metrics such as “Time To Interactive” (TTI) or “First Contentful Paint” (FCP). These same types of optimizations should be considered for apps that run inside a desktop.

It’s worth noting first that an improvement of 1 or 2 seconds of window launch time is probably not meaningful in the context of a worker’s day. It is only when switching large layouts that an end user generally feels any sense of slowness, and in most of our experience, the biggest gains can be had by optimizing the footprint of individual apps.

5. Desktop startup time

The final performance consideration is how long the desktop itself takes to launch. An end user is likely to perceive this as the time from double-clicking on the desktop icon to the time when the initial layout is loaded, and all the apps are interactive. As such, a large portion of desktop startup time is actually layout loading time, which corresponds directly to window launch times as discussed above. But any slowness with window launch times may be exacerbated during startup due to contention with system resources which are booting and initializing at the same time as the apps.

Desktop startup time depends greatly on the level of “infrastructure” that a firm requires to operate their desktop. By “infrastructure” we mean services which are run during the startup process. In raw form, io.Connect starts in about 10 seconds, but launching and sequencing of background services and other support applications can cause this startup time to balloon. As this sort of infrastructure grows in complexity, CPU and network contention become more likely (as mentioned above), which can further exacerbate startup times. A good practice to avoid these conditions is to limit the number of services by consolidating startup code into fewer, or even a single service.

Cost vs. Gain

It is worth noting that system startup time is generally a once-per-day occurrence. A startup time of 30-60 seconds is not ideal, but may not be worth huge effort to optimize unless usage is truly negatively impacted. If systems need to be restarted daily, then this can be accomplished through settings in io.Connect, which would allow the restart to occur during off-hours, so that users are not impacted.

Key takeaways for desktop interop performance optimization

We must not forget that the user experience interoperability achieves is seamless, but behind the scenes, an often not-so-powerful machine needs to handle dozens of applications at the same time. Sometimes, just one of them can be causing issues and needs to be investigated. In other cases, the cumulative load becomes too great. Balancing disk usage, memory, CPU, and startup processes can significantly improve both performance and user satisfaction. By continuously monitoring resource utilization and refining app configurations, organizations can maintain responsive, scalable desktop environments. In both cases io.Insights can be the tool that makes investigation and performance monitoring much faster, covering every little metric and app trace. See example: Track down issues fast with io.Insights

Read full topic

Intent Interception use cases

Toni Petov — Tue, 25 Nov 2025 00:37:12 +0000

Recently in a couple of meetings, TerryThorsten mentioned how powerful intent interception in io.Connect can be and Kalina Georgieva shared with me some neat use cases where it was handy. So I thought this was worth sharing with the community:

Use case 1: Limit intent resolution to the workspace only

When resolving intents in io.Connect Browser, the developer wants to ensure that only applications/windows within the same workspace as the one that raised the intent are considered as possible handlers. The goal is to prevent intents from being handled by applications in other, non-focused workspaces and to avoid requiring extra user interactions.

By default, the intent resolver considers all possible handlers, including those in other workspaces. While this provides flexibility, it can also lead to confusing behavior, such as intents being handled by apps that are not currently active or visible to the user. The developer, therefore, wanted to restrict intent resolution to the current focused workspace.

How Interception achieves the goal

The behavior can be implemented with a plugin interceptor, which intercepts the ‘raise’ operation within the 'intents’ domain. Once the interceptor is in place, it can leverage the interop.io API to identify the appropriate handlers that should be considered. The interceptor then forwards the ‘raise’ command to the Platform along with an array of the filtered handlers, ensuring that only relevant, workspace-local handlers will be provided to the user.

Use case 2: App listening to its own intents

When an app in io.Connect raises an intent and also listens for that same intent, the intent resolver UI offers the user the option to resolve the intent using the same app instance that raised it. By default, the FDC3 standard and the io.Connect implementation include all registered handlers for an intent, including the originating app instance, in the resolver UI. There is no explicit exclusion of the originating instance in the FDC3 specification. There might be a reason for that, but some customers prefer to have the app that raised the intent excluded from the listeners list.

How Interception achieves the goal

The solution involves intercepting intent resolution calls and filtering out the originating app instance from the handlers list before presenting options to the user. This approach keeps the platform compliant with FDC3 while meeting the specific workflow needs of the app teams.

Use case 3: Enforce geographic and compliance restrictions

A compliance-sensitive firm operates in multiple regions. European users run desktop tools that shouldn’t access or display personally identifiable information (PII) contained in chat transcripts or client notes, which are allowed only in the US due to data privacy laws. Yet, the same intents like ViewChatTranscript are available globally.

How interception achieves the goal

An interceptor captures raise() operations and evaluates the callerId to determine the user’s region. When a request comes from an EU app, the interceptor either blocks the operation or redirects it to a safer intent, which returns redacted information.

Use case 4: Staged rollout of a new client experience

A new version of an intent handler is being tested with a small pilot group. The older version is still in use by everyone else, and both versions are live on the same desktop environment. Need to enable A/B testing and keep the new handler for the pilot group only.

How interception achieves the goal

An interceptor is set up to inspect each intent request before it’s dispatched. It checks which app raised the intent and whether that app (or user) is part of the pilot group. If yes, the interceptor reroutes the request to the new v2 handler. All other apps continue using the stable v1 handler.

Related documenation:

io.Connect Browser Documentation - Plugins > Interception
io.Connect Browser Documentation - Plugins > Interception
io.Connect Browser Documentation - io.Connect Browser - Intents
io.Connect Browser Documentation - Plugins > Setup
Read full topic

From Strategy to PoC: Setting Up Desktop Interop That Actually Works

Toni Petov — Tue, 18 Nov 2025 08:57:50 +0000

Imagine you just got a new smartphone packed with amazing apps. A beautiful calendar, a notes app with brilliant search and a task manager that’s feature-rich and intuitive. Each one is best-in-class, but they don’t talk to each other. So you’re copy-pasting meeting details, retyping action items, and manually syncing everything.

That’s desktop interop when it goes wrong.

Different teams bring in their favorite applications. Each works brilliantly on its own. But without shared planning or design standards, you end up with powerful tools that don’t click together. Users go back to manual switching, copy-paste, and errors.

Rolling out interop across an entire firm: multiple business units, workflows, and legacy systems, is where the real value lives. It’s also where complexity multiplies. It’s not just about connecting apps. It’s about orchestrating live data flows across dozens of systems, keeping users in sync, and doing all of that while staying compliant with tight regulatory and internal controls.

At the interop.io consulting team, we’ve spent over a decade implementing desktop interoperability across Tier 1 banks, hedge funds, and buy-side firms. We’ve seen the full spectrum: from clean, elegant rollouts to absolute chaos. Here I’ll share best practices that will help leaders rescue derailed projects, migrate off legacy platforms, and turn cluttered, fragmented desktops into streamlined environments that actually work.

Here’s where most projects fail: before a single line of code is even written.

Don’t skip strategy

You got a powerful toolbox that can connect anything in different ways – channels, shared context, intents, FDC3. Someone says, “Let’s connect all our apps!” The idea of smart workflows, data sharing, and seamless integration sounds great. But in all that excitement, you can forget the most important question:

Why are we doing this?

Which workflows are we trying to improve? What are the biggest pain points we are trying to solve? Without those answers, you end up integrating tools just because you *can. *

First, ask relevant questions like:

Where are users re-entering the same data into multiple systems?
What slows people down during high-pressure moments like market open or close?
Where are we losing time, focus, or accuracy due to app-switching?

When you uncover those day-to-day friction points, that’s where interop can really shine. That’s when you’re solving real problems.

To do so, bring your stakeholders in early. This isn’t just a developer’s problem or a business wish list. You need alignment across the board: product owners, technical leads, compliance, security, and of course, end-users. Get them all talking before you start building. Define the goals, agree on how you’ll measure success, and make sure everyone knows who’s responsible for what.

Takeway

Interop what matters. Start with the pain, not the tech.

Don’t Underestimate Integration Complexity

In the real world, we’re dealing with software written 20 or more years ago, weird homegrown VBA macros, Excel plugins from who-knows-where, and proprietary APIs that were never designed to talk to anything else. Some of these systems don’t even have documentation, let alone a clean way to expose events or accept external triggers. Yes, the interop platform gives you the tools. But you still have to do the groundwork. That means mapping out the landscape: skipping it will set you up for surprises.

That’s why we always recommend starting with a Proof of Concept. Not just to prove if something can work, but how it should work. Build a small and focused integration. Get real users to try it and watch what they do. And then iterate. A phased approach not only reduces risk, it gives you real-world feedback early enough to make meaningful changes.

Takeway

Start small, set clear goals, progressive rollout, and constant feedback. Run a realistic PoC with legacy and modern apps.

Governance and collaboration

Here’s where projects really spiral: governance. Interop isn’t just a shiny frontend project. It cuts across almost every part of the organization: applications, infrastructure, UX, security, compliance, even legal. So unless there’s clear ownership and coordination, what you end up with isn’t integration, but chaos.

Picture this: you’ve got three different app development teams, all trying to implement interop in their own way. One builds a custom context layer, another hacks together a local framework, and the third just wires up some point-to-point messaging between apps. No one’s talking to each other. No standards. No shared roadmap. In the end you get three incompatible solutions, all branded “interop,” but none of them actually interoperate.

That’s what happens without governance. Everyone builds in isolation. Silos get a fresh coat of paint, but they’re still silos.

So your project needs leadership and it needs structure. You need someone owning the architecture, someone responsible for platform consistency, and a shared understanding of what “success” looks like across teams.

At the same time, governance doesn’t need to be heavy-handed, but it does need to be visible. A big part of that is having a central source of truth: a living repository that tracks everything from onboarded applications and available intents, to shared contexts, methods, and workflows. Most companies use something like Confluence, or an internal wiki for this. It becomes the place where onboarding new apps or defining a new intent goes through a quick review process. Not to slow things down, but to keep things aligned. That’s how you avoid duplication, conflicting designs, and “spaghetti” integrations that nobody wants to own.

It’s easy to set and forget it, but that’s not enough. Someone needs to own it and keep an eye on it. Most importantly stakeholders must comply with it, so don’t make it too complicated

Takeway

Establish governance, standards, and regular architecture reviews. Make sure documentation is up-to-date and ensure new developers are onboarded early on.

Before You Start Building

The work you do before writing code determines whether your project succeeds or gets abandoned. Before your team starts integrating:

Identify the specific workflows you’re improving (not “everything”)
Map your landscape to know what you’re actually working with
Run a realistic PoC with legacy and modern apps
Set up a governance structure and a central source of truth
Get stakeholder alignment across teams

Next up: Part 2 will cover how to actually build interop that people use—keeping architecture simple, designing for humans, and avoiding the complexity traps that create technical debt.

Let us know if you’re interested in discussing real-world use cases and dive deeper in what we’ve seen working before (and what to avoid).

Read full topic

io.Connect Data Sharing Comparison Cheatsheet

Toni Petov — Tue, 04 Nov 2025 13:00:57 +0000

The io.Connect platform provides several ways for apps to communicate and share data, from simple broadcasts to request/response calls, user-driven context linking, and continuous streaming. Each option has its own model, scope, and persistence rules that work best in different use cases and scenarios.

The table below is a cheat sheet that lines Interop Methods, Intents, Streams, Pub/Sub, Shared Contexts, Channels, Workspace Contexts, and Window Context side-by-side. The goal isn’t to teach each one in depth, but to help compare them quickly and choose the right tool for your workflow. If you’re looking for full explanations and examples (like how Shared Contexts differ from Workspace Contexts, or how Channels give users control), see the dedicated pages in the docs.

	Interop Methods	Intents	Streams	Pub/Sub	Shared Contexts	Color Channels	Workspace Contexts	Window Context
Communication Model	Request-Response	Request-Response	Streaming	Broadcast	Broadcast	Broadcast	Broadcast	Window-specific
Publish Data	✅	✅	✅	✅	✅	✅ * Based on Channel Restrictions	✅	❌* Not intended for dynamic interop
Read Data	✅* Servers could restrict access to data	✅* Servers could restrict access to data	✅* Servers could restrict access to data	✅	✅	✅* Based on Channel Restrictions	✅	❌* Not intended for dynamic interop
Discovery	✅	✅	✅	❌	✅	✅	✅	❌
User Controlled	❌	✅* Users are responsible for resolving ambiguous Intents through the Intents Resolver UI	❌	❌	❌	✅* Users assign Application Instances to Color Channels	✅* Users control the Workspace grouping of Windows	❌
Defined Statically	❌	✅* Intents could also be defined dynamically	❌	❌	❌	❌	✅* Could be defined as part of a Workspace Layout	✅* Could be defined as part of a Global Layout
Global	✅	✅	✅	✅	✅	❌* By design, scoped to the Application Instances joined on the same Color Channel	❌* By design, scoped to the Applications Instances within a Workspace	❌
Persistence Across Restarts	❌	❌	❌	❌	❌	❌	✅* Data could be persisted as part of a Workspace Layout	✅* Data could be persisted as part of a Global Layout
Persistent (remains available if the server disconnects)	❌	❌	❌	❌	✅	✅	✅* The Workspaces Application could automatically destroy a Workspace Context when the Workspace is closed, based on configuration	❌
Reannouncement (e.g., after a machine state change)	✅	✅	✅	❌	✅	✅	✅	✅
Caller/Updater Identification	✅	✅	✅	✅	✅	✅	✅	❌
One-to-One or Many	One-to-many	One-to-one	One-to-many	One-to-many	One-to-many	One-to-many	One-to-many	One-to-one
Instance Launch Capability	❌	✅* Can launch new Instances of Applications, if needed	❌	❌	❌	❌	❌	✅* Can be provided as an initial context by the launching Application Instance via the AppManager API
io.Connect API	`methods()` `register()` `invoke()` `unregister()` …	`all()` `register()` `raise()` …	`createStream()` `stream.push()` `subscribe()` `stream.close()` …	`publish()` `subscribe()`	`all()` `set()` `get()` `subscribe()` …	`all()` `join()` `publish()` `subscribe()` …	`workspace.setContext()` `workspace.updateContext()` `workspace.getContext()` `workspace.onContextUpdated()`	`window.setContext()` `window.updateContext()` `window.getContext()` `window.onContextUpdated()`
Interception	❌	✅	❌	❌	❌	❌	❌	❌
FDC3 API Mapping	❌	Intents	Private Channels	❌	App Channels	User Channels	❌	❌

[details="For those who don't like tables (ChatGPT and Claude looking at you), click here"]

Interop Methods

Has: publish & read; request-response; discovery; global; one-to-many; caller/updater ID; reannouncement.
Lacks: user control, static definition, persistence across restarts, persistence if the server disconnects, instance launch, interception, FDC3 mapping.
Note: read access may be restricted by the server.
API: methods(), register(), invoke(), unregister(), …
Learn more:
https://docs.interop.io/desktop/capabilities/data-sharing/interop/javascript/index.html#method_registration
https://community.interop.io/t/key-io-connect-integration-concepts-explained/255#interop-methods-streams-service-reuse-and-data-feeds

Intents

Has: raise & handle (publish/read); request-response; discovery; user-controlled resolver UI when ambiguous; can be defined statically (also supports dynamic); global; one-to-one at execution; caller/updater ID; reannouncement; can launch a new app instance; interception supported.
Lacks: persistence across restarts, persistence if the server disconnects.
Note: read access may be restricted by the server.
FDC3: Intents.
API: all(), register(), raise(), …
Learn more:
https://docs.interop.io/desktop/capabilities/data-sharing/intents/overview/index.html
https://community.interop.io/t/key-io-connect-integration-concepts-explained/255#intents-allow-users-to-select-actions

Streams

Has: publish (push) & read (subscribe); streaming; discovery; global; one-to-many; caller/updater ID; reannouncement.
Lacks: user control, static definition, persistence across restarts, persistence if the server disconnects, instance launch, interception.
Note: read access may be restricted by the server.
FDC3: Private Channels.
API: createStream(), stream.push(), subscribe(), stream.close(), …
Learn more:
https://docs.interop.io/desktop/capabilities/data-sharing/interop/javascript/index.html#streaming
https://community.interop.io/t/key-io-connect-integration-concepts-explained/255#interop-methods-streams-service-reuse-and-data-feeds

Window Context

Has: window-specific (not global); one-to-one; can be defined statically in a Global Layout; can persist across restarts via Global Layout; reannouncement; can be supplied as initial context when launching via AppManager.
Lacks: dynamic publish/read (not meant for dynamic interop), discovery, user control, global scope, persistence if the server disconnects, caller/updater ID, interception, FDC3 mapping.
API: window.setContext(), window.updateContext(), window.getContext(), window.onContextUpdated()
Learn more:
https://docs.interop.io/desktop/capabilities/windows/window-management/javascript/index.html#context
https://community.interop.io/t/key-io-connect-integration-concepts-explained/255#window-context

Pub/Sub

Has: publish & read; broadcast; global scope; one-to-many; caller/updater ID.
Lacks: discovery, user control, static definition, persistence across restarts, persistence if the server disconnects, reannouncement, instance launch, interception, FDC3 mapping.
API: publish(), subscribe().
Learn more:
https://docs.interop.io/desktop/capabilities/data-sharing/pub-sub/overview/index.html
https://community.interop.io/t/key-io-connect-integration-concepts-explained/255#p-523-pubsub-8

Shared Contexts

Has: publish & read; broadcast; discovery; global; one-to-many; caller/updater ID; reannouncement; persists if the server disconnects.
Lacks: user control, static definition, persistence across restarts, instance launch, interception.
FDC3: App Channels.
API: all(), set(), get(), subscribe(), …
Learn more:
https://docs.interop.io/desktop/capabilities/data-sharing/shared-contexts/overview/index.html
https://community.interop.io/t/key-io-connect-integration-concepts-explained/255#shared-contexts-programmatic-data-sharing

Color Channels

Has: publish & read (subject to channel restrictions); broadcast; discovery; user-controlled (users assign app instances to channels); one-to-many; caller/updater ID; reannouncement; persists if the server disconnects.
Lacks: global scope (channel-scoped), static definition, persistence across restarts, instance launch, interception.
FDC3: User Channels.
API: all(), join(), publish(), subscribe(), …
Learn more:
https://docs.interop.io/desktop/capabilities/data-sharing/channels/overview/index.html
https://community.interop.io/t/key-io-connect-integration-concepts-explained/255#channels-empowering-end-users

Workspace Contexts

Has: publish & read; broadcast; discovery; user-controlled via workspace grouping; can be defined statically in a Workspace Layout; one-to-many; caller/updater ID; reannouncement; can persist across restarts when saved in a Workspace Layout; persists if the server disconnects (may auto-destroy on workspace close, depending on config).
Lacks: global scope (workspace-scoped), instance launch, interception, FDC3 mapping.
API: workspace.setContext(), workspace.updateContext(), workspace.getContext(), workspace.onContextUpdated()
Learn more:
https://docs.interop.io/desktop/capabilities/windows/workspaces/javascript/index.html#workspace_context
https://community.interop.io/t/key-io-connect-integration-concepts-explained/255#workspace-context-multi-tasking-without-confusion

[/details]

For a simple overview, check:

Key io.Connect Integration Concepts Explained

And for more details see the respective documentation pages:

Read full topic

Salesforce - Lightning Locker and io.Connect platform connected components - Standalone

Toni Petov — Thu, 16 Oct 2025 09:04:56 +0000

Overview

⚠️ Note that the following sections are relevant only for:

If you intend on using Salesforce within the io.Connect Platform (io.Connect Desktop or io.Connect Browser)

Salesforce sessions with active Lightning Locker (in Session Settings)

the latest versions of the Salesforce Adapter (5.13 and later). For details on the legacy versions (3.0 and 4.0), see the Legacy Adapter section.

As 'Lightning Locker' does not allow direct usage of components packaged in an external namespace you will need to use Lightning Message Service (LMS) to communicate with the io.Connect Platform. Thus, we provide free of charge an LMS middleware package and a Plugin-based template that could serve as a reference point for further development. For simplicity of this documentation we will not focus on structuring the component, if you want you could do so on your own. Note that such custom components can be used both in your Lightning Our apps, or from within the Salesforce platform (with certain limitations and requirements).

⚠️ Note that using Salesforce within the io.Connect Platform has the advantage of not having to attach an io.Connect Utility Bar component to your Lightning App and not having to provide additional package configuration after installation in order to enable interoperability. These steps, however, are required when using Salesforce in a web browser.

Requirements

For the use of the InteropConsumerMixin to make sense, Lightning Web Security must be disabled:

Log in to your Salesforce organization as an administrator.
Go to Setup > Security > Session Settings.
Make sure that Lightning Web Security is disabled in the "Lightning Web Security" section.

⚠️ If Lightning Web Security is already enabled, consider using the LWS approach instead.

⚠️ You will need to use Tick42__lmsStandalone in one of your UtilityBars in the Lightning Applications.

Limitations

The LMS-based approach is not yet evaluated and tested in Salesforce Classic applications.
Currently, the LMS-based approach does not support streaming and other more complex interop methods functionality.
Due to the security restrictions imposed by Salesforce, it's impossible to embed the Salesforce platform in an <iframe> in io.Connect Browser. To avoid this limitation, you can use the InteropConsumerMixin component in Lightning Out apps or Visualforce pages that run in io.Connect Browser instead.
If using more than one instance of the component in the same app, all interop-enabled LWCs will have the same application name. This means that you won't be able to register more than one event listener for the same type of event. To avoid this limitation, it's recommended to either use the InteropConsumerMixin component with Plugins or in different Lightning Out apps instead.

Examples

An example Lightning Application is available in the LMS[T42] Salesforce package. To retrieve the package into your project, execute the following command using the Salesforce CLI vs your organization where you have installed the packages:

sf project retrieve start --package-name "LMS[T42]"

Salesforce App Definition

The following sections describe how to create app definitions for the Salesforce platform or for your Lightning Out apps depending on whether you are using the Salesforce Adapter with io.Connect Desktop or with io.Connect Browser.

io.Connect Desktop

To be able to open Salesforce in io.Connect Windows or Workspaces in io.Connect Desktop, you must provide a valid app definition for it. Besides the standard required definition properties ("name", "type", and "url"), it's also required to enable auto injection of the @interopio/desktop library and to configure the usage of preload scripts. Enabling auto injection is necessary because the @interopio/desktop library provides the interoperability capabilities of the InteropConsumerMixin component. The preload scripts configuration is necessary because it enables using the InteropConsumerMixin component.

⚠️ Note that the preload scripts configuration also allows you to enable the usage of a Utility Bar component. Using a Utility Bar component isn't necessary when Salesforce is running in **io.Connect Desktop, but if you decide to use one, you must provide the respective preload script. For details on how to attach one of the available io.Connect Utility Bar components, see the Usage > Web Browser > Configuration section.

The following is an example configuration for defining the Salesforce platform as an io.Connect app:

{
    "name": "salesforce",
    "type": "window",
    "title": "Salesforce",
    "details": {
        // URL pointing to your Salesforce organization.
        "url": "https://your-salesforce-url.salesforce.com/",
        // This is required to enable usage of preload scripts.
        "security": {
            "webSecurity": false,
            "allowRunningInsecureContent": true,
            "allowedExternalURISchemes": ["data", "https", "http"]
        },
        // This is required to enable interoperability and library usage in production.
        "preloadScripts": {
            "scripts": [
                // This preload script is required to enable using the `InteropConsumerMixin` component.
                "https://enterprise-demos.dev.interop.io/preload-scripts/salesforce-request-factory-from-platform.js",
                // This preload script is only necessary if you want to use a Utility Bar component when Salesforce is running in io.Connect Desktop.
                "https://enterprise-demos.dev.interop.io/preload-scripts/salesforce-utility-bar.js"
            ],
            "useBase64PreloadScripts": false
        },
        // Enable auto injection of the `@interopio/desktop` library.
        "autoInjectAPI": {
            "enabled": true,
            // If set to `false` (default), will enable you to provide initialization settings from your component.
            // If `true`, the library will be auto initialized with the default settings (e.g., you won't be able
            // to use features that are disabled by default such as the Workspaces API and the Search API).
            "autoInit": false
        }
    },
    "customProperties": {
        // Use this if you want to add Salesforce to the "Add App" menu in a Workspace.
        // This will enable users to open Salesforce in Workspaces.
        "includeInWorkspaces": true
    }
}

io.Connect Browser

To be able to open your Lightning Out apps in io.Connect Windows or Workspaces in io.Connect Browser, you must provide a valid app definitions for them when initializing your Main app.

The following is an example configuration for defining a Lightning Out app as an io.Connect app:

import IOBrowserPlatform from "@interopio/browser-platform";

const config = {
    licenseKey: "my-license-key",
    applications: {
        local: [
            {
                name: "salesforce",
                type: "window",
                title: "Salesforce",
                details: {
                    // URL pointing to your Lightning Out app.
                    url: "https://example.com/your-lightning-out-app/"
                },
                customProperties: {
                    // Use this if you want to add your app to the "Add App" menu in a Workspace.
                    // This will enable users to open the app in Workspaces.
                    includeInWorkspaces: true
                }
            }
        ]
    }
};

const { io } = await IOBrowserPlatform(config);

Usage

The following sections describe the InteropConsumerMixin component API and provide examples on how to implement an interop-enabled LWC.

Component API

The InteropConsumerMixin mixin provides a set of properties and methods that you can use to interop-enable your LWC.

The mixin has the following methods that can be accessed via the this object upon successful connection to the io.Connect framework:

Method	Accepts	Description
`requestConnectionStatus()`	`()`	Use this method to request the current connection status. It sends an LMS message to the `lmsStandalone` which will return `{isConnected}` object as a response.
`executePlatformMessageCallback()`	`(string, boolean, object)`	Use this method to send a response to the `InteropConsumerMixin` component about the result from the Interop method invocation. The component will relay the response to the calling app. Accepts three required arguments - the ID of the invocation (which can be extracted from event details), a Boolean value denoting whether the invocation `Promise` should be resolved (`true`) or rejected (`false`), and the actual result from the method invocation to be passed to the calling app.
`registerMethod()`	`(string, string)`	Can be used instead of the `connected-methods` property to register Interop methods for handling DOM events. Accepts as required arguments the name of the Interop method and the name of the DOM event.
`triggerOutbound()`	`(object)`	Invokes an Interop method registered by other interop-enabled apps. Accepts as a required argument an object with `method` and `payload` properties specifying the name of the Interop method to invoke and arguments for the invocation.
`unregisterMethod()`	`(string)`	Unregisters an Interop method. Accepts as a required argument the name of the Interop method to unregister.

The mixin provides the following hooks:
| Method | Arguments | Description |
|--------|-----------|-------------|
| connectedCallback() | () | Used by the LWC rendering engine when the LWC component is initialized. This implementation subscribes for the correct LMS channels. |
| renderedCallback() | () | Used by the LWC rendering engine when the LWC component is rendered. This implementation requests a connection status. |
| disconnectedCallback() | () | Used by the LWC rendering engine when the LWC component is disconnected from the DOM. This implementation requests a connection status. |
| handlePlatformMessage() | (object) | Used when a registered method is called from outside LWC's SF-application. |

The LMSPlugin class provides the following properties:
| Property | Type | Description |
|----------|------|------------|
| listenToAPI | String | Sets the interop API method to listen for, e.g., "My.LMS.Test.Inbound.Method". |

The LMSPlugin class provides the following hooks:
| Method | Arguments | Description |
|--------|-----------|-------------|
| onConnected() | () | Registers the dedicated API method. |
| handlePlatformMessage() | (object) | Determine if this Plugin instance is registering the API method and forwards to onInbound() hook. |
| onInbound() | (string, object, string) | Executes custom logic on inbound API call. Accepts three required arguments - the ID of the invocation method (which can be extracted from event details), a serializable payload object and a sting with the callbackID of the the invocation Promise |

The example myInteropEnabledLms component provides the following hooks:
| Method | Arguments | Description |
|--------|-----------|-------------|
| onConnected() | () | Initializes the Plugin instances. |
| handlePlatformMessage() | (object) | Extends the mixin's method and forwards to onInbound in the registering Plugin. |

Example Implementation

To interop-enable your LWC, you must:

create a standard LWC with XML, HTML, and JavaScript files;
use the InteropConsumerMixin mixin in your LWC's JavaScript file to add the required functionality to your LWC;
to use Tick42__lmsStandalone in your home or record page or for best experience in one of your UtilityBars in the Lightning Applications;

The following examples demonstrate how to create an interop-enabled LWC that will be used in an io.Connect Desktop platform. The component registers an Interop method that can be invoked by other interop-enabled apps, and also invokes an Interop method already registered by other interop-enabled apps.

Example XML configuration for a LWC:

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>60.0</apiVersion>
    <isExposed>true</isExposed>
    <description>This component demonstrates inbound and outbound interoperability between Salesforce and io.Connect apps.</description>
    <masterLabel>My LMS Interop-Enabled Component</masterLabel>
    <targets>
        <!-- Salesforce pages targeted by the component. -->
        <target>lightning__RecordPage</target>
        <target>lightning__AppPage</target>
        <target>lightning__HomePage</target>
    </targets>
</LightningComponentBundle>

Example myInteropEnabledLms.html structure of an interop-enabled LWC that uses the InteropConsumerMixin mixin:

<template>
    <lightning-card title="My Interop-Enabled LMS Component">
        <div class="slds-p-horizontal_medium slds-p-bottom_small">
            <div>
                <p>
                    Active plugins: {pluginStack}
                </p>
                <p>state: {state}</p>
                <p>last received value: {lastReceived}</p>
            </div>
        </div>

    </lightning-card>

</template>

Example myInteropEnabledLms.js implementation of an interop-enabled LWC:

import { LightningElement, track } from 'lwc';
import {LMSPlugin, ListenPlugin, BroadcastPlugin} from './plugins.js';

import {InteropConsumerMixin} from './lmsMixin.js';

export default class MyInteropEnabledLms extends InteropConsumerMixin(LightningElement) {
    pluginInstances = [];
    plugins = [ListenPlugin, BroadcastPlugin];
    @track
    state = "start";
    lastReceived = "";
    get pluginStack() {
        return this.plugins.map((cls)=>cls.name).join(", ")
    }

    // This is a simple check that the plugins are of the correct type
    connectedCallback() {
        if (super.connectedCallback) super.connectedCallback();
        if (!this.plugins) {return;}

        this.plugins.forEach((plugin) => {

            if (! (plugin.prototype instanceof LMSPlugin)) {
                throw new Error(`io.Connect: the plugin ${plugin.name} must extend the ${LMSPlugin.name} class!`);
            }
            if (typeof plugin.prototype.onConnected !== 'function') {
                throw new Error('io.Connect: Error configuring WorkspaceUtilityBar.\n A Plugin Class must have an onConnected method!');
            }
        });
    }


    init = false;
    isConnected = false;
    handleConnectionStatusUpdate(message) {
        super.handleConnectionStatusUpdate({...message});
        if (this.isConnected && !this.init) {
            this.init = true;
            this.onConnected();
            this.state = "ready";
        }
    }

    onConnected() {
        if (super.onConnected) super.onConnected();
        if (!this.plugins) {return;}

        this.plugins.forEach((PluginClass)=>{
            const instance = new PluginClass(this.io, this);
            this.pluginInstances.push(instance);
            instance.onConnected();
        });
    }

    handlePlatformMessage(message) {
        if (super.handlePlatformMessage) super.handlePlatformMessage({...message});
        if (!this.plugins) {return;}

        let lastValue = false;
        this.pluginInstances.forEach((instance)=>{
            lastValue = lastValue || instance.handlePlatformMessage({...message});
        });
        this.lastReceived = lastValue;
    }

    // disconnectedCallback() {
    //     if (super.disconnectedCallback) super.disconnectedCallback();
    // }

    // connectedCallback() {
    //     if (super.connectedCallback) super.connectedCallback();
    // }

    // renderedCallback() {
    //     if (super.renderedCallback) super.renderedCallback();
    // }

}

Example plugins.js implementation of an interop-enabled LWC:

const TEST_INBOUND_METHOD = "My.LMS.Test.Inbound.Method";
const TEST_OUTBOUND_METHOD = "My.LMS.Test.Outbound.Method";


export class LMSPlugin {
    listenToAPI = null;
    registered = false;
    constructor(_io, parent) {
        this.parent = parent;
    }
    onConnected() {
        if (this.listenToAPI && !this.registered) {
            this.registered = true;
            this.registerMethod(this.listenToAPI);
        }

    }
    /**
     * @description handles interop incoming message from other connected component, i.e. 'T42.SF.Test.Inbound'
     * @param {Object} message - invocation message with:
     *  - {string} method - the name of the remote method to be executed in the connected component
     *  - {Object} payload - the payload to be passed to the remote method
     *  - {string} callbackID - the internal auto generated callback ID
     */
    handlePlatformMessage(message) {
        if (this.listenToAPI && message.method === this.listenToAPI) {
            return this.onInbound(message.method, message.payload, message.callbackID);
        }
        return '';
    }
    /**
     * @description handles interop incoming message from other connected component, i.e. 'T42.SF.Test.Inbound'
     * @param {string} method - the name of the remote method to be executed in the connected component
     * @param {Object} payload - the payload to be passed to the remote method
     * @param {string} callbackID - the internal auto generated callback ID
     */
    // eslint-disable-next-line no-unused-vars
    onInbound(method, payload, callbackID) {
        console.debug(`ioConnect: platform message (${method}) received`);
    }

    // it is @api in InteropConsumerMixin
    requestConnectionStatus(...args) {
        this.parent.requestConnectionStatus(...args);
    }
    // it is @api in InteropConsumerMixin
    executePlatformMessageCallback(...args) {
        this.parent.executePlatformMessageCallback(...args);
    }
    // it is @api in InteropConsumerMixin
    triggerOutbound(...args) {
        this.parent.triggerOutbound(...args);
    }
    // it is @api in InteropConsumerMixin
    registerMethod(...args) {
        this.parent.registerMethod(...args);
    }
    // it is @api in InteropConsumerMixin
    unregisterMethod(...args) {
        this.parent.unregisterMethod(...args);
    }
}


export class ListenPlugin extends LMSPlugin {
    listenToAPI = TEST_INBOUND_METHOD
    onConnected() {
        super.onConnected();
        console.log(`ioConnect: ${this.constructor.name}`);
    }

    /**
     * @description handles interop incoming message from other io-connected application, i.e. 'My.LMS.Test.Inbound.Method'
     * @param {string} method - the name of the remote method to be executed in the connected component
     * @param {Object} payload - the payload to be passed to the remote method
     * @param {string} callbackID - the internal auto generated callback ID
     */
    onInbound(method, payload, callbackID) {
        const { value } = payload;
        if (method !== this.listenToAPI) {
            throw new Error(`Expected to receive (${this.listenToAPI}) it's own registered method, but received ${method}`);
        }
        // If `true`, the `lmsStandalone` component will resolve the invocation `Promise`.
        // If `false`, the `lmsStandalone` component will reject the invocation `Promise`.
        const isSuccessful = value ? true : false;
        // Result that will be returned from invoking the Interop method.
        const invocationResult = { "OK": value ? true : false };

        // Send a response to the `lmsStandalone` component.
        // The `lmsStandalone` component will relay the response to the calling app.
        super.executePlatformMessageCallback(callbackID, isSuccessful, invocationResult);

        console.log(`onInbound: data received: ${value}.`);

        const lastValue = value;
        return lastValue;
    }

}

export class BroadcastPlugin extends LMSPlugin {
    onConnected() {
        super.onConnected();
        console.log(`ioConnect: ${this.constructor.name}`);
        // Invoke an outbound Interop method.
        this.triggerOutbound();
        console.log(`onConnected: sending ${TEST_OUTBOUND_METHOD}`);
    }

    triggerOutbound() {
        // Providing the name of the Interop method to invoke and arguments for the invocation.
        const args = {
            method: TEST_OUTBOUND_METHOD,
            payload: { value: "value" }
        };

        // Invoke an outbound Interop method.
        // Alternatively, you can use the io.Connect API directly: this.io.interop.invoke(args.method, args.payload);
        super.triggerOutbound(args);
    }
}

Example lmsMixin.js implementation of an interop-enabled LWC:

// import {EnclosingUtilityId, getInfo, getUtilityInfo, open, minimize, updatePanel, updateUtility} from 'lightning/platformUtilityBarApi';
import { api } from "lwc";

import { APPLICATION_SCOPE, createMessageContext, publish, releaseMessageContext, subscribe, unsubscribe } from "lightning/messageService";

import CONNECTION_STATUS_UPDATE from "@salesforce/messageChannel/Tick42__ConnectionStatusUpdate__c";
import CONNECTION_STATUS_REQUEST from "@salesforce/messageChannel/Tick42__ConnectionStatusUpdateRequest__c";
import PLATFORM_MESSAGE from "@salesforce/messageChannel/Tick42__PlatformMessage__c";
import PLATFORM_MESSAGE_CALLBACK from "@salesforce/messageChannel/Tick42__PlatformMessageCallback__c";
import PLATFORM_MESSAGE_REGISTER from "@salesforce/messageChannel/Tick42__PlatformMessageRegister__c";
import PLATFORM_MESSAGE_UNREGISTER from "@salesforce/messageChannel/Tick42__PlatformMessageUnregister__c";
import SALESFORCE_MESSAGE from "@salesforce/messageChannel/Tick42__SalesforceMessage__c";

export const InteropConsumerMixin = (Base)=>class extends Base {
    messageContext = createMessageContext(); // LMS context
    subscriptions = []; // the LMS subscriptions

    connectedCallback() {
        if (super.connectedCallback) super.connectedCallback();
        this.subscribeToMessageChannels();
    }

    subscribeToMessageChannels() {
        if (this.subscriptions.length) {
            return;
        }

        this.subscriptions.push(subscribe(
            this.messageContext,
            PLATFORM_MESSAGE,
            (message) => this.handlePlatformMessage(message),
            { scope: APPLICATION_SCOPE }
        ));
        this.subscriptions.push(subscribe(
            this.messageContext,
            CONNECTION_STATUS_UPDATE,
            (message) => this.handleConnectionStatusUpdate(message),
            { scope: APPLICATION_SCOPE }
        ));
    }

    /**
     * @description handles interop incoming message from other connected component, i.e. 'T42.SF.Test.Inbound'
     * @param {Object} message - invocation message with:
     *  - {string} method - the name of the remote method to be executed in the connected component
     *  - {Object} payload - the payload to be passed to the remote method
     *  - {string} callbackID - the internal auto generated callback ID
     */
    handlePlatformMessage(message) {
        console.debug(`ioConnect: platform message (${message.method}) received`);
    }

    handleConnectionStatusUpdate(message) {
        const {isConnected} = message;
        if (!isConnected) return;
        this.isConnected = isConnected;
    }

    unsubscribeFromMessageChannels() {
        if (this.subscriptions?.length > 0) {
            this.subscriptions.forEach(unsubscribe);
            this.subscriptions.length = 0;
        }
    }

    disconnectedCallback() {
        if (super.disconnectedCallback) super.disconnectedCallback();
        this.unsubscribeFromMessageChannels();
        releaseMessageContext(this.messageContext);
    }

    renderedCallback() {
        // Note: all @wire are executed before renderedCallback()
        if (super.renderedCallback) super.renderedCallback();
        this.requestConnectionStatus();
    }

    @api
    requestConnectionStatus() {
        publish(this.messageContext, CONNECTION_STATUS_REQUEST);
    }

    /**
     * A Platform-call result callback
     * @param {String} callbackID the callback ID
     * @param {Boolean} isSuccess the state of result
     * @param {Object} payload the data to send to the callback
     */
    @api
    executePlatformMessageCallback(callbackID, isSuccess, payload) {
        if (!callbackID || !(typeof callbackID=== 'string') || typeof isSuccess !== 'boolean') {
            throw Error('ioConnect: callbackID and status are required\n callbackID is an auto generated system ID for the Promise callbacks\n and status is a boolean where you need to program it\'s value as true or false.');
        }
        publish(this.messageContext, PLATFORM_MESSAGE_CALLBACK, {callbackID, status: isSuccess, payload});
    }

    /**
     * Sends a Platform message request
     * @param {Object} payload the data to send to the platform
     */
    @api
    triggerOutbound(payload) {
        publish(this.messageContext, SALESFORCE_MESSAGE, {...payload});
    }

    @api
    registerMethod(method) {
        publish(this.messageContext, PLATFORM_MESSAGE_REGISTER, { method });
    }

    @api
    unregisterMethod(method) {
        publish(this.messageContext, PLATFORM_MESSAGE_UNREGISTER, { method });
    }
}

Understanding logs in io.Connect

Toni Petov — Thu, 16 Oct 2025 08:43:05 +0000

People talk about flashy frameworks, IDEs, and now AI copilots as the ultimate tools for developers. But I think logs hide real superpowers that we often overlook. They’re like truth serum you give to your apps, and they will reveal their secrets. Because they track every action, error, and alert, digging into logs can save you from embarrassing bugs and help you catch issues before they crush end-users’ systems.

Logs provide valuable insights into a program’s activities. Typically, logs offer various severity levels, ranging from detailed step-by-step records to general overviews of the software’s execution during log generation. This data aids us in analyzing software, performance, and security issues. It is important to note that log files rarely provide the exact reason for an issue in plain text. Instead, log analysis is used to understand and diagnose problems by reconstructing events.

There are multiple types of logs and storage locations. We will focus on application-type logs stored locally or locally like, meaning without the use of a dedicated logging system or log management software.

How are the log files structured in io.Connect?

We use:

log4js for our JavaScript-based code
log4net for our .NET components

log4js is a powerful logging library for Node.js, based on the Java log4j framework. It supports various flexible and configurable log levels and appenders.

The log4js library offers flexibility because its behavior and settings are controlled through JSON configuration files (rather than being hardcoded). We use file and console-type appenders, but you can also use various custom appenders (learn how here https://docs.interop.io/desktop/developers/configuration/system/index.html#logging-custom_log_appenders)

Additionally log4js allows log message formatting and filtering.

log4js appenders:

Appender Type	Description	Use Case
File Appenders	Writes logs to files on the disk.	Primary appender in io.Connect Desktop.
Console Appenders	Writes logs to the console.	Useful for debugging and development.
FTP Appenders	Writes logs to a remote FTP server.	Useful for centralized logging.

log4js log levels:

A log level is the severity or priority of a log event (debug, info, etc). Whether an appender will see the event or not is determined by the layout.

We use the following layout:

Format Example

[<DATE>] [<LEVEL>] [<COMPONENT>] - [<MESSAGE>]

DATE: The timestamp of the log entry. Provides the context of when the event occurred.
LEVEL: The severity level of the log entry (e.g., DEBUG, INFO, WARN, ERROR, FATAL). Indicates the importance and urgency of the message.
COMPONENT: The part of the application generating the log.
MESSAGE: The actual log message. Describes the event or error being logged.

Note: *.NET** logs also include [<THREAD-ID>].*

Defaults settings

Log files roll over when they reach a certain size (10MB in io.cd case).
A maximum of N rolled-over log files are kept (5 in io.cd case).
Oldest log files are deleted when the limit is reached.
Can be configured via %LocalAppData%\interop.io\io.Connect Desktop\Desktop\config\logger.json

Important:

Interop.io does not log sensitive data. We only log what the software is executing.
The timestamps in the log file reflect the time of the machine on which the application is running.

Tools for Log Analysis

Logs are formatted to be compatible with simple text editors like Notepad, as well as more complex solutions like Splunk, and everything in between, depending on your choice. As a bare minimum, we recommend using Notepad++ for log analysis and working with .json files.

Basic editors: Notepad, Notepad++, JSON formatters
Advanced: Splunk, Graylog, Datadog, etc.

Log Files Overview

Application log

The application.log file is the main log generated by the Electron application, which drives the logic, applications, windows, layouts, etc, for io.Connect Desktop. This file should usually be the starting point in the analysis process.

Default location: %LocalAppData%\interop.io\io.Connect Desktop\UserData\<ENV>-<REG>\logs

<ENV>-<REG> - represents the environment and region of io.Connect Desktop (e.g., DEMO-INTEROP.IO)

Bridge log

The bridge.log file is the log file of the .NET component in io.Desktop, responsible for the logic behind the windows (not to be confused with the OS).

Default location: %LocalAppData%\interop.io\io.Connect Desktop\UserData\<ENV>-<REG>\logs

Gilding log

The gilding.log file is generated by gilding.exe, a tiny .NET application used for starting and tracking the lifetime of the main io Application. This way gilding.exe can collect logs in case the main .exe crashes.

Default location: %LocalAppData%\interop.io\io.Connect Desktop\UserData\<ENV>-<REG>\logs

Getway log

The gw.log file logs the activities of the message bus of io.Connect Desktop. In the current version, it is written in Node.js (was written in Java in the past).

Default location: %LocalAppData%\interop.io\io.Connect Desktop\UserData\<ENV>-<REG>\logs

Installer log

The installer.log file is created by io.Connect Desktop during installation.

Default location: %LocalAppData%\interop.io\io.Connect Desktop\Installer

Adapter logs

The adapters logs are generated by the various adapters, like Outlook, Word, Excel, etc.

Default location: %LocalAppData%\interop.io\io.Connect Desktop\UserData\ApplicationAdapters

Application-specific logs

The application-specific logs are written by the applications participating in the io.Connect Desktop. You can use the API-s to log messages.

Default location: %LocalAppData%\interop.io\io.Connect Desktop\UserData\<ENV>-<REG>\logs\applications

Important: application-specific logs are not to be confused with the Electron application.log.

From 9.9 onward you can funnel a web app’s own uncaught errors, console messages and failed network requests into the shared application.log (under <installation_location>/interop.io/io.Connect Desktop/UserData/<ENV>-<REG>/logs) so frontend events sit in the same timeline as platform activity.

Learn how to enable and configure it here - https://docs.interop.io/desktop/capabilities/more/apis/index.html#logging-capturing_client_app_errors

Extra: Crash reports

io.Connect Desktop can automatically capture crash dumps whenever any of its processes crashes.

Default location: %LocalAppData%\interop.io\io.Connect Desktop\UserData\<ENV>-<REG>\logs\crashes

The feature can be turned on by adding the crashReporter block to system.json:

{
  "crashReporter": {
    "enabled": true,
    "companyName": "Your Company",
    "productName": "Your Product",
    "folderPath": "%LocalAppData%/interop.io/io.Connect Desktop/crashes",
    "output": {
      "type": "local"   // local | server | backtrace
    }
  }
}

Output types

Type	Behaviour
local	Writes .dmp files under /reports.
server	POSTs the crash payload to the REST endpoint set by serverUrl. Use this to forward dumps to io.Manager or a custom service.
backtrace	Sends the report to a Backtrace instance (supply backTraceConfig).

Example for sending dumps to io.Manager:

{
  "crashReporter": {
    "output": {
      "type": "server",
      "serverUrl": "http://localhost:4356/api/crashes"
    }
  }
}

Dump‑file maintenance

Add an optional dumps object under output to control retention:

{
  "crashReporter": {
    "output": {
      "dumps": {
        "limit": 10,
        "deleteOnSent": true
      }
    }
  }
}

limit – maximum number of dump files kept between restarts.
deleteOnSent – remove a dump after successful upload instead of archiving to /sent.

Reviewing Log Files – Best Practices & Use cases

Identify session boundaries and total number of runs.
Confirm version and environment metadata.
Review the full system configuration.
Trace warnings/errors across log sets.
Analyze each process from start to finish, across rolled-over logs if necessary.
Identify the user environment.

System log rotation

Starting with io.Connect Desktop 9.3 you can tell the platform what to do with older logs on startup. The setting lives under logging.files in system.json and lets you keep your log folder clean without scripting a clean‑up job.

onStartup value	Effect	Good for
keep (default)	Leave yesterday’s files alone.	Workstations where disk isn’t an issue.
delete	Remove the whole log folder before new session starts.	Locked‑down VDI or demo pods.
archive	Move files to moveOldTo or default archive path.	Debugging long‑running issues across days.

See how to configure it here: https://docs.interop.io/desktop/developers/configuration/system/index.html#logging-system_logs-log_files

In the next article, we’ll share some use cases and frequently used keywords that can help find useful information.

Examining logs in practice

Toni Petov — Thu, 16 Oct 2025 08:35:07 +0000

In a previous article (https://community.interop.io/t/understanding-logs-in-io-connect/36/1) we covered some logs io.Connect stores and how to configure them based on our needs and context. In this article we'll go through some sample use cases and common scenarios, and show where to look to find the root cause.

How to identify the start of a run

To identify the version of the component and how many runs you have in the log file, search for the string "===== " (5 equal symbols and an empty space) in application.log. Each run will begin with logging the mentioned string. In the example below you can see GlueDesktop being started 6 times over the reviewed log - you have 6 different hits searching with "===== ". Note that if you omit the empty space at the end of the search string, you need to divide the result by 2 since the equal sign string is used twice on each line:

How to check components versions and Environment & Region

Right under the io.Connect Desktop version, you can see other details such as the user environment, host OS settings, system configuration, all versions of the different components comprising the io.Connect Desktop, and the command line used to start the inner .exe. This is useful because sometimes there are extra parameters here that could explain certain behaviors.

Here is an example of the components visualized in a .json format:

Check which version of the components you are reviewing. Sometimes, the resolution is in a newer version.

How to check the full system configuration

Search for the “full system config” string to find the system configuration. The data is in .json format and can be additionally formatted for easier reading. As mentioned, issues can stem solely from configuration. Keep in mind that the io.Connect Desktop configuration can be locally based or fetched from a remote server during your analysis.

How to check running application list

To see a running app list, search with the string ‘app-mgr - app list’. Note that this list will change over time, as not all applications are loaded at startup - some are initiated by user clicks or intents from other applications as part of a workflow.

How to check all auto started applications

To search for all applications that are auto-start configured, search for the “auto-start-apps” string:

How to check the life cycle of a specific application

To see all starts of a particular application you are interested in, use the string "app - starting".
This is used not only to check whether an application started (or attempted to), but also to track the full lifetime of the app. A token (eqyKWn3I3g in the screenshot below) will be created for each start, which can later be used to track the application in the bridge.log file. This allows you to cross-check between different log files.

Using the same approach, you can also see and obtain the window ID(15380_2 in the screenshot below), which you can use to track the lifetime of the app window.

How to track layout restoration

To track the layout restoration, search for “restoring layout name”. You can copy and explore the restore options and the full layout definition. You can also get the token from the layout/manager call and track the restore operation. In the screenshot below, the token is [Hde_9GOUn2]. To check the completion event, search for “restore successful, duration:”

How to track workspace restoration

To track workspace restoration, search for “Received control operation openWorkspace”

If no frame is available -> “Creating new frame for workspace”

If frame is available -> “Creating new workspace 4sXYbDX1g8 in frame 50736_sf_2”

How to check Protocol handler usage

The protocol handler is invoked when a URL is clicked in the browser, or a file is opened in the file explorer. It goes to gilding.exe, which sends the request to the Electron main process via a pipe message. You can cross-check this in the gilding logs and in the application log.
1.1 Gilding logs - look at the startup arguments. These startup arguments will be missing in the gilding logs if the protocol handler is invoked when the system is already running.
1.2 Application logs - search for "pipe-manager" and "protocol-handler"

How to monitor CPU and memory usage

To check CPU and memory usage, search for “perf-log“ in the application log to see the total system CPU and memory usage and identify an application that might be consuming a suspicious number of resources.

Please note that logging is evolving, and some logs might appear only in newer versions, or others can be changed or deprecated.

Answering Questions with io.Insights Metrics and Grafana

Toni Petov — Thu, 16 Oct 2025 08:32:49 +0000

This tutorial shows how to use metrics information from io.Insights to answer questions about user and application behavior across your enterprise. It's a practical example of identifying the most frequently used applications in your io.Connect environment.

What You'll Learn

io.Insights publishes a rich set of information about the platform and applications running in it that can be used to investigate both individual entities (specific applications, workspaces, users, layouts) as well as generate aggregated reports about behavior and usage patterns.

When coupled with a querying system like Grafana, infrastructure and analytics teams can build dashboards, set up alerts, and run queries to gain visibility into a wide range of operational metrics.

Prerequisites

io.Insights enabled and configured in your io.Connect environment – see https://docs.interop.io/insights/configuration/index.html
Grafana connected to your OpenTelemetry metrics collector – see https://community.interop.io/t/getting-started-with-io-insights/55
Access to Grafana dashboard creation

Step 1: Access Your Grafana Dashboard

Navigate to your Grafana instance and access the Dashboards section. You should see your existing dashboards, including any io.Insights dashboards you may have already created.

Click New to create a new dashboard -> New Dashboard, then select + Add visualization to begin building your metrics query.

Step 2: Create a New Visualization Panel

You'll start with a blank panel configuration. The key to this demonstration is using data from the app_started metric, which represents the number of times each application has been started during platform sessions.

In the metrics selection dropdown, you'll see various io.Insights metrics available, including:

app_started_total - our target metric
app_duration_* - application focus time metrics
app_memory_* - memory usage metrics
platform_startup_* - platform initialization metrics

Select app_started_total as your primary metric.

Step 3: Switch to Bar Chart Visualization

For displaying top applications by usage count, a bar chart provides clearer insights than a time series. Change your visualization type to Bar gauge in the panel options.

This creates a much more readable view showing each application and its relative usage frequency.

Step 4: Configure the Query and Aggregation

Since we want to identify the most-used applications based on total startup counts, we need to apply aggregation. The app_started metric is an increasing counter, so we're interested in the maximum value it reaches for each application.

Configure your query settings:

Metric: app_started_total
Aggregation: Select Max over time since we want the total count per application

Group by: Application name (this will separate results by individual applications). Aggregations -> Max by -> application -> instance
Sum: get total runs per applications 3.gregations* -> Sum -> by label -> application

Click Run queries

Step 5: Add Data Transformations

To make the data more presentable and show only the top results, we'll add transformations. Click on the Transformations tab to access additional data processing options.

The transformations allow you to:

Limit results: Show only the top N applications
Sort data: Order by usage count (descending)
Rename fields: Clean up display names
Calculate values: Perform additional aggregations
Group by nested tables: If you want to organize by additional attributes

This ensures you're displaying the most actionable data and the applications that are actually being used most frequently by your users..

Step 6: Review Your Results

Your final visualization should clearly show which io.Connect applications are used most frequently in your environment. This information can help you:

Identify popular applications for optimization or additional investment
Spot underutilized applications that may need better promotion or could be candidates for removal
Plan infrastructure capacity based on actual usage patterns
Make data-driven decisions about application portfolio management

Beyond This Example

This demonstration shows just a simple example of extracting metrics information in a few clicks. Experienced analysts can build extremely sophisticated dashboards that include:

Regional breakdowns: Most used applications per geographic region
Version analysis: Usage patterns across different application versions
Time-based trends: Usage changes over specific periods
User behavior analysis: Individual user application preferences
Performance correlations: Connecting usage data with performance metrics

Key Insights from io.Insights Data

All the telemetry information published by io.Insights describes events that occur in your applications and platform. This data can optionally be exported as metrics, giving you instant visibility into any aspect of your application usage related to the features of the io.Connect platform.

The app_started metric used in this example is just one of many available metrics. Other valuable metrics include:

app_duration: The time an app has been on focus during each platform session.
app_error: The number of times an app error was received during each platform session.
workspace_stopped: The number of times a Workspace has been stopped during each platform session.
system_cpu and system_memory: Resource utilization patterns

Next Steps

From this foundation, you can:

Save the query for future use and monitoring
Set up alerts when usage patterns change significantly
Add the panel to a dashboard with other related metrics
Create additional breakdowns by user, time period, or platform version
Export data for further analysis in other tools

This approach transforms raw telemetry data into actionable business intelligence, helping you optimize your io.Connect deployment based on real user behavior.

Useful links

Track down issues fast with io.Insights

Toni Petov — Thu, 16 Oct 2025 08:31:54 +0000

Working in finance requires quick and precise identification of problems. In this article, we’ll walk through how to leverage io.Insights to utilize io.Connect telemetry data, specifically tracing and logging, to swiftly identify application issues.

Scenario Overview

We have two interconnected applications:

Client List: Displays client information fetched from a backend, allowing user selection.
Portfolio Viewer: Subscribes to selection changes from the Client List, fetching and displaying detailed portfolio data.

The synchronization has stopped for a specific user, and we want to quickly trace and pinpoint the issue. We’ll be using io.Insights to collect and pass all data and Grafana as an example platform for exploration and analysis. Any alternative of Grafana can be used in a similar way.

Step-by-Step Diagnostic Process

1. Enable Observability

Before digging into the data we need to make sure io.Insights is enabled. This is done simply by adding the "insights" (pre 10.0 versions use "otel")1 top-level key in the system.json system configuration file of io.Connect Desktop located in the %LocalAppData%/interop.io/io.Connect Desktop/Desktop/config or by using the otel property of the configuration object when initializing your Main app in io.Connect Browser, and specifying the publishing URL of the OTEL collector.

See the documentation about configuration here - https://docs.interop.io/insights/configuration/index.html#ioconnect_desktop

1 The "insights" top level object is used to enable and configure io.Insights since version 10.0. The "otel" top level object is used to enable and configure io.Insights in versions pre-10.0. Don’t worry - it’s backward compatible.

Having io.Insights enabled will now expose tracing and log events for our platform. Next, head to the Traces tab.

[

2. Open the Query Interface

Click the three-dot menu in the Traces panel and click Explore.

This brings up the TraceQL query builder. We can use this to filter the traces relevant to the issue.

[

3. Filter by User and Application

Construct a query targeting the specific user and app:

{ span.user = "VelkoNikolov" && span.tracingAppName = "ClientList" }

[

And run the query to list out all traces related to that user. Under Service & Operations we can simply click the table row we are interested in to drill down into more details.

[

4. Inspect the Trace Tree

Click any trace row to view its hierarchical structure. Click Span attributes to explore more,

Each span represents a sub-operation. At the top, you’ll typically see a span from ClientList, representing the update. Keep clicking downward through the spans to trace the flow.

[

5. Spot the Failing Span

One of the spans will have an error event. Click it and check the Events tab.

The exception message shows: "Failed to retrieve portfolio", indicating that the problem lies somewhere in the retrieval of the portfolio from the back-end service. So now we know where things are going wrong.

[

6. Dig into Backend Request

Since the back-end service also uses OTEL observability, we can dig deeper into its operation in the trace to find what the error was. Let’s scroll down to the backend service spans (e.g., ClientsService) and open the request handler.

Click Logs for this span to open the log view.

[

7. Analyze the Log Message

Here, the log output makes it crystal clear:

User VelkoNikolov does not have entitlement VIEW_EXTENDED_PORTFOLIO

This explains the error entirely - the user doesn’t have the required access to see that data.

[

Fixing the issue

Let the entitlements team know what’s missing.
Inform the user about the permission settings.
Optionally, investigate entitlement assignment via further trace exploration.

So no ticket escalations and no guessing - finding a tricky problem took just few minutes. The out-of-the-box instruments provided by io.Connect + io.Insights gives you everything you need with minimum setup in the observability platform you are already familiar with.

In the next article, we’ll cover custom instruments and more advanced workflows across services.

Useful links

Getting Started with io.Insights

Toni Petov — Thu, 16 Oct 2025 08:27:07 +0000

If you’re building apps or maintaining a platform running hundreds of apps across your enterprise, you might have run into a similar situation: something small breaks, performance tanks, or a user hits a weird and hard-to-reproduce bug. So you need to chase logs, check version mismatches, and guess at backend timings. Or you may just want to monitor and observe how your apps are doing inside the platform.

That’s where io.Insights comes in, giving you observability into what’s actually happening inside the io.Connect platform, your apps, and everything running on top of them.

What is io.Insights?

Io.Insights is an observability extension built specifically for the io.Connect ecosystem. It captures telemetry (traces, metrics, and logs) from desktop or browser-based apps, APIs, io.Manager, and the platform itself. And it does this with very little extra setup required.

In practice, that means you get clear, structured answers to questions like:

Why did this specific operation fail for this specific user?
What apps are being used the most, by start count, by session time, or by role?
When during the day do most errors happen and who’s hitting them?
What’s the latency of backend requests in real workflows?
Are end-user machines hitting CPU or memory limits?

This kind of telemetry isn’t just about performance monitoring. It’s the foundation for debugging production issues, making smart product decisions, and understanding platform-wide usage patterns.

How does io.Insights work?

io.Insights is based on the OpenTelemetry (OTEL) standard. That means everything it captures, like traces, metrics, or logs is structured, vendor-neutral, and works out of the box with tools like:

Grafana
Prometheus
Jaeger
Splunk
Power BI

Because it’s OTEL-compliant, you’re not locked into any specific vendor, and you can ingest the data however and wherever you want, locally, in the cloud, or straight into your existing dashboards.

Once io.Connect is installed with Insights enabled and the OTEL Collector is configured to handle the data pipeline telemetry will roll. No major code changes are needed to start capturing info.

What does it track?

io.Insights publishes:

Platform and API metrics: startup counts, usage, memory/CPU profiles, session durations
Traces from user actions and platform operations (like context updates or adapter calls)
Logs from the io.Connect platform and from your own applications if you opt in

Why OpenTelemetry?

OpenTelemetry has been adopted by observability vendors and enterprises as the de facto standard for instrumenting cloud-native applications, upon which the entire observability ecosystem builds. According to recent surveys, 48.5% of organizations are already using OpenTelemetry, with another 25.3% planning implementation soon. The framework has become the second-largest Cloud Native Computing Foundation (CNCF) project by number of contributors, sitting just behind Kubernetes.

One of OpenTelemetry’s most compelling advantages is its vendor-neutral approach that breaks free from proprietary vendor agents. By using OpenTelemetry SDKs, organizations can change observability vendors as simply as changing configuration for exporters

Key OTEL Terms to understand

OpenTelemetry offers several types of data

Trace: A full end-to-end sequence of operations, e.g. user selects a client, which triggers a context update, which triggers a backend fetch.
- Span: A single step or operation inside a trace. Spans are hierarchical and connected, showing timing, duration, and relationships. Think of them as nodes in a tree.
Metric: A numerical data point over time. For example, CPU usage, request counts, or session duration.
Log: An event-level message, often tied to a span. Includes error details, stack traces, or any structured message your app emits.

What can you do with this data?

Here are a few questions you can answer using io.Insights:

Usage & Behavior

What applications are used most? By start count or by how long they’re in focus?
How frequently do users switch between apps or workspaces?
What’s the average session length by app or user?
What departments or roles rely most on which tools?

Troubleshooting

Which actions are error-prone and for who?
Are performance issues tied to specific machines or network latency?
Is a failing adapter being called more often than expected?
When something breaks, what happened before and after?

System Health

How much CPU/memory is being used by Connect apps on user machines?
Are certain machines regularly hitting system limits?
Are backend services responding consistently across users?

All of this is driven by the instruments that come built-in and it can be extended with your own events, metrics, or log data using simple APIs.

What do you need to run it?

Here’s what the setup typically looks like:

Install io.Connect with Insights enabled.
Set up a local or remote OTEL collector (e.g. with Docker).
Configure io.Connect to send telemetry to the collector.
Connect your collector to your analytics or dashboard backend.

That’s it, you’re now streaming metrics, logs, and traces out of your platform, ready for analysis. Of course, the config could be fetched from io.Manager, using its remote configuration feature

Sample Setup

Visualizing metrics with Grafana

Grafana is a powerful platform that can be used to visualize metrics, traces and logs all in one place. This makes it convenient to jump for example, from a spike in a particular metric to the relevant traces with the same labels/time window. The dashboards, graph metrics and overlay annotations help track cause → effect and link to logs or trace details. It also offers additional features like alerting, multi-channel notifications, and a library of community dashboards and plugins.

How to set up Grafana?

Grafana is offered as Grafana Cloud and an open-source download. If you want to keep your data local go with the downloads, it’s super straightforward. Simply visit https://grafana.com/grafana/download , if you are a Windows user, select Windows and download the Standalone Windows Binaries zip → right-click and select the unblock checkbox, and click OK, now unzip the archive to your preferred location. In that folder, open /bin and run grafana-server.exe, which will start Grafana. Now you can open a browser and enter http://localhost:3000/ (or replace the port if preferred).

Default login credentials are admin/admin (make sure to change your password and keep it safe). That’s it you can now play around.

In the left-hand sidebar select Connections → Data Sources, click + Add new data source and select Prometheus.

Why do I need Prometheus?

Grafana is your cockpit used to visualize the dashboard, but the downloadable version doesn’t keep metrics on disk. You still need a database that will store every sample, answer queries, and expose an HTTP API. Prometheus fills that role.

Grafana ships “native support for Prometheus”, so you can point it at a running Prometheus and it can query with PromQL.

Prometheus can be downloaded from https://prometheus.io/download/ and configured via prometheus.yml following the steps here https://prometheus.io/docs/introduction/first_steps/ . By default Prometheus runs on localhost:9090.

Prometheus config (scrape the Collector)

Add a scrape job to your prometheus.yml:

scrape_configs:
  - job_name: 'otel-collector'
    static_configs:
      - targets: ['localhost:9464']   # default Prometheus exporter endpoint

Prometheus will now scrape all metrics the collector exposes (including metrics your apps send via OTLP that the collector converts to Prometheus format).

Can I skip Prometheus?

There are several alternatives that play well with Grafana

Grafana Agent / Alloy - embeds a cut‑down Prometheus engine
Grafana Cloud or Mimir – easiest to set up, but runs remotely
Other TSDBs ― InfluxDB, VictoriaMetrics, TimescaleDB, etc.

Visualize traces in Grafana to combine the power of metrics and traces

To visualize traces in Grafana, you’ll need a tracing backend since Prometheus is designed specifically for metrics. One of the easiest ways is to use Jaeger or Grafana’s own Tempo.

Why Jaeger or Tempo?

Grafana natively supports both Jaeger and Tempo data sources. They’re optimized specifically for handling distributed traces, allowing you to quickly navigate from high-level metrics down into detailed operation-level data.

Setting Up Jaeger

Jaeger is an open-source tracing system, straightforward to install locally:

Download the latest Jaeger Windows binary from Jaeger releases.
Unzip the package into a folder like C:\Jaeger.
Open PowerShell and run:

cd C:\Jaeger
.\jaeger-all-in-one.exe --collector.otlp.enabled=true --collector.otlp.http.host-port=:4318

This command starts Jaeger with OTLP support. It will listen for traces sent to http://localhost:4318/v1/traces, and expose a web UI at http://localhost:16686. Typical ports are:

Thrift HTTP ingest: http://localhost:14268/api/traces
gRPC ingest: localhost:14250

Connecting Jaeger to Grafana

Follow the setup guide from Grafana here - https://grafana.com/docs/grafana/latest/datasources/jaeger/

OpenTelemetry Collector config

Here’s a sample for pointing an OTEL collector to Prometheus and Jaeger running locally:

Apps send OTLP → Collector (:4317 gRPC / :4318 HTTP).
Collector serves metrics at :8889/metrics.
Collector sends traces to Jaeger.

receivers:
  otlp:
    protocols:
      grpc:        # default port 4317
      http:        # default port 4318

processors:
  batch: {}

exporters:
  # Prometheus: expose /metrics that Prometheus will scrape
  prometheus:
    endpoint: "0.0.0.0:8889"   # collector will serve metrics here
    namespace: "otelcol"

  # --- Choose ONE of the Jaeger options below ---

  # Option A (most universal): Jaeger Thrift over HTTP (Jaeger all-in-one/collector default)
  jaeger:
    endpoint: "http://localhost:14268/api/traces"
    tls:
      insecure: true

  # Option B (if your Jaeger exposes native OTLP 4317/4318 — newer Jaeger versions)
  # otlp/jaeger:
  #   endpoint: "http://localhost:4318"   # or "localhost:4317" for gRPC
  #   # For HTTP:
  #   tls:
  #     insecure: true
  #   # For HTTP, set explicit protocol:
  #   # If your collector version needs it:
  #   # headers: {}
  #   # compression: none

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [jaeger]        # or [otlp/jaeger] if you chose Option B