Sonoma Partners Microsoft CRM and Salesforce Blog

No Code Needed: Requiring Fields when Closing an Opportunity in D365

A recent requirement came up on a project to require specific fields when marking an Opportunity as Won.  The reasoning for this request is that you want your sales team to be able to quickly enter their opportunities without having to fill out a bunch of required fields.  However, you may also have specific fields that are needed upon closing the opportunity as Won, that you encourage your sales team to capture along the sales process.

At first, I thought that you could accomplish this by requiring fields in the last stage of the Business Process Flow.  Nope, that’s not the case.  Even if there are required fields in the BPF at any stage, users can go ahead and close the Opportunity as Won or Lost at any point.

Consider the Opportunity below.  Notice how Contact, Est. Close Date, Est. Revenue, and Budget Amount aren’t required.


However, you want this data captured before someone can mark the Opportunity as won.  You could invest in a developer and have them write a plugin to prevent save, but that would be costly.

The easy “no code” option is to use a Synchronous Workflow.  Head over the Settings –> Processes to create your new workflow.  Make sure to uncheck “Run this workflow in the background (recommended)” in order to make the workflow synchronous (or in other words, the Opportunity form won’t refresh until the workflow has run and completed).  This is key, because we’ll add a step in the workflow that will prevent the save, if our fields aren’t populated.


Your workflow would need to run After the “Record status changes”, and it will only need three steps:

  1. A Check Condition that will continue if the Status is set to Won.
  2. A Check Condition that will look and validate that all required fields have data.
  3. A step to stop the workflow as “Canceled” with an error message, if one of the required fields is missing data.

The overall workflow would look something like the following, along with the individual steps:





Now, when someone attempts to close an Opportunity as Won with those four fields above not populated, they’ll receive an error message as shown below.  All of this was done without a single line of code, and should the business requirements change and warrant future modifications, you can easily hop back into the workflow and make those changes quickly.


If you’re looking to leverage Dynamics 365 to better monitor, track, and move through Opportunities, let us know! We’d be happy to discuss your existing environment and how we might be able to help.

Contact Us

Topics: Microsoft Dynamics 365 Microsoft Dynamics CRM Microsoft Dynamics CRM Online

Spring '18 Puts Duplicate Detection to Work For You

Today's blog post was written by Troy Oliveira, Principal Architect at Sonoma Partners.

CRM systems are all about the data they contain and insights that they provide to users. Good data keeps an organization moving smoothly, but bad data can stop users dead in their tracks.

In Spring ’18, Salesforce has added another feather in the cap of Salesforce administrators when it comes to managing duplicate data: the Duplicate Data Job.

Salesforce already has strong means for proactive duplicate detection at the desktop or mobile application level by either completely blocking duplicate data or at the very least warning users that they are creating duplicate data. However, depending on a various number of factors such as sharing rules, Lightning Sync and API interactions, duplicate data can creep in to even the best of Salesforce implementations.

Until now, if you wanted to be able to periodically check for duplicate records, you would have to use a third party duplicate management tool. With Spring ’18, Salesforce released the Duplicate Data Job to Performance and Unlimited edition customers. This new job type allows for you to analyze your CRM data by executing a duplicate detection rule against your existing data.

Let’s take a look at how it works.

First, I’ve created a set of duplicate Contacts, all named various versions of John Doe.

Salesforce Duplicate Contacts
Click the image to expand.

Next, since my users have reported seeing a lot of duplicate data, I created a new Duplicate Detection Rule.  My new rule performs fuzzy matching against First Name, with an exact match against Last Name.

Salesforce Duplicate Rules
Click the image to expand.

Now that this is in place, users will be alerted when they try to create a contact that potentially already exists. But what about my existing data? That’s where the Duplicate Detection Job comes in to play. The next screenshots show navigating to the Duplicate Detection Job setup menu item and kicking off a new job by selecting a duplicate rule to evaluate.

Salesforce Duplicate Jobs
Click the image to expand.


Salesforce Duplicate Detect
Click the image to expand.

Depending on how much data you have, this process could take awhile. I would recommend executing these types of jobs during non-business hours, if possible, so that it doesn't risk adverse effects on your users.

Salesforce Duplicate More Jobs
Click the image to expand.

Once it has completed, you will see that the job has moved into a completed status.

Clicking into the job will give you an overview of the data that has been compared and how many potential “duplicate sets” it has found. A duplicate set is a group of records that the job has deemed could be duplicates of each other.

Salesforce Duplicate Jobs Setup
Click the image to expand.

You can then click the menu to the right side of the grid and view the duplicate sets that have been discovered.

Salesforce Duplicate Job Summary
Click the image to expand.

From here, you will be able to see the duplicates and merge records that need to be merged.

Salesforce Duplicate View
Click the image to expand.

Salesforce Duplicate Compare
Click the image to expand.

Salesforce Duplicate Merge
Click the image to expand.

Woohoo! Now I've got fewer duplicate records.

Salesforce Duplicate Related
Click the image to expand.

BUT, you’ll also notice that not all of the duplicates that I created were actually tagged as duplicate records.  This brings just a word of wisdom.  Duplicate matching is only as good as the rules that you create and the system executing the rules.  Salesforce’s fuzzy match saw that Jon and John were likely duplicates, but could not match Jonathon to either of those.  This goes to prove that duplicate management is not an exact science, it is definitely an artform and may take complex rules or attacking duplicate data from multiple angles to get it right.

I am excited to see how much customers use this in real life applications.

Topics: Salesforce