In this post, we will look at how forms with Business Process Flows can be affected by the saving of records or moving stages in a BPF, which may occur before or after you deploy your code to a new environment. We will take a look at how to troubleshoot these errors in general as well.
Let’s create a new business process flow at https://flow.microsoft.com/:
We will call it Carl’s Flow, on the Account entity:
The flow has 2 stages:
If we create a new account, we see the flow:
Now, let’s add this to a Solution:
Called Carl’s BPF:
We will add all components – the BPF, the Security Role, the account entity, and the new entity created in the BPF:
Let’s export the solution:
We have our solution export:
Now let’s import this into another environment. Think of the first environment as your Development environment and this one as your Testing environment.
Click Import in the Testing environment:
Choose the ZIP:
Activate the flow.
Now, ensure the app you are logged into has the BFP, e.g. the default app.
Let’s create a new account. We see the BPF, great:
Click Save. We get the error message “Access Is Denied. You do not have enough privileges to access the Microsoft Dynamics 365 object or perform the requested operation. For more information, contact your Microsoft Dynamics 365 administrator.” Click on Show Details:
Show Details and downloading the log file doesn’t tell us much – “at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.CreateInternal(Entity entity, InvocationContext invocationContext, CallerOriginToken callerOriginToken, WebServiceType serviceType, Boolean checkAdminMode, Dictionary`2 optionalParameters)” etc:
The real error message is being hidden. Let’s hit F12 and go to the browser dev tools:
On saving again, we see:
In my case – POST https://crm308991.crm.dynamics.com/api/data/v9.0/$batch 403.
Clicking on this, it takes us to the Network tab. We see the $batch request:
Which gives us:
Let’s open the error in VS Code:
It’s a 403 Forbidden error. We see various clues in the document such as CallerPrincipal, the PrincipalId etc, which tells us that a process is failing.
What’s interesting is this block, which says the minimum privilege required for AppendToAccess is Local, and it refers to the prvAppendToWorkflow privilege:
On setting that, we can now save our form:
Now if we had an existing record and we tried to go to the Next Stage of a Business Process Flow without setting this security privilege:
We would see the real error bubble up in the UI:
So set the privilege and you should be able to deploy your business process flows with proper access. Hope this saves you a headache or two.