Category: CDS

Canvas Apps & renaming field labels

Today I want to share with you something that I’ve realised. Changing field labels can have unintended consequences!

Let’s cast our minds back to the days of ‘traditional’ Microsoft CRM, or as it’s so lovingly referred to nowadays, ‘model-driven’ apps. What you had were a number of entities (eg Accounts, Contacts, etc), all of which contained fields. Fields could be different types (text, integer, boolean etc), and have varying properties on them. You could set them to be required (or not), searchable (or not), and have so much fun.

At the heart of a field is the name that it has. Well, technically there are two names. One is the actual database name. Once a field was created & saved, this was effectively written in stone. The only way to handle a situation where you spelled this incorrectly was to delete it, and then recreate it. Even then, it could still be floating around in the back-end database in its original form.

The second name is the Display name (or Display label). This was the text used on the entity form itself, & could be changed as desired. This was actually really useful – many a time a business unit would say something like ‘we don’t want the field to show as Zip/Postal Code’; we want it to say ‘Postcode’. Well, that was easy enough to address – simply go ahead, load up customisations, & change the display name property for the field. Everyone was impressed & happy, and could get on with their work.

There were of course times that Business Unit A would say ‘I want ‘ABC’ as the display name’, and then Business Unit B would say ‘Ah, but I want ‘XYZ’ as the display name!’. To handle this, it was very possible to customise the label on the form itself, which would then override the display name value. This, of course, would only be valid for that specific form, so it was then imperative to have different forms for the different business units.

Now, in the good old days we use to create SQL queries against the database, SSRS reports, etc. In order to do this, we needed to know the actual underlying (database) field name. We could of course open up customisations, & start trawling through, but there are better methods for doing this. One of these is Level Up by Natraj Yegnaraman. This can be found at https://github.com/rajyraman/Levelup-for-Dynamics-CRM, and is an extension which can be run on Chrome, Edge on Chromium, & FireFox).

Using this amazing tool, it was possible to merely load an entity form up in an existing system, and then TADA! At the click of a button (well, two clicks actually), the underlying database name was revealed. This was an absolute lifesaver, so many times.

So there we’ve been, toddling along for many years like this. It worked, and worked well. All was good.

Then came along canvas apps. Now I’m not a canvas app guru by any means – I’m quite new to them, and still trying to wrap my head around the ‘special’ way in which they operate. Thankfully there are quite a few gurus in the community who have given me help in one way or another to learn how to carry out various functions, and I think that I may JUST be starting to get the hang of it.

With the current COVID-19 situation, I’ve been working on a series of apps for work, to help local authorities. One of these is a canvas app for call centres, to record information easily & quickly. We chose to go down the canvas route due to being able to have a clean layout, as well as being able to display information for the operators to read. This would have been much more difficult in a traditional model-driven app, especially as such things as dialogues have been deprecated.

