web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Cloud for Sustainability | MSM, SDSF,...
Unanswered

Limitations with Built-in Concepts

(4) ShareShare
ReportReport
Posted on by 107

We’ve encountered an issue related to the built-in concepts that were introduced across two releases of the solution.

  • In one release, a set of OOB concepts prefixed with AIGenerated-” were released as part of the Fact Finding with Copilot functionality. These concepts were automatically linked to CSRD standard requirements.
  • In another release, a new batch of predefined concepts prefixed with "esrs-" was added. Many of these represent the same underlying concepts as the AIGenerated ones but with different data types. These were also automatically linked to CSRD standard requirements.

As a result, we now have duplicates: one Standard Requirement linked to duplicate Concepts: one prefixed with AIGenerated with the wrong data type, and another prefixed with esrs mostly with correct data type.

In the screenshot below, you can see a sample Standard Requirement with duplicate concepts marked in the same color. 

Moreover, a later release added two fields to Concept entity; Concept Group and Display Name, which were populated for the built-in S&G concepts, but not for the AIGenerated or esrs concepts released earlier.

This has become problematic for several reasons:

  • Since both AIGenerated and esrs concepts are managed:
    • We can't edit their data types.
    • We can't assign them to Concept Groups or update their Display Name.
    • We can't remove their links to Standard Requirements.
  • When working with assessments:
    • When creating an assessment based on the CSRD standard, the Assessment Requirements are automatically linked to both the AIGenerated and the esrs concepts. However, since they can't be modified, they're often unusable.
    • To capture the correct data with proper naming, grouping, and data type, we have to create custom concepts and link them to the same requirement.
    • This clutters the assessment and introduces unnecessary complexity because for each requirement, we end up with:
      • One or more unusable concepts.
      • One or more custom concepts that are actually used. 

Are there any workarounds or any upcoming fixes? 

It would be helpful if the demo data (i.e., built-in managed concepts) were provided in a separate solution that could be optionally installed. That way, we’d have the flexibility to adopt the OOB standard as needed and better tailor the implementation to the client's actual requirements.

I have the same question (0)

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > Microsoft Cloud for Sustainability | MSM, SDSF, EID

#1
Siv Sagar Profile Picture

Siv Sagar 49 Super User 2025 Season 2

#2
VS-01071403-0 Profile Picture

VS-01071403-0 8

#2
Anne-Laure D'Hondt Profile Picture

Anne-Laure D'Hondt 8

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans