Related sites:
Newsletter: Perspectives on Power Platform
Company: Niiranen Advisory Oy
Earlier I demonstrated the new capabilities that Microsoft Dynamics CRM 2013 has introduced for workflow processes: showing error messages with real-time workflows. I covered examples of record assignment, merging duplicate accounts and stopping unwanted updates in the Mobile Express client. This time I’ll take a look at how the error message feature can be leveraged in managing the sales process on opportunity records.
The new Business Process Flows in CRM 2013 provide the possibility of setting fields in a stage as required. This is a nice advancement over the previous platform functionality that only allowed you to set fields as business required per entity, since now we can dynamically control the stage at which we will require the user to input the information onto a form. It’s very typical that a user wouldn’t yet have much details available about a sales opportunity when first entering the information into the CRM system, so it makes total sense to not ask too many questions initially. After all, you can make a field required, but if the user simply doesn’t possess the information asked in it, he or she may just enter dummy data into the field to meet the technical minimum requirements.
Looking at the default opportunity sales process that comes with Dynamics CRM, we have a number of bit fields in the Close stage that indicate tasks the opportunity owner should complete before closing the opportunity. In the Business Process Flow editor we can tick a box and set these fields to be required. What does a required field in the Business Process Flow then mean exactly? It simply means that you can’t move the record forward from that stage until a value is entered in the field. In the case of bit fields (two options) the value should be set to Yes (ID 1) to meet the criteria.
OK, sounds logical, but what about if we’re already in the last stage of the process? How is the requirement level enforced if there are no more stages to move to? The answer is: it’s not. Since the actual closure of an opportunity as Won or Lost is not a stage in the process but rather a change of the record status, Business Process Flow has nothing to do with it. We can observe this behavior by setting a field required in a process stage and then navigating to a test opportunity and attempting to close it as Won. In our example, the File Debrief field has been set as required in the Opportunity Sales Process, but the system still allows the user to close the opportunity without entering data into this field.
“That sounds like an unfortunate gap in the business logic, I guess we’ll need to get a developer to write a plug-in for us to stop the status change operation if required data is missing.” Hold it right there, mister! We’re dealing with Dynamics CRM 2013 here, which means we can build the equivalent feature with a real-time workflow process! No custom code needed for such a simple task, as long as you know how to leverage the new interactive nature of synchronous workflows.
Let’s create a new workflow on the opportunity record and set it to start when the record status changes. We’ll configure it to be run as “after” the event, since we’re interested in capturing the new status value of the record. In the workflow criteria we’ll define that we want our business logic to apply if the opportunity is being set as Won but the File Debrief field has not bee set to Completed. Since this is a real-time workflow, we can add a step where we set the process to be stopped as Cancelled and then define an error message in that step’s properties. This will then be presented to the end user who is triggering the status change event if the workflow criteria is met.
Now, let’s go to our test opportunity, re-open it and attempt to close it without marking the File Debrief field as Completed. When clicking the Close as Won button on the opportunity form command bar we’re presented with the standard, non-customizable Close Opportunity dialog window asking us about the Actual Revenue, Close Date and so on. Since we’re so excited about having won the opportunity we’ve completely forgotten that there were still tasks we needed to complete before we’re allowed to close it off from the sales pipeline.
Once we click OK, a new dialog window is presented: the Business Process Error prompt, along with the error message that we defined in the Stop stage of our workflow process. The opportunity close event is rolled back and we can return to the opportunity form to see what steps of the process we had neglected.
As I mentioned in my previous article about the new business process automation capabilities of CRM 2013, Business Process Flows are essentially a process map that is meant to guide the user through the stages. It cannot actually perform any automated tasks by itself, nor enforce any rules apart from the changing of the stage through the visual business process control at the top of the form. To implement this type of functionality you should look into Business Rules and Real-Time Workflows instead.
Looks good, can you force that documents need to be attached to finish a process?
Do you mean as attachments to the opportunity? You could build another workflow rule on the note entity that will update a custom flag field on the opportunity once a related note with a file attachment has been saved. You could even stipulate that the file name needs to contain “report” or whatever string to qualify as the right kind of document. Then based on the status of the flag you could stop the closure of the opportunity.
I was thinking that if you needed to add a quote to the opportunity and then attach the physical file(PDF) sent to the customer or even add it to the Sharepoint library
If you need to reach out into data stored in SharePoint, then that’s outside of the powers of CRM workflows.
I quite like this new error message feature in real time workflows (and it’s not one I’ve seen called out by MS or others elsewhere)
Thanks once again Jukka!
What can be more beneficial than using errors in your own way, thank you!
I tried to use a similar workflow to trigger on Lead qualification. Unfortunately I can’t get it to work.
The requirement is to make sure that “Parent Account for Lead” gets populated before qualifing the lead.
Any ideas?
Pekka, I tested this and was able to stop the lead qualification process if I left the Company Name field blank. If there’s data in there, then apparently the qualification process will run through regardless of the criteria set on the Parent Account field.
Initially I thought that by default CRM will populate the “Parent Account for Lead” with a new account record if no reference exists. So, in the post event image this field would be filled with the new account record and no error would be thrown. It doesn’t appear to work quite like that, though, since the results are the same whether the real-time workflow is set to run before or after the status change. Perhaps someone with experience on writing plug-ins for the lead qualification event might be able to shed more light on what actually goes on in the platform when a lead gets converted to a new contact, account and opportunity.
Aside from writing a plugin, onr option would be to modify the Command Bar and disable the Qualify button if the Account lookup is blank.
I figured out another possible workaround: create a real-time on-create workflow for the account record. You can add a condition like “if Originating Lead contains data then stop workflow as cancelled”, this appears to “bubble up” the business process error message and roll back the lead qualification transaction.
It seems that I need both of those workflows to cover both situations:
– Company name blank => no account created, workflow on lead triggers
– Company name containing data => account creation started but halted by the account workflow
But togehter they seem to be workable solution. Need to test that a bit more.
Thanks a lot, Jukka!
I have to say I find the lack of documentation about the changes to lead qualification really problematic. I’m still not sure exactly what your use case is Pekka but I think the way Microsoft think this should work is using their new duplicate detection rules (see my comment on this blog here:
http://www.pedroinnecco.com/2013/10/lead-entity-2013/
The idea being that you get a (rather over enthusiastic) “you might be about to create a duplicate” dialog on lead qualification. The user takes notices and picks the right record (of course they do!). I wonder if the new duplicate detection rules are enabled in your tests and how/whether these modify the RTW behaviour?
Just out of interest have you looked at the old-school customer lookup on the lead record? In CRM 2011 it was hidden but not on the form. In CRM 2013 it’s still there – I don’t know if populating that will help you or change the behaviour. So far I’ve not yet noticed anything taking any notice of this lookup (or setting it from Parent Account/Parent Contact) but maybe I’ve missed something?
Thanks for posting this. Is it possible to add logic to validate a required business process flow field before allowing the user to advance to the next process stage? For example, if I have a required close probability field on an opportunity to advance from stage 1 to stage 2, can I use a workflow or a business rule to require that the value is > 50 before allowing the user to advance the business process flow?
Absolutely, Ryan! What we need to do is set the workflow to run on the change event of the Process Stage (stageid) field and evaluate the criteria for other fields. In the example below, I’ve specified that if the field “Customer need” contains the word “Dave” and someone clicks on the “Next Stage” button on the Business Process Flow control, then HAL… sorry, CRM will stop the process.
The only downside appears to be that once the Business Process Error appears, then the user cannot submit any other changes on the record, as the stage change is somehow “stuck” on the form. However, if they navigate away from the form and accept the loss of any other data entered between the save and the attempted stage change then everything will work correctly. The BPF stage itself won’t move to the next one until a user has a valid value in the fields being evaluated.
Thanks for the post! Is there a way of accessing the close dialog form fields from within a workflow? I want to stop the user from closing the opportunity as Lost if they did not submit a description in the close dialog form. Before we used to capture the XML provided by the close dialog in the onsave event but it seems like now the onsave method is not firing at all when you close the opportunity!
Charmaine, it would be quite difficult for the workflow to capture the description data that is being stored in a related opportunity close activity and not the opportunity itself. I would recommend hiding the default Close button and creating a custom dialog instead that asks the user to enter the description and stores it on the opportunity record itself. This way you can stop the process if required data has not been entered by rolling back the opportunity close transaction via a real-time workflow.
Hi Jukka,
Great post. We are trying to implement a BPF currently but we’ve found some troubling behaviours! Is it possible to stop users from “jumping ahead” to the next/future stages and filling in fields before they have properly progressed to those Next Stages?
For example even though I have required fields that are not filled out yet in STAGE #1 the user is still able to click/look ahead to STAGE #2 and fill in fields there.
We have experimented with using Business Rules to LOCK/HIDE fields on future stages based on the current active stage, but these rules only actually take effect when you are on the actual Stage in question. For example if you set a Business Rule to hide the first field on STAGE #2 it will still be visible when you’re active stage is STAGE #1. As soon as you progress to STAGE#2 it will hide itself. This is the same with Locking the field. So we are at a dead end.
It appears Microsoft has deemed the standard behaviour should be to allow users to jump ahead and fill in fields on future Stages, despite this claiming to be a Stage-Gating type process system!
Would appreciate any comments you could offer on this.
Cheers,
Dan
Daniel, this seems to be a bug in CRM 2013 Business Process Flow and Business Rule behavior that Microsoft has acknowledged, based on this item on Connect: Business Process Flow does not update from form status. I quickly tested it in Update Rollup 2 and the bug remains there, so hopefully it would be removed by the time we get the Leo release in Q2.
I can think of two supported workarounds: 1) place the actual data field elsewhere on the form and control the visibility with Business Rules, leaving only a tickbox “mark as done” visible on the BPF control. 2) stop the user from saving any data into the field by throwing a Business Process Error via a real-time workflow that runs on the change event of the field and validates that the related process stage is correct.
Hi Jukka,
We had the same problem as Ryan and we added the logic so it is blocked (Thank you). However, we discovered that once an opportunity is at a later stage, the user can go back and change the value manually(yes to no). The related field in the form is read-only but the step in the BPF is not, how can we prevent that? Can a step be block after moving to the next stage?
Joan
Joan, due to the same CRM 2013 bug that Daniel ran into (Business Process Flow fields only respect Business Rules in the current stage), you can’t directly prevent the user from editing the fields available in earlier BPF stages. Depending on how it fits your scenario, you could add a real-time workflow that will stop the users from saving a new value into the field in question if the record’s BPF stage is of a certain value. So, the field would remain editable, but saving an invalid value into it would be blocked by the workflow.
Hi Jukka,
Could this sort of workflow be modified so that if an Opportunity is closed as Lost to Competitor that Competitor is required? I have tried to do so (following your example as precisely as possible), but the workflow is always being cancelled even when the competitor is added. Any thoughts?
Thanks!
Andrew, that must be because the Competitor field is entered in the Opportunity Close dialog which will create an Opportunity Close record rather than update the actual Opportunity. Having the competitor field entered as a field on the Opportunity BPF would allow requiring this value to be filled before changing the record status to Lost, but this wouldn’t map into the field on the Opportunity Close dialog. Since those built-in dialog windows remain an uncustomizable area in Dynamics CRM, you would need to replace the process with your own fields and dialogs, then hide the default buttons, to really make this a seamless process. A plug-in could probably roll back the status change transaction if the related Opportunity Close record doesn’t contain a value, but again, the user experience wouldn’t be optimal as there would be no indication in the UI that the Competitor field is required while working with the standard dialog.
Great post! Also useful solution to enforce proper data entry during lead qualification.
Awesome insight!
I too need to preempt the closing of the opportunity unless description and competitor are inputted. I think the plug-in router is the least expensive solution. However, the pop-up after throwing an invalidpluginexception is not user friendly.
Below is the plug-in code.
if (currEntity.LogicalName == OPPORTUNITYCLOSE)
{
if ((currEntity.Attributes.Contains(“description”) && currEntity.GetAttributeValue(“description”) != null)
&& (currEntity.Attributes.Contains(“competitor”) && currEntity.GetAttributeValue(“competitor”) != null)) { }
else {
throw new InvalidPluginExecutionException(OperationStatus.Canceled, “Description and competitor are required.”);}
}
Cheers!
Thanks for the Post ! I implemented it in Opportunity for Checking few fields before saving as WON .
Hi,
Can I enforce the logic that user cannot close an opportunity/case/custom entity, by stage? Meaning I can close the record only when I am at one of the pre-determined stage(s) of the BPF. E.g. I can close the Opportunity only when the BPF stage=Proposal Defense.
Abhirup, this is perfectly possible. You’ll simply need to add a criteria into your workflow that checks what is the related Process Stage record’s Stage Category (or name, if you’re not using the category optionset).
Does anyone know if you can make it so that two users cannot be in an activity (e.g., phone call) at the same time? In effect, is there a way to “lock” a record so that two people cannot edit it at the same time?
Jen, you could develop a custom script that would warn users about potential conflicts when updating the record. Check this post for reference: Concurrency Control in Microsoft Dynamics CRM 2013.
@Joan (and others)
If you mark fields as read-only on the form then they are not read-only in the process flow. But if you use a Business Rule (or javascript) to change them to be locked (=read-only) then this affects the field on the form and the step in the process that corresponds to the field.
So a combination of things can help you to lock things down so users cannot move ahead and fill things in prematurely, or fill in false values to meet your requirements, move ahead then go back and change them.
For example, you could use a real-time workflow triggered by the stage change to update a text field to the name of the stage (or process + stage concatenated, if you need to). Then in your business rules check the current stage and determine whether to lock or unlock fields (you need rules in pairs, one to lock and one to unlock – in Vega you will be able to do this in a single rule with an If…then…else construction). When the stage changes, the record is always saved and the form is reloaded (as far as I remember), so the rules will always be run at this point.
Hope this gives you some ideas to get started.
Dear Jukka ,
I have a question about Opportunity’s OOB close functionality.
The Opportunity close dialog displays a disabled lookup – Competitor.
Can this field be removed ? or can this be enabled so that it can be used?
I know it is out of context here, but please do reply if you have suggestion.
Thanks,
Naveen
Naveen, the Competitor field should be disabled if you close an opportunity as “won” but enabled if you close it as “lost”, so that you can indicate which competitor actually got the deal.
As for the modifications, the Opportunity Close dialog is one of those decade old relics in the Dynamics CRM application that still remains uncustomizable. Please sign in to MS Connect and then vote on suggestions like this one to give some added visibility for this feature request. In the meantime, your only options are to edit the opportunity Command Bar with a tool like Ribbon Workbench, to hide the default close button and create a custom button that would launch your own custom dialog window.
Jukka , you are awesome , thanks a zillion !
Thank you Jukka, some of the information is still fresh :))
Maybe there are new comments about Workflow?
Lester, there haven’t really been any workflow process related enhancements since CRM 2013 RTM release, so the logic for blocking unwanted updates to opportunity records would still be largely the same as before.
Very helpful thanks. The process works well, I am using it on Opportunity Close (check whether field on Opportunity contains data) .
My issue is that I then go back into the Opportunity, input the data, then Close the Opportunity. The process still tells me I the data is not complete. Interestingly, also happens if I try to Close Lose the Opportunity. Finally, just as a gotcha (!) you cannot reopen an opportunity if the data was not completed. Thanks
Click On this page
Enforcing Business Process Flow Fields with Real-time Workflows