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

Custom API - Form no datasource selected

I have a Custom API to Northwind ODataV4 endpoints.  Connection added and PA is trying to deal with it.


The problem I'm having is trying to figure out proper DataSource and Item properties of forms controls.


Here is a sample response schema from CategoriesGet() method:

  "@odata.context": "string",
  "value": [
      "CategoryID": 0,
      "CategoryName": "string",
      "Description": "string",
      "Picture": "string"

As you can see the response is an object having two props (types: string and array)


PA seems to accept for DataSource: NorthwindAPI.CategoriesGet().value (this works in Items prop of a gallery too)


But nothing works in the Item prop.  For example, say I want to view the first item in the response array.  A proper expression would be: NorthwindAPI.CategoriesGet().value[0]


However none of the following works in PA: 0 , [0] , (0)


I tried First(source) function in Item prop, but how do we refernce the respective DataSource.  (tried: ThisDatSource, this.DataSource, inspected [@DataSourceInfo] whatever that is(?) - no luck)


Nor does it allow:

DataSource: NorthwindAPI.CategoriesGet()

Item: value[0]


Any suggestions including manually editing swagger would be appreciated.




Power Apps
Power Apps



Forms in PowerApps are designed to be used with tabular data sources whose schemas are known statically (i.e. at authoring time). In order to bind a form to a tabular data source, you need to add the data source to your app, then reference it by name in the formula for Form.DataSource.


Form.Item refers to the item that will be viewed or edited. This will typically be a record from that tabular data source (a row), for example First(MySpecialDataSource).


PowerApps's type system has no concept of "arrays", so there is no random access into data via numeric indices. Instead of writing foo[0], which is invalid syntax, please consider designing your data (server & swagger) and formula logic to refer to tables and rows of those tables. A row can be obtained in many different ways, for example by using the LookUp, First, or Last functions, described here:


In PowerApps, the '@' symbol is used for name disambiguation. The usage you listed refers to global disambiguation, which is a way to syntactically tell PowerApps that you really mean a globally-available identifier (such as a data source), instead of a field/column with the same name in a gallery item or row scope. Disambiguation syntax is documented here:


I hope this helps.


Radu Gruian [MSFT] ** PowerApps Staff

@rgruian Thanks for your reply.  My API returns a static schema which is known a design time, and I've added the data source and can set the Form.DataSource just fine.   It seems to me, the PA tooling doesn't handle the schema consistently. 


For example, the formula:


works fine for the Gallery.Items property and also for the Form.DataSource property.  Therefore I believe my response schema is considered a 'tabular datasource' by the tooling.


The problem is with the Item property of the Form.  I've tried First(), but I cannot get it to accept my 'table' as the source parameter.


However this formula:


is valid in the Form.Item prop, and I can use my fields in the tool like


yet the Fields are not listed on the Options tab so I have to create every control and label manually using Custom Cards.


This behavior seems inconsistent to me. I'd love to know if there is a way to make the Form controls useful for Custom APIs.


Such as perhaps x-ms- swagger vendor extensions would light up this functionality(?)


Related question:





Hi Josh,


Forms were designed for tabular data sources. These are named, and are typically introduced via connections. For example, with a named tabular data source in place, in PowerApps you would be able to use simply 'Categories' in formulas instead of making a function call to fetch data.


What you are referring to is a custom API (service function) that returns data in tabular format -- and that is not a named tabular data source. Yes, the return schema of that function is known statically, however forms need a higher abstraction: a unique named entity that declares and encapsulates all the specifics related to CRUD operations on the underlying tabular data (i.e., forms need to know how to remove a row, how to add or edit a row, etc). Custom APIs do not provide that abstraction, and that is the sole reason why forms do not directly support them.


Have you tried migrating your data to CDS or Sharepoint?




Radu Gruian [MSFT] ** PowerApps Staff

 Hi Radu,


Thanks again for your reply. 


I now understand that, to PA, there is a difference between 'named' tabular datasource and a a custom API that returns tabular data.  What I don't understand is why there is a difference.  My API does indeed have CRUD methods.  Create, Read, Update, Delete are http methods POST, GET, PATCH, DELETE respectively.  I can see that a higher entity abstraction is needed for the tooling to work, but is there a way to map swagger operations CRUD operations of named entities?


It seems to me what PA and Flow are missing is:


1) a first-class OData connector

2) x-ms- swagger vendor extensions to enable custom API devs to light up 'entity' the tooling. 


CDS and Sharepoint (and even SQL Connector) are not an option since there are no options for server side business logic.



Kudo Kingpin
Kudo Kingpin

I can see that a higher entity abstraction is needed for the tooling to work, but is there a way to map swagger operations CRUD operations of named entities?

Can anyone confirm whether it is possible to make a Custom API connector have 'tabular' capabilities?


Please vote here:


Thanks in advance,


Helpful resources

Super User 2 - 2022 Congratulations 768x460.png

Welcome Super Users

The Super User program for 2022 - Season 2 has kicked off!

Power Platform Conf 2022 768x460.jpg

Join us for Microsoft Power Platform Conference

The first Microsoft-sponsored Power Platform Conference is coming in September. 100+ speakers, 150+ sessions, and what's new and next for Power Platform.

Users online (2,183)