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!
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:
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.
Well…not to fear! When dealing with field values in PowerApps Entities, there’s an extremely helpful visual cue for this (outlined below):
How it works is simple:
You open up an existing field in the Entity Designer, and edit something, anything at all, within it
You save it
Bingo! The icon shows next to it!
When you then Publish the entity, the icon disappears
Now, what could we possibly do with all of that time saved…..
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!