Background

Ad you may know, CRM allows you to pick the layout style for a section within a CRM form.  For the most part, their settings work just fine.

In January I did a short presentation on CRM User Interface tips and tricks for the XRM Virtual User’s group where I reminded everyone that even once you have picked a format for a Section, you can still change the width of the fields labels within the section.

It’s highlighted below:

Unfortunately, it has a maximum value of 250 pixels, which is usually fine, but what if I have a really, really, long label?

The Scenario

Let us pretend that I am creating a questionnaire inside CRM to gather some type of relevant data.  I either create a Questionnaire Entity or just add some question attributes to an existing Entity.  Either way, I have a lot of question text and not much room to show it and it might look something like this:

Note: This is using the default column layout for a Section.

Notice that my answers are also really small – basically Yes or No, or a short amount of textual information – and they are taking up over 50% of the Section area.

We need to fix that.

The Solution

Ok, we’re going to change the column width of both columns within the Section using JavaScript.  But let’s start with a look at the HTML that makes up our Form:

CRM uses something called a Column Group ( colgoup ) to help define how the columns of the table are to be sized.  As you can see from the picture above, the column that contains the label is 250 pixels wide and the column that contains our data entry field is 270 pixels wide.

Using the following JavaScript, we can modify those values to be more representative of both the data and the label requirements:

var tableObj = crmForm.all.new_q1_c.parentNode.parentNode.parentNode;
var col0 = tableObj.getElementsByTagName("col")[0];
var col2 = tableObj.getElementsByTagName("col")[2];

col0.width = "60%";
col2.width = "40%";

How This Works

Step 1:

First we need to get a handle to our form field’s parent table, which we do with the first line of JavaScript.  crmForm.all.new_q1_c is actually the table cell that contains the label of our first form field ( which is the attribute new_q1, by the way ).

Step 2:

Next we need to get the handle to the first and third col objects that belong to the parent table which we accomplish by using the getElementsByTagName function.

Step 3:

Once we have that information, we can set the width of the first column to 60% of the container’s space ( the table ), and set the third column width to 40%.

Your new section layout should look like this:

You can change the values for each column to meet your requirements.

Note: I actually have a question at the bottom of this list that occupies much of the form but it contains customer-specific information so I can’t show it.

Conclusion

As I mentioned, this is very unsupported and I can’t guarantee it will work in every circumstance, but it seems to fit the need I had.

Also, If you’re good with jQuery, you can probably do something very similar with less code.

The Requirement

I needed to create a list of users that were members of a specific security role.  Rather than writing an application or designing a SQL query, I opened Stunnware Tools for Microsoft Dynamics CRM so that I could create a query in the FetchXML Wizard.

Using the FetchXML Wizard

The FetchXML Wizard allows you to query CRM by building a FetchXML query.  Here is a screen shot of the Designer:

Designing the Query

The following steps were required to created the desired query:

Step 1:

Query the SystemUser entity and return the Full Name of the user.

Step 2:

Include a Linked Entity that links the SystemUser Entity to the SystemUserRoles Entity

Step 3:

Add another Linked Entity from SystemUserRoles to Role.  This link will have a filter applied where the Name of the Role is equal to salesperson.

Here is the resulting FetchXML query:

<fetch mapping="logical" count="50" version="1.0">
  <entity name="systemuser">
    <attribute name="fullname" />
    <link-entity name="systemuserroles" from="systemuserid" to="systemuserid">
      <link-entity name="role" from="roleid" to="roleid">
        <filter>
          <condition attribute="name" operator="eq" value="salesperson" />
        </filter>
      </link-entity>
    </link-entity>
  </entity>
</fetch>

Which produces the following result set:

This whole process took me less than 5 minutes because the FetchXML Wizard Query Designer understands the links between CRM Entities and allowed me to quickly select those links and specify the necessary filter to produce the dataset I needed.

The Export to Excel module included in Stunnware Tools allows me to export the above result set to an Excel worksheet.

More About Stunnware Tools

There are two editions:

• The Community Edition: It's free and contains the Metadata Viewer, FetchXml Wizard and Excel Export.
• The Professional Edition: A subscription-based version with access to all tools of the Community Edition plus the Code Generator for C# and VB.NET, the CRM Help File Generator, additional features of the FetchXml wizard and the Customization Comparer.

