Well, somewhat of a mouthful of a title for this article, but I couldn’t think of a better way to put it!
You know the scenario – we’ve all been there. There’s a custom form (for a system entity, or even a custom entity). Multiple sections, tabs, and multiple fields that are required. Users are going through data entry, but SOMEHOW have forgotten to fill one (or more???) in, and they’re just not able to save the form!
Well, Microsoft has now upped the quality of the user experience, and OH BOY was I SO excited to see this!
Previously when you clicked the Save button, it just wouldn’t allow you to save. It told you that it was missing required information, and you had to go search to see WHICH field(s) you had missed out on.
But search no longer. For now the notification bar has a whole new behaviour:
Firstly, it tells you that there are notifications, and to select to view (Note: If you’ve only missed out one field, just skip to step 2!)
Then when you click on it, it tells you which (required) fields have data missing from them!
Even better, if you click on the notification for a specific missing field, it even takes you to that field – no longer do you have to try to find where it is!
This is truly amazing, and will help enable users (and relieve their frustration) so much!
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:
Don’t! Accept the situation for what it is, and hope that Microsoft allows it in the future
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
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
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!
In Model Apps, it’s extremely easy to set out the fields on the form as you wish to. It’s a simple case of drag and drop.
However when looking at Canvas Apps, it’s not so straightforward (at least not initially!).
When adding a form to the app, you can then select which fields you’d like to appear (assuming you’ve connected it to a data source with fields, eg a CDS entity). These then show up, but aren’t always in the order that you’re wanting them to.
You can’t drag and drop the fields on the form itself – the interface doesn’t allow you to! So how exactly is this done then?
It’s actually done on the field selector slide out – you click the field that you want to change the placement of, and move it up (or down) the list.
This will then change where the field is then displayed on the form (you can also do some clever stuff with the number of columns being used etc). Quite a nice way to easily update them.
The thinking behind this came out of a conversation I was having with someone last week. I had asked them to briefly document their thinking behind what they were creating on the PowerPlatform (especially with PowerApps). This would help me (and others) when reviewing the created item/s, to understand the thought processes and logic paths.
I mentioned to them that traditionally when coding, developers would include comments in the code itself. This would help other developers in reading through it, understand why things had been done in a specific way, and not in another way. Heck – even though I have minimal coding experience (mostly SQL), even I’ve done that.
Apparently they had NEVER heard of this. Somewhat surprising, as they’re from a technical background.
This got me to thinking – with the shift from Microsoft to LowCode/NoCode, it would be great if there was somewhere where comments could be loaded when doing PowerPlatform stuff. This is especially true when trying to follow a line of thinking from people who are more orientated towards the business side of things, rather than the tech side.
So – how/what would YOU suggest to handle this? Please comment!
In my previous post (Creating a Flow to set record image), I created a way to bring an image into the CDS from an external source. This works well (obviously!).
There are 3 stages involved in the process:
The next stage of thinking is if we would be doing this in an enterprise environment, how would we do things differently? Talking to Mike Carlton, there are a number of things that we’d need to take into consideration, including (but not limited) to:
Security
Storage
Compatibility
Classification
Record management & lifespan
Let’s talk about these, and go into more detail for each
Security. There are a number of ways in which people try to hide attacks. One of these ways are in images – it’s possible to include a .exe file (or similar) – the user downloads a normal looking image, which is actually an attach vector onto the computer. To minimise the risk of this occuring, the image file would need to be scanned by appropriate antivirus/antimalware first (which is a Flow action, using Azure Security for this purpose). Incidentally Microsoft use the same heuristic engine across all of their estate, so some people would want to also incorporate a second one as well
Storage. As everyone knows, storage is important! And depending on what type of storage is being used, pricing can vary greatly (anyone who’s costed D365 storage against Sharepoint storage against Azure Blob storage will know this). It’s therefore important to keep on top of this, as otherwise it’s very possible that the storage costs will increase rapidly! It would therefore be rational to include a file size check, to avoid someone trying to use an image file that’s hundreds (or thousands) of MB’s.
Compatibility. In the scenario here, we’re using an image. There are many different image types, and when scaling up we should implement checks to ensure that the image type is indeed one that’s supported (by whatever system we’re pushing the image into). In scenarios for other data types, it would also be important to check (and enforce when required).
Classification. When bringing data into a system from external resources, it’s essential that correct classification (ie metadata) is stored against the data. This ensures that the system is kept
Records Management & Lifespan. When scaling up functionality, it’s important to start considering who should have access to the data, and if any necessary security controls should be put in place to manage this. It’s also important to understand how long data should be kept with the system, and if processes should be implemented in order to redact and/or remove the data after a specified period of time (this is extremely relevant with GDPR now being in place)
You’re in the middle of editing the values of specific fields within Dynamics. Suddenly a colleague comes over to your desk to ask you something, or you get a phone call (obviously to assist with a technical matter!). You spend some time on the call, and deal with whatever is needed. You hang up, and look back at the screen.
Hold on. The train of thought is gone. You’re looking at the overall entity, and can’t remember if you did update a specific field, or you didn’t? And if you did, did you already publish the entity, or not?
You’ll need to open up each field that you’re needing to update, to see if you already dealt with it or not. MAJOR pain and headache, and loss of productivity.
I’ve recently started my journey into the Microsoft Power Platform, and am digging into how it all works.
Late last night I decided to start playing around with entering the data fields directly into the entity first (the aim is to drive a Model App eventually). Managed to get some stuff done, then headed to bed.
This morning I brought it all up again, and picked up from where I left off. Something immediately jumped out at me – the fields I was adding were shown in bold (as outlined in the image below)
This intrigued me – originally I thought that perhaps I was creating a field that was named the same as a default schema, and the system was letting me know this somehow. However, this wasn’t the case at all.
What it actually is, is showing the new fields that have been added (whilst the entity hasn’t yet been saved). Once you save the entity, then the bolding of the name disappears.
So quite a useful way to see new fields, and work out exactly where you are with things!
