Frédéric Vercaemst

Several UI related properties (Tooltip, ApplicationArea, ...) are part of page objects only, forcing developers to maintain / duplicate these properties on the entity card page, the entity list page(s), ... It would be beneficial if these properties would be available at table / field level, so page objects can inherit the property (similar to how captions have been implemented). Examples: - Allowing specification of 'Tooltip' property on a table field would allow developer to specify tooltip only once and allow all pages containing the field to inherit the 'Tooltip' table field property (when not specified on page field controls) - When a user 'designs' a page by adding new table fields, tooltips would be immediately available. - Provide platform support to retrieve the table field tooltip via 'Rec.Tooltip(FieldNo)' (similar to Rec.Fieldcaption()). This would allow developers to reuse tooltip definitions (usefull on page field controls with sourceExpression = RecordVar.Field). - Allowing specification of 'ApplicationArea' property on a table field would allow developer to specify ApplicationArea only once and allow all pages containing the field to inherit the 'ApplicationArea' table field property (when not specified on page field controls) - When a user 'designs' a page by adding new table fields, ApplicationArea would be immediately available.

Using 'ApplicationArea' (set by the 'Experience Tier') we can remove certain UI elements from the user / exclude objects from the 'Tell Me' search results. This applies to page, field controls, reports, ... We would like to get 'ApplicationArea' support on other object types as well: - Enum values : this would allow us to exclude certain values from enum lists from being shown (and avoid complex structures using Option Lookup Buffer) - Profile : if an app contains X profiles, only the profiles with a matching / enabled 'ApplicationArea' would become available for the end user. This would allow us to ship one app containing various profiles and - based on the 'ApplicationArea' - enabled/disable some.

Short: Page 9179 "Application Area" must be editable In Business Central, a user experience can be chosen by setting the 'Experience Tier' to Essentials or Premium. Based on this, different 'areas' in the application will be enabled / disabled. When application areas are disabled, this feature is hidden from the user, providing a better experience. (less controls / actions on pages, ...) We would like to take the 'Experience Tier' and step further, allowing users to toggle application areas individually (within the boundaries of the 'Experience Tier'). This would allow customers to disable e.g. Dimensions, Intercompany, Jobs, .... if not used. The same applies for ISV's with one solution / one code base covering lots of areas. Toggline application areas would allow us to provide a more fine-grained setup of the user experience. Remark: Seems like the 'custom' experience was intended for this, although it does not work. Additional references: https://github.com/microsoft/ALAppExtensions/issues/7216 https://www.yammer.com/dynamicsnavdev/#/Threads/show?threadId=533310825242624

The new 'Peek Experience' allows users to easily navigate to the related card page, based on the TableRelation / LookupPageId and the CardPageId of the linked table. The system contains various setup tables / referential data (e.g. Payment Methods, Payments Terms, ...) that only have a listpage - with no cardpageId linked (there's simply no card, but an editable list instead to manage data). In earlier versions, we were able to use drilldown > Advanced ... to get the list page opened, whereas in the webclient this is no longer possible. It would be great if the 'Peek Experience' for these entities offered the same experience, so the user can drill-through - with a hyperlink - to the list page of the entity.