So, yes, there is a change. Before I continue, I wanted to make sure you know what business processes are. If you are not too familiar with them, you might want to do some reading first:
Otherwise, I’ll simply walk you through this change.
In my Dynamics 365 environment, I have an entity which is called “Parent” entity. It’s been created for a different scenario, so don’t bother with the name. What’s important is that there are two business process flows defined for that entity – “First” and “Second”:
I’ll now go to Dynamics and create a new Parent record:
As you can see, this is happening under my account, there is a process flow, so everything looks good. I’ll save the record and will use another user account to see how it looks like there (just for the sake of this experiment, I’ll actually use a different browser as well.. no caching then):
It’s another user now(CRM Admin), but, as you probably expected, it’s the same process flow. So, where is the change that I promised?
Let’s use this last screen to switch the process:
Here is the result – it’s a different process now (remember, we are still under CRM Admin there):
Stop for a second and ask yourself: which process is going to show up under my original “Alex Shlega” account? It must be the same process that “CRM Admin” has set for the record, right? That’s how it used to be, and I would not think twice myself.. until earlier this morning when I saw this:
Under my original account, I’m happily looking at the same record (and I did refresh the page/reloaded the browser), and I am still seeing the same original process!
This is by design, I will explain shortly. But the consequences are.. You can switch the process, but everybody else can still be using a different process. Is it a bug? A feature? It’s definitely a different way to do things (and it is also affecting the API-s, btw. They are still using the same old function signatures, but they are switching processes per user as well).
For the explanation, you have to read through this article published by Microsoft Dynamics team:
Long story short, The Fall 2016 release of Dynamics has introduced the concept of Concurrent Business Processes. That also involved quite a few changes in the underlying entity model; however, the end result is that there can be more than one active process per record. Yet, it seems, every user can now pick the process they are following for each record.
And, for example, if you are still using this technet article for a reference, it does not seem to be valid anymore, since it’s saying that “Each record can have only one business process flow at a time”:
I’ve spent some time trying to find a way we could use SetProcessRequest SDK request to synchronize active business process between different users, and, eventually, it worked. There is a strange problem, though. Usually, this is how we would create IOrganizationService in our plugins:
IOrganizationService service = serviceFactory.CreateOrganizationService(context.UserId);
So, basically, I was simply trying to create IOrganizationService for different users and use those different service instances to execute SetProcessRequest requests for each of the users. It was not working till I moved my plugin to the “Pre-Validate” stage of the plugin execution pipeline. I have no explanation as to why, but, it seems, SetProcessRequest request is using some sort of contextual information that gets locked in the transaction since Pre-Validate runs outside of the database transaction.
There is a new Set Active Process custom workflow activity that has been added to the TCS Tools. You can use it to assign the same business process to one or more users per record:
As you suggested I create a IOrganizationService object using different user ids i my plugin and execute the SetProcessRequest request which works fine as long as the user has the write permission to the entity. If not it throws an error. In my case there are some users who has only read privilege to the entity. But still they should see the current business process (not the previouse one)
This is the error:
SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: b5824d8c-cf70-e711-80d5-005056b44566, OwnerId: 689a0c02-06c0-e611-80d3-005056b44566, OwnerIdType: 8 and CallingUser: 111a95b9-02de-e611-80d3-005056b44566. ObjectTypeCode: 10001, objectBusinessUnitId: 1e8b0d26-6b05-df11-8ed1-005056b47db0, AccessRights: WriteAccess
can those users do it in Dynamics through the user interface? If they can’t do this in the user interface, they would not be able to do it through the SDK either, so I am guessing you’ll have to give them the permissions (on the BPF and, possibly, on the entity..)