Category: Flow

Lookup fields & Power Automate

This is an interesting post, for several reasons. Firstly, it’s the first one in 3 weeks – I was off on holiday, and decided to take an (almost) absolute break from all things digital, which included this blog. It was actually quite refreshing, though now coming back & starting to write again does seem a bit daunting, I’ll admit!

Thankfully, whilst wondering what exactly to start with, a scenario came up that I was working on. It seemed quite simple at first, but then actually got someone complicated. I therefore thought it would be helpful to others if I wrote about it, so here it is.

The scenario was as follows. We had records being auto-created in the system, and needed to create child records for them. This, as I’m sure you’ll agree, is really quite simple to do with Power Automate. We also needed to set lookup values on the child record, that were already populated on the parent record (for reference purposes).

So for example, the parent record has a lookup to Country (being a separate entity), and the child record also has a lookup to Country. These need to be the same.

Being both lookup fields, I figured that I’d be able to take the value from the parent record, and simply plop it into the corresponding field on the child record in Power Automate:

So I did that – and immediately hit an error. Not just any error, but the fabled ‘Resource not found for the segment’ error!

Obviously, I did what anyone would do at first – I put it into Google & Twitter, and took a look at what came up.

The ‘problem’ was coming from using the ‘CDS Current Environment’ connector, which is the latest version available (the old one is no longer available to use). It’s really great for a lot of things, but unfortunately not so great in a few areas. See, in the old CDS Connector, you could just drop the lookup field value into the field you were wanting to populate. Power Automate had no issues with that, & it would run just fine.

However in the ‘new’ CDS Connector, you can’t just do that. Instead, you need to use an OData reference (which I haven’t done much of before, to tell the truth). So based on the blogs I had come across, I went to work to try to get this working.

Part of the challenge was that there didn’t seem to be a unified consensus in how to do it. I came across the following variations:

  • /entityname(Lookup Field Value)
  • /entityname/(Lookup Field Value)
  • /pluralentityname(Lookup Field Value)
  • /pluralentityname/(Lookup Field Value)

Somewhat confusing, as I’m sure you’d agree. Nevertheless, I ploughed through all of the different possibilities. But nothing was working – every single time, I still got the ‘segment not found’ error message. This, as you can image, was extremely frustrating!

Thankfully, one of my good friends was around & able to help out. Namely, Tricia Sinclair came to the rescue!

We took a look at the code I was using, and she took a look at some of her own use cases (where it had worked for her). I was starting to think down the path of needing a capital letter in the entity name (some systems can be REALLY finicky around things like that), but thankfully it wasn’t.

Instead, it was the following. See, this was a custom entity. It turns out that for a custom entity (& heck, for all I know system entities as well) the syntax needed is ‘publisherprefix_pluralentityname(lookupfieldvalue)’. Now that’s not something that I had come across ANYWHERE at all!

Looking at it, I guess it makes sense. After all it would technically be possible to have multiple entities with the same name, though with different publishers. As a result, the system needs to know WHICH exact entity is being needed for the Power Automate, so uses this. Somewhat complicated (and hey – it worked without all of this in the OLD CDS Connector), but we got it to work!

Testing it out, everything worked smoothly. The Power Automates fired off without any issues, the data got created & populated, and everyone was happy.

So there you go. Another interesting little twist in syntax needed, which hopefully will NOT change in the (near) future!

Have you come across anything like this? I’d love to hear – drop a comment below around it!

Creating a Flow to set record image

Due to my interest in motorbikes, and being a keen biker (as touched upon previously), obviously one of my PowerPlatform/D365 environments is based around motorbikes! I mean, why not….

My aim is to have a list of motorbikes, and be able to distinguish them by make, model, and type. This is going to form the basis of various things that I’m minded to test out in the CDS with PowerApps and Flow, which I’ll be blogging about on a semi-regular basis.

Having the list of data is obviously necessary. Then it occurred to me – I should be saving an image for each motorbike against its record.

So there’s a default field available in every entity for an image. This is the little icon that displays next to the record name at the top left of the form when you open it:

There’s only ONE image field available for each entity – which makes sense, after all.

Now, this can be manually added to the record by manually uploaded. That’s a pain though – surely there’s a BETTER way to do this…and what could be better than using Flow!

So I started to create this, and see how it would work. Thanks to Mike Carlton for his amazing support with this.

The aim is to have a URL to a picture that the system will then automatically go out to retrieve.

The first Flow that we created did this by getting the URL, saving the image to OneDrive, and then taking that image and uploading it into the CDS record (we’re not touching D365 at all here)

After tweaking one or two of the parameters (the finished Flow is shown above), it ran successfully! High fives all around.

Looking further at it, I wondered if it would be possible to remove the stage where the image file was saved to OneDrive. I played around with it further, and lo and behold – it was indeed possible!:

This is now working very nicely, and I’m quite happy with it. More to come!