Stunnware Tools is probably the most valuable Dynamics CRM add-on that I have.  I use it on a weekly, if not daily basis and which makes me a much more productive developer.

The user interface is fairly straightforward, as you can see below:

How It Works

The operation is pretty simple:

1) Select if your organization is OnPremise or CRM Online.

2) Enter the name of your server and the credentials required to connect properly.

3) Select the organization you wish to connect to.

4) Select the Entity you wish to delete attributes from.

5) Select the attributes to delete.

6) Click the delete button.

Behind the Scenes

This utility uses standard CRM SDK methods to delete the attributes you specify.  A log file is written to the location where the application is stored.  All actions will be logged and if errors are encountered, the log file will be displayed at the end of the processing cycle so you can see what happened.

Remember: The same rules that would apply if you were to delete an attribute through the CRM user interface apply here.  For example: if the attribute is used on a form, a view, or within a workflow, the deletion will fail and you will be given a list of locations where the attribute is in use.  You must remove the attribute from those locations before you can continue.

Download

You may download it here.

Perform the following steps:

1) Navigate to your CRM 4.0 installation folder, ( c:\program files\Microsoft Dynamics CRM ).

2) Open the Setup folder.

3) Set the View of the folder to be Details.

4) Right click on the file list grid to display the pop-up menu:

5) Click the More… menu.

6) Scroll down the Details list until you find File Version and check the box beside it:

7) Click OK and your file list will update to show something like this:

Fairly simply, I know, but it just occurred to me that this feature was available and it is surely easier than checking files individually.

But first, a bit of background from Jon’s article:

A non-interactive user is a user account in Microsoft Dynamics CRM Online that can access the system but only via the web service layer. Essentially, that user can not use the user interface. Service accounts are used to access CRM Online using the service to service model. A service account is a non-interactive user account with the proxy role assigned to it. Microsoft Dynamics Online allows 5 free non-interactive user accounts. To make the user account a non-interactive account, you need to change the access mode. The access attribute is not visible in the UI by default.  The attribute is “access mode”, you can either customize the form to show it, or manipulate it by an SDK call.  Setting the access mode to non-interactive simultaneously frees up a license and prevents that identity from logging in interactively.

He goes on to tell you how to add the Access Mode field to the System User Entity form so that this field can be changed by the administrator.

You may also find it useful to put the Access Mode on the Active Users View, so that it displays when you are reviewing your user list:

Interesting Observation

Last week I was discussing non-interactive users with a colleague when I noticed a rather interesting situation:  If you are out of user licenses for CRM Online you can’t create a non-interactive user through the CRM user interface. Curious, but understandable.

In a nutshell, the New User wizard will inform you that you are out of licenses and not allow you to continue.

You can circumvent the issue by performing these steps:

1. Temporarily disable a user
2. Create a new user and change their Access Mode setting to Non-Interactive
3. Re-enable the user disabled in step 1.

That should do it.

Programmatic User Creation

Nothing, however, will stop you from creating a user programmatically.  You just need to supply the proper values.  Here’s some sample code:

systemuser user = new systemuser();

user.accessmode = new Picklist(SystemUserAccessMode.NonInteractive);
user.firstname = "system";
user.lastname = "integration";
user.businessunitid = new Lookup("businessunit", new Guid("{C9694BD7-C0C4-DE11-B95D-02BF0A0679DB}"));

service.Create(user);

As you can see, you only need four properties:

Access Mode

In this case, we’re going to supply NonInteractive as the value, since that is the purpose of our discussion.

First Name

First name of the user.

Last Name

Last name of the user

Business Unit ID

This is the ID of the business unit the user belongs to.

Calling the CrmService.Create method to actually create the user.

Afterwards, any connection that you need to make to CRM Online can use the new non-interactive user instead of a fully-licensed person.

Security and Authentication in Microsoft Dynamics CRM: Field-level Security in Microsoft Dynamics CRM: Options and Constraints

Brief Description

While Microsoft Dynamics CRM does not provide for true field-level security, there are a number of options available for using supported custom logic to control of access to data at a more granular level than provided out of the box. This document discusses some of the key options and constraints available for implementing this type of solution.

Overview

This white paper, Field-level Security in Microsoft Dynamics CRM: Options and Constraints, provides selected aspects of the conceptual application of the security model in Microsoft Dynamics CRM. While Microsoft Dynamics CRM does not provide for true field-level security, there are a number of options available for using supported custom logic to control of access to data at a more granular level than provided out of the box. This document discusses some of the key options and constraints available for implementing this type of solution.

