(this page was created automatically. In case of formatting issues, please visit the official Wiki Page)

Boardlet

Overview

• Dynamic Boardlet is automatically created when a boardlet from the app boardlet library is used.
• It provides a consistent framework with header, body, and footer sections.
• Each section can hold other dynamic components.

Specs

General Tokens

Boardlet Sections Tokens

Structure

(Configured in General Properties)

• displayName – sets the display name of the component shown in the structure panel. For example, "Customer Dashboard" allows for easy identification of the boardlet’s purpose in the component structure.

Header

Appears at the top of the boardlet and typically includes:

• titleTranslations/title – the main heading text for the boardlet, which can be localized through translations.
• moreIconVisible – controls whether an overflow menu icon appears in the header.
• leftIcon – an optional icon displayed at the left side of the header.
• rightIcon – an optional icon displayed at the right side of the header.
• elements – an array of components to display in the header, typically including action icons or menus.
• layout – controls whether elements are arranged horizontally or vertically within the header.

Body

The body section is the main content area of the boardlet and can contain any combination of components:

• elements – an array of dynamic elements to be displayed in the body section.
• layout – controls whether elements are arranged horizontally or vertically within the body.

Footer

The footer section appears at the bottom of the boardlet and typically includes action buttons:

• elements – an array of components to display in the footer, typically button components.
• layout – controls whether elements are arranged horizontally or vertically within the footer.

Styling

(Configured in Visual Properties)

• title – the shown title of the element.
• boardletNameTranslations – defines the displayed name of the boardlet in different languages. Example: {"en-US": "Customer Insights", "de-DE": "Kundeneinblicke"} ensures proper localization of the boardlet name.
• layout – determines how elements are arranged within the boardlet. Options include horizontal (elements side by side) or vertical (elements stacked).
• scrollingEnabled – enables internal scrolling for the boardlet content. Content exceeding the height becomes scrollable.
• showHeader – controls the visibility of the boardlet header section.
• showFooter – controls the visibility of the boardlet footer section.

Actions & Variants

(Configured in Events)

• events – configures the events that the component can trigger and respond to.
• ON_INIT – triggered when the boardlet component is initialized. Can be used to perform setup operations like loading initial data.
• ON_DESTROY – triggered when the boardlet component is removed from the DOM. Useful for cleanup operations and releasing resources.

(Configured in Visual Properties)

• boardletType – sets the visual style of the boardlet. Options include Normal (standard bordered container) or Ghost (borderless container).

Tests

(Configured in Testing Hooks)

• dataTestId – sets the testing hook ID for automated testing. For example, setting it to "customer-dashboard-boardlet" allows test scripts to reliably locate this component.

Authorization

(Configured in Authorization)

• visibilityPolicySetId – determines the visibility of the component based on specified policy sets. For example, setting it to "adminOnlyPolicy" restricts the boardlet to users with admin privileges.

Guidelines

Header / Toolbar

• Every boardlet must always include a toolbar on the right side.
• The toolbar can exist in two variations:
• First actionbar – actions that affect the boardlet itself.
• Second actionbar – actions that affect the content inside the boardlet. Always separated by a dividing line and cannot exist alone.
• Limit toolbars to three visible actions. Additional actions must be grouped into an overflow menu under the “more” icon.
• The “more” action is mandatory in every boardlet toolbar.

Footer

• The footerbar always controls the workflow of the boardlet.
• Workflow-related actions are always placed at the bottom right. Hierarchy flows from bottom right to bottom left.
• Allowed footerbar layouts:
• Tabs only.
• Tabs with buttons (maximum two).
• Buttons only (maximum two).
• Tabs with actionbar (secondary option, e.g., kiosk mode).
• The footerbar has a fixed height and may never be multiline.

Usage

• Create a three-part frame for content that needs a header, body, and footer by toggling section visibility (showHeader, showFooter) and placing components into the corresponding arrays (elements.header[], elements.body[], elements.footer[]).
• Pick the visual emphasis that matches the page context by setting boardletType to Normal (bordered) for stronger separation or Ghost (borderless) when the Boardlet should blend into surrounding content.
• Keep the header action area compact: place at most three immediate actions in elements.header[] and expose the rest via the mandatory overflow by setting moreIconVisible: true.
• Use the footer only for workflow-related actions or tabs. If there is no workflow, hide the region (showFooter: false) so the layout stays clean.
• Provide a clear, localized identity: set a human-readable builder label with displayName, a localized product-facing name with boardletNameTranslations, and a localized header title with titleTranslations/title (the visual title reads from these values).

Sizing & Layout

• Choose the overall arrangement using the root layout (horizontal for side-by-side sections or vertical for stacked presentation), and refine placement inside each region using the section-level layout on header, body, and footer.
• Prevent clipping when content grows by enabling internal scrolling with scrollingEnabled: true; this preserves container height and reduces layout shifts.
• Reduce visual noise by hiding unused chrome (showHeader: false, showFooter: false) instead of leaving empty regions.
• Provide quick, recognizable affordances in the header by configuring leftIcon and/or rightIcon with symbols that match the Boardlet’s purpose (e.g., info, settings).

States & Feedback

• Switch visual style by changing boardletType (Normal ↔ Ghost) to communicate emphasis without altering content.
• Control presence of major regions at runtime with showHeader and showFooter to reflect task needs (e.g., hide footer after workflow completes).
• Expose additional actions via overflow by toggling moreIconVisible; when true, users have a stable “more” entry point even when visible actions are limited.

Interactions & Events

• Prepare the Boardlet on first render using events.ON_INIT (e.g., preload data, compute whether showFooter should be true, prime any section layout decisions).
• Release resources and listeners on teardown with events.ON_DESTROY to keep the UI responsive and stable over time.
• Provide deterministic automation hooks for QA and a11y testing with dataTestId so scripts can reliably target the Boardlet across builds.

Data-Driven / Conditional Behavior

• Keep the layout steady while data updates by relying on scrollingEnabled: true and stable section layout values; avoid toggling showHeader/showFooter mid-session unless essential, and prefer making those decisions once during ON_INIT.
• If the number of header actions varies with data, keep visible actions capped by limiting elements.header[] and depend on moreIconVisible: true for overflow consistency.

Visibility & Authorization

• Restrict who can see the Boardlet by supplying visibilityPolicySetId; when a user doesn’t match the policy, the component remains hidden, preventing accidental exposure of content or actions.

Content & Localization

• Localize all user-facing copy with boardletNameTranslations and titleTranslations/title to match the user’s locale; keep labels short and specific so truncation is unlikely in tighter layout configurations.
• Use displayName for internal structure-panel clarity without changing end-user text; this helps maintain a clean authoring experience across large boards.

Dos & Don’ts

Accessibility

Protocol of implemented accessibility measures

• Provide localized output to assistive tech by filling boardletNameTranslations and titleTranslations/title for all supported locales.
• Maintain predictable reading and navigation order by keeping section visibility (showHeader, showFooter) and section layout stable during interaction.
• Ensure overflow actions remain discoverable by enabling moreIconVisible, so important commands are reachable without shrinking targets.
• Expose dataTestId to support automated accessibility checks and regression testing.

Practices to improve accessibility

• Avoid using color alone to convey meaning; augment with recognizable leftIcon/rightIcon and clear titleTranslations/title text.
• Reduce focus jumps by avoiding mid-session toggles of major regions; prefer configuring showHeader/showFooter once during events.ON_INIT and managing long content with scrollingEnabled.