Best Of

CONTENT

1.1 Display an image stored in the Azure Storage

Displaying images stored in Azure Storage directly in Board is possible by dynamically constructing the URL according to the File Storage public access schema. The integration leverages the algorithm blocks to concatenate the relevant URL components

Each image is accessed through this URL structure:

https://$STORAGE_ACCOUNT.file.core.windows.net/$SHARE_NAME/$DIRECTORY_PATH/$FILE?$SAS_TOKEN

Note that only HTTP or HTTPS protocols are supported for image rendering in Board.

1.2 How to Build It in Board

Define URL Components in Separate Text Algorithms

Create five text algorithms in your layout to represent each part of the Azure URL:

Each algorithm block returns a single text value

Build the Dynamic Picture algorithm that concatenates the five text algorithms:

$STORAGE_ACCOUNT & $SHARE_NAME & $DIRECTORY_PATH & $FILE & $SAS_TOKEN

Use this algorithm in the layout of a Label or Card and your Azure image appears dynamically in Board.

Below an example of Layout configuration to display the stored image: 

Retrieve the SAS token from the SAS URI

!!! Be cautious: Displaying or exposing a SAS token in text is a potential security risk, because it effectively acts as a temporary key that grants access to the Azure Storage resources.

Azure storage : 

1.3 Conclusion

Displaying images from Azure Storage in Board is a good alternative to storing them directly in the data model. By dynamically building HTTPS URLs through text algorithms or cubes, you can keep your data model lighter while still enriching dashboards with secure, cloud-hosted visual content.

Author: Amruta Shaha, Senior Consultant for Board.

This article takes a deep dive into the Smart Import Object facility in Board, exploring how and when to use it in place of Data Readers, the different modes of import available, and practical scenarios where formula-based imports can unlock real value. While existing resources already cover the fundamentals, this piece is designed to go further—highlighting additional areas and advanced applications. The aim is to help readers configure Smart Import not just for reading Cube or Entity values, but to fully leverage its solution-driven capabilities in tackling complex business cases.

Existing Useful Articles as a pre-read:

• Smart import Object
• New training for the Smart Import Objects tool - Board Community
• How to hide/ignore columns of an Excel data source when using the Smart Import Object - Board Community

When to use: Smart Import Vs Data Reader

1. End User in play mode can populate entity members/cube with Excel-like interface through file upload / copy paste on screen from their local machine directory as source
2. Users can see the errors on screen on failed upload

Not useful for:

1. Admin activities for mass uploads/scheduled batch uploads
2. Procedure based data reading
3. Migration activities/multiple period and cubes massive updates/application-level updates or changes needing huge database updates

Smart Import modes of data upload

A frequent question about Smart Import is: “What happens if I upload the same file more than once?”

The answer depends on the configuration mode—Add, Replace, or Merge—and each handles repeated imports differently. Using an inventory stock cube with dimensions Month and Category, the table below shows how the data behaves under each mode when the same file is imported multiple times.

Upload 1

Upload 2

Resulting Cube Value

From above it is clear that Merge option will be more favored in configuring the smart import.

Add option will be used when the users are aware that each upload increments the existing values (they can then adjust by uploading negative values to adjust).

Replace mode is to be carefully used as any member entity not in the upload data is zeroed if it already holds some value. Replace mode recommended to be used with active selections / discard outside selection mode on so that any entity members that are outside the active selections are not zeroed down.

To note however even with discard outside selection mode on, any absent combination in the new upload will zero down existing value present on that combination.

Example in above month selection could be 202501 and category selected could be all 1, 2, 3. In that case the second upload will nullify/zero out the value existing on combination 202501 as month and 2 as category.

Use case for advanced Auto Incrementation / Serialized numbering (Using procedure trigger for Data reader from Smart Import):

When an entity is made auto incremental, each new upload increments the number from the last upload. The database entity member list is checked in the backend to have new smart import upload place the incrementation to next number.

Example: creating new Employee ID. The employee ID is to be system generated as auto incremented but also to include the department. This can be achieved by Smart import of a stage cube, Stage cube with dimensions – Department and Auto Incrementing Entity and Name, Cube fixed value = 1.

Additionally, setting a trigger on smart import object that on the save action will extract the cube and data read the Emp ID entity concatenating Increment ID and Department ID for the required name as a mapping cube.

The Auto incrementation can also be triggered for backend data read processing where the serialization needs to be from a higher “Start” number example if the series starts with “5000000” and the records uploaded are first 100, the formula in the data read trigger procedure can be 5000000 + the column for value of auto incrementation in the ETL function of Data reader.

