Limit Opportunity Creation To Originate from Leads or Contacts
The Audience for this article is Salesforce System Administrators. The administrator should also have access to the Response Management configuration pages.
This article explains steps you can use to restrict the creation of Opportunities so that they can only be created from lead or contact records. This is useful in organizations either running in passive mode, or with passive users.
For opportunities created during lead conversion this is a seamless process, but for those created off a contact record, it is 'tough love' to those users, so this approach should be only be used once the requirement to create opportunities from leads or contacts has been made clear to the sale team. We call it 'tough love' because when the user creates the opportunity, they will arrive to the opportunity edit page, and after making any edits, they will be prevented from saving the opportunity if it did not originate from a contact record, and this will frustrate them.
Also in the steps below we will highlight other considerations such as exceptions to the validation rule, and the impact on unit tests. In addition to this approach, you may want to remove other 'new opportunity' buttons from any related objects as a way to restrict the ways users can create opportunities. And of course, always build this first and test in a sandbox ;-)
First Step - Create Fields
Create the following fields. For the Id fields, if you have an existing field performing the same function you may use it instead of creating new fields. You can also use your own field names - this is just an example of the data required.
Lead: 18 Digit ID - this is a formula field that displays the lead's 18 digit ID.
This field does not have to be on page layouts but should be visible to users creating opportunities.
Contact: 18 Digit ID - this is a formula field that displays the contact's 18 digit ID.
Make a note of the field API name you created or that of the field you will be using.
This field does not have to be on page layouts but should be visible to users creating opportunities.
Opportunity: Originating Record ID - this is an 18 character text field.
Make a note of the field API name you created.
Grab the ID of the field you created - The ID for the field can be found in the browser URL. The example below is a lightning URL that shows the opportunity field Id.
This field has to be visible to users creating opportunities (with types you want to validate for ) and needs to be added to any opportunity page layouts that those users will be using. It should be placed low on the fold hidden amongst admin type fields so that salse users don't notice it.
Second Step - Field Mapping
Lead Field Mapping
Map the lead field to the Opportunity Originating Record ID field.
From Lead fields list select the 'Map Lead Fields' button and make sure the lead field is configured to populate the opportunity field.
Contact Field Mapping
Now we're going to use Response Management to map the contact field to the Opportunity field. This is standard Response Management functionality and can be used to map other contact fields to the opportunity as well.
Go to Setup > Installed Packages > Configure link by Full Circle Response Management.
Click on the General button.
You will see an Opportunity Creation Query String setting.
What we are going to do is populate this query string with our new fields, both for classic and lightning. If your users are unable to switch to classic you only need to use the lightning syntax. If you already have values in this string - join your new queries to the existing ones with the & symbol. You will also join your classic and lightning query strings with the & symbol.
Classic syntax is: Opportunity field Id = contact API Name, so in our example it is: 00NP0000007eGU0=X18_Digit_ID__c
Lightning syntax is: Opportunity field API name = Contact API Name so in our example it is: Originating_Record_ID__c=X18_Digit_ID__c
Put together to support classic & lightning the whole query string is (note that there are no spaces):
00NP0000007eGU0=X18_Digit_ID__c&Originating_Record_ID__c=X18_Digit_ID__c
Create your query string using your orgs field Ids and API Names. Enter them in this field , and remember to click the Save and Return to Main button at the top of the configuration page.
Third Step - Plan
We are ready to create the validation rule that brings this all together but first think about this rule and plan it out.
What opportunities or users or automations should be excluded from this requirement? You will want to include this in your validation rules.
This validation rule will likely impact unit tests (and so unit test coverage) do you have a global bypass process so that this validation rule will not fire for unit tests? Is there an opportunity helper class that always creates opportunities with the same data that you can use as a basis to bypass the validation rule criteria? Do you want to take some time to create a mechanism that standardizes bypassing opportunity validation rules?
Fourth Step - The Validation Rule
Here is a very very simple example - your validation rule should not look like this because you're going to add exceptions, right? ;-) The validation error should be at the top of the page and not call out the Originating Record ID field - we don't want reps to put nonsense in there to get past the validation rule.
- Add your opportunity criteria bypasses
- If you are concerned about reps populating the field with nonsense - you can require that the field begin with 00Q or 003 and be 18 digits long.
Fifth Step - Test, Deploy and Monitor
After you've tested in the sandbox you can deploy. In production create a report to monitor the Originating Record ID field to make sure it's being populated with valid values (unless you added this to the validation rule).
Comments
0 comments
Please sign in to leave a comment.