Finding out from Mat as to how he got into social media creation, his time in Army training, and how the challenges along the way have taken him to where he is now!
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.
DLP (or Data Loss Prevention) is a very important capability in the Power Platform. With being able to bring together multiple data sources, both within the Microsoft technology stack as well as from other providers gives users amazing capabilities.
However with such great capabilities comes great responsibility. Of course, we trust users to be able to make proper judgements as to how different data sources can be used together. But certain industries require proper auditing around this, and so being able to specify DLP policies are extremely important to any governance team.
Being able to set how data connectors can be used together (or, in the reverse, not used together) across both Power Apps as well as Power Automate flows is imperative in any modern organisation.
To date, Power Platform DLP capabilities have existed that allow us to be able to categorise connectors (whether Microsoft provided or custom) into three categories. These categories specify how the connectors are able to function – they’re able to work with other connections that are in the same category group, but cannot work with connectors that are in a different category group.
So for example, it’s been possible to allow a user to create a Power App or a Power Automate flow that interacts with data from Dataverse, but cannot interact with Twitter (in the same app or flow).
With this approach, it’s possible to create multiple DLP policies, and ‘layer’ them as needed (much like baking a 7 layer cake!) to give the functionality required per environment (or also at the tenant level).
Now this has been great, but what has been missing has been the ability to be more granular in the approach to this. What about if we need to read data from Twitter, but just push data out to Twitter?
Well, Microsoft has now iterated on the DLP functionality available! It’s important to note that this is per connector, and will depend on the capabilities of the connector. What we’re now able to do is to control the specific actions that are contained within a connector, and either allow or not allow them to be able to be utilised.
Let’s take the Twitter connector as an example:
We’re able to see all of the actions that the connector is capable of (the scroll bar on the side is a nice touch for connectors that have too many actions to fit on a single screen!). We’re then able to toggle each one to either allow or disallow it.
What’s also really nice are the options for new connector capabilities.
This follows in the footsteps of handling connectors overall – we’re able to specify which grouping they should come under (ie Business, Non-Business, or Blocked). As new connectors are released by Microsoft, we don’t need to worry that users will automatically get access to them.
So too with new actions being released for existing connectors (that we’ve already classified). We’re able to set whether we want them to be automatically allow, or automatically blocked. This means that we don’t need to be worried that suddenly a new connector action will be available for users to use, that they perhaps should not be using.
From my perspective, I think that any organisation that’s blocking one or more action capabilities for a connector will want this to be blocked by default, just to ensure that everything remains secure until they confirm whether the action should be allowed or not.
So I’m really pleased about this. The question did cross my mind as to whether it would be nice to be able to specify this on a per environment basis when creating a tenant-level policy, but I guess that this would be handled by creating multiple policies. The only issue I could see around this would be the number of policies that could need to be handled, and ensuring that they’re named properly!
Have you ever wanted these capabilities? How have you managed until now, and how do you think you’ll roll this out going forward? Drop a comment below – I’d love to hear!
Chatting to Robin to find out how he got to love mountain biking, a recent biking episode, & what happened when a last-minute finance app was deployed using SharePoint lists as the datasource!
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.
Talking to Roma about gardening in a small space, touching on pigeons, and delving into MDM. No, it’s not Master Data Management, it’s Dynamics 365 Marking 1.0!
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.
Interesting title to start a blog post with, right? I can’t tell you how much I tried to work out what to call this, but then I figured that I’d just put at a high level what I’m going to be talking about!
So let’s start at the beginning. Environments within Dataverse. An environment is essentially a container for all sorts of different components, such as data models, apps, code, etc.
Examples of what an environment can contain
Within the Power Platform, there are different types of environments. As a quick recap, currently we have the following:
Default. Every Power Platform tenant has a default environment. We of course shouldn’t be using this for any proper development!
Production. Used for any Line of Business application
Sandbox. A sandbox environment is any non-production Dataverse environment. Isolated from production, a sandbox environment is the place to safely develop and test application changes with low risk.
Trial. Used to take out a trial
Trial (Subscription Based). Used to take out a trial when there’s subscription licensing in place
Developer. Personal environment, limited to one user. Previously called the Community plan.
Teams. Used when an app is created within Teams, to use a Dataverse for Teams environment. Doesn’t have full Dataverse capabilities, and has various limitations
Support. Only able to be created by Microsoft support during a support case. Is essentially a clone of an existing environment, used for diagnosis purposes.
Now, sandbox & production environments are automatically backed up – backups occur continuously, using Azure SQL Databases underneath. It’s also possible to create a manual backup instance of an environment as well, which usually takes a few seconds to carry out (restoring a backup, on the other hand, takes quite a bit longer…).
When restoring an environment, it’s not possible to restore to a production environment (though the backup could be from a production environment). It’s only possible to restore the backup to a sandbox environment – you’d then need to promote the environment from sandbox to production.
Let’s move away from backups for a moment. When we create an environment, we have the ability to select that the environment should be enabled for Dynamics 365:
This is actually a REALLY IMPORTANT CONSIDERATION! At this point in time, it’s not possible to update from a Power Platform Dataverse environment to then bring in Dynamics 365 capabilities. What this means is that if an organisation starts with just Power Apps, and then wants to expand into using Dynamics 365, IT’S NOT POSSIBLE TO DO THIS NATIVELY. Even Microsoft Support can’t do anything around this – you’d need to create a new environment, enable it for Dynamics 365, and then restore a backup to it.
It’s something that a lot of us would like be in place, but we’re not sure if it’ll ever come about. This is a tweet of mine from 2019 that Charles Lamanna responded to (I was SO thrilled that he actually responded to me!!):
However, it’s still not in place. As a result, we recommend to all clients that when they deploy a Dataverse environment, they toggle the switch above (Note: A Dynamics 365 license is NOT needed to toggle this). Once this has been toggled (without deploying any of the Dynamics 365 apps), the Dynamics 365 apps and functionality can be installed/deployed at a later point in time.
There are actually various capabilities, such as the Data Export Service (yes, I know it’s now been deprecated) that actually relied on having the environment enabled as a Dynamics 365 environment in order to work. We found this out the hard way at a client, and had to do an overnight environment re-build to get the capabilities in place.
But there’s one other thing to consider around the differences between a native Dataverse environment, and an environment which has been enabled for Dynamics 365. This is around backups.
Now, backups are of course very important (thankfully they now occur automatically, as mentioned above – I remember my onpremise days when needing to run these manually!). But there are also some important differences for backup behaviour when it comes to environment types. See, it turns out that environments aren’t actually equal in backup behaviour. This is what actually happens:
Sandbox environments (all types) – backups retained for 7 days
Dataverse production environment (not enabled for Dynamics 365) – backups retained for 7 days
Dataverse production environment (enabled for Dynamics 365) – backups retained for 28days
See that? Having Dynamics 365 enabled for an environment gives you FOUR TIMES as much backup retention time! That’s incredible!
Dataverse Environment enabled for Dynamics 365 – 28 days of backups available!
So not only are you able to then upgrade to Dynamics 365 applications at a later date, you then also have more peace of mind (hopefully you don’t need to use it though!) around keeping backups for longer.
This is really cool – I hope it helps you plan your environment implementation strategy! Have you ever come up against issues when using environments, or the type/s of environment? Drop a comment below – I’d love to hear!
Chatting to Joy about her love of reading, the education system she came up in, & how getting caught up in the ‘focus zone’ can make us forget the world that’s going on around us!
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.
Talking about Foyin’s love of animated movies (including times away from the kids!), the ‘joys’ of DLP changes, and what might happen as a result of doing work on an app, to then find out that though you thought you were working in the Development environment, you actually weren’t!
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.
Most of us are aware of the knowledge article functionality within Dynamics 365. For those who aren’t familiar with it, knowledge articles can empower users within any organisation with access to existing information.
Types of knowledge articles can include solutions to common issues, product or feature documentation, answers to frequently asked questions (FAQs), product briefs, and more. Being able to have access to this means that customer service agents can easily answer queries, without needing to spend (lots of) time investigating what’s happening, and find resolutions.
Note: At this point in time, the Knowledge Article functionality is still a restricted table within Dataverse. It requires either a Dynamics 365 plan, Customer Engagement plan, or Customer Service Enterprise plan
It’s great to be able to share information around within an organisation. There is native functionality for this, with the ability to share a knowledge article record directly with other users by clicking the ‘Email a link’ button:
Note: This is performed through going to the to Knowledge Article table, opening up a record, and carrying out the functionality from there. It cannot be done through access to Knowledge Articles on the Case form.
This will create an email (in Outlook) with a URL to the specific record:
This is of course very helpful, but is only internally facing. It’s not possible to send this to a customer who’s having an issue, as the customer wouldn’t be able to access the URL!
It’s also not particularly useful if we think about how customer service agents work, as they’d need to be moving through different areas of Dynamics 365.
Thankfully knowledge management is built into the customer service capability within the system. So for example, when we open a case record, we have the ability to search for knowledge articles directly in here:
This of course works much better from a customer service agent perspective – they have all of the functionality that they need in just one area.
So how can we share information directly with customers? Copying and pasting the information into a chat or email interaction seems quite manual and bothersome.
But there’s no need to do this manually, thankfully! Again, we have in-built functionality to handle this:
Clicking the little email icon on a knowledge article creates an email within Dynamics 365 (so you’ll need to have email enabled for users, to make this work!) with the information copied into it:
OK – this much easier. We can send customers the exact information, so that they then have it to hand.
But here’s a new scenario – what if we wanted to send MULTIPLE knowledge articles to a customer at once? We could of course click the email icon each time, but that results in a separate email being created for each one, which means the customer will be receiving multiple emails. Not the most ideal scenario, surely?
Well, thanks to my amazing colleague Ryan Hunter-Stott, there is actually a way to do this! In fact, technically you could say that there are two approaches, but holistically it’s the same thing – it involves an email.
So, you can either:
Select to email the knowledge article to the customer, or
Create a blank new email
Within the email message, we have the following option to insert a knowledge article:
Clicking this brings up an interface to be able to search for knowledge articles. Clicking the envelope icon will then insert the information in the email:
Now it’s not possible to select multiple knowledge articles in this window. BUT, it IS possible to click the button to open it up again, and insert a second one. And then a third one!
This can then be sent out to the customer, with all of the information contained in it!
It’s a nice little touch, and I think it definitely beats copying & pasting information into an email manually!
Have you ever thought about this scenario? Did you find this functionality, or end up doing it in a different way? Drop a comment below – I’d love to hear!
Talking to Joy Kirkwood about how she got into knitting to begin with, some interesting projects she’s done, and why it is SO important for us to embrace the concept of a growth mindset in order to enable us to move forward!
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.