Thoughts & musings from a Microsoft Business Applications Ninja!
Talking to Vivek about his love of home automation (we may find out how many devices he currently has!), how he got into API usage in the first place (hence being called thatAPIguy), and lessons learned from cycling!
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.
Finding out from Simon about how he decided to go about starting a car collection, why he loves playing around with Tesla’s so much, and discovering just what happened one day when he was diving the English Channel!
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 for a start, I know that the title of this blog post is somewhat of a mouthful. It’s definitely longer than my usual titles! However I felt it important to do so, given the functionality that I’m actually going to talk about…
So here goes!
As part of the Wave 1 2022 release, both for Power Platform as well as Dynamics 365, we have the new ‘Modern Advanced Find’ capability. This replaces the (legacy) Advanced Find interface, which has been around since almost the beginning of Microsoft CRM…that’s quite a few years!
So within a model-app (as this covers both Power Apps as well as Dynamics 365), the classic Advanced Find was a good friend. Though using the legacy interface (& sometimes being VERY slow to load initially), we could create powerful queries through it. Being able to specify conditions, span multiple tables (with needing to understand the data model), we were able to show & filter data as we needed to.
When loading the Advanced Find interface, we could select from any of the tables within the system, with a LONG list presented to us for this purpose:
Now, just because we could see all tables (system & custom) within the list didn’t mean we could view all data within the tables. Oh no – the security roles applied to users limited what we could do.
In fact, users having security roles with NO permissions on certain tables would NOT see those tables appearing in the Advanced Find interface. Even when users had permissions on tables, but these permissions were limited (such as only being able to view our own records), the data results would be filtered based on our security role access to the records within the table.
OK – all good so far. Well, in general – there have been various complaints over the years about the Advanced Find functionality. So finally, Microsoft updated it to the ‘Modern Advanced Find’.
This needs to be enabled by a system administrator in the environment settings:
So in order to access the Modern Advanced Find, we need to do the following:
After clicking this, we then get presented with the following interface:
Once we select a table (we can only select one table, as this will be the primary table used), we then switch screens to set the filters that we want to use:
Now here’s where things got a little strange. On the filter screen, we can select related tables to the primary table (ie connected through a relationship), and we get EVERY table that’s available for this. So if we’re starting with the Accounts table, we can then select from the following:
So in this list, I can see tables such as Emails, Invoices, and various others as well. In fact, it’s actually a very extensive list (limited, of course, to all tables that have a relationship in place with the Accounts table, and which the user has access to through their security role).
But if I look back at the initial list of tables, I’m MUCH more limited in my choice:
This, to me, was quite confusing. After all, what if I wanted to start the search from a different table – one that isn’t shown in this initial list?
So I started doing some digging. Initially, I thought that these tables are the ones defined in the sitemap (ie the app navigation). This could mean that I’d need to somehow create a section that shows all tables within it, just to be able to have them searchable.
Thankfully, it turns out that this isn’t actually the case. What’s happening is that with the new Modern Advanced Find, tables need to be directly associated to the APP, to be able to show up and use for search purposes.
Actually, there’s some more granularity around this. The list of tables available to search on (as the primary table) need to meet ALL of the following criteria:
So essentially, the ability to search tables within an app is now limited to the tables that have been associated to the app itself! This could be very helpful in various scenarios, when users can be quite confused with seeing the entire list of tables.
To do this, we’d edit the app, and add it to the list of tables available through the app designer (note – we don’t have to include them in the sitemap, if we don’t want to display them in the app navigation):
So this now makes sense, and I think it’s a good step forward.
Also thanks to my colleague Bill (who’s an AMAZING Customer Success Manager!) for his collaboration on this.
What are your thoughts on the Modern Advanced Find? Are you finding it better for functionality? Is there something that you feel is missing, or that you’d like to see in it? Drop a comment below – I’d love to hear!
Talking to Julian about the wonders of using IoT & AI capabilities with cats, communicating openly with customers, & putting internal comments into project documentation!
#community #learning #sharing #ownthemistake #theoopsfactor #MVPBuzzhttps://youtu.be/82JkiaLQjtE
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 with Girish about the wonders of having a child (hint – she may be advanced in certain scientific items already!), his love of cricket, and being able to keep positive through very challenging situations.
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, isn’t it? I thought to do something that might grab peoples attention, and this was the best that I could come up with! So, let’s get into the scenario, the issue experienced, and how we managed to resolve it.
The scenario on this project was as follows. We’ve been implementing a customer service solution for a sales company, that manufacture multiple products, under multiple brands. Currently there are multiple systems used for order entries, which at some point will be moved to a single system.
However for the moment, they’re wanting to be able to carry out holistic customer service across all brands, to be able to enable all customer service agents to have access to the same data, customers able to be serviced in the same way, regardless of brand, etc.
As a result, Dynamics 365 Customer Service was the ticket, and has many standard capabilities that addresses the need of the customer.
Now, whilst sales (aka orders) will not be handled within Dynamics 365 itself, we didn’t want the customer service agents to have to look up order information in the ordering systems. Instead, we wanted to be able to bring the sales/order information into Dynamics 365 for reference (at some point it’s likely that the customer will actually use Dynamics 365 capabilities for sales as well).
In order to do this, we’ve had some amazing data architects bringing the data together into Azure Data Factory (ADF)) from the multiple order systems, and then pushing the data into Dynamics 365 (users have read-only view of it).
With bringing in the data, we were looking to capitalise on the native functionality of Dynamics 365, namely the ability for columns to be automatically calculated. An example of this would be bringing in the order line amount, the tax amount, and then having the total order line amount automatically calculated. This is standard system functionality, and when working in Dynamics 365, has many different uses across the system.
Now, it’s important to note here that as we’re not actually handling orders within Dynamics 365, we’re also not holding a ‘proper’ product list within Dynamics 365 itself. However, orders need to show product information on them (bit useless otherwise!), so we’re using the capability of ‘write-in products’.
Note: If you haven’t come across write-in products before, it’s actually a really great item. Essentially, it allows products to be entered for opportunities, quotes, orders etc (wherever products are used), but for when the product/s aren’t in the system product catalogue. Write-in products allow you to simply type the name of a product or service, & then type in the price. This is very useful if, for instance, a product isn’t yet available in the product catalogue, but you still want to be able to quote it. In our scenario, we’re using write-in products to avoid the need to manage the product catalogue itself. It’s also helpful for when you don’t want to use price lists, as all products need to be associated to a price list.
So we start off the data migration, and it’s looking good. No issues being reported by the integration…
But, then users go in to the UAT system to check through things, and find that when looking at orders, the totals aren’t being calculated:
Hmm. That’s strange. So we started to look at what could have caused this problem…
For clarification, we didn’t want to auto-calculate the information within ADF, and then push it into the relevant Dynamics 365 columns. We wanted to be able to rely on the system working in the way that it should!
Finally, we found out why the calculated columns weren’t working. There’s actually a system setting that governs how this works:
With this set, the auto calculations are now working in the system:
So, thankfully we managed to get this working, and everything went smoothly from that point.
Have you ever been caught out by something similar? I’d love to hear – please drop a comment below!
Talking to Zoe on our shared interest of low & slow BBQ, the importance of UI/UX in app development, and how imposter syndrome can affect us all.
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.
Chatting to Jeff around how he got into cooking, model/canvas app integration, and the benefits that OCM can bring to projects – quite interesting!
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.
Chatting to Michelle about her long-time interest in anime/manga, the wonders of #PowerAutomate cloud flows, & what might happen as a result of an unexpected loop…
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.
Let’s face it, and call a spade a spade (or a shovel, depending on where in the world you happen to be). Security roles are very important within Dataverse, to control what users can (& can’t!) do within the system. Setting them up can be quite time-consuming, and troubleshooting them can sometimes be a bit of a nightmare.
Obviously we need to ensure that users can carry out the actions that they’re supposed to do, and stop them doing any actions that they’re not supposed to do. This, believe it or not, is generally common sense (which can be lacking at times, I’ll admit).
Depending on the size of the organisation, and of course the project, the number of security roles can range from a few, to a LOT!
Testing out security can take quite a bit of time, to ensure that testing covers all necessary functionality. It’s a very granular approach, and can often feel like opening a door, to then find another closed door behind the first one. Error messages appear, a resolution is implemented, then another appears, etc…
Most of us aren’t new to this, and understand that it’s vitally important to work through these. We’ve seen lots of different errors over our lifetime of projects, and can usually identify (quickly) what’s going on, and what we need to resolve.
Last week, however, I had something new occur, that I’ve never seen before. I therefore thought it might be good to talk about it, so that if it happens to others, they’ll know how to handle it!
The scenario is as follows:
Now, initially we had some issues with different teams not having the right level of access, but we managed to handle those. Typically we’d see an error message along the following lines:
We’d then use this to narrow down the necessary permissions, adjust the security role, re-test, and continue (sometimes onto the next error message, but hey, that’s par for the course!).
However, just as we thought we had figured out all of the security roles, we had a small sub-set of users report an error that I had NEVER seen before.
The scenario was as follows:
Now this was a strange error. After all, the users were able to open/edit the lead record, and on checking the permissions in the security role, everything seemed to be set up alright.
The next step was to go look at the error log. In general, error logs can be a massive help (well, most of the time), assuming that the person looking at it can interpret what it means. The error log gave us the following:
As an aside, the most amusing thing about this particular error log, in my opinion, was that the HelpLink URL provided actually didn’t work! Ah well…
So on taking a look, we see that the user is missing the Read privilege (on what we’re assuming is the Lead table). This didn’t make sense – we then went back to DOUBLE-check, and indeed the user who was trying to carry out the action had read privileges on the table. It also didn’t make sense, as the user was able to open the lead record itself (disclaimer – I’ve not yet tried doing a security role where the user has create/write access to a table, but no read access..I’m wondering what would happen in such a scenario)
Then we had a lightbulb moment.
In truth, we should have probably figured this out before, which I’ll freely admit. See, if we take a look at the original error that the user was getting, they were getting this when trying to assign the record to another user. We had also seen that the error was only happening when the record was being assigned to certain users (ie it wasn’t happening for all users). And finally, after all, the error message title itself says ‘Assignee does not hold the required read permissions’.
So what was the issue? Well, it was actually quite simple (in hindsight!). The error was occurring when the record was being attempted to be assigned to a user that did not have any permissions to the Lead table!
What was the resolution? Well, to simply grant (read) access to the Lead table, and ensure that all necessary users had this granted to them! Thankfully a quick resolution (once we had worked out what was going on), and users were able to continue testing out the rest of the system.
Has something like this ever happened to you? Drop a comment below – I’d love to hear the details!