Using 8 year old technology or today’s technology for field mapping challenges?

A project I’m working on has thrown up an interesting problem. I’ve done my best to check my sources across the net for solutions (as we all do) but all I can find is a couple of posts from 8 years ago on this topic. Let’s see if

1. This solves my problem and
2. Has anything changed in that time to make the process a bit slicker?

But first, let me explain the issue...

A customer of ours at Tecman has started a new Microsoft Dynamics 365 CRM project and wants to store some audit details of some suppliers they work with. There will be one record per audit holding things like when the audit was done, who did the audit, when it’s due to be done again, etc as well as any documents produced during that audit which will be in a linked SharePoint folder. Seems straight forward enough. Now for the problem.

Because there could be a long chain of audits for a supplier, they want to have a couple of links to other audits on the record; a link to the previous audit and, if it’s available, a link to the next audit. These fields can then be used for various things such as:

• If the ‘next audit’ gets filled in, we know that we can deactivate the current record as we know it’s been replaced.
• If the ‘next audit’ is empty, we know that it’s the current audit and we can make sure that our views reflect this.

However, when I tested this and created a new audit from an existing record, it certainly created the record but the ‘previous’ and ‘next’ fields weren’t as expected.

Time to revisit the field mappings. When you go into the setup of the field mappings (which is, annoyingly, still something that requires ‘Switch to classic’), there’s lots of them that I want but there’s one in there that I don’t want.

I want the first one in there, so the new audit is linked to the older one but, as you can see, it’s also filling in the Next Audit field on the new record – this isn’t correct. So let’s delete that mapping.

The 8-year-old advice I found was to add some JavaScript to remove this link. When I looked at what was suggested is done, I thought that it should work but isn’t there something a bit more modern that we can do to sort this out? Surely the Power Platform has allowed us to move our solutions on in 8 years…

So, let’s try the JavaScript.

function onLoad(executionContext)
 {
   var formContext = executionContext.getFormContext(); 
   if (formContext.ui.getFormType()==1)
     formContext.getAttribute("tm_nextauditid").setValue(null);

Does it still work?

Yes, it does. It’s good to know there’s a backup. So what are the other options?

As I said, this is a new project being built on the Microsoft Power Platform, so a Flow would be the obvious choice and the logic would be simple. On creation of an Audit record, if the Previous Audit contains data, clear the value in there. Let’s give it a go.

Does it work? Yes. Eventually. The record is created with Next Audit filled in but the Flow does correct this after a few moments.

To make it a bit quicker, let’s try a real-time workflow. The logic is the same as the Flow so we get…

Again, this does work and it does it a bit quicker – when the record opens up, Next Audit is populated. When the Save button is pressed, it does clear this out ready for it to be used.

One more thing to try is a business rule to set the default value of this field. I started writing this with the opening condition being ‘If Next Audit contains data’ then adding a default value.

However, when we go into the properties for the default value, we can select the field but the options available are limited.

So I can either set it to another field’s value or to a specific record but there’s not a ‘Clear’ option to remove the value. We’ve seen from earlier that adding another lookup to Audit will simply populate this with the same value so using the ‘Field’ option isn’t going to work. When selecting ‘Value’, I get an option to choose a record but there’s nothing that allows me to clear this out (as ‘Remove Value’ is greyed out): leaving this blank looked promising until I tried to save the record.

In conclusion, we have a few options available but which one works the best?

I’ve got to say it’s the JavaScript – it does what it needs to do and it does it when the record opens up. This will provide the least confusion for the end-users as well as not putting extra information in the audit history of the creation and then update of this field.

So to answer my original question – is there something more modern that we can do that is as effective as 8 years ago? No. We looked at what was in the Microsoft Power Platform, as well as what we had in Microsoft Dynamics 365 CRM before going right way back to the start when XRM was implemented. But we’ll continue to ensure we follow this mantra at Tecman to evaluate new technology for the best solution, not just rely on something done before.

For more information on field mapping or Microsoft Dynamics 365 CRM please get in touch with us here.