A Couple of Form Security Tricks

Forms have come a long way in CRM 2011 and here are a couple of tricks I use a fair amount.

Hiding Locked Fields

Some forms have fields which simply cannot be taken off the form. A good example is the Account Name field on the Account entity.

While we can stop the field from being compulsory, by going to the field settings, we cannot remove the padlock indicating it is locked to the form (and any other forms we create from this one).

The solution is we hide the field in a hidden section. If we create a new section on the form, we can set its properties to be not Visible by default:

All we then do is drag our locked field to this hidden section and we no longer see it on the form.

Please note: If you put a compulsory field in a hidden section and try to save the record it will automatically expose the hidden section so you must make the field not compulsory for this to work (or autopopulate it via jscript OnSave). Also, as in my example, if you are hiding the default name attribute, populate it by using either a jscript or workflow because, otherwise, any child record will show a blank lookup reference, which can be confusing for users.

Dodging Compulsory Fields

Let us say you have a two-step process for handling cases. The call center team receive the emails, quickly reply to the simple queries and convert the trickier ones to Cases for the resolution team. The resolution team then get into the details of the Case and resolve it. It is conceivable that the call center team will not need to know as much detail as the resolution team and, being a team which is dealing with high volumes of queries, simply do not have the time to get bogged down into finding out the important information. It makes more sense for the resolution team to find this information out as part of their investigation.

In version 4, this meant we had a problem. If there are key fields on a Case form needed for things like business reporting, assuming they are compulsory, they must be filled out when the Case is created. Even today, many consultants will tell you to get around the problem we either relax the compulsory nature of the fields or write some tricky jscript to check the role of the user and tweak the fields dynamically.

With 2011 there is a little known alternative approach using forms. As you may know we can create multiple forms for a given entity and assign them to different security roles. We can even create roles with no actual security rights but use them as a way of giving forms to users.

In our case, let us create two forms: one for the call center users and one for the resolution team. We will take the detailed form with all our compulsory fields on it and ‘Save As’ to act as a template for our call center version. The problem comes when we try to remove the compulsory fields; the computer says ‘no’.

To get around this, we do a bit of a supported hack/workaround. We go to the field in question, make it non-compulsory, come back to the form, remove it and then make the field compulsory again (you will probably need to publish the changes between these steps as well).

The net result is we have a form with a bunch of compulsory fields missing from it. What is great is the form does not complain when the call center staff use it and hit the save button; it seems saving only checks the fields on the form in visible and hidden sections but not the fields off the form. This means the call center can create the seedling of a Case, assign it to the resolution team and, because the resolution team only have access to their detailed version of the form, they are forced to fill in the rest of the compulsory fields. No code needed and no compromise to what the business needs to capture.

Conclusions

If you are looking at form design and working with forms for entities like Cases or Products, you may have come across the kinds of problems mentioned above. With any luck these tips might save you some angst and code writing, enjoy