Reporting on your user’s configuration

I created the following process to review how each user had their CRM environment configured.

I started by running the following SQL script:

SELECT

    s.fullname,

    u.homepagearea,

    u.homepagesubarea,

    u.userprofile

FROM

    usersettingsbase u

    INNER JOIN systemuserbase s ON u.systemuserid = s.systemuserid

ORDER BY

    s.fullname

Which results in a report something like this:

So what does this tell us?

Well, the first column is the user’s name, of course.

The second and third columns instruct CRM what to display as the user’s “Home” page when they first start CRM.  These settings are found on the General tab of the Personal Options dialog when the user selects Tools, Options:

The final column defines how the user’s Workplace will appear:

When you select one of the checkboxes in the Select Workplace Areas box, it will add that group to the user’s Workplace area.  The Preview area on the left allows the user to see how the Workplace will look after the changes have been saved.

When you look in the database, the Profile column will contain a comma-delimited list of those groups that should be shown in the Workplace.  Here is the list:

Changing the User’s Environment

The only problem with knowing how the user has their CRM environment configured is there is no way to make a global change unless you write an application to do it.  If you don’t feel like writing an application, you’ll need to fix the any issues by logging into CRM as that user.

Security Considerations

If you would like to prevent your users from changing their settings, you can remove the Write right from the User Settings section in their security role:

1) Export the Entity in question. In my case, it was Opportunity.

2) Locate the Quick Find view.

3) Change filter type from this:

<condition attribute="statecode" operator="eq" value="0" />

to this:

<condition attribute="statecode" operator="not-null"/>

4) Save the customizations.

5) Import and publish the customizations.

This will allow the Quick Find operation to find Opportunity records no matter what their state is ( active, canceled, closed, etc. ).

And yes, this is unsupported.

The Basics

You should have at least one test user for each role in which normal users exist.  Normal being not-CRM Administrators.  This will allow you to test the functionality of your customizations and custom solutions as each type of user.

While this may not seem like a huge issue, you need to keep in mind that CRM alters the environment and the user interface based on the user’s security.  This means that sometimes they will not see things you expect them to or they will have permissions issues where you least expect them.

How to Test

Prior to Windows Vista and Server 2008, you could simply right-click on the Internet Explorer icon, select Run As, then supply the credentials of whatever test user you wished.

Unfortunately, Microsoft changed that behavior and according to this article, it no longer works.  Thanks guys.

A possible work-around is using the ShellRunAs commandlet found here.

It is supposed to provide this functionality but I’ve had mixed results ( probably didn’t follow the directions properly ).

So if you’re using Vista or Server 2008, should nothing else work, you can always just Switch Users and log into the machine as the test user.

What to Test

Here are the usual suspects for testing customizations within CRM:

• The Site Map ( left-hand navigation )
• ISV.Config ( buttons and menus )
• JavaScript ( does your custom JavaScript work with all users )
• Custom Solutions ( any custom ASP.NET code you have written and added to CRM )
• Processes.  If you have a process that moves data through the system, test it from start to finish as the particular user or users who actually perform the work to make sure you’re covering the whole process as a “normal” user and experiencing what they experience.

Conclusion

This is, at the very least, the minimal amount of testing you need to perform on a customized system.  You can get as comprehensive and complex as you desire.

If you will document your testing procedures and steps and repeat those each time a change is made, you should be able to more quickly identify problems and create solutions before your changes reach the hands of the users.

This functionality is extremely useful when perfecting data import processes where you are supplying the IDs of the item being imported.

So, I wrote a utility that would call the internal CRM Deletion Service function to run the service against a specific CRM organization.

You will find this utility in the Free Utilities section.

Caveats

This utility utilizes and internal and undocumented CRM function call. 

Undocumented translates to unsupported by Microsoft so you will be using this utility at your own risk. 

That being said, I’ve used this utility for well over 18 months and have never had an issue.  It’s a fairly binary equation: it runs the deletion service or it doesn’t.

I’m finally publishing it because I continue to run into situations where i need this functionality and I figure that if I need it, other people might as well.

Alternatives

If the above statements make you a little uncomfortable, you can always download the CRM 4 ScaleGroup Job Editor.  Which can perform roughly the same functionality as this utility.