Intent Interception use cases

#ioconnectbrowser

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.