Topics and Use Cases for the Notifications Event

io.Connect Desktop
,
1

As we are preparing for the Online Meetup on March 5 about io.Connect Notifications it will be helpful to hear your thoughts about what we should focus on:

  • Which notification scenarios should we dig into (e.g., system alerts, workflow nudges, approvals, cross-app coordination)?
  • Should we keep it beginner-friendly or more advanced?
  • Any must-haves for notifications in production observability, delivery guarantees, latency, user controls)?
2

One topic, I would like us to cover is Notification source and how it relates to user → in the context of interop we have app, workspace, and layouts → when the Notification is arrived on the notification panel typically we tie it to App Name where it’s originated from → however, from user stand point, they might be familiar with workspace or layouts name which they use on daily basis, and apps are part of it. For Example → I’ve a Portfolio Management workspace with combination of several apps, when the notification arrives users expect it’s for trade workspace and not for app1 with in the workspace.

2 Likes
3

Thanks for sharing @Adithya, that makes sense. Quick quesion - can an app live in mulltiple workspaces or be a standalone window? Would that be an edge case?

4

yes, app can live in more than one workspace or layout. sometimes, these can be public, private. it’s an interesting problem but I don’t think it’s an edge case.

1 Like
5

Sorry I’m late to responding to this, but one thing we would like to see is how to tie up toast notifications with FDC3 intents encoded in the action buttons as first class citizens. This is really the key for us to be able to create true workflows from these notifications.

1 Like
6

The io.Connect Notifications API currently supports Interop methods as the only action mechanism for toast notification buttons — there is no native support for FDC3 intents in notification actions as first class citizens.

It is technically possible to invoke an internal FDC3 intent-related Interop method directly, but this relies on an implementation detail and is not a supported pattern. Instead, I’d strongly recommend registering your own Interop method as the notification action handler, and wrapping fdc3.raiseIntent() call inside it. This gives you the full FDC3 intents experience:

  • Intent Resolver UI — the user gets a picker when multiple apps can handle the intent
  • Intent filtering — correct routing based on app manifests and context types
  • Intent targeting — ability to direct the intent at a specific app or instance

Native first-class support for FDC3 intents in notification actions does not currently
exist in io.Connect, but this approach is the recommended way to preserve everything that makes the intent system valuable.

2 Likes
7

Hi @Adithya, I think you weren’t able to join us for the event, but the answer here is what you’re trying to achieve should be possible. If you are using components-react (which is strongly recommended), you can override the HeaderTitle and render a custom value instead. In practice, map the source app (the one that raised the notification) to io.workspaces/layouts, then display that workspace/layout name in the header, with appTitle as a fallback when no mapping is available. It will be best to query by app id or instanceId.