Layout and Workspace sharing in io.Connect Desktop 10.5 lets users publish their setups for colleagues and teams to use, without involving an administrator every time.
The docs clearly explain how to enable sharing and use the new APIs + requirements.
You must
- Use io.Manager 4.0+ as the Layout store, with Desktop 10.5+ on every instance connected to it. In
system.json, setserver.enabledtotrueandserver.features.layoutsStoretotrue.- Enable Advanced Layouts in both io.Connect Desktop and io.Manager.
- Migrate existing Layouts using Layouts → Migrate legacy layouts in the Manager Admin UI or the migration REST endpoint.
- Update application code: Use
io.layouts.v2available in@interopio/desktop 6.23or later for Layout operations.- To provide the sharing controls, custom Launchpad apps must use
@interopio/components-react5.0 or later, and custom Workspaces Apps must use@interopio/workspaces-ui-react5.0 or later.
Below are a few tips, things worth testing, and less obvious behaviors to keep in mind when implementing sharing or explaining it to users.
Will sharing work with a customized Launchpad?
Check how your Launchpad was customized and whether the sharing controls appear after upgrading.
The answer depends on how you’ve customized your setup.
| Your setup | What you need to do | What to expect |
|---|---|---|
| Customized Launchpad (you extended or modified the standard Launchpad) |
Upgrade to the new Launchpad version. To get started quickly, use the Launchpad template. |
Standard customizations like logos, buttons and app configuration keep working. Deeper code changes may need small fixes to pick up the new sharing functionality. |
| Custom Launcher (you built your own launcher app) |
Add the sharing interactions yourself (some extra development). |
Sharing controls won’t appear automatically. To build them faster, use the new io.layouts.v2 APIs and the ready-made functions in @interopio/components-react and @interopio/workspaces-ui-react. |
The minimum library versions to use are @interopio/components-react 5.0, @interopio/workspaces-ui-react 5.0 and @interopio/desktop 6.23. If you’ve disabled automatic library injection, make sure your applications explicitly reference a compatible @interopio/desktop version.
Layouts with the same name
- Use Layout IDs when you need to target a particular saved Layout.
With Advanced Layouts enabled, a user can have a private Layout and access a shared Layout with the same name. Layouts are identified by unique IDs, and the io.Connect protocol handler supports restoring Layouts by ID. This is important if you use application code that looks up Layouts by name or deep links.
Worth testing:
Create private and shared Layouts or Workspaces with identical names, then try your existing links and restoration logic. Make sure each action restores the intended Layout. Update any logic that relies on Layout names instead of IDs.
Sharing is role- and permission-based
Sharing uses role-based permissions: the Owner manages the Layout and its access, Editors can update it and manage access, and Viewers can use it and save a private copy to customize. Users can share with specific people or groups and assign view or edit permissions.
A private copy is independent of the shared original. Changes to that copy do not update the version colleagues use.
These permissions apply to both Global Layouts and Workspace Layouts. See the sharing roles and permissions documentation.
Saving Layouts without cluttering Launchpad
As teams start sharing Layouts, users may end up with many configurations that they don’t need regularly. They can use the Hide from Launchpad functionality to declutter. Here’s the catch: hiding is controlled by both the Layout’s hidden state and the user’s Launchpad preference.
If someone has hidden a Layout but it still appears, check whether their preference to show hidden items is enabled.
Agree on a process for sharing and updating Layouts for end-users
A user can share a Layout by clicking Publish. The “Keep a Private Copy” option preserves the user’s private Layout, which remains accessible only to them.
This means a user can create a Layout for a team and publish it + his own private copy. A week later, he improves that private version by adding another application and changing the arrangement. His colleagues won’t automatically receive those improvements. They’re still using the published version. For everyone to benefit from the new arrangement, he’ll update the shared version.
This distinction also matters when colleagues save private copies of Layouts shared with them. Viewers can use Save a Private Copy to create their own version, customize it, and even publish that copy to someone else.
Teams should agree on when to update shared Layouts and when to work with private copies, to avoid unexpected changes affecting colleagues.
The “Public” label in the UI includes both public and shared Layouts
io.Connect distinguishes between private, shared, and public Layouts:
| Type | Who can access it? | How is it created? |
|---|---|---|
| Private | Only its owner. | A user saves a private Layout or makes a private copy of an existing one. |
| Shared | Its owner and the selected users or groups, with view or edit permissions. | A user selects Publish in Launchpad or the Workspaces App and chooses whom to share it with. |
| Public | All users, while the Layout remains public. Editing is limited to its owner and users or groups granted edit permissions. See the Desktop 10.5 caveat below.* | Through io.Manager or an application using the new Layouts API. Launchpad and the Workspaces App cannot create public Layouts. |
The potentially confusing part is how these types appear in the UI: Launchpad groups both shared and public Layouts under “Public.” The Workspaces App similarly labels both types “Public Workspace.”
For example, a Layout a trader publishes for just two colleagues appears under Public for those colleagues. It remains a shared Layout accessible only to the selected audience. But appearing under the “Public” label does not mean it’s available to everyone.
The UI label alone therefore doesn’t tell you who has access. Check the Layout’s access details to see its audience and permissions.
* Desktop 10.5 caveat: Adding users or groups with view permissions to a public Layout through Launchpad or the Workspaces App converts it to a shared Layout in io.Manager. Access then follows the selected sharing permissions, so the Layout is no longer available to everyone. It still appears under Public in the UI, which can make this change easy to miss. Desktop 10.6 will change this behavior: public Layouts will remain available to all users, and only users or groups with edit permissions can be added to them.
Have you encountered other behaviors worth knowing about? Share your experience or questions below.