It's been over a year since Microsoft introduced the concept of Role Based Forms in CRM 2011. In that year we've run into scenarios where they make a lot of sense, but we've also discovered a few things to consider when using Role Based Forms. We'll discuss things to consider and rate them as Pros or Cons in this article.

For those seeking assistance with Creating and Managing Role Based Forms, we encourage you to read this excellent tutorial.

When you create a new form by performing a "Save As", all of the properties of the original form come along, including any JavaScript that was in use. This can be both a good thing and a bad thing.

One of the great features of CRM 2011 is the ability to consolidate frequently used JavaScript functions to fewer files and use them wherever you need to, but if you intend to have specific JavaScript running for each version of your form, you will need to create a new web resource for each form and assign it to the form, removing resources for other forms. Managing your JavaScript well will save you from troubleshooting errors on the other forms.

Be sure to export your customizations to a solution before making changes to JavaScript, especially when working with Role Based Forms.

With Role Based Forms you can address many of the user interface requirements that were previously only possible with JavaScript.

With smaller forms specifically tailored for the CRM needs of your departments or workgroups, you can eliminate role driven functions and focus on the remaining requirements. This isn't just limited to the body of the form. You can tweak or hide form elements such as header, footer, and navigation, potentially creating shorter forms that require no scrolling.

And, if you minimize the amount of JavaScript in place, your forms will load faster which will allow your users to work faster. They'll love you for it!

Depending on how your organization rolls out Role Based Forms, some or all of your users may end up with access to multiple forms which might require them to switch forms as they use CRM. This is a small training matter but it can become frustrating for users. Form switching can be scripted, so with careful consideration and clever design, this may not be a problem, but it's something to take into consideration.

System Administrators and Customizers will have access to all of the forms for each entity, so be sure to include your support and administration personnel when training on Role Based Forms. Troubleshooting can be frustrating when you're on the wrong form, and we want to keep our support and admin people smiling, don't we?

On the topic of support and admin personnel, in environments that continue to use a main form for everyone with JavaScript to conditionally show and hide form elements, we've used Role Based Forms to create "Admin Override" forms which run free of JavaScript to provide support personnel or department managers a quick view of all of the fields and the data for a record. It's proven to be a time saver in some environments, particularly in environments where field values drive which form elements are displayed.

Role Based Forms can be tedious to maintain, especially for "global" changes.

For example, maybe you customized a form label to refer to some data as "Area" and now the company has decided to refer to this data as "Group". Maybe an iFrame URL has changed and the iFrame is used on each form.

Sadly there aren't easy ways to make these kinds of global changes one time in one place. Someone will have to go through each form and make the changes. Fortunately this doesn't seem to happen much once a CRM organization is established and in production, but these types of changes happen frequently during design.

Each entity needs a "Fallback Form", the default form that loads when the user does not have a role matching one assigned for the available forms. Good practice is to make the fallback form pretty blank, maybe even limiting it to just the required fields. This is no replacement for proper management of security roles, but it could be viewed as a safety net for incorrectly configured security roles.

We hope you enjoyed our discussion on the Pros and Cons of Role Based Forms. (If you want further reading on role based forms, see our post on labeling CRM 2011 forms meaningfully.) If you have any experiences to share we welcome you to leave them in the comments.

Happy CRMing!