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!

Environments & Security

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.

Image result for security

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 .

DevIntegrationUATStagingTrainingProductionSupport
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!

Environments for Projects

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.

Image result for technical environment

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!