Best Of

Hello @Product Management Team ,

I’d like to raise an enhancement request regarding attachments stored in BLOB cubes and downloaded from a Data View.

Current behavior (pain point)
When a user downloads a PDF via the attachment icon, the generated filename is not the original uploaded file name. Instead, it is automatically set to the member of the first Entity placed “By Row” in the Data View layout.

In practice, this is confusing for end users when they download multiple documents from the same Data View:

• filenames look similar or misleading
• users often need to open each file to confirm what it is
• they then have to manually rename files one by one (or risk keeping the wrong naming), especially if they didn’t notice the active selection at download time

Also, the original filename is never preserved when loading a file into a BLOB cube, which makes the situation worse.

Proposed enhancement
Provide an option to define the downloaded filename, ideally by allowing a dynamic naming pattern based on the Data View context, such as:

• concatenation of the “By Row” entity members (e.g., Customer + Period + Document Type)
• a configurable filename template like:
  Customer_Period_DocType.pdf
• optionally, keep the original uploaded filename as part of the template (if stored/available)

This would make each downloaded document immediately identifiable without extra manual steps.

Why this matters (additional value for broadcasting)
This becomes even more important with Broadcasting. If attachment filenames could be dynamically generated based on the data context used in the Advanced broadcasting rule, users would instantly understand what the attachment contains and why they received it — improving adoption and reducing back-and-forth.

Expected benefits

• Better end-user experience and trust
• Faster processing (no manual renaming / validation loops)
• Clearer broadcasting outputs and improved communication

Happy to share concrete customer examples and naming patterns we see in the field if helpful.

Kind regards,
Kevin

Hello team,

I expect to be considered enhancement of a tool to reduce the workload involved in verifying/testing after the version upgrade.

The desired functionality includes exporting and comparing positional information and setting values displayed on the screen. If it is difficult to provide comparison feature, using a third-party tool could be an option like diff tool apps. The goal is to make it easier to identify differences that occur after the upgrade, thereby reducing the manual effort required.

Additionally, improvements that enable output of configuration information to enhance work efficiency would be beneficial for our customers. These outputs could also serve as reference or design documentation, providing further advantages for the project.

Thank you for your consideration.

Masa,

Problem / Motivation

Building and maintaining Board data models, rules and capsules is becoming increasingly complex.
While Board offers powerful modeling capabilities, development is still mostly manual and UI-driven.

At the same time, modern software development is evolving rapidly:

• Requirements, architecture and code are increasingly created with AI support
• Teams work with agent-based workflows (Product Owner, Architect, Developers, Testers)
• Git repositories act as the single source of truth
• Automated tests protect systems against regressions and upgrades

Today, Board solutions cannot fully benefit from these approaches.

Core Idea

Enable AI-driven development of Board applications, where:

• Board metadata is treated as Model-as-Code
• A Git repository is the single source of truth
• Board ALM manages the lifecycle between Git and Board environments
• AI agents collaborate to design, implement and test data models and capsules

1) AI Agent-Based Development Model

Instead of manually creating everything in the Board UI, development starts in a Git repository.

An AGENTS.md file defines the AI agents involved, for example:

• Product Owner Agent
  Translates business goals into user stories and acceptance criteria
• Solution Architect Agent
  Defines data model structure, calculation concepts and design decisions (ADRs)
• Backend Developer Agent
  Implements data models and calculation rules as metadata JSON
• Backend Tester Agent
  Creates test datasets and automated tests for calculations
• Frontend Developer Agent
  Designs capsules, layout and navigation as metadata
• Frontend Tester Agent
  Validates capsule structure and basic UI behavior

Each agent works on clearly defined artifacts in the repository.

2) AI-Generated Artifacts (Concrete Example)

With AI support, a typical flow could look like this:

1. Product Owner Agent
   • Creates user stories and business rules (Markdown)
2. Solution Architect Agent
   • Defines the target data model
   • Documents architectural decisions (ADR)
3. Developer Agents
   • Generate Board metadata as JSON strictly validated against versioned JSON Schemas:
     • Databases, dimensions, cubes
     • Calculation rules
     • Capsules (pages, layout, navigation)
