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.
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)
Having recently completed several exams, including the new MB-900 Fundamentals for Dynamics365, I thought it would be useful to set out how the new exam structure works, and what paths can be taken within it. This post is meant to be for D365 CE, not for F&O (I’m hoping to do a separate post on that another time).
The first question that usually comes up around certifications is ‘why should I take the exams – I know how to use/configure/deploy the system!’.
The answer to this is actually quite easy – if you know the stuff, then the exams won’t be too hard for you. They’ll also give you a better overview of things, especially due to the new curriculum (eg including cloud offerings, etc).
Not only is it rewarding for you to take (and pass!) them, it shows that you’re able to do so (and you get cool badges…thanks Microsoft for gamifying things lol). Additionally it can also help your company to qualify for different Microsoft Partner tiers, which can be quite important in the grand scheme of things (I am NOT going to talk about the recent IUR situation…)
It can also help when applying for a job position, as recruiters will check to see if you’re current with the latest exams. Experience is great of course, but they’ll want to know why you may not have any (recent) exams to show your knowledge.
The first exams in the series that I’d recommend to take are:
The MB-900, as per the name, goes over the fundamentals of Dynamics 365, and also gets you used to the new format (it’s now 60 minutes, with approx 25 questions). There are now drag’n’drop questions, multiple choice answers, and ‘journey style’ questions (these are when the question presented depends on the answer given for the previous question)
The MB-200 exam covers the different deployment types, configurations and integrations, and click-based customisations. It expands on the base that’s set out in the MB-900.
The next question usually asked is ‘what area/app should I specialise in’? That’s ALSO quite simple to answer – there are (currently) 4 options available for exams (after the MB-900). These are:
So, pick which one you think would be most suitable to your role, and take them. Of course, that’s not stopping you taking some of the OTHER exams as well – why not try to get the whole set in!
Study tips:
Read the syllabus! Microsoft doesn’t just draw them up randomly – they cover the material needed. They’ve also been through Beta phases where feedback has been given (which Microsoft usually take some note of). It will give you an idea of where the focus is, what’s needed to check, etc
Practise – hands on experience. You really DO need this now. Fire up a trial, start playing around. Use the syllabus as a guide for this – if it says that you need to know about cases (eg case management, case routing, case rules, parent/child cases), then make sure that you DO know how to do these!
Talk to others who are studying at the same time – perhaps try to make a study group. I was fortunate enough to join twice-weekly session for one of my exams, hosted by an amazing Microsoft Trainer.
When taking the exam, if you come across something that you don’t know, and are guessing the answer to – DON’T CHANGE THE ANSWER LATER ON. In this sort of scenario the gut reaction is usually 85% correct, and it’s better to leave it than try to second guess yourself.
Also, don’t stress out about the exams. They’re not the Big Bad Wolf – once you do them, you’ll see that they’re not absolutely crazy. Sure, you may have to guess a question or two, but even very experienced people do that.
Following on from my post last week (https://thecrm.ninja/2019/07/05/environments-for-projects/) where I talked about the different environments for projects, I thought it would be good to talk about security relating to it as well.
What I’ll be discussing below is best practise for projects that relate to (external) clients.
However, there are usually some small differences when it’s an internal project for a company – security is can be slightly more relaxed (after all, the dev teams are usually the ones responsible for rolling the project out, providing on-going support, new features, etc). It’s also the case that internal developers (usually) won’t be prevented from seeing what the actual company data is.
The essential principle is as follows: Users should be restricted to only using environments that they are needing to access
This follows Best Practise for system security, as well as some common sense (it’s surprising how many times this can seem to be lacking!)
Access to the environment/s will depend on roles/s of the person, along with infrastructure that is in place. Users should not be granted access to any environment that they have no need to access at all .
Dev
Integration
UAT
Staging
Training
Production
Support
Team
Developers
✔
✔
Consultants
✔
✔
✔
✔
Clients
✔
✔
✔
✔
Note: There may be exceptional cases people are required to access the Production instance for a client. In such a circumstance, it is vital and absolutely necessary to have a complete audit trail to cover this, setting out the reason/s for it, along with all actions that are taken within the system. This should be ideally be via email, or any other system that may be present to allow a definitive time-stamped communication of request and sign-off
There is an extensive security model within Dynamics365 that can be used to enable and control this, if needed (eg for users to have access to one part of the system, but not another – this could be due to the system holding restricted access data, for example).
Have you come across any cases where this wasn’t followed, and caused issues? Feel free to comment – I’d love to hear about what happened!
As as tech guy, I immediately know what someone is referring to when they’re talking about environments (within a technical context, of course). However there are a large number of (non) technical people who have absolutely no idea what the word ‘environment’ means, leaving aside how they are used.
The aim of this post is therefore to demystify what environments are, the different types, how they’re used, etc.
Caveat: There may be specific circumstances in which these may differ, eg for Dynamics F&O
So firstly – what is an environment?
This is simple to answer – an environment is a full (technical) system. There may be multiple different systems contained within the same environment (or they could be split out). There will be different environments used (more details below) in any company
Incidentally, people may also use the word ‘instance’ instead of ‘environment’.
The next question is – how are environments used?
Thankfully this is also simple to answer – environments are used to enable different parts of the technical system roll-out process. Each environment is unique (and should usually not be connected to each other
Types of environments
There are quite a few different types of environments needed. Listed below are the ones that are usually considered to be MVP (no, not Microsoft Valued Professional….in this context it means Minimum Viable Product)
Development This is the environment that the development team will use for coding and configuration, as well as initial testing of code Once code is stable, it will be promoted to the next environment
UAT (User Acceptance Testing) This environment is where the client/business will access to test the system. Each development item will have a logged story, and these will be tested against. They will either pass (and then be signed off) or not pass (with explanations given as to why they haven’t passed) and be sent back to the development team
Note: It may be possible to use the UAT instance for training, and all client/business users to access it. This will depend greatly on the resources needed, project timeline/progress, etc. It is not usually advised to do this though
Staging This environment is where data migration is tested out, to ensure that all data from the previous system/s are successfully migrated (with any transformations that may need to take place).
Note: It may be possible to combine the UAT and Staging instances, if the proposed system is very simple and not complicated/large
Production This is the actual LIVE system for the company
Customisations, code etc are promoted through the different environments with releases. It’s important to ensure that these are carried out properly and scheduled in, especially when applying a release to a production environment. I’ll cover how this should be done, and what things to bear in mind, in a future post.
There are also several other types of environments that may be being used, depending on the type/scale/scope of the project:
Training This is an instance with all customisations and code (to date) along with data that is used to train all client/business users. Any updates in functionality to test environments would need to be replicated to this environment as well
Integration Depending on the other system/s that D365 will be exchanging data with (both in and out) it may be necessary to have a specific instance set up to test out the integration with these other components
Support A clone of the Production environment for use in support cases eg attempting to recreate issues/bugs that have been raised
If you’ve come across any other types of environments, please do comment!
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!
