by Gustaf Westerlund | Feb 8, 2017
The new Dynamics 365 release of CRM or as I like to call it 8.2, as that makes it a bit simpler. Dynamics 365 is a bit ambigious, it can mean AX and NAV as well and at the same time I want to discuss the platform and not just an app… so it becomes trick. I hope Microsoft figures some decent naming for the xRM part of the platform so we all have something to call it. (hint… xRM is a decent word)
Well, one of the cool new features of the 8.2 release is the revamp of the Business Process Flows (BPF) which now have gotten a couple of different facelifts, of which some are:
- A new editor which looks identical to the Business rules editor. However, the Workflow editor is still very old-style… I wonder if this might be next. 🙂
- BPF:s final stage can now be closed/or you actually close the entire BPF. This was not the case previously where the last stage simply sat there.
- If you have multiple BPF:s and you switch between them, D365 will remember where you are in each of the BPF:s. This was not the case in earlier versions when it always restarted when you changed.
In order to handle the last point, the underlying architecture of the BPFs have been changed. Previously when you had an entity that was BPF enabled by a lookup called “Process stage” and when this changed you knew that the record had changed stage in the workflow.
Alas, in comes 8.2 on its white horse, and “Process stage” lookup falls dead to the ground like knight before a modern day tank. In other words, it simply isn’t triggered.
The new BPF architecture is based on the principle that a new shadow entity is created for each BPF that you create. And yes, they are removed when you remove your BPF.
So, when is this typically a problem? The most common uses for triggering on stage changes in BPF is using a Workflow to trigger on changes in an Opportunity to set the probability. This is then later used in calculated fields like Weighted Estimated Revenue (not a standard field) and similar fields.
The effect upgrading to 8.2, which is just a minor upgrade from an upgrade perspective, is hence that these customizations that you might have done to set the probability, stop working and the opportunities get the wrong, 0 or no probability making any calculation based on this number incorrect.
So, how are you supposed to fix this? There is a new WF triggering mechanism built in to the BPF designer. You simply create a workflow that can be manually triggered, and drag a workflow compontent into the appropriate step in the BPF designer.
Do note that you can choose if you want it to trigger when the stage is started or completed.
|
| BPF Editor with a workflow added with the Stage Entry trigger selected as highlighted |
And this is how the workflows needs to look
 |
| This is the workflow that was selected in the BPF Editor above. Note the highlighted checkbox. This needs to be checked in order for the workflow to show up in the BPF editor lookup |
A final comment. Even though the BPFs can now be completed, that does not mean that the final stage’s Stage Exit is triggered. As far as I have understood it, it is still in this phase even though the BPF in it self is considered closed. I would call semantics on that. I hope Microsoft fixes that bug or enhances that lack of feature if they rather call it that.
Was this original workflow supported? Was it ignorant of your partner, you might ask, to create a workflow that triggered as described in the old manner and this has now stopped working and you
are faced with additional costs for fixing this? Shouln’t they have known? Well, frankly no, your partner, if they followed what I described above, did make what are called “supported customizations” which according to the documentation from Microsoft is supposed to be upgradable. At least one major version, often 2 or 3 major versions This time it was not even a minor, from 8.1 to 8.2. Hence it is a regrettable situation but if you want to complain somewhere, I do suggest you complain to Microsoft.
Gustaf Westerlund
MVP, Founder and Principal Consultant at CRM-konsulterna AB
www.crmkonsulterna.se
by Gustaf Westerlund | Feb 2, 2009
When implementing a business process in Dynamics CRM there are several different implementation paths to choose from. There are advantages and disadvantages to the different techniques but there are some goals that I feel the implementations should meet, mainly:
1. Fully supported customizations only
2. Flexible and non-static.
3. Power user modifiable
4. Movable from environment to environment (dev-test-production)
I will discuss the different aspects bellow and why I feel they are important.
Fully supported customizations only
This is almost so self-evident that it doesn’t even need mentioning but I have seen several CRM implementations that not only nudge this paradigm in the corner, but bite big large chunks out of it. For me, the number one reason why this is so important is that all customers will sooner or later want a hotfix or upgrade to a later version and when Microsoft, in their greatest foresight and benevolence definied the concept of supported customizations, they made this possible without costly maintanance agreements or hostile customer relationships. So, not following it should be punishable by death or something close to it.
I would presume that you CRM implementations are meant to last for your customers and that you want a long a fruitfull relationship with your customer, why you just cannot underestimate this point. If you have to make unsupported customizations, make sure they are as light weight as possible, document them thouroghly and how to validate them when installing a hotfix or upgrade.
A business process must hence be made as supported as possible.
Flexible and non-static
The solution has to be flexible and non-static. We, and our customers live in an ever changing world and to cope with this, business processes have to change as the world around a company changes. Just imagine the changes the telecom industry has gone through the latest 20 years. To fully accomodate this the customer implementations have to be flexible and changable. Microsoft Dynamics CRM is one of the most versatile and flexible systems available, especially now that it incorporates windows workflow foundation. Implementing a business process in code entirly, locks the processes down, and builds a dependance on the CRM delivering partner, something every customer-value focused consultant must despise. I do not need to force my customers to use my services when I can get them to choose me because of the value I deliver to them every hour of every day.
Instead, use the power of Windows Workflow Foundation combined with custom workflow activities. If needed, trigger these workflows using plug-ins and isv.config customizations.
Power user modifiable
A business process often involves users of different sorts and communicates with these using emails, tasks and other activites. The content of these and the recipients, sometimes dynamically set, sometimes static (like the CFO), might need to be changed. Therefore it is not very flexible for the customer if code has to be re-written everytime a mail has to be changed. It is a lot more flexible to create a workflow that creates the activity and then just execute the workflow from code, apart from the fact that it is a lot quicker to implement. Just write a method that enables you to execute the workflow by name instead of Guid.
Movable from environment to environment (dev-test-production)
All implementations of any notable size always includes at least three environements, not seldom up to 5 or 6 depending on how you count (local dev, central dev, test, training, production). Business process implementations have to be easy to move between solutions without any or with as little as possible environement specifics. Hence, try to use names (or some other environment indpendant value) instead of guids since guids are environment specifics when relating to workflows and other similar things. Try to get all environement specific settings in one place, one file or create an entity for them. This can be a challange but try, it will pay off in the long run.
These are my thoughts on the business processes implementation stategy concerning Dynamics CRM 4. I would be happy to discuss the topic so please leave comments!
Gustaf Westerlund
Microsoft Dynamics CRM Architect
Logica
www.logica.com
Recent Comments