cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos

Separate data type from constraints and other field metadata

I shouldn't have a field in my custom entity of data type picklist. That is not a data type. If I have an entity for budget requests and I have a field called Department of data type picklist, that leads to problems should I ever need to change it. Let's say I now need to make my form allow for multiple department selections. I have to create an entirely new field for Departments. I think we are conflating constraints with data types. If my Department field had been a text field all along, I could then just switch my PowerApps form to a control other than a dropdown to allow multiple selections and I wouldn't have had to change my custom entity field. 

If you were to tell me that I really should have had a Departments entity and a Budget Requests entity with a relationship back to Departments, I would agree with you. But I would still rather have all the fields in my Department have real data types, not picklist. If you wanted to add properties for input constraints in the CDS (although one could argue that is the job of the PowerApps forms), I could see associating a picklist with the appropriate Department field that way. But this has lead to headaches for me, and I image it will for others using CDS and in future development of CDS down the road. 

Status: Need Info

Hi Meagan,

 

Thanks for your feedback. I'll try and respond in two parts - firstly, the approach you're suggestion of using the String/Text data type and then using a combobox in PowerApps to present values to a user is completely valid and there should be nothing stopping you from implementing this today in the service.

 

With regards to why we allow users to add more structured data types like a picklist, this allows us to ensure data consistency across all entry points using the Common Data Service; PowerApps, Flow, Excel, Import/Export, SDK without requiring a end user control in all of these places to ensure data consistency. I understand this does come with some limitations in changing these data types down the road - however we feel it still simplifies the initial app building experience.

 

At this point, we are not planning any features to change this behaviour.

 

Please let me know if I've understood your feedback, and if I can provide any further information.

 

Thanks,

Clay.

Comments
PowerApps Staff
Status changed to: Need Info

Hi Meagan,

 

Thanks for your feedback. I'll try and respond in two parts - firstly, the approach you're suggestion of using the String/Text data type and then using a combobox in PowerApps to present values to a user is completely valid and there should be nothing stopping you from implementing this today in the service.

 

With regards to why we allow users to add more structured data types like a picklist, this allows us to ensure data consistency across all entry points using the Common Data Service; PowerApps, Flow, Excel, Import/Export, SDK without requiring a end user control in all of these places to ensure data consistency. I understand this does come with some limitations in changing these data types down the road - however we feel it still simplifies the initial app building experience.

 

At this point, we are not planning any features to change this behaviour.

 

Please let me know if I've understood your feedback, and if I can provide any further information.

 

Thanks,

Clay.