Finding out how Raphael got into cooking, the joys of simplicity in dishes, and how we can prepare ourselves for issues/failures that we know may come up!
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.
Well, the title is a bit of a mouthful, I’ll admit. Hopefully though this brings some good information, and can help people out.
Cases are wonderful things, and can be used for tracking client interactions, compliments/complaints, and so many other things. What cases do have is the ability to resolve them, and provide information around the resolution.
Now, the standard way of doing this provides the following screen:
There’s the ability to set the Resolution Type (being a dropdown, aka Choice, field), & putting in free text for the Resolution itself (allowing us to track information around it). There are also time fields, which can be used for working out the time spent, as well as any time that’s going to be chargeable.
Now when going in to modify these, we’d think to open up the Case Resolution table. However, this isn’t actually the right place to do it. Instead, we’re needing to update the Case table itself, as the Care Resolution items comes from the Case Status field!
Somewhat annoyingly, it’s not possible to do this through the new ‘Maker’ interface:
In order to actually handle this, we need to switch across to the Classis editor to set this up. This could be because it’s actually a situation of having both parent & child entries. What I mean by this is that there’s the actual status (being Active, Resolved or Cancelled), and then a reason under each one. Hopefully at some point it’ll be updated into the new UI, so that we can do it from there.
We’ll need to change the Status item to ‘Resolved’, & can then add in the options that we want:
After adding them, we need to save & publish, and then they’ll show up for us, and are able to be selected:
So that’s great – we’re able to customise it. But what if we’re wanting to customise the actual ‘Resolve Case’ form itself? Not everyone wants to show Time/Billable Time on it (quite a few of our clients ask us to remove it), and perhaps they want to add additional custom fields.
So from the usual perspective of doing this, we’d open up the Case Resolution table, create new fields as required, and modify the existing form (we’re not able to create any other forms for this specific table). After all, this is how we’d do it for any table in the system (whether a standard one, or a custom one). This is going to be the Main form, rather than the QuickCreate one:
We save & publish it, and then would open up a Case record, click ‘Resolve Case’, and expect to see it. However, that doesn’t happen, which has been most puzzlingly to me!
It turns out that there are two things needed to be done in order to get to see our ‘custom’ form (though it’s not really custom, as it’s modifying the default form, but whatever).
We need to modify security permissions for users, and is a critical requirement. An example of this is shown below:
2. We need to enable customisable dialogues. Yes, it’s a setting that needs to be updated in order for users to see the custom layout of the form. If we don’t do this, they’re shown the default form, even though we’ve modified it! Seems a little strange that the system seems to have this concept of a ‘shadow’ form, but I guess that’s how it is.
To do this, we need to go into the Service Management settings area. I usually launch this through the Customer Service Hub app, though it’s available through several of the other standard apps as well:
Once there, we need to click into the Service Configuration menu item, and then change the ‘Resolve Case Dialogue’ option as shown below:
Remember to click the ‘Save’ button to save this.
Finally we can go back to our Case record, click ‘Resolve Case’, and look what appears!
So in summary, it’s definitely possible to modify & change the way that Case resolutions works in the system. It does take a little bit of fiddling around with settings in different areas, which can be confusing if we’re not used to this, but can give a great result in the end.
Have you ever come across this, and wondered how to do it? Have you developed Case Resolutions any further? Drop a comment below – I’d love to hear!
Some of you, no doubt, will be wondering what exactly this post is about. Others will be all too familiar with this, and likely be nodding their heads as they read through it. Cryptic, right? Well, let’s begin….
Our community. It’s amazing – that’s simply the only way to describe it. People give talks at User Groups, engage on the forums, hack at hackathons. Outside of our ‘day jobs’, we continue with sharing the knowledge & love that we have for things. Look around the world, and the number of user groups is astonishing. So many great people out there who are speaking, blogging, mentoring, etc.
Of course, socialising was a major part of this as well. Go to any event, and afterwards you’d likely find a large percentage of people going to their local ‘watering hole’ (aka pub/bar/drinks location), and continuing to chat around things. It’s one of the reasons why I was drawn into the community several years back.
Then in early 2020, COVID-19 hit. Suddenly there were no user group meetings in person. Most of us were working from home, spending a lot (most?) of the day on Teams calls. We couldn’t get out, we couldn’t socialise, and we definitely couldn’t hang out & have drinks (non-alcoholic drinks ARE counted as drinks as well, for the record!) together. It was depressing, and weighed us all down.
Then a hero stepped forward. Admittedly, due to it being Chris Huntingford, he was already a hero in most people’s eyes, but this took things to the next level. He realised the need for social interactions in this ‘new world’ that we were facing, and started a virtual pub. The Bespoke Badger was born!
Running on Thursday evenings, starting off around 6:30pm UK time, and going…until the last person left. People would drop in to say hi, catch up with friends, and drop off again. Some stayed for a few minutes, others stayed for hours. Some even would stay the whole night!
It wasn’t just the UK though. Plenty of people from multiple European countries joined as well, and soon became regulars. The USA would start coming online too (even though it was during the workday there) across multiple time-zones. One person (no names!) there even re-organised their Thursday schedule so that no-one would book meetings whilst it was ‘Bespoke Badger time’. Even people based in the Far East, Australia & New Zealand would come on as well (being Friday their time).
Sure, there were regular topics brought up again & again, but we all had a laugh from them. Welcoming new members to the Badger, sharing laughs & sadness together. Even better, no queues at the bar to get drinks, as all it usually took was a short trip to the kitchen! Some technology talks as well (careful not to mention SharePoint!), but SO many different subjects & topics that came up.
Larry Merkelis took over as the Landlord, and would throw open the (virtual) doors with aplomb every week.
Now you might be thinking ‘why would I spend my evening on yet another virtual call’? Well, from my experience (& those of others), it’s not just ‘another virtual call’. Time flies by, we’re all having fun, and then suddenly you realise it’s past midnight, and you’ve been there for 5+ hours.
Why am I mentioning all of this? Well, for a few reasons. For me, the Bespoke Badger has become a staple in my weekly schedule (which my family all knows about), and a way to keep up/connect with friends, as well as meeting new people.
The Christmas Party (held this past weekend, organised by Tricia Sinclair & Alison Mulligan) had a total of 87 people from around the world joining in live, covering 11607 minutes (that’s almost 200 hours!) across them. Awards were presented, and I was honoured to received the ‘Social Butterfly’ award, presented by Dona Sarkar.
Current times can be challenging, but I feel that the Bespoke Badger makes it so much more bearable for so many of us.
You may have come for the nerdy tech stuff, cool apps and awesome Microsoft gear, but you will stay for the heart-warming, encouraging people. We’ll all welcome you with open arms, cheer you up, help you out and take so much care.
Finding out about Daryl’s love of reading with his children, why we should push our limits, an amusing driving story involving woodchucks, and why exactly he denied new laptops to everyone in the company!
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.
Today’s post is around record security, and how Power Automate can really be quite useful with this!
Let’s take a quick recap of how security works (which is applicable to both Dynamics 365, as well as Power Platform apps). We have the following:
Security roles, which are set up with specific privileges (Create/Read/Update/Delete etc) across each entity table, as well as for other system permissions
Users, who can have one (or more) security roles applied to them (security roles being additive in nature)
Teams, who can have one (or more) security roles applied to them. Users are added into the team, and inherit all permissions that the team has (much easier than applying multiple roles on a ‘per user’ basis)
That’s great for general security setup, but it does take a system admin to get it handled. Alternatively, of course, it’s possible to use AAD Security Groups which are connected to security teams within Power Platform, and users added to them will inherit the necessary permissions.
But what if we want to allow users who aren’t system administrators to allow other users access to the records? Well, it’s also possible to share a specific record with another user – doing this allows the second user to see/access the record, even if they usually wouldn’t be able to do so. This is really great, but does require a manual approach (in that each record would need to be opened, shared with the other user/s, and then closed).
I’ve been working on a project recently where we have the need to share/un-share a larger number of records, but with a different user for each record. We’ve been looking into different ways of doing this, and obviously Power Automate came into mind! We didn’t want to use code for this, for a variety of reasons.
The scenario we had in mind was to have a lookup to the User record, and with populating this with a user, it would then share the record with them. This would be great, as we could bulk-update records as needed (even from an integration perspective), and hopefully all would work well.
So with that, I started to investigate what options could be available. Unfortunately, there didn’t seem to be any out of the box connectors/actions that could be used for this, which was quite disheartening.
My next move was to look at the user forums, & see if anyone had done anything similar. I was absolutely excited to come across a series of responses from Chad Althaus around this exact subject! It turns out that there’s something called ‘Unbound Actions’, which is perfect for the scenario that we’re trying to achieve.
There are two types of actions available within Power Automate:
Bound actions. This are actions that target a single entity table or a set of records for a single entity table
Unbound actions. These aren’t bound to an entity type and are called as static operations. They can be used in different ways
There are quite a lot of unbound actions available to use:
It does require some JSON input, but when formatted correctly, it shows along the following lines:
The different parts of this works as follows:
Target is the actual record we’re wanting to apply the action to
SystemUserID is the actual system user, and we also need to specify the odatatype
AccessMask is what we’re wanting to do when sharing the record (as there are different options available for sharing, ie ReadOnly, Edit, ShareOnwards, etc)
Using this, we’ve therefore built out the following scenario:
Field added to the record, looking up to Users
Relevant users who are able to access the record can set this lookup field to be a specific user record (who doesn’t have access to this record)
Power Automate flow fires on the update of the record when it’s saved (filtering on just this attribute), sharing the record with the selected user
The user then gets an email to notify them that the record has been shared with them, with a URL link to it (it’s somewhat annoying that there’s no inbuild system notification when a record has been shared with you, but I guess that’s something we’re having to live with!)
They can then go in & access the record as they need to
We’ve also given some thought to general record security, and have additionally implemented the following as well:
If the user lookup value is changed, we obviously share the record with the new user that’s been saved to it
Using a different Unbound Action (RevokeAccess), we remove the sharing of the record with the previous user (we have another field that’s being updated with the value of it, which we’re using to pass the action in, as otherwise we don’t actually know who the previous user was!)
All in all, we’re quite happy that we’ve managed to come up with this solution, which is working splendidly for us. Also, major thanks to Chad for his assistance in getting the syntax correct!
Have you ever needed to do something like this? Did you manage to implement it in some way? Drop a comment below – I’d love to hear how your experience was!
This is something that stumped me fairly recently. It’s also something that I was trying to work out what I should use at the title for this post! Let me share what happened.
I’m working on a project that’s quite critical (COVID-19 related). This is a project that we’ve built something around Dynamics 365 as an additional wrapper, to provide specific functionality for the pandemic. It’s being rolled out (the same solution) to multiple clients, and is only using the functionality from Power Platform. No custom code at all.
Now, before going into the specifics around it, let’s take a moment to revisit what a lookup field is, and what it does. Essentially a lookup field connects two tables together (wow – that felt strange not to use the word ‘entity’!). In the front interface, it’s used for a 1:N relationship.
So for example, we can have a lookup from Account to Contact, to set the primary contact for the account. The user navigates to the field, searches for the record they’re wanting to associate, and saves it.
Underneath, there’s a relationship that’s automatically created between the two tables, showing the way that the relationship will go (ie 1:N or N:1). This is created on both sides (more on that another time around dependencies), and most people will never need to modify it
When I first started with this particular project, I got the solution, and deployed it into the Dev environment (for the project that I was on). On testing it out, I found something very interesting. We’re using the Case (Incident) table, and there are various lookup fields on it. One of these was already populated with a value. Hmm – that’s interesting, I thought. It was a new deployment, and we hadn’t set any static data up yet at all. So how could it already be populated?
How is this being set, when I’ve not entered it into the system as a record…
Furthermore, I was unable to save the Case record. When I tried to, I was getting an interesting error:
On drilling down into the error log (which admittedly is actually getting better in the details shown in it, thankfully!), it turned out to be because I didn’t have access to the referenced record (in the lookup field). It just didn’t exist.
So the lookup field value was coming in with a hard-coded GUID (record identifier). But how was this being done, especially if there weren’t any records (of that type) in the system at all?
From my experience of things, I could think of two ways in which to populate a lookup field with a hard-coded value:
Through a ‘real-time’ Power Automate flow, on create of the record. It’s possible to set a GUID value in the flow, and then it would be set
Through custom code, running on the form. Again, it’s possible to hard-code a GUID there, and then set the field
However on checking both options, none of them were happening. No Power Automate flows touching the Case record, and no custom code at all on the Case.
It was then, digging through the other parts of the solution, that I saw various Business Rules. For those unfamiliar with these, I’ll quote from the official Microsoft documentation around them:
By combining conditions and actions, you can do any of the following with business rules:
Set column values
Clear column values
Set column requirement levels
Show or hide columns
Enable or disable columns
Validate data and show error messages
Create business recommendations based on business intelligence.
I’ve used Business Rules (somewhat extensively) before. However on going into the one for the Case table, I found that something was happening that I wasn’t aware could happen! It’s actually possible to set a lookup field value through it:
I spy a lookup option
Even though we’ve deployed the solution from the original development environment to a different environment, this is still set. But there are no records that are available:
I had never thought that it would be possible – to set a static value (eg a number, or some text), fine. But to set referential data? Wow.
Obviously this can be quite helpful. The bit that it’s NOT helpful though is when deploying the solution to another environment (as this situation was). It doesn’t help if you re-create the record that it’s referring to with using the same record name, as it’s using the underlying GUID (which you can’t re-create). This really does take solution deployment into a whole new perspective, where you need to be careful around these sorts of things as well.
So something new that I’ve learned (I do try to learn something new each day), and specifically around an area I thought I knew quite well. It did take some time, but I’m glad that I (finally) found the root cause of it, and identified what was causing it.
Have you ever had something like this happen, where you’re searching & searching for the cause of it? Drop a line below – I’d love to hear!