Lead Qualification Process in CRM 2013

After an upgrade to CRM 2013, in sales module, confusing factors for some like me, is the linkage between Opportunity-Account-Contact. In CRM 2013, Quality Lead process behaves a bit differently. When it comes to mapping, as CRM 2013 is now done away from most of the popup dialogs, just as it was while qualifying leads earlier.

Instead, on lead qualification, lead is directly converted to opportunity while a decision for creation/mapping of account/contact to opportunity, is taken dynamically.

Below scenario table describes the behaviour of QualifyLead process on Opportunity-Account-Contact mappings.

Scenarios Scenario with Lead record Account Creation Contact Creation Effect on Opportunity
 1 Existing Contact mapped but no account info No No Existing contact mapping is carried forward, but no account mapping
 2 Existing account mapped but not contact No Yes Account mapped. Contact created by not mapped. Contact is mapped to account as Primary Contact.
 3 Both contact & account mapped (diff account & company name) No No Both account & contacts mapping is carried forward.
 4 Nothing is mapped. A simple lead with just necessary info i.e. name & topic but no company info No Yes Only contact is mapped
 5 Nothing is mapped. A simple lead with just necessary info i.e. name, topic & company Yes Yes Account mapped. Contact created by not mapped. Contact is mapped to account as Primary Contact.

Scenario 1: Existing Contact mapped but no account info

In this case, on lead record, only look-up attribute is mapped to the suitable contact but there is no account information or company information is available. When such a lead is qualified to opportunity then since contact mapping already exist, it will be carried forward but nothing will happen at account level as there is no enough information available for account creation.

Scenario 2: Existing account mapped but not contact

When a lead, with existing account look-up attribute already mapped, is qualified, as account mapping already present, only Contact record will be automatically created. On opportunity, existing account mapping will be carried ahead without any contact whereas this created contact will be mapped to account as a Primary Contact.

Scenario 3: Both contact & account mapped (diff account & company name)

When mapping already exist, same mappings are always taken ahead irrespective of information present in company section.

Scenario 4: Nothing is mapped. A simple lead with just necessary info i.e. name & topic but no company info

When a simple lead without company info is qualified, then only a contact is created and mapped to opportunity. As there is no enough data to create account, there won’t be any account creation hence no account mapping.

Scenario 5: Nothing is mapped. A simple lead with just necessary info i.e. name, topic & company

Similar to scenario 4, but in addition if company info is available, then account as well as contact both are newly created. But when it comes to opportunity, still only account is mapped but no contact and this contact is then mapped to account as a Primary Contact.

So overall, in Lead Qualification process, if account mapping is a process option and contact mapping is not readily present on participating lead, then account is given the priority while mapping it to Opportunity and contact is mapped is instead mapped to account.

Mapping contact always:-
But problem comes if contact mapping is always required on opportunity? ..
Well this can be easily solved by OOTB asynchronous processes i.e. a workflow. A workflow will be required on create of opportunity to update this created opportunity’s “Contact” attribute with similar “Primary Contact” look-up attribute of opportunity’s associated Account.

Note:- Use of real-time workflows would not be recommended in this particular case, as opportunity will be created in context of QualifyLead operation and hence its not necessarily behave as expected.

Password controls on CRM entity forms in a supported way…

Password controls, struggles most of us, specially when that need to be done on CRM form in a supported way. There are many solutions for this with unsupported customization and by playing with Jquery to DOM.

But in an attempt to look closer on how forms are rendered/managed, I came across a formXML tag which can do the magic and since this is a SDK documented thing, I can think about no reason to consider it un-supported! In formXML ,we can make a use of <IsPassword> tag to have our control behave like a password field right inside crm without JQuery – XML game.

Scroll below for detailed implementation steps –

1) Add concerned entity in a new/empty unmanaged solution (New solution is convenient because other components in solution will make it harder to locate a required control)

2) Export the solution, save .zip file and extract its content to a new folder. (Extract in a separate folder because we are going to need these files later…)

3) Open “customization.xml” file into preferred editor.

4) Locate formxml inside your entity tag.

5) Locate the exact control tag which you are interested in. It can be identified by looking at the description or name or id attributes along.

Also to locate your required control tag into big & messy formxml, simply assume the form structure in a row to column matrix/mesh.

That is how an entity form is structured. This will help you to go directly into your row of interest to find the control tag.

6) Once correct control tag is identified, add separate closing tag (</control>) for control instead of one liner close tag (/>).

Image

7) Add <IsPassword> tag from image within the control tag as shown, save the file and create .zip file again using all the exported files from STEP 2 above.

8) Import this zip file, publish customizations and you are DONE! Try typing into this attribute in your entity form so see the effect.

Happy coding !!!

Restrict data overwrite in crm 2011

The CRM applications being open for multiple users to access, there arises a rare situation where two or more users are accessing the same record.

Also in such cases, there can be a requirement to let users work on latest information only. Specially in case when users can edit same attribute for same record from multiple locations. This is important when such shared data need to be protected from being overridden.

Below steps although might not be a good standard for a client-server architecture, but gives a control for supporting the rare requirement of having a record version:

  1. Customize the entity for which this behavior is required and add hidden attribute e.g. ‘passKey’ which will store a unique number whenever the record is refreshed.
  2. Mark its submit mode as always so that it will be pushed for all updates.
  3. Register a (post operation create & update) plug-in to store a random number as a passkey in this attribute. This plug-in will be a key generator for generating such passkeys.This passkey will be treated as a key for a user in update operation later.
  4. Register a (pre operation update) plugin to check for the latest passkey value for the current record. This can be done by having an image to load the latest record version. It is recommended not to have all attributes in the image as it could increase its size substantially.
  5. Allow update operation only if both passkeys are matching else operation could be stopped throwing an exception with a nice friendly message which will ask user to refresh the form as it is a older version now.
  6. This still holds true at attribute level as well, if versions to be avoided for complete entity. Just that passKey generation will happen only if the required attribute is updated and not on each entity update.

Use these steps when such requirement is absolutely un-avoidable. Although it is all supported code but the style used is not recommended for many entities at one go.

Happy coding.

This is the first version from my laptop! 🙂