One of the functions that I’ve had to learn to do this has been to use the ‘Patch’ function (see https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/functions/function-patch for more information on this. The following is an example of one of the Patch statements that I was using:

This was working remarkably well – it was creating the task record, and setting all of the different values that I needed. For those who are curious as to why I was using a Patch statement, rather than submitting the form, it was due to needing to set the ‘Regarding’ field, which has some very special behaviour!

Then someone on the team said ‘Hold on – we’re only storing one address. Let’s change the field display names to remove the ‘Address 1′ part, so that we don’t confuse users’. OK – I didn’t INITIALLY see any issue with this. I bet that you can see what’s coming through…

Yes – you’re right. The patch statement isn’t referring to the field database name. It’s referring to the field display name! The reason for this is that this is the syntax that Canvas Apps use – there doesn’t seem to be a way to refer to the actual underlying field database name

Of course, I only actually discovered this when I ran through the canvas app again. And indeed, it was whilst demonstrating it to other people! Oh joys – what a wonderful time for it to happen.

So, I then had to figure out what had happened – thankfully that didn’t take too much time. What DID take time was going through every single place in the canvas app that had code referring to the specific fields, and update them to the new (correct) values. This therefore ended up looking like:

So, the vitally important lesson to learn here is be VERY careful when changing field display names, especially if you have one (or more) canvas apps that are referencing them. The last thing that you want is a major headache in having to go back through every place that refers to them, and changing/updating the values.

The only workaround that I’d suggest, is that if you’re wanting to change how fields display in the canvas app itself, change the ‘Text’ value for the field:

That way, HOPEFULLY, nothing will break moving forward.

I hope that you’ve found this useful. If you have a different way in which you’ve handled this situation, feel free to leave a comment below!

Canvas App record set Regarding field

For the last few days, I’ve been working on an app. Not just any app – it’s a canvas app! (It actually happens to be a COVID-19 related app, for local authorities to use to contact vulnerable people & check they’re OK etc).

Now, my background isn’t canvas apps – it’s the model-driven app approach. I’ve been doing this for years – after all, my experience goes back to Microsoft CRM 3.0! So that’s all really nice & easy for me (even with some of the more modern ‘tweaks’ that have been brought in). Canvas apps, on the other hand, are very different from what I’m used to, and are taking quite a bit of getting used to.

See, the following example is easy in a traditional model-driven app:

Create a contact, save various attributes to the contact record. Then create a task, and set the Task Regarding field to the contact that you’ve just created

Looking at that, my mind says ‘easy-peasy’!. I create the fields required for the contact entity (& task entity as well, if needed). I then add them to the entity form/s (creating or modifying the form view/s as well). Finally, I create a Business Process Flow for users on the contact entity, and append the task creation to it. Simple, and done – not much time needed to be spent.

But when needing to do this as a canvas app, things change around QUITE a bit. I can’t create that business process flow, and I have multiple screens to have all of the information on.

Now, if I could add the ‘Regarding’ field to the edit form grid, and apply formatting to it, I could hopefully then just submit & save the grid. However, that unfortunately doesn’t work. I can add the field, but when I do so, I get the following:

So that doesn’t work. Hmmm – how then should I go around doing it?

I did (obviously!!) take a look online. Here I came across this wonderful article all about polymorphic lookups (https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/working-with-references). Having read, & re-read through it, I’m STILL not understanding what exactly I should be doing by this!

So I was stumped. Thankfully we have an amazing community, and on reaching out to someone within it (thanks Eric!), I was helped out. I therefore thought to write this post up, so that it can help others as well.

There are two parts to this, for my specific scenario:

  • Saving the contact record down. This is a matter of using (in my case) the command ‘SubmitForm.ContactInformation’ on my contact form screen. I can then also set a variable if I want to, to refer to the Contact record GUID (hey – I’m trying to be cool here & show that I can!)
  • Finding a different way to save my task record. I accomplished this using the Patch statement – this thankfully wasn’t too difficult for me to grasp how it worked.

So, how did I go about using the Patch statement? Well, the function is referenced here – https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/functions/function-patch. With Eric’s help, I soon started to see how to do it.

What I did was add the following line in my Patch statement when I was wanting to save the task: ‘Regarding:ContactForm.LastSubmit’ (‘ContactForm was the name of the form for the contact information). What this did was write into the record the GUID for the contact record that I last saved.

An alternative to this would be to use a variable instead, and set it there.

Thankfully this all worked. I’m now able to create Task records and set their Regarding field value to the Contact that I set up before them – which is the exact thing that I was trying to do!

I hope that this has been helpful – leave a note in the comments if you’ve found another way of doing this.

Wave 1 2020 – Search Behaviour Changes

Having applied the Wave 1 2020 release to several of my test environments, I was browsing around to see the new functionality within it, which is pretty good. However, there was something that I wasn’t expecting, which was a little startling to see! This is around the way that the search behaviour is now working within the system.

What am I talking about? Well, for years, users have asked me if they could search within a specific view. Ie if we had a view set up for ‘My accounts’, where the user is set as the account manager, it would show only the accounts where that condition applies. However when using the search functionality, the system would search & return ALL results that match the search criteria (eg if searching for ‘Apple’, it would return all accounts with the word ‘apple’ in them, regardless if the user was set up as the account manager or not).

Explaining this to users was probably the most complicated thing, in my experience (well, that, and having to then trawl through hundreds, if not thousands of records, where it’s a common word). But for the most part, they accepted it. OK – we all moved on.

Let’s see an example of this. The screenshot below shows an account that exists within one of my Sandbox environments (which has the Wave 1 2020 update applied to it):

I’m now going to search for it within the entity itself (more about Global Search at the end of this post):

Hold on – it’s not showing up! What is happening here – is the system OK???

Let me explain what’s happening. Previously (before the Wave 1 2020 update was applied) it would indeed show up in the search results.

But this has now changed! The system is now performing searches ONLY within the view that the user is using. The reason why it’s not showing up here? Well, it’s because I’m not set as the owner of the account – a different user is (and I’m using the ‘My Accounts’ view, as seen in the previous screenshot):

If I now change my view to ‘All Accounts’ and repeat the search again, the record now shows up:

I hadn’t come across this in my perusal of the release notes. On going back to it and digging deep, I found the mention here – https://docs.microsoft.com/en-us/power-platform-release-plan/2020wave1/microsoft-powerapps/improvements-quick-find-search-experience-grid.

Amusingly there’s actually even a little hint within the system for this. If you look at the entity search box, this is now the text that’s being displayed within it:

There’s also an additional feature as part of this – if you’ve prefiltered a view using column value, searching within the entity will RESPECT the pre-filtering!. OK – now this is indeed incredible:

My thoughts on this is that it’s going to be a double-edged sword. For years, we’ve been educating customers about how searching works, and now this has the potential to change things up.

Thankfully it’s actually possible to turn this off, and revert back to the way that searching has always worked – this is likely to be needed to be done quite a bit. To do this, go to Settings, Administration, System Settings, and change the value for Categorised Search to ‘Yes’ (it’s about 1/3 of the way down the page):

It would have been nice if Microsoft had made people more aware of this, in my opinion.

Please note that this only applies to searching within an entity itself. Global Search (for the moment) still uses the Quick Find view, and returns all results (regardless of filters).

Canvas Apps & Lookup Fields (CDS)

Canvas apps are amazing. Seriously so. I’ve been developing my knowledge around them, and it’s incredible what you’re able to do with them. Clients are loving them as well, with how quickly it’s possible to develop something that’s visually appealing.

From a licensing perspective when looking at using data into/out of D365, I’m usually using the CDS as the datasource. This means that apart from a handful of scenarios, users would be licensed with a PowerApps licence, rather than a D365 one.

With all of the wonders and benefits that canvas apps brings, there still are some limitations. One of them I came across earlier today pertains to lookup fields.

Using Contact as an example, we see that ‘Currency’ is a lookup field:

When inserting a Gallery control, it’s possible to choose up to 3 fields to be displayed (depending on the layout selected). However, when we go set the value to a lookup field from the entity, they’re not there – it’s not possible to select a lookup field to be displayed. As you can see below, there’s no possibility to select ‘Currency’ (which we saw above):

I have no idea why Microsoft chose to do this, as it is possible to select a lookup field when connecting using a D365 datasource (though admittedly even then it only seems to work in limited situations, such as for Opportunities)

So, ways to work around it:

  1. Don’t! Accept the situation for what it is, and hope that Microsoft allows it in the future
  2. Create a custom text field for the entity. Create behaviour (eg with Flow, though keep in mind scalability of the solution and Flow run limits – you don’t want to be burning through all of them!) to copy the value of the lookup field to this new field (ensure that if the value is changed, it updates the custom field value as well). You can then use this field to be shown on the gallery control
  3. For lookup fields that are actually lookups (see item 4 below), it’s possible to change the ‘Text’ property for the field. Using the example above of Currency, the formula needed would be ‘LookUp(Currencies,’Currency Name’ = ThisItem.Currency.’Currency Name’) (without the extra quotation marks). See left side image below for example of this
  4. For lookup fields that are actually of type ‘Customer’ (yup – special behaviour…thanks Microsoft!) there’s a different way that you’ll need to do this. You have to use the AsType function to declare  the type (i.e. account) of the relationship (this can also work for Owner fields, where the owner can be a user or a team). The formula needed to show the Account name would be AsType(ThisItem.’Company Name’,[@Accounts]).’Account Name’. See right side image below for the example of this

I’d also like to give thanks to Jason Almeida for his help and assistance with finding solutions – he’s an amazing guy!

What are your thoughts on this?