So… your organisation might have Dynamics 365 Sales implemented as a CRM solution primarily focusing on collecting, leads, winning opportunities and finishing a sales process. But, what if your organisation was looking to utilise other Dynamics 365 CE applications such as Project Operations or Field Service, whilst still utilising Sales for its main purpose… well, these applications actually work brilliantly together! Keep reading to find out the changes you might notice in Sales if you decide to implement Dynamics’ Project Sales and Management Tools or even Field Service!
New Lead & Opportunity Types?
So, if you’ve installed either Project Operations or Field Service in your environment, you might’ve noticed a change or two before even opening these applications. Because of the way these tools integrate well with Sales within Dynamics 365 CE, you’ll notice some changes within the Sales application which allows for integration between both Sales and P.O. or Field Service.
The first change in the Sales process you’ll see is that we now have different types of Lead’s which then become the same type of opportunity once qualified. I’m in fact going to refer to these as ‘Sale Types’ because not only does our Lead type get set, it then remains of that type for the full sales process, meaning we have an aligned opportunity type, quote type and order type.
Sale Types
Item Based – Normal Sales Process / Lead or Opportunity Type
Work Based – Added via the Project Operations solution
Service-Maintenance Based – Added via the Field Service solution
What is controlling our Sale type?
Very simply, the only thing determining the type of lead or opportunity we’re working with is our ‘Order Type’ column (msdyn_ordertype). This choice/option set column is added to the lead, opportunity, quote and order tables. Further choices are added when we install either Project Operations or Field Service, as above relevant to our ‘Sale Types’.
Helpful restrictions?
So, whilst it’s good that we can store some data to easily be able to identify the type of sale we’re conducting, say, to make it easier for a colleague to pick up if we need support or go on holiday, it is important to note that selling a product is likely to be a slightly different process to if we were to sell project work or service maintenance based work. Dynamics has some further features here which are quite helpful!
Lets take the opportunity for example… if we have an item based opportunity (default product based sale), then we can only edit this opportunity using the ‘Opportunity’ form which is designed to support product based sales in the best way. We cannot edit this type of opportunity using the opportunity forms added by Project Operations or Field Service, for example the ‘Project Information’ form. We can only edit a ‘work based’ (project) opportunity using the Project Information form. This effectively means we are using the correct set of fields and tools for the sale we’re attempting to make, providing the best set of tools to our Sales workers to allow them to work efficiently on the specific job they’re doing.
So… to summarise on form restrictions:
Item Based Sale – Standard Sales form can only be used e.g. Opportunity form
Work Based Sale – Only the Project Information form can be used
Field Service Sale – Only the Field Service Information form can be used
There is actually JavaScript on the OnLoad handler of each of these forms that detects the sale / order type that has been selected and will then lock the form if the wrong one is selected. This is good because it forces us to use the correct form… but it is tedious in that we have to manually switch to the correct form in order to work on our sale.
Project or ‘Work Based’ opportunity uneditable when using the ‘Opportunity’ form which is intended for ‘Item Based’ sales.
Making the ‘restrictions’ more helpful
So, now we know that we can only use the correct form for each sale type such as the Project Information form for work based sales. But we have to manually switch to the correct form if the previous sale we worked on was of a different type to the one we’re working on now.
I reached out to the community not long ago to see if there was a way that we could automatically change the form selected based on the selected value in the order type field. It turns out, with another JS event, we can do this!
Credit goes to Steve Zhao in the Dynamics community for the script to be able to do this
So… let’s make a customisation. Be sure to do this in a new unmanaged solution so you can keep your customisations organised. Add your opportunity entity (or the appropriate one you want to do this for) to your solution, and navigate to the forms section. You’re going to want to edit each form ‘Opportunity’, ‘Project Information’ and ‘Field Service’ information and add this JS to the OnLoad handler in your form. Make sure you have added the script as a web resource in your solution first, and it has been added to the available resources in your form using the left hand strip in the modern form designer.
The following JS Code is only for switching automatically between the Opportunity and Project Information forms, but you can add an additional else if to factor in the Field Service Information form.
function changeCurrentForm(executionContext){ var formLabel; var formContext = executionContext.getFormContext(); var orderType = formContext.getAttribute("msdyn_ordertype").getValue(); //item based if(orderType && orderType === 192350000){ formLabel = "Opportunity"; //work based }else if(orderType &&orderType === 192350001){ formLabel = "Project Information"; } var currentFormLabel = formContext.ui.formSelector.getCurrentItem().getLabel(); if(currentFormLabel == formLabel){ return; } if(formLabel){ var formItems = formContext.ui.formSelector.items; formItems.forEach(function(item,index){ console.log(item.getLabel()); if(formLabel == item.getLabel()){ item.navigate(); return; } }) } }
Summary and the ‘Why?’
So… now we know that we can use Dynamics 365 Sales along side Project Operations or Field Service, or even both! We know how each sales process is differentiated based on the type of sale we’re conducting (msdyn_ordertype field!) Finally, a reminder of why sales ‘types’ implemented like this in Dynamics…
Not only does using the correct form for the appropriate sale type mean we get the best tools available to us for that sale, using the correct type of sale in Dynamics also means we can further take advantage of the tools further than the sales process when we follow this workflow correctly, for example when we conduct a work based sale, we can move this on to being a Project in Project Operations to be worked on and managed, also allowing workers to do things like input timesheets, and expenses.