System Rules (Data Model)

The default system rules that are evaluated automatically include the following:

Rule Name	Rule Description	Source
[Performance] Do not use floating point data types	The "Double" floating point data type should be avoided, as it can result in unpredictable roundoff errors and decreased performance in certain scenarios. Use "Int64" or "Decimal" where appropriate (but note that "Decimal" is limited to 4 digits after the decimal sign).	Microsoft
[Performance] Set IsAvailableInMdx to false on non-attribute columns	To speed up processing time and conserve memory after processing, attribute hierarchies should not be built for columns that are never used for slicing by MDX clients. In other words, all hidden columns that are not used as a Sort By Column or referenced in user hierarchies should have their IsAvailableInMdx property set to false. Reference: https://blog.crossjoin.co.uk/2018/07/02/isavailableinmdx-ssas-tabular/	Microsoft
[Performance] Avoid bi-directional relationships against high-cardinality columns	For best performance, it is recommended to avoid using bi-directional relationships against high-cardinality columns. In order to run this rule, you must first run the script shown here: https://www.elegantbi.com/post/vertipaqintabulareditor	Microsoft
[Performance] Reduce usage of long-length columns with high cardinality	It is best to avoid lengthy text columns. This is especially true if the column has many unique values. These types of columns can cause longer processing times, bloated model sizes, as well as slower user queries. Long length is defined as more than 100 characters.	Microsoft
[Performance] Split date and time	This rule finds datetime columns that have values not at midnight. To maximize performance, the time element should be split from date element (or the time component should be rounded to midnight as this will reduce column cardinality). Reference: https://www.sqlbi.com/articles/separate-date-and-time-in-powerpivot-and-bism-tabular/	Microsoft
[Performance] Large tables should be partitioned	Large tables should be partitioned in order to optimize processing. In order for this rule to run properly, you must run the script shown here: https://www.elegantbi.com/post/vertipaqintabulareditor	Microsoft
[Performance] Reduce usage of calculated columns that use the RELATED function	Calculated columns do not compress as well as data columns and may cause longer processing times. As such, calculated columns should be avoided if possible. One scenario where they may be easier to avoid is if they use the RELATED function. Reference: https://www.sqlbi.com/articles/storage-differences-between-calculated-columns-and-calculated-tables/	Microsoft
[Performance] Consider a star-schema instead of a snowflake architecture	Generally speaking, a star-schema is the optimal architecture for tabular models. That being the case, there are valid cases to use a snowflake approach. Please check your model and consider moving to a star-schema architecture. Reference: https://docs.microsoft.com/power-bi/guidance/star-schema	Microsoft
[Performance] Model should have a date table	Generally speaking, models should generally have a date table. Models that do not have a date table generally are not taking advantage of features such as time intelligence or may not have a properly structured architecture.	Microsoft
[Performance] Date/calendar tables should be marked as a date table	This rule looks for tables that contain the words 'date' or 'calendar' as they should likely be marked as a date table. Reference: https://docs.microsoft.com/power-bi/transform-model/desktop-date-tables	Microsoft
[Performance] Remove auto-date table	Avoid using auto-date tables. Make sure to turn off auto-date table in the settings in Power BI Desktop. This will save memory resources. Reference: https://www.youtube.com/watch?v=xu3uDEHtCrg	Microsoft
[Performance] Avoid excessive bi-directional or many-to-many relationships	Limit use of b-di and many-to-many relationships. This rule flags the model if more than 30% of relationships are bi-di or many-to-many. Reference: https://www.sqlbi.com/articles/bidirectional-relationships-and-ambiguity-in-dax/	Microsoft
[Performance] Limit row level security (RLS) logic	Try to simplify the DAX used for row level security. Usage of the functions within this rule can likely be offloaded to the upstream systems (data warehouse).	Microsoft
[Performance] Consider using aggregations if using Direct Query in Power BI	If using Direct Query in Power BI Premium, you may want to consider using aggregations in order to boost performance. Reference: https://docs.microsoft.com/power-bi/transform-model/desktop-aggregations	Microsoft
[Performance] Minimize Power Query transformations	Minimize Power Query transformations in order to improve model processing performance. It is a best practice to offload these transformations to the data warehouse if possible. Also, please check whether query folding is occurring within your model. Please reference the article below for more information on query folding. Reference: https://docs.microsoft.com/power-query/power-query-folding	Microsoft
[Performance] Avoid using many-to-many relationships on tables used for dynamic row level security	Using many-to-many relationships on tables which use dynamic row level security can cause serious query performance degradation. This pattern's performance problems compound when snowflaking multiple many-to-many relationships against a table which contains row level security. Instead, use one of the patterns shown in the article below where a single dimension table relates many-to-one to a security table. Reference: https://www.elegantbi.com/post/dynamicrlspatterns	Microsoft
[Performance] Unpivot pivoted (month) data	Avoid using pivoted data in your tables. This rule checks specifically for pivoted data by month. Reference: https://www.elegantbi.com/post/top10bestpractices	Microsoft
[Performance] Many-to-many relationships should be single-direction	Microsoft
[Performance] Reduce usage of calculated tables	Migrate calculated table logic to your data warehouse. Reliance on calculated tables will lead to technical debt and potential misalignments if you have multiple models on your platform.	Microsoft
[Performance] Remove redundant columns in related tables	Removing unnecessary columns reduces model size and speeds up data loading.	Microsoft
[Performance] Measures using time intelligence and model is using Direct Query	At present, time intelligence functions are known to not perform as well when using Direct Query. If you are having performance issues, you may want to try alternative solutions such as adding columns in the fact table that show previous year or previous month data.	Microsoft
[Performance] Reduce number of calculated columns	Calculated columns do not compress as well as data columns so they take up more memory. They also slow down processing times for both the table as well as process recalc. Offload calculated column logic to your data warehouse and turn these calculated columns into data columns. Reference: https://www.elegantbi.com/post/top10bestpractices	Microsoft
[Performance] Check if bi-directional and many-to-many relationships are valid	Bi-directional and many-to-many relationships may cause performance degradation or even have unintended consequences. Make sure to check these specific relationships to ensure they are working as designed and are actually necessary. Reference: https://www.sqlbi.com/articles/bidirectional-relationships-and-ambiguity-in-dax/	Microsoft
[Performance] Check if dynamic row level security (RLS) is necessary	Usage of dynamic row level security (RLS) can add memory and performance overhead. Please research the pros/cons of using it. Reference: https://docs.microsoft.com/power-bi/admin/service-admin-rls	Microsoft
[DAX Expressions] Column references should be fully qualified	Using fully qualified column references makes it easier to distinguish between column and measure references, and also helps avoid certain errors. When referencing a column in DAX, first specify the table name, then specify the column name in square brackets. Reference: https://www.elegantbi.com/post/top10bestpractices	Microsoft
[DAX Expressions] Measure references should be unqualified	Using unqualified measure references makes it easier to distinguish between column and measure references, and also helps avoid certain errors. When referencing a measure using DAX, do not specify the table name. Use only the measure name in square brackets. Reference: https://www.elegantbi.com/post/top10bestpractices	Microsoft
[DAX Expressions] No two measures should have the same definition	Two measures with different names and defined by the same DAX expression should be avoided to reduce redundancy.	Microsoft
[DAX Expressions] Use the TREATAS function instead of INTERSECT for virtual relationships	The TREATAS function is more efficient and provides better performance than the INTERSECT function when used in virutal relationships. Reference: https://www.sqlbi.com/articles/propagate-filters-using-treatas-in-dax/	Microsoft
[DAX Expressions] Use the DIVIDE function for division	Use the DIVIDE function instead of using "/". The DIVIDE function resolves divide-by-zero cases. As such, it is recommended to use to avoid errors. Reference: https://docs.microsoft.com/power-bi/guidance/dax-divide-function-operator	Microsoft
[DAX Expressions] Avoid using the IFERROR function	Avoid using the IFERROR function as it may cause performance degradation. If you are concerned about a divide-by-zero error, use the DIVIDE function as it naturally resolves such errors as blank (or you can customize what should be shown in case of such an error). Reference: https://www.elegantbi.com/post/top10bestpractices	Microsoft
[DAX Expressions] Measures should not be direct references of other measures	This rule identifies measures which are simply a reference to another measure. As an example, consider a model with two measures: [MeasureA] and [MeasureB]. This rule would be triggered for MeasureB if MeasureB's DAX was MeasureB:=[MeasureA]. Such duplicative measures should be removed.	Microsoft
[DAX Expressions] Filter column values with proper syntax	Instead of using this pattern FILTER('Table','Table'[Column]="Value") for the filter parameters of a CALCULATE or CALCULATETABLE function, use one of the options below. As far as whether to use the KEEPFILTERS function, see the second reference link below. Option 1: KEEPFILTERS('Table'[Column]="Value") Option 2: 'Table'[Column]="Value" Reference: https://docs.microsoft.com/power-bi/guidance/dax-avoid-avoid-filter-as-filter-argument Reference: https://www.sqlbi.com/articles/using-keepfilters-in-dax/	Microsoft
[DAX Expressions] Filter measure values by columns, not tables	Instead of using this pattern FILTER('Table',[Measure]>Value) for the filter parameters of a CALCULATE or CALCULATETABLE function, use one of the options below (if possible). Filtering on a specific column will produce a smaller table for the engine to process, thereby enabling faster performance. Using the VALUES function or the ALL function depends on the desired measure result. Option 1: FILTER(VALUES('Table'[Column]),[Measure] > Value) Option 2: FILTER(ALL('Table'[Column]),[Measure] > Value) Reference: https://docs.microsoft.com/power-bi/guidance/dax-avoid-avoid-filter-as-filter-argument	Microsoft
[DAX Expressions] Inactive relationships that are never activated	Inactive relationships are activated using the USERELATIONSHIP function. If an inactive relationship is not referenced in any measure via this function, the relationship will not be used. It should be determined whether the relationship is not necessary or to activate the relationship via this method. Reference: https://docs.microsoft.com/power-bi/guidance/relationships-active-inactive Reference: https://dax.guide/userelationship/	Microsoft
[DAX Expressions] Avoid using '1-(x/y)' syntax	Instead of using the '1-(x/y)' or '1+(x/y)' syntax to achieve a percentage calculation, use the basic DAX functions (as shown below). Using the improved syntax will generally improve the performance. The '1+/-...' syntax always returns a value whereas the solution without the '1+/-...' does not (as the value may be 'blank'). Therefore the '1+/-...' syntax may return more rows/columns which may result in a slower query speed. Let's clarify with an example: Avoid this: 1 - SUM ( 'Sales'[CostAmount] ) / SUM( 'Sales'[SalesAmount] ) Better: DIVIDE ( SUM ( 'Sales'[SalesAmount] ) - SUM ( 'Sales'[CostAmount] ), SUM ( 'Sales'[SalesAmount] ) ) Best: VAR x = SUM ( 'Sales'[SalesAmount] ) RETURN DIVIDE ( x - SUM ( 'Sales'[CostAmount] ), x )	Microsoft
[DAX Expressions] The EVALUATEANDLOG function should not be used in production models	The EVALUATEANDLOG function is meant to be used only in development/test environments and should not be used in production models. Reference: https://pbidax.wordpress.com/2022/08/16/introduce-the-dax-evaluateandlog-function/	Microsoft
[Error Prevention] Data columns must have a source column	Data columns must have a source column. A data column without a source column will cause an error when processing the model.	Microsoft
[Error Prevention] Expression-reliant objects must have an expression	Calculated columns, calculation items and measures must have an expression. Without an expression, these objects will not show any values.	Microsoft
[Error Prevention] Avoid structured data sources with provider partitions	Power BI does not support provider (a.k.a. 'legacy') partitions which reference structured data sources. Partitions which reference structured data sources must use the M-language. Otherwise, 'provider' partitions must reference a 'provider' data source. This can be resolved by converting the structured data source into a provider data source (see 2nd reference link below). Reference: https://docs.microsoft.com/power-bi/admin/service-premium-connect-tools#data-source-declaration Reference: https://www.elegantbi.com/post/convertdatasources	Microsoft
[Error Prevention] Avoid the USERELATIONSHIP function and RLS against the same table	The USERELATIONSHIP function may not be used against a table which also leverages row-level security (RLS). This will generate an error when using the particular measure in a visual. This rule will highlight the table which is used in a measure's USERELATIONSHIP function as well as RLS. Reference: https://blog.crossjoin.co.uk/2013/05/10/userelationship-and-tabular-row-security/	Microsoft
[Error Prevention] Relationship columns should be of the same data type	Columns used in a relationship should be of the same data type. Ideally, they will be of integer data type (see the related rule '[Formatting] Relationship columns should be of integer data type'). Having columns within a relationship which are of different data types may lead to various issues.	Microsoft
[Error Prevention] Avoid invalid characters in names	This rule identifies if a name for a given object in your model (i.e. table/column/measure) which contains an invalid character. Invalid characters will cause an error when deploying the model (and failure to deploy). This rule has a fix expression which converts the invalid character into a space, resolving the issue.	Microsoft
[Error Prevention] Avoid invalid characters in descriptions	This rule identifies if a description for a given object in your model (i.e. table/column/measure) which contains an invalid character. Invalid characters will cause an error when deploying the model (and failure to deploy). This rule has a fix expression which converts the invalid character into a space, resolving the issue.	Microsoft
[Error Prevention] Set IsAvailableInMdx to true on necessary columns	In order to avoid errors, ensure that attribute hierarchies are enabled if a column is used for sorting another column, used in a hierarchy, used in variations, or is sorted by another column.	Microsoft
[Maintenance] Remove unnecessary columns	Hidden columns that are not referenced by any DAX expressions, relationships, hierarchy levels or Sort By-properties should be removed.	Microsoft
[Maintenance] Remove unnecessary measures	Hidden measures that are not referenced by any DAX expressions should be removed for maintainability	Microsoft
[Maintenance] Fix referential integrity violations	This rule highlights relationships which have referential integrity violations. This indicates that there are values in the table on the 'from' side of the relationship which do not exist in the table on the 'to' side of the relationship. Referential integrity violations will also produce the 'blank' member value in slicers. It is recommended to fix these issues by ensuring that the 'to' table's primary key column has all the values in the 'from' table's foreign key column. Reference: https://blog.enterprisedna.co/vertipaq-analyzer-tutorial-relationships-referential-integrity/	Microsoft
[Maintenance] Remove data sources not referenced by any partitions	Data sources which are not referenced by any partitions may be removed.	Microsoft
[Maintenance] Remove roles with no members	May remove roles with no members.	Microsoft
[Maintenance] Ensure tables have relationships	This rule highlights tables which are not connected to any other table in the model with a relationship.	Microsoft
[Maintenance] Visible objects with no description	Add descriptions to objects. These descriptions are shown on hover within the Field List in Power BI Desktop. Additionally, you can leverage these descriptions to create an automated data dictionary (see link below). Reference: https://www.elegantbi.com/post/datadictionary	Microsoft
[Maintenance] Perspectives with no objects	Perspectives that contain no objects (tables) are most likely not necessary. In this rule, it is only necessary to check tables as adding a column/measure/hierarchy to a perspective also adds the table to the perspective. Additionally, tables in general covers calculated tables and calculation groups as well.	Microsoft
[Maintenance] Calculation groups with no calculation items	Calculation groups have no function unless they have calculation items.	Microsoft
[Naming Conventions] Partition name should match table name for single partition tables	Tables with just one partition should match their table and partition names.Tables with more than one partition should have each partition name starting with the table name.	Microsoft
[Naming Conventions] Object names must not contain special characters	Tabs, line breaks, etc.	Microsoft
[Naming Conventions] Trim object names	Unintentionally leaving a trailing space in an object name is a common occurrence when copying/duplicating objects in Tabular Editor.	Microsoft
[Formatting] Format flag columns as Yes/No value strings	Flags must be properly formatted as Yes/No as this is easier to read than using 0/1 integer values.	Microsoft
[Formatting] Objects should not start or end with a space	Objects should not start or end with a space	Microsoft
[Formatting] Provide format string for "Date" columns	Columns of type "DateTime" that have "Month" in their names should be formatted as "mm/dd/yyyy".	Microsoft
[Formatting] Provide format string for "Month" columns	Columns of type "DateTime" that have "Month" in their names should be formatted as "MMMM yyyy".	Microsoft
[Formatting] Provide format string for measures	Visible measures should have their format string property assigned	Microsoft
[Formatting] Do not summarize numeric columns	Numeric columns (integer, decimal, double) should have their SummarizeBy property set to "None" to avoid accidental summation in Power BI (create measures instead).	Microsoft
[Formatting] Percentages should be formatted with thousands separators and 1 decimal	Microsoft
[Formatting] Whole numbers should be formatted with thousands separators and no decimals	Microsoft
[Formatting] Relationship columns should be of integer data type	It is a best practice for relationship columns to be of integer data type. This applies not only to data warehousing but data modeling as well.	Microsoft
[Formatting] Add data category for columns	Add Data Category property for appropriate columns. Reference: https://docs.microsoft.com/power-bi/transform-model/desktop-data-categorization	Microsoft
[Formatting] Hide foreign keys	Foreign keys should always be hidden.	Microsoft
[Formatting] Mark primary keys	Set the 'Key' property to 'True' for primary key columns within the column properties.	Microsoft
[Formatting] Hide fact table columns	It is a best practice to hide fact table columns that are used for aggregation in measures.	Microsoft
[Formatting] First letter of objects must be capitalized	Microsoft
[Formatting] Month (as a string) must be sorted	This rule highlights month columns which are strings and are not sorted. If left unsorted, they will sort alphabetically (i.e. April, August...). Make sure to sort such columns so that they sort properly (January, February, March...).	Microsoft