Tag: advanced find

Searching tables within the Modern Advanced Find

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:

  1. Click in the search box at the top of the screen
  2. At the bottom, click the ‘Search for rows in a table using advanced filters’ (that’s a mouthful as well, isn’t it!)

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:

  1. Table is part of the model-driven app
  2. Table is enabled for unified interface
  3. Table is valid for advanced find (set on the table settings)
  4. User has read access to the table (handled through security roles)

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!

Working with Opportunity Close table

I’ve recently had the experience of working with the Opportunity Close functionality within Dynamics 365, and given what occurred, thought it would be useful to document this so that others are able to see this as well. There are many scenarios in which we’d use this, and being able to give a comprehensive solution to clients does make all of the difference!

There are three areas that I’d like to cover:

  • Working with Opportunity Close table
  • Challenges with data
  • Power Automate to the rescue!
  • Caveats

So let’s get started then!

Thanks to various members of the community such as Matt Collins-Jones, Andrew Bibby & others, who helped me along the way

Working with Opportunity Close

The Opportunity Close functionality within Dynamics 365 (& yes, I’m going to refer to it as this, rather than Power Platform) is used to provide information around why an opportunity is being closed. This is regardless of whether the opportunity has been won, or it’s been lost. It’s still quite important to track the information around it, so that companies can understand better how the market views the products it offers, how it stacks up against others, etc.

The default path in the system is to create a lead, and then qualify it. Qualifying a lead then automatically creates an opportunity record, which further information (quotes, etc) can be entered against. An account record (if company information is specified) is also created:

Updated Solution Release: Lead Qualification Version 2.0.0 for Microsoft Dynamics 365

On the opportunity record, users are able to show if it’s been won or lost by clicking an appropriate button on the toolbar:

Doing this brings up the Opportunity Close pane on the right hand side of the screen:

Now it’s possible to customise this screen. In fact, the screenshot above shows 3 custom columns that have been added to it already in the system I was in.

To do this, we go to customise the solution (in the Maker Experience), and add the column/s that we’re wanting to:

Next, we need to remember to add it to the form! Otherwise it’s not going to show up. If we’re wanting it to appear on the side bar, then it’s important to customise the ‘Quick Create’ form version, to make our customisations show up.

Note: We’re able to put conditional visibility of the column/s if we want to, based on whether the opportunity is won or lost, using Business Rules. I haven’t done so in this scenario, but you’re obviously able to do so if you want to

Remember to save & publish the form, and then it’ll display within the system for users. Brilliant!

Challenges with data

So we’ve gone ahead & created the custom columns, and users are actually using them to record data. Wonderful – that’s exactly what we’ve been wanting to achieve.

OK – let’s now review the data so that we can see overall what’s happened with our opportunities. Of course we’re wanting to do this simply & easily, so we’ll open an Advanced Find window, go to the Opportunity Close table, add columns from the associated Opportunity, and….hold on. Opportunity Close ISN’T displaying in the Advanced Find????

It’s just NOT there. In case you’re wondering if you saved/published things correctly, or forgot some system setting, stop worrying. It’s not you – it’s the system.

See, Opportunity Close, though a table in its own right, is a SPECIAL sort of table. It doesn’t show up, and can’t be directly queried. I know – frustrating. I felt exactly the same way.

On digging deeper into things, I found out that there’s actually an activity record saved. It’s possible to query against this:

However, and this is the BIG catch, it’s NOT possible to return custom columns when carrying out this query. The search will ONLY return the (system) columns that are present for activities. So this leaves us with a problem.

Essentially, though we can set up custom columns to track the data that we’re needing to, it’s not possible (through the front end) to query it. This sort of negates what we’re trying to achieve here overall, and is a pain.

So what’s the way round it? Well, it’s actually going to be Power Automate!

Power Automate to the rescue

In order to handle our issue, what we need to do is the following:

  • Add custom columns to the Opportunity table (these should mimic the custom columns that we’ve added to the Opportunity Close table)
  • Use Power Automate for automation purposes!

The first step is easy. We need to go & create custom columns on the Opportunity table. These WILL show up in the Advanced Find search. They obviously need to be the same as the custom columns on the Opportunity Close table. If we’ve used Choice or Choices there, point the Opportunity column to the same source (it’s a good argument for using Global, rather than Local, choice/s).

We then can go and create a Power Automate. This should trigger when an Opportunity Close record is created.

Note: For this, I’ve made it so that it runs under the user triggering the action, rather than a system account. This is to keep in line with licensing limits etc

You’ll then need to add a ‘Get Dataverse row’ step, and get the Opportunity Close record that has just been created. This is annoying, but for some strange reason the trigger doesn’t present the custom columns/values in the JSON that it returns. Hopefully Microsoft fixes this at some point, but for the moment, we need to work around it.

The last step is to add a ‘Update Dataverse row’. This should point to the Opportunity table, & we can simply map the values across (from the SECOND step, NOT the first one – VERY IMPORTANT).

