In this post we are going to explore navigating to field customization and the customization interfaces. Field type comparison is the subject of Part 2.
In either case you end up with a list of fields for each entity/object. How you get there differs.
With Dynamics you can either choose Customizations or Solutions from the Settings menu. While this is off topic, best practices dictate that modifications should be done in solutions. Salesforce breaks objects into standard and custom. Standard objects such as Accounts are accessed through the Customize menu option under Setup | Build whereas custom objects are accessed under Setup | Create | Objects.
In both cases the Fields menu option displays the list of fields. In Dynamics it is a single list that can be sorted and filtered to show all fields or only custom fields. Salesforce maintains separate grids for standard and custom fields. One limitation of Salesforce is that the fields cannot be sorted. The default is alphabetical by the field label.
Adding a Field
New button to add a field.
Dynamics uses a one form approach whereas Salesforce field addition is done through a wizard. There are pros and cons to both approaches. If you are adding a lot of basic fields Dynamics is considerably faster. This does come at the expense of later customization in other areas for field level security settings and inclusion on page layouts (forms).
Each field type has unique settings and with few exceptions these settings are reasonably similar. Both platforms provide documentation outlining these settings in more detail.
Modifying a Field
Use the same process as described above to navigate to the field. Click
Edit instead of
Both platforms allow a field label and an internal name. Salesforce has an additional API Name that is used when accessing the field in code. Salesforce also has a few additional options that are not the subject of this post.
What is notable here is the differences in flexibility. Dynamics does not permit changing either the internal name or the type of the field. Salesforce allows both of these and this comes with potential consequences. Changing an internal name will not change the code that references it and this will lead to exceptions. Data loss is also a possibility. With these caveats in mind, there are times when having the option to change field type is handy.
Let’s assume that we have created a single line text field and later determine that it needs to be upgraded to a multiple line text area field.
- Dynamics: create a new field, create a workflow to migrate the data from the old to the new field, add the new field to forms, remove the old field from forms, delete the old field.
- Salesforce: click the
Change Field Typebutton and follow the prompts.
Deleting a Field
The first thing that comes to mind when deleting a field is dependencies. Once again, use the same process as described above to navigate to the field. Click the
Delete button or icon.
Both platforms do a decent job protecting you from yourself. In the event you attempt to delete a field with a dependency the operation will fail. With a click or two you can see the list of dependencies and drill into each.
There is one exception to this: Salesforce will only warn you in certain instances. As a general rule, Salesforce will allow the delete in any case where it can safely remove the dependencies. If the field was included on a page layout or report the references will be deleted with no warning. Although Salesforce does not have a comprehensive dependency list you can download the Field Dependency Finder from the Salesforce AppExchange.
Reverting a Delete
A really nice feature of Salesforce is that it retains deleted fields for 15 days. This is particularly useful in a sandbox environment where you are making many changes during the design stage of a project. The ability to retrieve a deleted field is not much different than the backspace key! A link to deleted fields appears at the end of the custom fields list as shown in the above figure.