Power BI filtering

As a BI Admin, use Power BI filtering to manage which Power BI metadata Collibra ingests. This process allows you to include or exclude specific object types, which ensures your Data Catalog remains focused on high-value assets.

Power BI filtering uses the latest filtering configuration. The latest filtering configuration was introduced in Edge version 2025.02.70 or later. In addition to filtering on capacities and workspaces, filtering lets you filter on reports and dashboards, and on reports published in Power BI apps.

The previous filtering configuration is now referred to as Legacy filtering. You can continue to use Legacy filtering, but new filtering enhancements are available only with the latest filtering configuration.

If you use Legacy filtering, you can use the Legacy filtering conversion tool to convert your existing configuration to the latest filtering syntax.

To configure filters, you must enter the filter configuration, as JSON code, in the Source configuration field in your technical lineage Edge capacity.

Important considerations

• Depending on the authentication type, you must have specific roles and permissions to access the metadata in the Power BI workspaces.
• You can only fully ingest new Power BI workspaces. This means that classic workspaces and My Workspace in Power BI are not supported.
• To ingest Power BI dataflows:

  • You need access to the Power BI environment in which the data flow is stored.
  • The semantic model in the data flow must exist in a premium workspace.
• Workspace filtering takes precedence over capacity filtering, meaning workspaces are filtered first. If there is no explicit exclusion of capacities containing workspaces, all capacities containing workspaces are ingested. Filtering of reports and dashboards is subordinate to workspace filtering, meaning that to include reports and dashboards from a certain workspace, that workspace has to be ingested as well. Reports and dashboards from a single workspace cannot be ingested in different domains.
• When processing workspace filters, processing stops after the first matching filter. To illustrate, in the following example configuration, the first filter dictates that all workspaces (courtesy of the wildcard *) are ingested in DOMAIN_A. Therefore, the second filter, which dictates that my_workspace is ingestion in DOMAIN_B, is not considered.
  
  Copy

  [
      {
          "domainId": "DOMAIN_A",
          "workspaceNames": [
              "*"
          ]
      },
      {
          "domainId": "DOMAIN_B",
          "workspaceNames": [
              "my_workspace"
          ]
      }
  ]

Collection-time vs processing-time filtering

The filter properties you use determine whether filtering happens before metadata collection or during processing after collection.

Collection-time and processing-time filtering can be used together. The following table describes how each type of filtering works and the implications of using it.

Note The metadata of inactive and personal workspaces is not harvested or uploaded to the Collibra Data Lineage service instance. An inactive workspace is one for which no reports or dashboards have been viewed in the past 60 days. My workspace is the personal workspace for any Power BI customer to work with their own, personal content.

Inclusion and exclusion filters

By default, Collibra Data Lineage collects and ingests the metadata of all Power BI capacities and workspaces, including their reports and dashboards. Filtering lets you limit collection and ingestion to the assets that matter to you.

For the complete list of Source configuration properties, including filtering properties, go to Power BI source configuration.

Wildcards are supported for name-based inclusion and exclusion filters, for capacities, workspaces, dashboards, and reports.

You can combine inclusion and exclusion filters in the source configuration.

{
    "filters":[
      {
        "domainId":"07d5d441-b9f8-4add-982f-d7a5d6ba06cc",
        "description":"Domain for BICatalog",
        "capacityFilter": {
          "includedNames": ["CapacityABC"]
        },
        "workspaceFilter": {
           "excludedNames": ["Workspace1"]
           }
        }
     ]
}

Enforce collection-time filtering

To ensure that workspaceFilter/includedIds is applied before metadata collection, set enforceRemoteFiltering to true in the source configuration, at the same level as the filters array. This forces workspace filtering to be applied before metadata is retrieved, even when other filter properties are present.

This property applies to filtering only.

{
  "enforceRemoteFiltering":true,
  "filters":[
    {
      "domainId":"07d5d441-b9f8-4add-982f-d7a5d6ba06cc",
      "description":"Domain for BICatalog",
      "capacityFilter": {
        "excludedNames": ["*"]
      },
      "workspaceFilter": {
        "includedIds": ["workspace ID"]
      }
    }
  ]
}

Filter on reports in published Power BI apps

If you add a report or dashboard to an app in Power BI, what actually happens is that a copy of the original report or dashboard is created in the app. The original report or dashboard still exists outside of the app.

When integrating Power BI, by default Collibra Data Lineage:

• Harvests the original report and the in-app version of the report.
• Ingests both of them, meaning it creates 2 Power BI Report assets in Data Catalog:
  • One for the original report, for example: report-abc
  • One for the in-app version. The prefix "[App]" is used to identify the in-app report, for example: [App] report-abc.

