We are attempting to use the assign step in a workflow (or dialog) to assign a custom entity to a team, and we are getting a security access error that the assignor does not have permission to read the record being assigned. The following is the error that we get in the dialog process:
The key elements to this are the "AccessRights: ReadAccess" and the variable GUID details. The object in question is a custom entity. The current user in this case is the assignor of the record. THe OwnerId references the new owner (team) after the assignment.
The assignor has Read access to the entity at the "Parent: Child Business Units" level (aka "Deep" level). and Assign permission at the "Global/Organization" level
There are three business units that are important. The root business unit is the default organization business unit. The "regular" business unit is a child of the root, and is the business unit of the assignor. The "special" business unit is also a child of the root and this is the business unit of the assignee .
The team to which the entity record is being assigned is in a separate business unit and this means that the assignor will not have read permission to the record AFTER the assignment is made. This is by design in our application: we are attempting to prevent further action on this record by assigning it to a "special" team and preventing all other teams/users from accessing the record.
We have tested that the assignor can use the "Assign" button on the ribbon to assign the record to this team in the "special business unit" and no error occurs.
However, attempting to use a workflow or dialog to perform the assign fails. The difference lies in the code in the built-in "Assign" workflow step. Apparently, the Assign activity that is used in workflows attempts to Read from the record AFTER making the assignment, and it is attempting to do this read using the original user's credentials. The following call stack obtained from the error that we get in the workflow verifies that an attempt to read the record is occurring:
at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.Retrieve(String entityName, Guid id, ColumnSet columnSet, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType) at Microsoft.Crm.Extensibility.InprocessServiceProxy.RetrieveCore(String entityName, Guid id, ColumnSet columnSet) at Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy.Retrieve(String entityName, Guid id, ColumnSet columnSet) at Microsoft.Crm.Workflow.Services.AssignActivityService.<>c__DisplayClass1.b__0(IOrganizationService sdkService) at Microsoft.Crm.Workflow.Services.ActivityServiceBase.ExecuteInTransactedContext(ActivityDelegate activityDelegate) at Microsoft.Crm.Workflow.Services.AssignActivityService.AssignInternal(Guid entityId, String entityName, AssignType assignType, Guid assignTo) at Microsoft.Crm.Workflow.Services.AssignActivityService.ExecuteInternal(ActivityContext executionContext, AssignEntity assignEntity) at Microsoft.Crm.Workflow.Services.AssignActivityService.Execute(ActivityContext executionContext, AssignEntity assignEntity) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
I believe it is a bug that the custom workflow activity attempts to read the record using the original user's credentials after the assignment is made.