Thursday, April 26, 2012

CRM UI Tip: Chnaging prefix of custom entities

1. Go to the default publisher record. Its located in the Customizations section of CRM 2011.
2. Locate the prefix box at the bottom left of the form.
3. Update and save.

CRM 2011: Disable Duplicate Detection Save button on Popup

So in my efforts to reduce usage of plug-ins in CRM 2011, I decided to re-evaluate the duplicate detection I had designed.

Quick Overview:
CRM 2011 allows you to create duplicate detection rules that will attempt to find duplicates on criteria you select. However, the user has the ability to save the record regardless. My first inclination was to create a couple of reference entities and utilize the Create and Update message of the plug-ins. After talking with some other CRM guys, I've learned that handling writing of any entity is just too costly.
This technique I will describe below will change the behavior of the duplicate detection view duplicates page. If you don't want to do this proceed no further.

Instructions:
1. Navigate to your CRM instance on your app server.
2. Navigate to \CRMWeb\Tools\DuplicateDetection\ViewDuplicates\
3. Edit this file in Visual Studio or Notepad.
4. Add this line to the ShowPage() javascript member or any member that is called by onLoad():
document.getElementById("btn_id_Ok").disabled="true";
5. Save your change.

This simply disables the button as you can tell. The fun part would be to allow not allow by the current user's role. I suggest using WhoAmI() or any AJAX call to accomplish what you want.

Happy Coding!

Thursday, April 19, 2012

CRM2011: Export entities from one organization and import to another while changing the ownership of the entity.

In this post I will demonstrate, with code examples, how to export your structure from one org to another using the SDK.
Before I really got knee deep in it, my first inclination was to modify the customizations.xml file and import into the new org. The idea of modding the xml is a great way to  However considering the idea of creating relationships and lookup fields, this practice always fails.
The solution lies within the SDK of CRM 2011.

The basic concept is this:
1. Retrieve the entity structure from one organization.
1b. Modify structure as needed. In my case I need to change the ownership to user/team owned but you can also add fields, views, etc.
2. Loop through the custom entities and add to new organization.

In reality, at a low level viewing, it works like this:
1. Retrieve the entity structure from one organization.
2. Loop through the custom entities and add to new organization.
2a. Find entities where prefix matches yours to filter out system entities.
2b. Modify structure as needed. In my case I need to change the ownership to user/team owned but you can also add fields, views, etc.
3. Create new entity, minus any attributes.
4. Create attributes that aren't of type Lookup.
5. Do Steps 2 and 2a.
6. Create one to many relationships for each entity. This will create the many to one to the corresponding entity and also the lookup attribute you filtered out earlier.
7. Create many to many relationships.
8. Complete.

SDK objects used:
enums for componenttype and systemformtype. located at helpercode\optionsets.cs
Microsoft.Xrm.Sdk.Messages
Microsoft.Xrm.Sdk.Metadata
AttributeTypeCode
RetrieveAllEntitiesRequest
RetrieveAllEntitiesResponse
EntityMetadata
AttributeMetadata
CreateEntityRequest
CreateAttributeRequest
ManyToManyRelationshipMetadata
CreateManyToManyRequest
CreateOneToManyRequest
LookupAttributeMetadata

Members to create:

  • member using RetrieveAllEntitiesRequest and RetrieveAllEntitiesResponse to get entity structure.
  • member using CreateEntityRequest to create entity.
  • member using CreateAttributeRequest to create entity. This member will need to filter using AttributeTypeCode.Lookup.
  • member using CreateOneToManyRequest and LookupAttributeMetadata to explicit bind a new relationship. The lookup needs to be created in the request.
Considerations:
  • When using RetrieveAllEntitiesRequest set the EntityFilters property to All. This will take longer but will grab all attributes and relationships if you want to do this in one routine.
  • When looping through, do a conditional to only run process on entities that are custom.
  • In the CreateEntityRequest Notes and Activities won't acknowledge you structure setting so set these booleans.
  • In the CreateEntityRequest Primary Attribute has to be created. Set the RequiredLevel to None.
  • When using CreateAttributeRequest, loop through the EntityMetadata where IsCustonAttribute is true and attributeof is null. AttributeOf seems to correlate to a lookup.
  • When using the CreateOneToManyRequest, set the ReferenceEntity and the ReferencingEntity.
  • When using the CreateOneToManyRequest lookup property, get the displayname by using the localizedlabels[0].Label property.
