Showing results for 
Search instead for 
Did you mean: 
Kudo Kingpin
Kudo Kingpin

Can have One-to-One Relationship in CDS?



Can Can have One-to-One Relationship in CDS?


Super User III
Super User III

Hi @Yahya 

If two tables have a one-to-one relationship, they can generally be combined into a single table unless there is a good reason not to do that. (Usually for security reasons, for example, an employee and that employee's salary, where you do not want to expose the salary table).  I don't think that PowerApps will create such a relationship for you, However, if you have a common field in both entities, like the table ID, you can do it manually using a lookup in a gallery and a Dropdown control in a form. 


I am more into model-driven apps. I created a one to many relationship and in the parent entity lookup, I filtered for the non-related records (yet) to be available for a new relationship. That is fine.


The concern I have is that a user can still add more childs to the parent, from the form of child, related. I know i can hide the child entity from there but is it still a good data design?


Hi @Yahya 

Why not just combine the fields in the two entities into a single entity but create custom forms and views from that entity that only display the fields that you want. That way you won't be creating multiple child records for each parent. 


I have a PROJECT Entity, and a PROJECT-QUOTATION Entity that against each PROJECT that we submit a proposal, a PROJECT-QUOTATION is booked. This is one to one relationship, and QUOTATION ENTITY is meant only to give this relationship, no other data inside.


Then there is the real QUOTATION entity that is a child to PROJECT-QUOTATION, in which there could be many QUOTATIONS for a PROJECT-QUOTATION (for a PROJECT)


Here is an example:



E191-001J - Status Submitted

E191-002J - Status No Quotation

E191-003J - Status Submitted


For the Projects in line 1 and 3, they should have a PROJECT QUOTATION 


Q19-001 - E191-001J

Q19-002 - E191-003J

Q19-003 - waiting to be booked


in the QUOTATION entity you will then find


Q19-001-1.0 first quotation rev 0 for Project E191-001J [which is actually a child for Q19-001]

Q19-001-2.0 second quotation rev 0 for Project E191-001J [which is actually a child for Q19-001]

Q19-001-1.1  first quotation rev 1 for Project E191-001J [which is actually a child for Q19-001]

Q19-002-1.0 first quotation rev 0 for Project E191-003J [which is actually a child for Q19-002]


what is good and bad in this design? what are the recommendations?


You cannot have a pure one-to-one relationship, so with a one-to-many there is always the possibility of creating multiple child records (though you could create a plugin, or workflow with flag fields) to prevent this.

As per the other posts, I'd suggest combining the PROJECT and PROJECT-QUOTATION entities to avoid the need for a relationship; you can use field-level security if you need detailed control over permissions down to the field level

Helpful resources

Community Conference

Power Platform Community Conference

Check out the on demand sessions that are available now!

News & Announcements

Community Blog

Stay up tp date on the latest blogs and activities in the community News & Announcements.


Power Platform 2020 release wave 2 plan

Features releasing from October 2020 through March 2021

Community Highlights

Community Highlights

Check out the Power Platform Community Highlights

Users online (9,847)