Here’s a fun one.

A client was having issues importing a solution. They were getting the following error:

ItemType: Workflow
Id: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
Name: Murphy’s Law
Status: 
Failure
ErrorCode:
0x80040231
ErrorText: Principal user (Id=YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY, type=8) is missing prvReadWorkflow privilege (Id=ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ)

OK, so looks like a workflow is having some kind of issue with an associated user’s privileges. So I look up the user:

http(s)://(CRM Org URL)/main.aspx?etn=systemuser&pagetype=entityrecord&id=%7BYYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY%7D

Sure enough, this guy basically had no privileges. Looks like he’s been stripped of his security roles. I happened to know that this guy (we shall call him “Bob”) was a system administrator that no longer worked on the system, so his privileges were probably removed as a security precaution. That would explain why the error was suddenly occurring.

On to the workflow. I go to Settings->Processes->All Processes and look for “Murphy’s Law”. But it wasn’t there. I look in the system where the solution was exported from – same there.

Now what? Well, I have the GUID. Let’s try using that.

http(s)://(CRM Org URL)/sfa/workflow/edit.aspx?id={XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}

WAIT A MINUTE! THIS ISN’T A WORKFLOW AT ALL!! THIS IS A BUSINESS RULE!!! YOU LIED TO ME, IMPORTLOG!!!! I THOUGHT WE WERE FRIENDS?! (ノಥДಥ)ノ︵┻━┻・/

But what do “Bob” and “Murphy’s Law” have to do with each other? Well, “Bob” was on the project team that designed this CRM system. Good chance he created “Murphy’s Law”.

Coincidently, I had just learned that you could list Business Rules using the following search:
Advanced Find - Business Rule query

I fired up my Advanced Find window and looked for “Murphy’s Law”. And who was the owner of that record, I hear you asking? Why, “Bob”, of course.

So why was the error occurring? Well, if “Bob” owns the business rule and the system considers this to be a workflow, but “Bob” can’t read workflows (“missing prvReadWorkflow”), then how can he own one? Answer, he can’t – it’s some sort of catch 22 situation.

The solution to this was to assign the business rule to a service user – same as you would do with a normal workflow.

What I still don’t know is if “Bob” was the business rule owner because this was the case on the system the solution was exported from, or because when the business rule was first imported to the destination system, “Bob” was the one importing the solution. My guess would be the latter. I’ll update this post when/if I know for sure.

I also can’t say whether this error is a new occurrence in CRM Online 2015 Update 1, or can occur for business rules in general. I’d be surprised if it weren’t true for CRM 2013 and up, though.

In any case, the next time you’re working with business rules, remember to set an appropriate owner.

Comments

comments