Ordering Launchpad Groups in SAP Build Work Zone

One of the first pieces of feedback I get when delivering a Fiori Launchpad on SAP Build Work Zone is about group order: the business expects the areas they use every day to sit at the top, and instead the home page shows everything in alphabetical order. The follow-up request is always the same — "let's move this group first" — and the answer, surprisingly, is that the Site Manager offers no way to do it.

In this article we look at why, at the workaround I use, and at the point to watch out for so it keeps working: translations.

The behaviour: alphabetical sorting, not configurable

In the Fiori Launchpad served by SAP Build Work Zone, groups and tiles are sorted alphabetically, automatically. There is no drag & drop in the Content Manager, no order or priority field in the group definition, and no site setting that disables alphabetical sorting in favour of a manual order.

This is not a configuration gap but a product decision: the FLP applies sorting as a fixed rendering rule. The practical consequence is that the only lever available is the group title, because it is the only value that enters the comparison.

The comparison rules are documented in SAP KBA 3102280 — The sorting mechanism of groups in BTP Cloud Foundry launchpad — and there are three of them:

• digits take priority over letters: a group named 333 comes before any alphabetically named group;
• sorting is case-insensitive: sAP comes before URL titles, with no precedence given to uppercase initials;
• a leading space has the highest priority of all: a group whose title starts with a space is displayed before the others.

That last point is exactly the lever the workaround is built on.

Two strategies follow from that:

• Visible prefixes — renaming groups to 1 - Sales, 2 - Purchasing, 3 - Reporting. It is self-explanatory for whoever maintains the site, but it adds visual noise to the end user's home page and is almost always rejected by the business. More importantly, it breaks as soon as you go past nine groups: the comparison is between strings, not numbers, so 10 - Warehouse and 11 - Quality land right after 1 - Sales, before 2 - Purchasing. You need zero padding (01, 02, … 10, 11) for the order to hold, and even then every insertion in the middle of the list forces you to renumber all the following groups — in every translated language.
• Invisible prefixes — prepending Unicode characters to the title that take up width but produce no glyph. This is the approach I use when the order has to be controlled without polluting the interface.

The workaround: hair space (U+200A)

The hair space (U+200A) is an extremely thin typographic space, graphically invisible at normal sizes but a fully valid character. In the character table it comes before letters: a title starting with one or more hair spaces sorts before any title starting with a letter.

The principle is simple: the more hair spaces you prepend to a group name, the higher that group appears.

Groups with the same number of hair spaces stay alphabetically sorted among themselves: in the example, Administration would come before Reporting. That is why every group that needs a precise position should get a different hair space count, leaving without a prefix only the tail that can live in natural alphabetical order.

It works with a regular space too, as KBA 3102280 confirms: the mechanism is the same, and that is why the trick holds at all. I prefer the hair space for two practical reasons: it is a fraction of a space wide, so even three or four prefixes do not visibly shift the title inside the group card, and being a "non-whitespace" character for many editors and translation files, it survives copy-paste round trips and tools that strip leading spaces. If plain spaces are preserved correctly in your context, that is perfectly fine: the counting logic is identical.

The character is pasted straight into the title field. Here it is, ready to copy, between square brackets: [ ] — or you can find it on compart.com/en/unicode/U+200A. Since it is invisible, it is worth keeping it in a technical note together with the site's ordering scheme.

Ready-to-use sequences (copied from character U+200A):

pos. 1  ->       + title
pos. 2  ->            + title
pos. 3  ->                 + title
pos. 4+ ->                        title (alphabetical order)

The point to watch: group translations

This is the point that costs the most time, and one the KBA does not bring out.

If translations are active on the site and the group has a translated description in the user's language, the FLP sorts using the translated title, not the original title from the definition. The result is seemingly inconsistent behaviour: the order is correct when you test the site in one language and completely wrong in another, because in that language the hair spaces simply are not there.

The operating rule is therefore: hair spaces must be replicated in every active translation of the group, with the same count as the original title. If the site is bilingual EN/IT, the group in first position needs three hair spaces in both Sales and Vendite.

In testing this boils down to a trivial check that must not be skipped: open the launchpad with the user set to every supported language and verify the order, not just in the development language. It is also the first thing to check when someone reports that "the order broke": almost always a language was added or a translation edited without carrying the prefix over.

The supported alternative: pages and spaces

If the order has to be precise and stable — not "close enough" — the right path is not the title but the content model: spaces and pages. Within a page, the order of sections and tiles is part of the layout, so you define it explicitly instead of inheriting it; spaces, in turn, are ordered in the role assignment. The same applies with the Work Zone new user experience, where the home page is built on spaces and pages rather than on a list of groups.

The price, though, has to be stated clearly to the customer: adopting pages and spaces means losing group management. The model changes (role → space → page → section), the way users personalise their home page changes, and existing groups have to be rebuilt as pages and sections. It is a change in how the site is set up, not a cosmetic tweak: it is decided at project level, not to fix the position of two groups.

The rule of thumb I apply: hair spaces if the site is already group-based and the need is fine-tuning; pages and spaces if ordering is an explicit requirement and there is appetite to rework the home page structure.

Limitations to account for

Before adopting this approach as a project standard, it is worth being honest about its limits:

• It is a workaround, not a feature. It relies on rendering behaviour: a product change can alter it.
• It is invisible to maintainers too. Whoever opens the Content Manager six months from now sees no difference between the titles. Documenting the scheme is part of the job, not an extra.
• It is fragile against copy-paste. Renaming a group by retyping the title silently removes the prefix and moves the group.
• It must stay aligned with translations, as seen above, for every active language.

For very large sets of groups, or ones subject to frequent reorganisation, beyond moving to pages and spaces it is always worth reducing the number of groups on the home page and delegating fine-grained navigation to search. A "perfect" order across twenty groups solves fewer problems than a home page with five well-chosen groups.

In summary

In the SAP Build Work Zone Fiori Launchpad, group and tile ordering is alphabetical and cannot be changed through configuration. The only lever is the title: prepending a decreasing number of hair spaces (U+200A) produces the desired order without visually altering the interface. The prerequisite for the trick to hold is replicating the prefixes across all active translations, because when a translation exists it is the one that drives sorting. It should still be treated for what it is: a pragmatic solution to be documented and verified at every release. If instead ordering is a non-negotiable requirement, the structural answer is pages and spaces — including in the new user experience — accepting the loss of group management in return.

Useful references when you need to justify the choice in a design review: SAP KBA 3102280, which documents the group sorting rules.