Once this is all done, save & test it, and you should see it working. I generally don’t add the Opportunity custom columns to the form, but rather leave them for querying against.

Caveats

It’s important to keep in mind that when an opportunity is marked as either won or lost, it’s then closed, and changed to a read-only state. That’s how the system is designed to be, and makes sense.

However it’s ALSO possible to re-activate a closed opportunity, and then close it again. Ie a single Opportunity record could have multiple Opportunity Close records against it. This solution won’t handle this (it would need to be built out further – the Opportunity record itself will only show the values from the latest Opportunity Close action, so please do keep this in mind!

Have you ever come up against something like this? How have you handled it? I’d love to hear – please drop a comment!

Strange behaviour with views

Normally when I write a blog post, it’s about sharing some cool features, new functionality, etc. However this post is going to be a little different, because I don’t actually have an answer (yet!) to what is going on here.

Let me explain the situation.

I’m needing to show some very specific data for reference purposes. For the purposes of this, let’s say that I’m looking at Contacts, and needing to report on Phone Calls. The reason is to identify Contacts who are frequent callers. My criteria are as follows:

  • At least one phone call (that has the Contact as the Regarding value) need to have a specific field set
  • At least one phone call (that has the Contact as the Regarding value) needs to have its Activity Status as Open

These two conditions are separate. So the contact essentially needs to have at least 2 phone calls against them, with each one meeting one of the conditions. There can be more than 1 phone call record with the same condition – that’s not an issue here.

Back in the (good old) day, I’d have written some cool SQL to return this data. Two Left Outer Joins, and we’d be done. However I can’t do that now (I’ve recently started dipping into FetchXML, which is an entirely other story to cover at some point). So I’m having to use the Advanced Find to check that I’m getting the right data.

This isn’t the easiest of things to do. I’m needing to start from Contact, go to Phone Call, go back up to Contact, & go back down to Phone Call. But hey, this is what it looks like:

So with this set up, I run the query, and get some results (in this specific scenario/time, there are 3 results). I go through the data to check that the results are actually satisfying my requirements, which they are:

Wonderful – let’s move forward then!

My next step is to look to set this up as a system view. To do this, I go to the Power Apps Maker (http://make.powerapps.com/), open my solution & find the Contact entity. Opening it, I switch to the Views tab:

I create a new view, add the columns I need, and then open up the Filter Criteria to start setting this up. I’m using the Advanced Find as a reference guide for the conditions I’m needing to use. Going through it, I replicate the values across:

That looks about the same as the Advanced Find, right? It’s laid out slightly differently, but that’s just the designer. OK – let’s go ahead to save/publish it, and see it it in the app:

Hold on. There’s only 1 record showing up there. Admittedly it’s in the list that came from Advanced Find, but what’s happened to the other 2 records?

So I go to check the data. I had already done this before, but I thought that perhaps I overlooked something, so I checked again. Nope – all of the data is fine/correct. There should indeed be 3 records showing up in the system view, but 2 are missing…

Note: As an aside, I do know that this isn’t permissions related. I’m doing all of this as a systems administrator with full privileges to everything. So it’s not that

OK – next steps:

  • Clear browser cache, reload and see if they’re showing up (useful tip – Control+F5 does this!). Nope, they’re not showing
  • Use Incognito mode, log in and see if they’re showing there. No, they’re still hiding away
  • Use a different browser, with a different system administrator login. Unbelievably they’re still being very shy, and refusing to appear!

Even more confusing about all of this is something truly perplexing. I can open up Advanced Find, select the system view (without doing ANYTHING else) & click ‘Results’. When doing this, all of the records appear! So in the entity view they’re not, but when I use that same system view through Advanced Find, they are!

I’m scratching my head at this. It just doesn’t make sense. I have no idea why this is happening. Reaching out to others, they also don’t seem to have any idea either.

My next step (I’m feeling SO proud of this, and so dev!) was to check the FetchXML. Perhaps there was something underlying in it that’s causing this? Using the FetchXML Builder in XrmToolBox, I loaded both views up, and compared them. It’s crazy – they seem to be exactly the same! (well, some cosmetic differences with where aliases appeared on the line, but this wouldn’t affect it):

At this point, I’m thinking that there are some magic elves under the hood, squirrelling away the data. It has to be the only logical reason for this, right?

The only thing I could find in the FetchXML that might make a difference is that there’s a ‘Distinct’ clause at the top of it in the one that’s working:

Why this would cause the issue, I have NO idea. Views return distinct results in them anyhow, so I’m not sure what this is actually doing here.

Regardless, using FetchXML Builder I updated the code, and WOW – it worked! I’m now returning 3 records in my system view! Absolutely strange, but hey – if it’s working now, who am I to question it…

I’m going to try to raise this through official Microsoft Channels, and see what I might be able to find out from them. However if you’ve come across this (or similar), or have some ideas about how to work around it, I’d LOVE to hear from you!