The ultimate Fabric, Power BI, SQL, and AI community-led learning event. Save €200 with code FABCOMM.
Get registeredEnhance your career with this limited time 50% discount on Fabric and Power BI exams. Ends August 31st. Request your voucher.
Dear all,
for our projects we have created standard SharePoint site templates with standard lists to document project stuff (action items, risks, decisions, monthly report, etc.), each of these lists uses a content type. In the list "Monthly report" we're referencing items from other lists of the same project; these are columns of type lookup in the same site: RiskReference, DecisionsReference with multi select enabled.
On top of this SharePoint structure we have a Power BI report that aggregates the information per project across the related logs.
Getting the data out of SharePoint is done by using SharePoint Search API queries in Power Query. However, for getting the cross-references in the list monthly report to other lists (risks, decisions) we can't use SharePoint Search API as these list columns couldn't be implemented in the content type, as they are site specific. So we're getting that part of the monthly report list via SharePoint rest api call on the method "GetByTitle" which works like a charm, but only gives results for the column RiskReference and not for the column DecisionReference. The expected result of the API call would be the ListId of the linked items, which works for RiskReference, but for DecisionReference is just empty.
Here is the power query call to the rest api:
Do you have an idea what could be the cause for this inconsistency? The columns are configured identically in SharePoint.
Solved! Go to Solution.
Check out this doc: https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins/use-odata-query-operations-in-sharepoint...
As it mentions, some complex / resource-intensive fields (this can often include lookups) will not be included by default. If RiskReference is single-select and DecisionsReference is multi-select, that could be a factor in the discrepancy; also, probably the number of columns in the lookup lists would be a factor.
To ensure you get the lookup column metadata you need, you'll have to request them via $select in your query.
So, assuming RiskReference is single-select and DecisionsReference is multi-select, and those are the internal names for both, something like the following may work better for you.
Web.Contents(
"https://entity.sharepoint.com/sites/" & [ProjectName]
& "/_api/web/lists/getbytitle('" & [ListName] & "')/items('" & [ListItemId] & "')",
[
Headers = [accept = "application/json"],
Query = [
#"$select" = "Id,Title,RiskReferenceID,DecisionsReference/ID",
#"$expand" = "DecisionsReference"
]
]
)
Also, as an aside, it is pretty inefficient to make a web request per item. You would probably get better performance (and better avoid throttling) if you make a single call on the list to get all items and then either join them in Power Query or load in separately and handle with a relationship in your model (the latter is usually the better option IMO). You can get up to 5k items with a single call (will need to specify #"$top"="5000" in Query), after which you'll need to implement paging (there are a few ways to do this in PQ for SharePoint).
Check out this doc: https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins/use-odata-query-operations-in-sharepoint...
As it mentions, some complex / resource-intensive fields (this can often include lookups) will not be included by default. If RiskReference is single-select and DecisionsReference is multi-select, that could be a factor in the discrepancy; also, probably the number of columns in the lookup lists would be a factor.
To ensure you get the lookup column metadata you need, you'll have to request them via $select in your query.
So, assuming RiskReference is single-select and DecisionsReference is multi-select, and those are the internal names for both, something like the following may work better for you.
Web.Contents(
"https://entity.sharepoint.com/sites/" & [ProjectName]
& "/_api/web/lists/getbytitle('" & [ListName] & "')/items('" & [ListItemId] & "')",
[
Headers = [accept = "application/json"],
Query = [
#"$select" = "Id,Title,RiskReferenceID,DecisionsReference/ID",
#"$expand" = "DecisionsReference"
]
]
)
Also, as an aside, it is pretty inefficient to make a web request per item. You would probably get better performance (and better avoid throttling) if you make a single call on the list to get all items and then either join them in Power Query or load in separately and handle with a relationship in your model (the latter is usually the better option IMO). You can get up to 5k items with a single call (will need to specify #"$top"="5000" in Query), after which you'll need to implement paging (there are a few ways to do this in PQ for SharePoint).
Hey @PetterR,
Issue Analysis & Resolution Steps
Based on your description, this appears to be a common SharePoint REST API behavior with multi-select lookup columns. Here's my recommended approach:
1. Verify Column Configuration
2. REST API Call Modifications
3. Permission & Access Verification
4. Power Query Debugging Steps
5. Alternative Approaches
Quick Test: Run the REST API call directly in browser first to isolate whether it's a SharePoint or Power Query issue.
Fixed? ✓ Mark it • Share it • Help others!
Best Regards,
Jainesh Poojara | Power BI Developer