Recently I received an error message from one of my customer concerning a Business Process Error. Moreover the users who was trying to create a record, lacked a necessary right. I have treated these kind of errors on the blog before, but this is quite different then the “Acces is denied – Unable to convert a lead to a customer” blogpost I wrote earlier.
After calling the user it became clear that she was trying to create a new record in a custom entity called “dossier”, which I had made for the organization. So first things first, I checked the user’s role and the privileges the role had in CRM.
The user has the necessary “create” privilege, so this could not be the source of the business process error.
Second, I checked the active workflows for the custom entity and saw that there was a real time workflow active, which created automatically numbers for a new dossier. This workflow is based on the blogpost written by Jukka Niiranen: “Auto-Numbering with CRM Workflows: Real-Time vs. Asynchronous“. I have used and expanded this logic many times before and it was the first time I got an error, which made me check every step of the workflow.
One of the main steps in the process is updating an autonummer record. To be able to create this record, the executing user (depends on your workflow settings) needs to have the “write” privilege. Hence the “is missing prvWritenew… privilege”-error.
As the user was not allowed to write an autonummer record manually, she lacked this privilege and thus could not execute this business process in CRM.
In the workflow options you can set the user who executes a workflow.
- Execute as: the user who made the changes to the record. This is the default setting as you don’t want people to be able to create/delete/update/… a record without the proper security role.
- Execute as: the owner of the workflow. This setting is used by exception for a simple reason. Usually system administrators create workflow for users. If ‘normal’ users could trigger workflows, which in their turn are executed as system administrators, they could inherently do stuff they would never have the proper privilege for.
In this case, making sure the workflow was being executed as the owner of the workflow (which was the system admin) proved to be the solution. But I do advice to think over your options before adjusting this setting.