Try Microsoft Edge
A fast and secure browser that's designed for Windows 10
For the latest updates to this post please visit the original posting here: Pros and Cons of Role Based Forms in CRM 2011
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.
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.
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?
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.
The post Pros and Cons of Role Based Forms in CRM 2011 appeared first on PowerObjects.