4. Tester Agents
   • Generate test cases:
     • Input data
     • Expected calculation results

All artifacts are versioned and reviewable in Git.

3) Git-First + ALM Lifecycle

The Git repository is the single source of truth.

Git → Board

• ALM deploys AI-generated or manually edited metadata into DEV / TEST / PROD
• Changes are transparent and reproducible

Board → Git (Explicit Publish / Promote)

• Manual UI changes are allowed in DEV
• Changes are committed back to Git only after an explicit publish/promote step
• This ensures clean versioning and governance

4) Automated Testing as a First-Class Citizen

AI agents can also generate and maintain tests:

• Runtime regression tests can be executed in Board by running a Procedure that materializes results via “Extract all Cubes” (CSV export) and comparing the exported CSV snapshots against expected baselines in CI.
• Test execution after:
  • Metadata changes
  • Board upgrades
• Test Layers
  • Schema validation (fast): every generated/edited JSON must validate against the repo’s schemas
  • Lint / best-practice checks (custom): naming, forbidden patterns, performance heuristics
  • Runtime tests: golden datasets + expected calculation results in Board/CI environment

Tests become part of the standard ALM pipeline, increasing trust in the solution.

5) Why This Is More Than “Just Automation”

This approach enables:

• Faster solution design through AI assistance
• Higher quality through systematic testing
• Knowledge preservation (design decisions don’t live only in people’s heads)
• Safer upgrades and refactoring
• Reusable and composable Board solution components

Suggested MVP

1. JSON-based metadata export/import + versioned JSON Schemas for:
   • Data models & rules
   • Capsules (layout & navigation)
2. CI pipeline: schema validation + custom rule checks on every PR
3. ALM Git integration (pull/deploy + commit on publish)
4. Git-first governance model
5. Basic automated calculation tests (e.g., golden datasets + Procedure-based CSV snapshots via “Extract all Cubes”)
6. Reference AI agent workflow (documentation & examples)

Long-Term Vision

Board could evolve from a UI-centric modeling tool into a platform that supports:

• AI-assisted application design
• Professional DevOps practices
• Scalable enterprise solution development

This would make Board even more attractive for both business users and modern data / software engineering teams.

Design Considerations

• Stable, deterministic metadata representation
• Clear agent responsibilities
• Guardrails for AI-generated models (naming, performance, best practices)
• Schema-first guardrails
  • JSON Schema as contract: schemas define required fields, enums, naming patterns and versioning for every artifact type (model, rules, capsules).
  • Repo as single source of truth: schema changes are reviewed like code (PRs), enabling safe evolution of the metadata format.
  • Custom validators for cross-file constraints: referential integrity (IDs, links) and domain rules run in CI in addition to schema validation.
• Clear conflict resolution between Git and UI changes

This approach does not replace the Board UI – it complements it with AI-driven, version-controlled and testable development workflows.

Hello team,

Let me post the idea of "the variety of line styles for the Cartesian graph".

Customer would like to choose dashed or dotted line as line style.

Especially, it is benefit to use monotone printing the graph or easy to identify the each lines.

Could you please consider this feature in new release?

Masa,

Encryption of data sent or received from Board via SFTP / Azure Storage in flat files

Ability to Align Headers Left/Right/Center, in Header box of Printable report PDF. As of now, the left box is left aligned, centre box is centre aligned and right box is right aligned as default. But in the requested CR, we will need right box as centre aligned as we are using address in the header.

Hi
Would it be possible to have a new diagram/chart type added to Board like a Sankey diagram. It provides a way to display information through pipes that represent the financials by type/department (for example). See example below:

Hi all,

I love the additional features added in B14 to quickly format objects on a screen.

Something that I am still missing and would be a huge improvement to reduce the amount of repeated actions is the ability to add / subtract values in the position and size option. When you need to move multiple objects that don't align with eachother you currently either have to do it by eye with the help of the red anchorpoints - which is inaccurate most of the time - or use the direction keys.

Best,

Remo