This is the fourth part in a series contrasting fields in the Dynamics and Salesforce platforms. In the last post we devoted a section to a unique capability of Dynamics in relation to option selections. To be balanced we now highlight a related feature in Salesforce: dependent pick lists.

Dependent Picklist

A disclaimer: this can be easily done in Dynamics, but will likely require a developer as opposed to an administrator. See this post for instructions on how to achieve this using Java Script.

Suppose there are three widget models and each model can be ordered in certain colors. The widget model is the controlling field and the color is the dependent picklist. In this case both of the controls are picklists.

The additional step required to bring this all together is to create a field dependency.

Images

It is not uncommon to want a picture associated with a contact, product or other entity. Despite this fact neither of the platforms handle this exceedingly well. Both place the image in the upper left corner next to the name. It is a fixed size and only one standard image is allowed per record. Dynamics uploads a file whereas Salesforce requires you to log in to one of the supported social media sites, navigate to the correct person and select that profile.

This is acceptable for a contact, but what about a product or other custom entity? For simple ease-of-use, Dynamics offers the flexibility of uploading any file on disk. This still doesn’t deal with issues such as more than one image per record, image placement or image size.

Past this point Dynamics offers no non-developer options. Salesforce has a rich text custom field that can be leveraged to do nothing more than hold an image with or without text and styling. While this is not optimal, it works.

In the realm of code-based options, you may want to check out a post by Simon Lawrence regarding a classy solution implemented in Salesforce.

Final Thoughts

I have intentionally ignored a few other field types for a variety of reasons. This should give you a good foundation and resources on which to build. There is one significant consideration that will impact any implementation of custom fields and that is how the two platforms handle field interaction and validation.

It’s really quite simple: Dynamics acts like a traditional client-side form-based application even though it operates in a browser whereas Salesforce does not. I suspect this plays a part in the screen responsiveness and overall performance of Salesforce.

In the Dynamics world events can be field-based. In other words, changing a value in one field can influence another field, trigger validation and launch business rules. Custom events can be linked to related Java Script code giving the developer a wide range of possibilities.

Salesforce works on more of a form submit basis. Validation, re-calculation of formulas and launching workflows only occurs when the Save button is clicked. When there are exceptions, such as the dependent picklist example above, it is related to a specific Salesforce feature.

Why is this important? It represents a paradigm shift in design principles. If you are a Dynamics developer moving to Salesforce, you will need to come to grips with this and not fight it. In contrast, Salesforce administrators and developers should take the time to embrace both the flexibility of Dynamics real-time events as well as the associated risks and limitations.