The next morning, the users logged in as usual, and began the days work. Hours later, a few users noticed that particular fields on some of the forms were locked, others were not locked, and some values that typically would get prepopulated on new records were not prepopulating. It was quickly determined that the “Business Rules” feature of Dynamics CRM were not triggering.
After some various troubleshooting, the effective entities were re-published and the business rules started working. Had there been a step missed when publishing the new solutions, despite our meticulous check lists? Regardless, case closed and we moved on.
A few hours later, reports of business rules not working again! What? Now we went into deeper troubleshooting mode, why would business rules work for a while and then stop? Was this happening for specific users?
Very few patterns emerged. The issue would present itself for for users with the System Administrator role as well. The problem was intermittent. The log files did not turn up any information. Eventually we looked at the servers, routers, firewalls, load balancers, phase of the moon, time of the day, wind direction, etc, etc.
Working with Microsoft support, we analyzed the database, and the issue could not be replicated on TEST or even when the production database was redeployed elsewhere.
We took another shot at determining patterns. There were some perceptions emerging (it was thought that the issue only occurred on IFD clients, only on certain browsers, etc) so I added some modifications to a key entity (Optionset -> Business Rules Not Working, Working) and a field to capture what URL was used.
The results showed that the issue was not 100%, that it happened both on IFD and non-IFD clients and from different browsers, it didn’t show any particular pattern.
We were looking at trying to find patterns and were about to analyze network traffic. We are also wanted to pinpoint the exact time after a reboot and see if that would shed some light on the issue.
During this time some of the analysts were working on another unrelated issue with Business Process Flows on the Lead entity. At this time they updated the security role for the general users to have greater access to the Process entity. This change was applied to the production system.
A few days later, while compiling the data from the recent reboot and the particular users from the team, we saw that the Business Rules had been working 100%. Double-checking, we pinpointed that the Business Rules started to work when the recent security role change was made for the Business Process issue. Whaaaat? If the issue was security related, wouldn’t the issue present itself immediately? Also, this would not affect users with the System Administrator role! This is not a typical permissions issue!
So what happened?
When the issue first presented itself, the “all users” security role was modified to reduce access to the Business Process Flows so the security was changed from “organization” to “user”. This change was part of the package of the enhancement updates.
A while later, the security role privilege was changed back to “organization”, and the Business Rules started working for everyone.
Microsoft is apparently investigating a fix so hopefully this issue will be addressed in an upcoming service pack or update.
In the meantime, the workaround is to ensure that all users have at “organization” read access to the Process entity.
While a small issue, it caused a lot of grief. Hopefully this post will save some of that hassle if anyone Googles “Dynamics CRM/365 Business Process Issue”.
Nick Doelman is a Microsoft Business Solutions MVP and is pretty pumped that the Ottawa Senators are up 2 games over the Rangers in the NHL Playoffs.