How to Name Calculated Fields and Parameters Like a Pro

Following our guide on naming dashboard chart titles, let's look at another crucial factor that affects efficiency for dashboard creators: naming calculated fields and parameters.

Unlike default fields in a data source, custom calculations and parameters require clear naming conventions. Establishing these rules from the start drastically reduces the time spent searching for the right items among countless fields. Here are some of the most widely used best practices in the field.

1. Fields Displayed on the Screen: Name Them as They Will Appear

For fields that will be directly exposed to users—such as in tooltips, axis labels, or table headers—it is best to use the exact name you want to display on the dashboard.

If you use complex names like 'Calc_Sales_01' for developer convenience, you will have to do extra work to change aliases or header texts when placing them in the view. Creating fields with intuitive, final names like 'Sales' or 'Total Revenue' from the beginning minimizes this unnecessary repetition.

2. Parameters: Use English and Prefixes

It is highly recommended to write parameter names in English to ensure dynamic interactions work flawlessly.

Parameters often interact with development languages (like JavaScript APIs) when a dashboard is embedded in a web page, or when values are passed through URL Actions after being published to a server. Using non-English characters or special symbols can cause encoding errors or prevent the code from functioning correctly.

• Use Prefixes: Since parameters can easily be mixed up with calculated fields, it is an industry standard to add a prefix like p. or Param_.
• Formatting: Use developer-friendly formats like CamelCase or snake_case instead of spaces to ensure safety.
  • Recommended: p.SelectMeasure, Param_StartDate
  • Not Recommended: p. Select Measure

3. Filters and Specific Purpose Fields: Group by Symbols

Most BI tools automatically sort fields alphabetically. For fields used specifically as 'filters' or temporary placeholders rather than for visual display, adding a specific symbol at the beginning keeps them neatly grouped together for easier management.

• Filter Fields: Use f. or _ to group them at the top or bottom of your data pane. (e.g., f. Top 10 Customers, _Date Filter)
• Temporary/Test Fields: For fields that are a work in progress or need verification, use z_ to send them to the bottom of the list. (e.g., z_Test_Sales_Calc)

4. Specify Aggregations and Data Types

It is helpful to establish rules so that you can tell just by looking at the name whether a calculation already contains an aggregation function (SUM, AVG, etc.), or if it returns a ratio or a boolean value. This prevents critical errors, such as accidentally re-aggregating a ratio in the view.

• Specify Aggregation: Avg. Profit Margin, Total Sales
• Ratios and Differences: Unify suffixes for Year-over-Year (YoY) or Month-over-Month (MoM). (e.g., Sales YoY, Traffic MoM)
• Booleans: Start calculations that return true/false with is_ or has_ to improve intuition. (e.g., is_Profitable, has_Discount)

5. Indicate Complex Calculations (e.g., LODs)

Clearly distinguishing fields containing Level of Detail (LOD) expressions (Fixed, Include, Exclude) or complex table calculations from regular fields is highly beneficial, especially when collaborating with others.

• Examples: LOD_Customer First Purchase Date, TC_Moving Avg Sales

Clear naming conventions speed up your workflow when working alone and serve as excellent tools for smooth communication during collaboration. Use this guide to build a clean and manageable data environment that fits your needs.