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?