How Secured Fields are Displayed
Both platforms support field-level security paradigms. Aside from a slightly expanded set of options in Dynamics, access to a particular field can be effectively restricted in Salesforce and Dynamics.
Let’s start with how a field is displayed on the form.
There are a few things to note. The most obvious is that when a field is hidden using field security it is completely removed from the page view in Salesforce even if that field is present on the current page layout. This is not the case for Dynamics. If you are migrating from one platform to the other and are insistent on having the new platform function like the old one, let me offer some not-well-thought-out suggestions.
- Hiding the field in Dynamics is as easy as creating an additional form without the field and assigning security roles to the different forms.
- Since Salesforce is not designed to show “non-visible” fields by default, any workaround is quite messy. In theory a new formula field could access the value from the original field and show it depending on the profile. Another option is to use encryption. While both of these might be a great exercise in building your Salesforce administrator knowledge, my advice is to always use the platforms as they were designed unless the use case is compelling.
Both platforms support in-line editing on forms. There is no choice with Dynamics. Salesforce, however, gives you the option of requiring the user to open a separate edit form or the option to use in-line editing as well. At the risk of getting too far off topic, here is a quick look at the edit form in Salesforce:
Applying Field Level Security
The concept is simple. Metadata for a particular field is modified to restrict access already granted to the current user. This means, of course, that giving a particular user rights to edit a field when the user does not have rights to either edit the particular record or any record on that object/entity is meaningless. Our first assumption is that there are groups of users that currently have access to a particular field and this access needs to be restricted.
What types of access can be configured?
| Platform | Visible | Read | Edit |
| Dynamics | always | Allow Read | Allow Update, Allow Create |
| Salesforce | Visible | Visible | not Read-Only |
We already covered the visibility issue. Dynamics divides editing into changing a field value when the record is first created versus when it is updated. This is not an uncommon situation. For example, a sales representative may be required to enter the value of an opportunity or a goal when it is created but she is not allowed to modify it. This insures that the sales manager has control over adjustments.
A little more work is required to achieve this in Salesforce. It can be done through validation rules. The rule checks to see if a particular field has been modified and verifies that the current user’s role has “permission” to make the change.
Setting Field Level Security in Dynamics
The figure below outlines the steps necessary to create a field security profile and configure security for a particular field. For a complete description of steps, including how to enable security for a particular field, please refer to Dynamics 101 or Hosk’s Dynamic CRM Blog.
Setting Field Level Security in Salesforce
Unlike Dynamics, Salesforce does not have separate field security profiles. I suspect that this extra granularity could potentially give Dynamics more flexibility in certain situations but so far I have not personally seen a need for an extra layer. Salesforce ties field security to the existing profiles.
There are two ways to access the settings for a particular field.
For this example, from the Setup page choose Build | Customize | Opportunity | Fields | Estimated Revenue. Recall that Salesforce divides objects into standard and custom. If you wish to modify a standard object choose Customize and if you want to modify a custom object choose Create | Objects.
The alternate route, again from the Setup page, is to choose Administer | Security Controls | Field Accessibility and either select View by Fields or View by Profiles. Once again, my apologies for a short digression. I find that this second route provides valuable high-level information as shown below.
Now, back to actually editing the field security. The field access columns in the above figure are hyperlinks. The profile that needs access to this field is Standard User. Currently the access is restricted to read only.
All settings related to the visibility and functionality of this field are available in one location. Here you can modify the field level security, which applies to everywhere the field is accessible, or you can manipulate the properties of the field as it pertains to a particular page layout.
Also note that unlike Dynamics field security is not enabled or disabled for a field. It is a property of every field.