Page History

...

• 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.

Accessibility

...

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.