In building a range of Seamless connector plugins, we’ve worked with a number of APIs for different platforms. That experience has sometimes been an absolute validation of how the API ecosystems should work (shout out to Dynamics, Autotask and Freshdesk) and sometimes, well, sometimes just a big ol’ steaming pile of unmentionableness.
In celebration of our first “official” day designing and developing software for Recursyv, we turn our attention to the birthday controls within Dynamics CRM. Getting to know customers and being responsive to them on a personal level is one of the drivers of implementing a CRM system. In this light, it’s frustrating that the storing and use of birth dates is so poorly handled.
Let me illustrate with the birthday selector on the contact form.
It’s a standard date control. You’d think there’d be no problem there, but in practice it means that either you need to know the contact’s birth year or your data is inaccurate. One is unlikely, the other is inelegant. Neither make for great design. In practice, the pragmatic approach is just to ignore birth year in the data set, but it seems that in a mature software system, it shouldn’t be necessary to use workarounds for such basic features.
Our design ambition for the In-a-Box product set is that it should be intuitive and easy-to-use. Inelegant workarounds don’t fit into this mindset. Consequently, our current thinking for the In-a-Box product set is to create custom fields for birthday (day of the month, i.e. 1 – 31) and birth month. This will at least enforce that data held on system is robust (i.e. accurate). It will require some changes to views but that’s straightforward enough. In practice, the data should be used to drive dynamic marketing lists and that is easily achievable with data structured like this.