Feedback needed: Usability/fix for working with custom field "value"

Ben Lambert

Hi Community folks! I wanted to get your feedback on a enhancement (really a bug fix and usability improvement) we're working on for dealing with custom field value property in the Power Platform connector.

Related to the issue identified in this thread, the SKY API defines the value property of a custom field (incorrectly) as type: object. This is wrong, because object really means a JSON object with its own set of properties, which isn't accurate for all types of custom fields (some are simple data types like booleans, strings, etc.).

Several months ago, per guidance from Microsoft, we removed this static type definition for the value property for all the xxxCustomFieldRead response objects in the connector because the Power Platform began enforcing some stricter type validation to the runtime response for an API vs how the API is defined in the connector. This validation caused flows to fail at runtime because the output of the underlying endpoint didn't match the schema defined in the connector. The change we made (removing the static type definition) fixed runtime failures, but made it a bit harder to work with the value property in Power Automate (since the field is now treated as a dynamic type). The user experience suffered more so in Power Apps because it doesn't support dynamic type definitions…so the value field no longer shows up in the list of fields).

To improve this, we're considering appending an additional bespoke strongly-typed field to the xxxCustomFieldRead response object, which will be named based on the data type of the custom field. A Number custom field will have a new property named number_value, a Date custom field will have a new property named date_value, a code table entry custom field will have a new codetableentry_value property, etc.

This change would allow you to reference the “value” of a custom field using a strongly-typed field in the dynamic content window (instead of working around the ill-defined value field). Here's a screen shot showing what this might look like:

Any feedback on this approach? Will this simplify your life? Feel free to let us know in the comments on this thread, and as always don't hesitate to ask if you have any questions! If this change helps, we'll get it into the next round of updates to the connector.

Thanks!

Ben Lambert

Note - this technique would also be applied to the response for “Ratings” (which has a similarly ill-defined “value” property)