Scenario where Impersonation in custom workflow can be used for Dynamics CRM

By | August 8, 2016

Requirement: 

Recently we had a request where client wanted to have an automated process of assigning the case to a team member.

To explain further, whenever any case is created in Dynamics CRM and when it is assigned to a team, that case should automatically get assigned to the first team member of that team. Once the case is assigned to the first team member, and if a new case gets assigned to same team again then that new case should be assigned to the second team member instead of first one.

In this process of automation, if any user does not want case to be assigned to him for some period then he can remove himself from the team and when he is available then he could add himself back in the same team. For this scenario, we started thinking of impersonation.

Because in this scenario, normal user (User who does not have the privilege to add/ remove a user in a team) can Add/Remove himself in a team.

Problem Faced:

Here is the problem faced while adding the user in a team.

After creating real time OOB workflow that has the owner as System Administrator user and which will call custom assembly.

The normal user need to run this real time OOB on-demand in order to add himself to team by clicking the “Run Workflow” button on team.

In custom assembly, we had used “AddMembersTeamRequest” to Add the members in team and passed the “UserId” to the CreateOrganizationService.

When we ran the OOB on team by clicking the “RUN WORKFLOW”, below shown permission error popped up as normal user ran the workflow that did not had privilege to add member in a team. business process error

On team, after executing the OOB on-demand, we noticed below thing.

  • Whenever we run the workflow on-demand, we get the UserId and IntiatingUserId as follows.
  1. UserId: User running on-demand workflow.
  2. InitiatingUserId: User running on-demand workflow.

As you can see, both are same.

  • And whenever any workflow get trigger automatically
  1. UserId: Workflow owner
  2. InitiatingUserId: Triggering user.

In our case, in custom assembly we had passed the UserId to CreateOrganizationService which means assembly was running under normal user (user who didn’t had the privilege to add user in team) that’s why we were getting the error.

Solution:

To overcome this, we retrieved SYSTEM user id and passed that user id to the CreateOrganizationService as shown below.

public Guid getUserId(IOrganizationService service, string userName)
        {
            Guid systemUserId = Guid.Empty;
            try
            {
                QueryByAttribute queryByAttribute = new QueryByAttribute("systemuser");
                ColumnSet columns = new ColumnSet("systemuserid");
                queryByAttribute.AddAttributeValue("fullname", userName);

                EntityCollection retrieveUser = service.RetrieveMultiple(queryByAttribute);
                systemUserId = ((Entity)retrieveUser.Entities[0]).Id;
            }
            catch (FaultException<OrganizationServiceFault> e)
            {
                throw new Exception("Error: >>" + e.Message);
            }

            return systemUserId;
        }

   IOrganizationService systemService = serviceFactory.CreateOrganizationService(getUserId(service, “SYSTEM”));

So the workflow ran under the system admin user who has all the privileges and user were added to team successfully.

Or else we can directly pass the guid of the any other user who has the privilege to add the user in a team to the createOrganizationService as shown below.

IOrganizationService service = serviceFactory.CreateOrganizationService(new Guid(“C1A5741C-6131-E611-80EE-C4346BDC2F41”));

Conclusion:

In this way Impersonation can be achieved in custom workflows by passing the SYSTEM user id to the CreateOrganizationService. So that user can automate the process of assigning the case to a team Member.

Have you checked whats new in Maplytics August Release?