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

Notifications

Announcements

Community site session details

Community site session details

Session Id :
Power Platform Community / Forums / Power Pages / Web API: "entityRelati...
Power Pages
Suggested Answer

Web API: "entityRelationshipRole... not found" (0x80040216) when cascading Parent Table Permissions

(0) ShareShare
ReportReport
Posted on by

I am developing a Power Pages portal and facing an issue retrieving records from a custom table (mkd_planning) using the Portal Web API. By design, users should only see "Plannings" related to a "Session" they have signed up for.

Data Model & Logic:
The relationship chain is a bit complex. Here is the flow from the User to the Planning records:

  1. Contact: The logged-in system user.
  2. Learner (mkd_learner): Related to Contact via mkd_linked_contact.
  3. Submission (mkd_submission): This is the junction table representing a signup. It connects a Learner (via mkd_linked_learner) to a Session (via mkd_linked_session).
  4. Session (mkd_session): The parent event.
  5. Planning (mkd_planning): The child records I need to fetch. These are related to the Session via lookup mkd_assignedsession.

Current Status:
The Web API works perfectly for the first few levels of this chain.

  • GET /_api/mkd_learners → Returns only the logged-in user's learner record (Success).
  • GET /_api/mkd_submissions → Returns only the submission for that learner (Success).
  • GET /_api/mkd_sessions → Returns only the session linked to that submission (Success).

The Problem:
When I try to go one step deeper to fetch the plannings (GET /_api/mkd_plannings), I get this error:

{
  "error": {
    "code": "9004010D",
    "message": "Common Data Service error occurred.",
    "cdscode": "0x80040216",
    "innererror": {
      "code": "0x80040216",
      "message": "entityRelationshipRole for given navigation property not found"
    }
  }
}

My Table Permission Configuration:
I am using a chain of Child Table Permissions in the Portal Management App. All 4 permissions are assigned to the same Web Role ("Authenticated Users").

  1. Permission A (Root): mkd_learner
    • Access Type: Contact Scope (via mkd_linked_contact).
    • Status: Works.
  2. Permission B: mkd_submission
    • Access Type: Parent (Parent Perm: Permission A).
    • Status: Works.
  3. Permission C: mkd_session
    • Access Type: Parent (Parent Perm: Permission B).
    • Relationship: mkd_submission_mkd_session (Session is looked up on Submission).
    • Status: Works.
  4. Permission D: mkd_planning
    • Access Type: Parent (Parent Perm: Permission C).
    • Relationship Selected: mkd_planning_AssignedSession_mkd_session
    • Status: Fails with 0x80040216.

Troubleshooting Steps Taken:

  1. Tested Data Existence: I temporarily changed Permission D (mkd_planning) to Global access. The API immediately returned the records successfully. This confirms the API is enabled, the Entity Set Name is correct, and the data exists.
  2. Verified Schema: I checked the Solution in Power Apps. The N:1 relationship from Planning to Session is definitely named mkd_planning_AssignedSession_mkd_session.
  3. Verified Web Roles: Confirmed all four permissions belong to the exact same Web Role.

Question:
Why does the Power Pages Web API fail to resolve the relationship role (0x80040216) specifically at the 4th level of this hierarchy? Is there a limit to how deep permissions can cascade for the Web API, or is there a specific relationship naming convention I am missing?

I have the same question (0)
  • Suggested answer
    Fubar Profile Picture
    8,361 Super User 2025 Season 2 on at
    The Portal Web API does have limitations. Depending on your query your problem may be one of the limitations but it is not clear from what you have posted (you would need to disclose the full queries you are making), if it is the nesting limitation you may be able to work around it by making the query use fetchxml rather than odata, or alternatively call a power pages flow rather than use the Web API (but Web API is probably technically more secure as scoped to your table permissions).
     

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

Forum hierarchy changes are complete!

In our never-ending quest to improve we are simplifying the forum hierarchy…

Ajay Kumar Gannamaneni – Community Spotlight

We are honored to recognize Ajay Kumar Gannamaneni as our Community Spotlight for December…

Leaderboard > Power Pages

#1
Fubar Profile Picture

Fubar 78 Super User 2025 Season 2

#2
Jerry-IN Profile Picture

Jerry-IN 75

#3
sannavajjala87 Profile Picture

sannavajjala87 31

Last 30 days Overall leaderboard