The two asset pages contain the same information, except for the URL. The original report asset links to the original report in Power BI, while the [App] report asset links to the report in the Power BI app.

Use the createAppReports and includedInApp properties individually or in combination to control how Collibra Data Lineage handles in-app reports.

"filters":[
    {
    "reportFilter": {
      "excludedNames": "*restricted*",
      "createAppReports": false,
      "includedInApp": true
    }
   }
  ]

Common patterns

The following examples show how to combine inclusion and exclusion filters for the most common Power BI filtering scenarios. For complete source configuration details, go to Power BI source configuration.

{
  "filters":[
    {
      "domainId":"b5d02896-8a79-49a3-bab0-12a7b37f45c6",
      "description":"<Any description, for the HR department>",
      "workspaceFilter": {
        "includedIds": ["HR's workspace ID"]
      }
    },
    {
      "domainId":"b5d3h796-wg79-86a3-hab3-e7cdj48r9fk49",
      "description":"<Any description, for the Finance department>",
      "workspaceFilter": {
        "includedIds": ["Finances's workspace ID"]
      }
    },
    {
      "domainId":"8sue2896-0s79-93d3-ki90-2fr459jht4s4",
      "description":"<Any description, for the Marketing department>",
      "workspaceFilter": {
        "includedIds": ["Marketing's workspace ID"]
      }
    }
  ]
}

Filter configuration validation

Filter configurations are validated against the following scenarios:

• Duplicate keywords.
• Unknown or unsupported keywords.
• Contradicting inclusion and exclusion filters.
• Mixed filter v1 and filter v2 keywords.
• A single workspace is mapped to more than one domain. (In this case, only the first filter is considered.)

If validation fails for any of these scenarios, a warning with failure details is shown in an analyze error on the Technical lineage Sources tab page. Critical errors occur only if the source configuration is incorrectly formatted or doesn’t contain valid keywords. In such cases, the filter configuration is not processed. If configured inclusion and exclusion filters are contradicting, only the exclusion filter is taken into consideration.

In the following example, the same workspace is specified for inclusion and exclusion. If this case, the exclusion filter takes precedence, meaning workspace ABC2 is not included.

"workspaceFilter": {
     "includedNames": ["ABC2"],
     "excludedNames": ["ABC2"]
  }

The following error is the same scenario as in the previous example, except that wildcards are used. The result is the same, meaning workspace ABC2 is not included.

"workspaceFilter": {
     "includedNames": ["ABC*"],
     "excludedNames": ["ABC2"]
  }

In the following example, a warning is included in an analysis error because workspace ABC2 is specified in multiple filters.

"workspaceFilter": {
     "includedNames": ["ABC2"]
  },
  "workspaceFilter": {
     "includedNames": ["ABC2", "ABC3"]
  }

The includedInApp property is valid only for reports. meaning in a reportFilter section. In the following example, an analysis error is generated because it is used in the dashboardFilter section.

"dashboardFilter": {
    "includedInApp": true
  }

In the following example, a report Test report would qualify for inclusion because it passes both report includedInApp and report includedNames properties. However, due to the order of filtering, the report was already excluded before the inclusion properties were considered. Therefore, the report Test report is not included.

In this case, the report Test report (and any other reports that match the inclusion criteria but will not be included) is considered to have an “absent” parent. Configurations that result in dashboards or reports with absent parents result in analysis errors, and metadata of such dashboards and reports are not ingested.

{
  "filters": [
    {
      "domainId": "12g6d0dc-8291-476a-9bb0-9b13g6cc1356",
      "description": "Filter by display name",
      "capacityFilter": {
        "excludedNames": "Excluded Capacity"
      },
      "workspaceFilter": {
        "excludedNames": "Test1"
      },
      "reportFilter": {
        "includedInApp": true
      }
    },
    {
      "domainId": "default",
      "description": "Filter by display name",
      "reportFilter": {
        "includedNames": "Test report*"
      }
    }
  ]
}

Continuing with this example, if you want to include report Test report in one domain, but not another, consider the following configuration:

{
  "filters": [
    {
      "domainId": "12g6d0dc-8291-476a-9bb0-9b13g6cc1356",
      "description": "Filter by display name",
      "workspaceFilter": {
        "excludedNames": ["Test1"]
      }
    },
    {
      "domainId": "d0f2966c-018b-4e8a-9085-266b3c01c46f",
      "description": "Filter by display name",
      "workspaceFilter": {
        "includedNames": ["Test1"]
      },
      "reportFilter": {
        "includedNames": [
          "Test report"
        ]
      }
    }
  ]
}

In this case, in the domain with ID ending “1356”, neither the capacity nor the workspace that includes the report Test report is included. Therefore, you can include the already excluded workspace in the second filter, for the domain with ID ending “c46f”.

Warnings in generated analysis errors about “absent” parents can help explain filtering behavior. In the following example, workspace filtering happens first, so the report Report in app is ingested in the domain with ID ending “c46f”, thereby rendering obsolete the first filter, a report filter that targets the default domain.

{
  "filters": [
    {
      "domainId": "default",
      "description": "Filter by display name",
      "reportFilter": {
        "includedInApp": true
      }
    },
    {
      "domainId": "d0f2966c-018b-4e8a-9085-266b3c01c46f",
      "description": "Filter by display name",
      "workspaceFilter": {
        "includedNames": ["workspace_name_1"]
                        },
      "reportFilter": {
        "includedNames": ["Report in app"]
      }
    }
  ]
}

If you want to ingest reports into multiple domains, the following example shows the recommended configuration.

{
  "filters": [
    {
      "domainId": "d0f2966c-018b-4e8a-9085-266b3c01c46f",
      "description": "Filter by display name",
      "workspaceFilter": {
        "includedNames": ["workspace_name_1"]
      },
      "reportFilter": {
         "includedInApp": true
      }
    },
    {
      "domainId": "default",
      "description": "Filter by display name",
      "workspaceFilter": {
        "includedNames": ["workspace_name_2"]
    },
      "reportFilter": {
        "includedInApp": true
      }
    }
  ]
}

Legacy filtering

Legacy filtering is the original Power BI filtering configuration and is still supported. Unlike filtering, Legacy filtering supports filtering on capacities and workspaces only, not on reports or dashboards.

You can use the following inclusion filters:

• capacityNames
• capacityIds
• workspaceNames
• workspaceIds

You can use the following exclusion filters:

• excludeWorkspaceNames
• excludeWorkspaceIds

Wildcards are supported for the capacityNames, workspaceNames, and excludeWorkspaceNames properties.

You can combine inclusion and exclusion filters in the source configuration.

{
  "filters":[
    {
      "domainId":"07d5d441-b9f8-4add-982f-d7a5d6ba06cc",
      "description":"Domain for BICatalog",
      "capacityNames":["CapacityABC"],
      "excludeWorkspaceNames":["Workspace1"]
    }
  ]
}

{
  "filters":[
    {
      "domainId":"b5d02896-8a79-49a3-bab0-12a7b37f45c6",
      "description":"<Any description, for the HR department>",
      "workspaceIds":"<HR's workspace ID>"
    },
    {
      "domainId":"b5d3h796-wg79-86a3-hab3-e7cdj48r9fk49",
      "description":"<Any description, for the Finance department>",
      "workspaceIds":"<Finance's workspace ID>"
    },
    {
      "domainId":"8sue2896-0s79-93d3-ki90-2fr459jht4s4",
      "description":"<Any description, for the Marketing department>",
      "workspaceIds":"<Marketing's workspace ID>"
    }
  ]
}

Filter configuration validation

Filter configurations are validated against the following scenarios:

• Duplicate keywords.
• Unknown or unsupported keywords.
• Contradicting inclusion and exclusion filters.
• Mixed filter v1 and filter v2 keywords.
• A single workspace is mapped to more than one domain. (In this case, only the first filter is considered.)

If validation fails for any of these scenarios, a warning with failure details is shown in an analyze error on the Technical lineage Sources tab page. Critical errors occur only if the source configuration is incorrectly formatted or doesn’t contain valid keywords. In such cases, the filter configuration is not processed. If configured inclusion and exclusion filters are contradicting, only the exclusion filter is taken into consideration.

In the following example, the same workspace is specified for inclusion and exclusion. If this case, the exclusion filter takes precedence, meaning workspace ABC2 is not included.

"workspaceNames": ["ABC2"],
"excludeWorkspaceNames": ["ABC2"]

The following error is the same scenario as in the previous example, except that wildcards are used. The result is the same, meaning workspace ABC2 is not included.

"workspaceNames": ["ABC*"],
"excludeWorkspaceNames": ["ABC2"]

In the following example, a warning is included in an analysis error because workspace ABC2 is specified in multiple filters.

{
  "domainId": "<domain-ref-id>",
  "description": "FirstFilter",
  "workspaceNames": ["ABC2"]
},
{
  "domainId": "<domain-ref-id>",
  "description": "SecondFilter",
  "workspaceNames": ["ABC2", "ABC3"]
}