User preferences - set Start Objects in Universal

Adding/removing Start Objects (called Favorites in the Universal UI) has become available with the latest 2026.1.11 release! We’ll also work on the ability to re-order your Start Objects.
 

This functionality is now available as of version 2026.1.11!

Start objects are now implemented as Favorites in the list bar and treeview menu. Users can create a list of their most used documents, tasks, and reports. Similar to saving favorites in a browser or other applications.

Because start objects are used to build the favorites list, selected items will automatically open when the user logs in.

What is your view on this?

• Should favorites open automatically at login?
• If not, is there still a need for users to define separate start objects, now that they have easy access to their most used menu items?
• Should favorites also be available in the tiles menu?

Also, some other noteworthy updates to the list bar and treeview menu:

• The Open documents section is now collapsible. This helps reduce clutter when many documents are open.
• Open documents are now ordered differently. When a document is opened, it is added to the bottom of the Open documents section. This keeps the order consistent with Favorites and aligns better with behavior in other applications.

I see “Favourite” as something to pin for easy access. A “Start object” is something I very likely need to use every the time I boot the application. So they are not the same in my opinion.

A marking on the favourite with “Open on startup” would suffice I think.

The menu should not matter for the reason to have a favourite list, so YES on availability in a Tile menu.

The new favorites functionality has been available for a few weeks. Now that users have added their most frequently used items to their favorites, many end users find it confusing and unexpected that these favorites automatically open on startup.

We propose disabling this behavior so that favorites function purely as favorites. As a result, users would no longer be able to define personal start objects. Our view is that favorites already serve the same purpose from an end-user perspective: providing quick access to frequently used documents and tasks.

This change would not affect start objects defined by the developer (user group–defined start objects); those would still open on startup.

What are your thoughts on this proposed change?

Having both options could come in handy: when clicking on the icon next to a menu item cycle between Favorite / Auto start / Remove from favorites.

And clicking on the icon next to a favorite could cycle to auto start / remove.

Or instead of cycling through options when clicking on the icon, show a small popup menu with separate options to auto start and favorite that can be checked/unchecked at will.

We agree that, ideally, it would be possible to support both behaviors through a UI option so users could decide whether favorites should launch on startup or simply act as a quick-access list. 

However for the time being, we have to choose between the following behaviors:

1. Keep the current behavior. Favorites launch on startup, meaning users can effectively define personal start objects.

2. Favorites behave purely as favorites, they would no longer launch on startup, but function only as a quick-access section.
   Consequence: users would no longer be able to define personal start objects.

3. Only the first favorite will open on startup

Which would you prefer?

My clients found option 1 to be confusing, because they won’t neccesarily understand the difference between refreshing the app and the active subject opnening because it is in the address bar, or if it’s opening because it is pinned as a favourite.

They also found option 1 annoying because is keeps re-opening favorites that you have already closed when changing menus. It would be useful if that favourite only opens when the user opens the menu in which it was actually pinned. We have users which are usig the app simultanously on tablet and desktop, and they keep

Currently it's like playing a game of whack-a-mole.

Option 2 would be the way to go, it’s the most intuitive of the options and it’s what users are used to with browser bookmarks for example

Option 3 will seem like random behaviour to the user

A compromise between 1 and 2 would probably be the best of both worlds, where the user can pin an item for quick access, which helps users with a large set of roles. If the user can mark (some of) those favourites as ‘auto start’, that would be very useful indeed.

But I do want to press the issue that whichever option we choose, it should only open pinned items from the menu that the user is navigating into, and not the menu they are leaving.

We have decided that favorites will behave as true favorites! They will no longer launch automatically when the application opens. Instead, the Favorites section will be expanded by default on startup, keeping your favorite items immediately accessible with a single click.

This change will be introduced in an upcoming release, alongside the ability to reorder favorites directly from the menu.

Keep in mind: User group start objects will continue to function as before. Developers can still use start objects for scenarios such as defining a starting page, displaying release notes, or triggering tasks when users open the application.