KB001196

Note: The content in this article is specific to Microsoft Dynamics CRM 4 only.

Introduction

To enable Service Accounts to own entities within CRM, impersonation can be configured using the WEB Services. Once this has been configured the service account; which is the logged on user and the logged on user owns the identities, would be able to manipulate entities specifically for the default views for example My Tasks and My Leads.

System Configuration

Before the K2 Service Account can be given ownership of entities within Microsoft CRM, preliminary steps must first be completed within Active Directory. The steps below must be followed first and are a prerequisite before configuring Microsoft CRM.

The CRM Impersonation feature requires the logged on user to be a member of the PrivUserGroup in Active Directory and a GUID is used to identify the user in the User Entity. See below on how to configure this:

1. To add the K2 Service Account to the PrivUserGroups it is usually located at the root of the Domain. Once the K2 Service Account has been added, the Administrator may need to do one of the following to ensure that the steps take effect:
   1. gpupdate /force
   2. Refresh the Active Directory Service
   3. If the above two steps do affect the update, then the Administrator can logout and then login again. Alternatively, the fail safe way to ensure that the changes are put into effect is to restart the server
2. When impersonating the K2 Service Account with Microsoft CRM web services, the user account name domain and password are not passed for authentication. A GUID, generated within the Microsoft CRM Server is used and the GUID identifies the User Entity i.e. System name: System user.

The GUID has already been generated from within Microsoft CRM and can be located in one of three places. See the steps below to locate the GUID via:

• Microsoft CRM User Interface
• K2 SmartObjects
• K2 SmartObjects from within the K2 Designers

Microsoft CRM User Interface

1. From within Microsoft CRM go to Settings > Administration > Users
2. Locate the entity i.e. K2 Service Account and open it
3. Press F11 to put the window into full screen mode
4. Copy the GUID from the ID query string value.

Options available to retrieve the GUID

Via SmartObjects

To retrieve the GUID using K2 SmartObjects perform the steps below:

1. Register an Instance of the CRM Entity broker
2. Create a SmartObject against the User entity
3. Perform a Get List call against the CRM User SmartObject
4. The User column contains the GUID that you need

SmartObjects in the K2 Designer

To retrieve the GUID using SmartObjects from within the K2 Designer:

1. Use your CRM User SmartObject and do a filtered list
2. Pass in the FQN of a user to the Domain Logon Name field – make sure you trim out the label prefix.
3. Use other filter values if you need
4. Store the User value for later use

Usage Scenario

Note: The example below requires that the aforementioned steps be completed first before attempting it.

In this example a new Task entity will be created for each destination user

Important: Note: Not all steps are provided

1. Add a Client event to the process
2. Add destination users: Ensure that the destination rule options are set to the following
   1. All at once
   2. Resolve all roles and groups to users
3. Drag a SmartObject wizard onto the Activity : this will be used to perform the Get List on the CRM User SmartObject which needs to be created
4. Configure the Input Mapping so that Domain Logon Name has a value of ActivityInstanceDetUserName, use Inline Functions to remove the K2: label
5. In Return Mappings save the User field to an Activity Data Field

Create the CRM Task

1. Add the CRM Event wizard to the process
2. Specify the CRM Server URL, Org Name, and Entity Name i.e. Task
3. Specify the relevant Entity Attribute values

Implementing Impersonation

1. View Code, Event Item on the CRM Event
2. The code clearly shows the three methods, Create, Update and Delete. Since a New Entity will be created, minimal modifications to Create code are required
3. The Wizard code contains two methods for GetCrmService, these implement the impersonation feature, and unfortunately the wizard UI just doesn’t have a means to leverage it
4. In the try block we are going to make the following change

Comment out:

Replace it with:

Caution: Do not replace the creation of the service on line 284 for Create or 596 for modify. This instance of the service is used to retrieve systems values for other elements of the wizard which the impersonating user may not have permission to access.

Summary

To finalize, if the requirement is to modify or create entities in Microsoft CRM as a user other than the K2 Service account then it is possible with just a few minor changes to the event wizard code to facilitate this. The advantage is that impersonation uses a standard feature of Microsoft CRM and does not require username and password i.e. credentials to be specified.