ParseJSON feedback

[JorisdG]

It’s been roughly two months since we released ParseJSON as an experimental feature in Power Apps. A lot of scenarios for makers have been unblocked with this feature, and we’ve seen great uptake even though it’s still considered experimental. We’re anxious to get this out of that experimental status. I wanted to take the opportunity to highlight a recent improvement, and address feedback with some of the future plans we have once we take ParseJSON (and untyped objects) out of the experimental phase.

Finally, and most importantly, I’m asking for your feedback. I will elaborate below but if you’re using ParseJSON I would love to hear from you. We’ve seen comparatively low feedback given the amount of usage. This is probably a good sign, but it makes us a little nervous pushing to preview or GA without making sure there aren’t any issues we just haven’t heard about.

Update since experimental launch

You can now use ForAll(), like Index(), directly on an untyped object. A JSON object array such as [ { “id”: 1, “Title”: “One” }, { “id”: 2, “Title”: “Two” } ] would previously require a Table(ParseJSON()) call before going to ForAll. This has the added drawback of resulting in a single-column table with untyped objects, so you would get something like:

ForAll( Table(untypedObject), { id: Value(ThisRecord.Value.id) )

requiring you to use the .Value field on ThisRecord for the single-column table. You can now pass untyped objects directly into ForAll, which no longer creates a single-column table requiring the use of the Value column. So the previous example becomes:

ForAll( untypedObject, { id: Value(ThisRecord.id) )

Feedback so far

The feedback we’ve received so far is positive in that this feature unblocks many scenarios involving JSON. There are two recurring points of feedback we’ve heard from multiple customers:

1. The feature is very “verbose” today due to the requirement of casting every field individually to a specific type. If you set a table of untyped objects as the Items source of a gallery, each use of a field requires Value(), Text() and other casting everywhere you wish to use the fields. For now you can consider using ForAll to type everything into a typed table first, as shown above, making field access easier. Our ultimate goal is to allow you to define your own type schemas and cast the whole JSON to it. We envision this feature to be used with the ParseJSON() function, where you pass in the JSON string as well as the type you defined, and the result of ParseJSON() would then be a typed object as opposed to an untyped object that requires casting. To be clear, we intend to GA ParseJSON with untyped objects first, and add the new typing features later on.

1. Using ParseJSON() with connectors. If a column from a datasource contains a string with JSON, that is easy enough. But we’ve heard of scenarios where makers want to take the whole response message from a connector and manually parse the JSON when the app runs. The connector team is looking to build on top of our work with untyped objects, and beyond that also the previously mentioned type schema definitions to take connectors to a new level. The experimental Dynamic Schema feature is great but is missing some features and flexibility in Power Fx, and we’re starting to address those in Power Fx (with untyped objects and type definitions). There’s some short and long term work going on that I hope you will get to hear about soon.

If you have any feedback or concrete scenarios you’d like to share, I'd love it if you could comment on this thread. I would love to understand how you’re using ParseJSON or trying to use ParseJSON!

[Zanzaid1]

@biterbitI tried that earlier actually upon googling the issue, but it doesn't really solve the issue, just pushes away the error visually. I have actions the user must see and do once the flow is started, but the flow can take anywhere from 1minute to 20 minutes, so it just sits there waiting the whole time until the flow is done, before moving on. Not quite what i'm after. Worked for another simple flow i had though, so thanks 🙂

[biterbit]

@Zanzaid1 Yes - it does have the disadvantage that the app waits for the flow to finish. You might try enclosing the call to the flow in an IsError() statement, which worked for a similar issue with the Office365Outlook connector (as long as you do not want to trap errors in the app).

[Zanzaid1]

@biterbitHadn't considered that option, sounds like it might be an okay temporary solution, will give it a go tomorrow!

[J_Taylor]

I have been trying to find my way around this experimental feature. I seem to be having an inconsistent error. In summary, if I use ParseJSON(varJSON), I get an error, but if I write the JSON inside the function, I don't get the same error.

The JSON (saved as varJSON) is:

[{ ""id"": 1, ""name"": ""0_Student_Template"" },{ ""id"": 2, ""name"": ""123456_DOE, John"" }]

If I run the formula ParseJSON(varJSON), I get the error: "JSON parsing error: Expected ':' after property name in JSON at position 5". However, if I just the same thing with the result of varJSON, I do not get an error - for example:

ParseJSON("[{ ""id"": 1, ""name"": ""0_Student_Template"" },{ ""id"": 2, ""name"": ""123456_DOE, John"" }]")

Below is a screenshot of the two situations at work.

 

The wider situation: I have a Flow that gets the lists from a SP site and places them in a string to pass to the App (via Respond to an App). If it is relevant, below is the response coming from the app and my intended function to convert it to a collection.

EDIT:

I figured out the problem. I don't know if the documentation is incorrect, but after I removed one of the double quotes, it worked (there was a little more to it, like keeping \" occassionally). Maybe this part of the documentation needs to be updated or elaborated on?

[JorisdG]

Hi all - sorry for the late reply. The issue with the connector is being looked at. The connector team is working on support for untyped object (i.e. return "raw" json) and this means return types are no longer "boolean" but untyped object instead. I'll get more info on this on what the plan is to handle this incompatibility better when switching on the support.

As far as the last issue mentioned here, I'll go back through all the posts to see if I can understand the full picture. But it sounds to me you have some confusion on escaping quotes in strings. The string itself should obviously NOT be escaping quotes as that would be invalid JSON. But if you're hardcoding json strings in PFX expressions then you'll need to. If the string is coming from elsewhere, one would expect the JSON received does not have escape characters in it. Note that some debuggers will show the string with escape characters, so it may be confusing if you're debugging this.

If you feel there's an issue here I'm happy to connect offline with you and see if we can reproduce your problem. To be honest though I'd be very surprised if there were an issue with the Power Fx side of this. Again I'm wondering if the JSON you're receiving from somewhere is coming in with escape characters unexpectedly.

[J_Taylor]

Hi @JorisdG, 

Yes, I believe you are correct about my lack of understanding of escaping quotes. I think I managed a basic understanding to get it to work. Thank you.

[biterbit]

@Zanzaid1 Another option to consider: revert your Power Apps Studio version to 3.23021.21 which seems to be the latest version before the issue was introduced. You can follow these instructions: Change authoring version for Power Apps Studio - Power Apps | Microsoft Learn.

[Zanzaid1]

Oh that's clever! I'll have to try that tomorrow, sounds very promising to sort it out in the meantime.

[Zanzaid1]

@biterbit Chances are that our environment is restricted in some form but I'm only able to choose from the current version 3.23023.21 and 3.23024.12. What a bummer!

[AaronDong]

@JorisdG 

Hi, 

Is Microsoft fixing the ParseJSON error related to sendEmail and other no response flows?