Good Luck and comment with any questions.

Wednesday, April 11, 2012

CRM 2011: Setting up relationship to allow delete of parent but not children

I recently have been working on dynamically changing an entity that was originally setup as organization owned to be team owned.
After pulling my hair out trying various methods that would allow me to keep the data intact, I decided to export the data and empty out the entity so I can update it. This method allows me not to drop the entity and use the method from my earlier post.

However, the relationships are set up as referential and that won't work for what I want since there are child records related. The way I got around this was to setup those relationships as Configure Cascade. I then selected the Remove Link action in the Delete picklist.

Monday, April 9, 2012

CRM 2011: Changing an entity from organization owned to team or user owned without dropping

So after my testing with role based security, it became obvious that the entities that are newly created should be given team or user based ownership to ensure the security would be used correctly.
However what if you already have entities created and are unwilling to drop and recreate the entity?

I have to preface this by saying this is unsupported by Microsoft but will do the trick.
The key is updating not only the customizations xml file but also the EntityView in the SQL database.
To do this you will need the proper role such as System Administrator.

Steps:
1. Gather the necessary xml needed to add owner columns and a team relationship. I find this easier if you can create a sample entity that is user or team owned and copy the specific xml. Always keep a backup of your initial solution to ensure you can roll back.

2. Locate the EntityView inside your database. Navigate to the specific entity in question. Notice the OwnershipTypeMask column. This will be set to 8 and will be updated to 1.

3. Update the EntityView record to OwnershipTypeMask to 1.

4. Once this is done, you can now push your updates to CRM using the solution. The next steps will help you attempt to locate the nodes you need to update.

5. Add the atrributes you gathered from the test entity. These include
OwnerId
OwnerIdName
OwnerIdType
OwnerIdYomiName
OwningBusinessUnit

6. Scroll to the <OwnershipTypeMask> node. If you are using a solution exported from before your sql change, you will have to change the value to say UserOwned.

7. Add to the EntityRelationship section of the file. Again, if you have the test entity do a search for team_ and it should find it. Duplicate this and insert accordingly.

I would only attempt this if you are familiar with modifying the customizations file extensively. One wrong move and you will have to try various routes to revert back.

It can be done but the road is slippery when wet! :)

CRM 2011: Utilizing Role Based Security to hide and show records

One of the interesting features of CRM 2011 is the expansion of the team concept in role based security.
In the past, ownership of a record was on a user or organization basis. However now, a team can now own a record which can affect everything from adding roles to teams instead of users to adding multiple teams to a user.

After testing out various theories using role based security, I have found that for a standard end user, implementing and maintaining roles for each is cumbersome. By removing roles from the user and adding them to the team, maintainability is often easier.

A useful way of implementing teams is allowing access to individual records in an entity. Each team can have certain access, such as read or write, but also you can hide individual records from users who shouldn't have access.

Example:

1.       Create 2 entities.
2.       Create 2 Business units.
a.       These business units represent a client such as Apple and Microsoft.
b.      When creating a business unit, you must declare a parent. The parent in this case will be the master data. An example would be something like software.
3.       Create 2 Teams.
a.       These teams are assigned to their respective Business Unit. This step is optional since creating a Business Unit above also creates a Team with the same name.
4.       Update a standard role in CRM to only show business unit when reading.
a.       This is represented by the yellow half circle.
5.       Remove role from user.
a.       If a role is set to the user, it will override roles implemented in the team.
6.       Add update role to the each team.
a.       This step and the before mentioned are gotchas.
7.       Add three records to the team owned parent entity.
a.       Three records were created, one owned by the master data team. One owned by Apple and one by Microsoft.
b.      Ideally in this step we should only see 2 records. Master and whatever team(s) the user is a part of.

So say your three records consist of Photoshop, Final Cut Studio and Microsoft Office.
You would want Photoshop accessible by both since it runs on both Apple and MS software.
However you wouldn't want to see Final Cut Studio as a MS Employee not MS Office as an Apple Employee.
By following the above example, you can add users to teams associated to each record and they will only see the two specific records.
The reason they both see Photoshop is because its owned by the master BU which both BUs are a child of.

If implemented correctly, this feature can be utilized and all facets of CRM; including xRM, dashboards, reporting, etc.

Also if you have a developer or system admin user and want to see all records, simply add the system administrator role to the user.

If a role is set to a user, it will override any team roles.


Happy Coding!