To note, the auto incremental entity used in smart import to also have equal code width as the final series entity so that the above addition updates the series at higher numbers too (for example when it reaches 5999999, to increment to start with 6000000.

The setup in ETL will look as below:

And result as:

This is to address the limitation of Smart Import that only existing column header name of the excel like layout in play mode of the smart import object can be referenced in the [@....] formula and at the same time the auto incremental entity cannot reference any such play mode column header, it needs to be mapped as fixed/formula in the configuration.

Multi step calculations

Except auto incrementation to overcome smart import limitation of being able to reference only frontend column headers in formula i.e. [@Column Header …], Users can handle multi step calculations using combination of frontend column excel like formulas + backend mapping configuration.

Consider the below case as example: we need to calculate Net Amount with slab discount:

Step 1: Calculate Basic Amount

• Qty × Rate = Amount
• e.g., 15 units × 120 = 1800

Step 2: Apply Slab Discount

• If Amount > 1500, discount = 10% of Amount
• Net Amount = Amount – Discount
• e.g., 1800 – 180 = 1620

We can add the Basic pre Discount Amount in the front end of the smart import (Users will upload Qty and Rate in this example).

In design mode, the amount column will be added with formula as below to simplify the steps:

In backend mapping configuration of the smart import, the cube can be mapped to formula as:

=if([@Amount (Calc)]>1500,[@Amount (Calc)]*90%,[@Amount (Calc)])

Conditional value based on other columns value (Dependent Dynamic value)

There are many uses for using formula based on another column reference.

Example: default value for blanks example if Department is not provided, the default value to take is “Operations” (Ensure that department entity has the member “Operations”.

While populating the dimension Department for the cube, and if the play mode column header is “Dept.”, you can use the formula if([@Dept .]="","Operations",[@ Dept .])

Above is used to populate default entity member. The same approach can be used to populate cube values and dependent calculated cube values from the formulas.

Example if column headers populating cubes are “Qty” and “Amount”, then the rate cube can be derived using formula =([@Amount .]/[@Rate ])

Importing non Board format Date can also be achieved in Smart Import configuration.

This is especially useful when Users need to upload files downloaded from their ERP or other systems.

Example: if we need to populate cube at month level with data at date level, as in below samples where each row is for 02nd January 2025 in different date formats, the formulas to achieve board month identifier format is as below:

Use Cases for Smart Import Validations:

The smart import Validations are useful tool to further guide and control incoming data with enhanced error messages, the validation option is found on the right panel:

They can be used to validate cube value/entity value. The reference follows same syntax [@Column header ].

For example, for controlling the month value for allowing only 202501 onwards data, the configuration used is as below:

Similarly cube values can also be validated for example negatives not allowed (>0 as True) else user message: “Negative Values not allowed”.

This tool can also be used with Multiple validations running parallel, but to note that the validation refers to only the column headers from the play mode. So any dimension / cube populated other than the column header reference in the smart import configuration (like mapped as fixed or formula) cannot be used in validation the [@....] can only be a reference to the column header of the play mode format of the smart import.

Suggested Values

Suggested Values can be used for popping up a list of drop down to select the values from, this can be used for both cubes and entities.To note, if a parent hierarchy is added in suggested value and the child entity is mismatched in the smart import, the relationship will be overwritten as per the smart import. Also adding parent as a preceding column will not limit dynamically the suggested values of the child entity column.

Smart Import is not just a convenience feature; it’s a design choice that can fundamentally change how you manage data in Board. By learning when to use it instead of Data Readers, mastering the behaviors of Add, Replace, and Merge, and applying advanced formulas with validation, you’ve gained the ability to transform Smart Import into a solution engine rather than a simple input tool.

The aim of this article was to show that Smart Import is not only for reading Cube or Entity values as is, but also a tool that can support more complex business cases.As a next step, try applying these concepts in your own models and see the difference. And if you’ve discovered unique ways to use Smart Import, share them in the comments — your ideas could help others explore new possibilities.

Thanks @Anastasia Vladimirova for this content.

1. Abstract

Rules applied to an Entity are widely used in Board to support aggregation logic within reporting structures. A common example is a P&L Reporting Line entity, where rules allow users to calculate and aggregate specific reporting categories.

When working with such rules, it is critical to understand how entity sorting impacts both the display of members and the results of rule calculations.

Although entity members may be loaded in one order, a SORT setting can reorder them, creating discrepancies between the underlying member sequence and the visible order. This can affect:

• How members appear to the user
• Which members are included in rule-based operations
• How data moves between cubes during procedures, especially via Dataflows

In particular, rules that use a SUM range (e.g., SUM([Member1]:[MemberN])) can produce inconsistent results when sorting differs across models or cubes.

2. Context

Assume we have a P&L report based on a cube where a rule is used to calculate aggregated results. We now want to create a dashboard that uses a new set of dashboard cubes, and the rule logic needs to work identically in this new environment.

If the original rule relies on positional logic—such as SUM ranges—the calculations in the dashboard cubes may differ from those in the original report due to differences in entity sorting or cube structures.

3. Content

To ensure rule evaluations behave consistently when data flows from one cube to another (e.g., Reporting → Dashboard), rules should be constructed using explicit, member-by-member aggregation rather than SUM ranges.

Example (Avoid):

SUM([Member1]:[MemberN])→ This depends on the entity's internal order, which may be modified by SORT settings.

Example (Recommended):

[Member A] + [Member B] + [Member C] + …→ This method is order-independent and ensures stable results across cubes, regardless of sorting differences.

HINT:

If you need to transition existing rules, one way is to use ChatGPT using a similar prompt to the image

Please note:

1. It is VERY important to tweak the prompt in order to fit the structure of your file. Check if different coding structure is being used, or any other formulas rather than SUM.
2. ALWAYS check the output file, since AI isn’t perfect

4. Conclusion

• Avoid SUM range functions in Rules: Do not use SUM([Member1]:[MemberN]) when defining rules for entities that may have custom sorting. SUM ranges rely on positional order, which can break when sorting differs between members.
• Use explicit member aggregation: Always write rules as:[Member A] + [Member B] + [Member C] + …This ensures consistency and prevents incorrect aggregation in Dataflows or dashboard cubes.
• Validate entity sorting before creating Rules: Confirm whether an entity uses a custom SORT configuration. Since SORT can change the runtime ordering of members, it may influence which members are included in rule calculations.
• Test rule behavior across cubes: When data is pushed from a source cube to a target cube (e.g., Reporting → Dashboard), verify that the rule’s output matches expectations in both cubes.

Incorrect use of SUM ranges can lead to unexpected results when saving a rule to a new cubes. By adopting explicit member-by-member aggregation and validating entity configurations, users can ensure that rule results remain consistent across cubes and throughout Dataflows.