Power Pages and Virtual Entities - id in url (limitations)

[ffrr7788]

Hi power pages experts,

I'm struggling with the opportunity to have id (recordid) in URL after inserted record in a basic form (Insert), using virtual entities.

I've set in my basicform an append record id to querystring (using "id" as record ID parameters) for a redirect to a webpage.

After submit, I should expect to have in the URL the recordid of the created record in the virtual entities, but i see an "id" that i don't know exactly what is.

Virtual Entities don't have record id inside but a unique identifier, so I should expect this value in my url after record creation.

Is there any limitation with Power Pages and Virtual Entities ? 

Any suggestion on how could be possilbe retrieve virtual entity unique identifier after basic form submit, and put this value in the URL when redirect on a new page ? 

Thanks a lot

[EmadBeshai]

Hi @ffrr7788 ,

Please check the limitations section at this article and the most important thing is that, the primary key for the entity in the external data source must be a GUID.

Engineered Code - Blog - Virtual Entities and Dynamics 365 Portals – Part 1

If this post helps you with your problem, please mark this answer as Accepted Solution.

If you like my response, please give it a Thumbs Up. 

[ffrr7788]

Hi @EmadBeshai 

thanks a lot for the link, I've checked it but it is outdated (2018). I hope in more than 4 years, something is improved 🙂

Virtual entity I'm working on is automatically exposed from Finance and Operations, and inside I've the unique identifier that is a GUID:

The strange behavior I see in a basic form redirection (but it's the same even with multistepform) is that the ID automatically passed after submit is completely different from what I see in Dataverse.

Here is an example:

Form where I create the Sales Order Header:

On success submit I redirect to a new page in order to see details fields of the record already created, but I get this error:

The error, for what I've understood, happen because the ID passed in the URL is different from the record created in Dataverse Virtual entities. This is the ID passed by the submit form:

that is completely different of the ID unique identifier in Dataverse Virtual Table:

In fact, if  change manually the wrong with what I see in Dataverse table, everything works well:

I'm able to see the correct data and the correct Sales Order created:

This is the setup I've on form redirection:

It seems, there is a wrong behaviour with Virtual tables or some important limitation, because Power Pages is not able to pass the correct ID.

Do you have any idea and/or other suggestion? 

Thanks a lot

[EmadBeshai · Accepted solution]

Hi @ffrr7788 ,

I have tried the same scenario and it is not working 😞 

I have a workaround for you, instead of redirecting to the target Webpage directly you can create intermediate Webpage and inside Webpage has a Web-Template inside this Web Template you will type fetch query to retrieve the created records on your virtual entity sorted descending by createdon and select the first, since you are creating this record for authenticated users only then no need to filter by user because the  Power Page is already retrieving the record only associated to the logged in user based on the table permissions.

After selecting the first record you can redirect the Web Page to the target Webpage as shown below

<script>
window.location.href = "/NEW_EDIT_Basic_Form?id="{{selectedrecord.id}}

</script>

Note:

Don't forget to add invalidating cache condition as Oliver mentioned here Power-apps-portals-caching-tips  to get the real time data and avoid cached data.

If this post helps you with your problem, please mark this answer as Accepted Solution.

If you like my response, please give it a Thumbs Up. 

[ffrr7788]

Hi @EmadBeshai 

thanks for your time and for confirmation that this scenario doesn't work. Probably the use of Virtual Entities is still very limited, even if I didn't see anywhere in MS documentation this limit clearly documented.

Even talking with MS support, the answer usually is that it should work.....but it don't work.

In anycase I've already applied a workaround similarly to what you have suggested, so I'm pretty sure that this workaround is an acceptable solution.

Thank you