Jukka Niiranen

Tag: usability

  • Relational data on Model-driven forms, part 1: Main Form Dialog

    Relational data on Model-driven forms, part 1: Main Form Dialog

    Model-driven Power Apps are built on top of the relational data model of Microsoft Dataverse (formerly CDS). Planning how you split your business data into different tables is a crucial step in ensuring that your app’s user experience (UX) is optimal for the data entry, consumption and update tasks that the users will need to live with. This is because unlike with Canvas Power Apps, the data model defines much of the user interface behaviour as well.

    The key thing to keep in mind is that you’re not supposed to build the most normalized data model possible, where every concept in your business process is spun into its own little table. Yes, you do want to leverage the power of relationships (one-to-many, many-to-one, and on some rare occasions also many-to-many) to make the data more manageable than a single flat list structure would offer. No, you don’t want to make your users have to think about the Entity Relationship Diagram (ERD) of the system to know how to navigate within your app.

    Despite of the tight coupling of the data model and the UI, there are plenty of things you can configure on Model-driven forms to improve usability. I’ll be drilling into a few recent features that can make it easier to work with related tables from within a single form.

    The scenario: Rental Car app

    I’ll be using an example app that I’ve built for my own purposes: Rental Car App. It contains functionality that allows me to track and analyze information about the rental cars that I use, by adding new Rental records for each reservation I make and then tracking the process all the way until the final invoice and related costs. At the heart of the app there’s the Rental table, which has relationships to both the rental car company information (Account table) as well as the Car table, which again links to a few supporting tables like Manufacturer and Model.

    The rental process stages are modelled via the Business Process Flow feature of Power Apps Model-driven apps. We start with 1) the reservation, then proceed to 2) pick-up at the chosen location, 3) use the car we’ve been given, 4) return it and 5) finalize the process upon ensuring we’ve captured all the required data and that the invoice was what we expected to pay.

    Each rental event will have one car associated with it. However, at the first step of the process, meaning reservation time, we won’t yet have any idea what specific vehicle that will be. (You’ll only know the ACRISS code that describes the level of the vehicle features, like “IWAR” for Intermediate, Wagon, Automatic, Air Conditioning.) Once we get to stage 2 of the process, the pick-up, we’ll be given a specific car that we can describe with properties like Manufacturer, Model, Model Year, Trim Level and so on.

    Car is the parent table of Rental, since there can only ever be a single vehicle for one rental event (for now, let’s ignore the possibility of the car breaking down and getting exchanged during the rental period). A single car will of course be used in many, many rental events. However, since the app user is the customer who’s consuming the rental service from different car rental companies, we won’t have the fleet of vehicles defined in advance for our database. The data entry of the car’s details is therefore always a step within the context of the rental process.

    So, we know that logically the car is a different type of object than the rental event, which is why it should have its own table. From a user experience perspective, though, filling in the details of the car should be just a similar task as describing the duration or price of the rental car reservation. Just a set of fields on the single form. Yet by default what the Model-driven app form will give us is a single lookup field to the related table’s car record, with the expectation that we’d go and work with the Car data on a different form than the Rental form where the rest of the details are.

    Despite of the underlying 1-to-N relationship in the data model, we can improve the user experience by leveraging a couple of neat features in Model-driven apps.

    Quick View Forms

    Model-driven Power Apps have evolved from the XRM platform that Microsoft first used for builing a CRM product of their own in 2003. Around seven years ago when Dynamics CRM 2013 was launched, it introduced this new and exciting “flat UI”. Before that, the experience of using CRM was often a maze of popup windows since opening a new record always gave you a new browser window you now had to juggle on your desktop.

    The boundaries of different entities (which is what tables were called for the first 17 years of the platform we now know as Dataverse) were therefore very tangible indeed. While form subgrids were launched in 2011 to offer some relief, it wasn’t until 2013 when we could start to make the users worry less about the data model and focus more on the business process and actual business data involved in it. A key element in this was the Quick View Form.

    Above is a screenshot from seven years ago of a case entity form that included data from not just the child entities like activities, but also from the parental record of the customer, via a Quick View Form. We can see the email and phone number of the customer, event though they are physically stored on the account entity. It’s not limited to just that N:1 data from “case:account” either, as we can reach down to N:1:N of “case:account:case” by showing all the related cases that this customer has recently opened with our support department.

    Quick View Forms were a seriously powerful feature back when they were released. I did some blogging to demonstrate the possibilities, like building a similar opportunity analytics feature that resembled (well, remotely at least) the concept of an ecommerce recommendation engine that shows “customers who bought this item also bought these other items”.

    The scenario in our Rental Car app is a lot more straightforward. We want to display the key properties of the Car record associated with the Rental record within the form that drives the rental process. By having a lookup field for Car on the form, this allows us to add a Quick View Form control to show the Car table fields embedded on the Rental table form:

    From this static screenshot it would seem like everything is in its right place and the user couldn’t be happier. Right? Well, the challenge here is that the Quick View Form really is just a view. It doesn’t allow editing any of the field values on the related parental table record, let alone creating new records. In short, it’s not as actionable as the data living natively in the Rental table.

    Main Form Dialog (MFD)

    A much more recent entrant into our Power Platform low-code toolkit for designing Model-driven application UI’s is the Main Form Dialog feature. What this allows you to do is to launch a modal window from the lookup field on a Model-driven app form. The user interface doesn’t actually move you fully away from the original record, rather it just renders the (Main) Form of the chosen record from a different table in a Dialog window. It’s not like the CRM 2011 era popup windows, since you remain within the same browser window/tab. Once you’re done with looking at the related record, clicking “X” will return you to exactly same state where you were before clicking in the lookup field. It’s not as jarring an experience as if you’d have fully navigated away from the original form.

    Originally launched as part of 2020 Release Wave 1, the MFD feature was initially available only via the API. At this moment that is still what the documentation says, but I recently discovered that the modern Power Apps form designer now has graphical tools to configure this feature:

    When selecting a lookup field in the form editor, the properties dialog on the right now contains new options to check:

    • Use Main Form Dialog for Create
    • Use Main Form Dialog for Edit

    Oh yeah! We now have the power to keep the users from unintentionally navigating away from the “home” form that acts as the anchor for all relevant details concerning the business process. In the rental car example, the user can now safely click on the Car lookup, examine the available options for properties of the car, change the values, click “Save & Close”, then end up right back to where he or she started from:

    This also works for the experience of adding a new car record. Instead of having to offer a separate Quick Create Form experience for this step that would behave differently from any other occasion where the user interacts with car data, we can launch the full record form in the Main Form Dialog:

    The key benefit with this modal window approach is that there’s almost zero chance of the user wondering into the wrong menu or page of the application after they’re done with creating, editing or just viewing the related record. There is no visible page load that would change the mental context away from the primary record, in this case the Rental event.

    Considerations

    Should you enable the Main Form Dialog feature now on all your lookup fields? Probably not. There will be times when the user may prefer to actually move along in the process and change the context to the parental record. There is no navigation path available in MFD that would support this context change. The user has the option to launch the dialog in full screen mode, but that just expands it to cover the whole screen, rather than doing a page load that would change the navigation position in the sitemap.

    There is currently no way to select which form specifically should be opened in MFD. Presumably the form will be determined by the table’s main form order, as well as the specific form the particular user has last viewed. Depending on the number of scenarios where the same table is leveraged, the forms shown by MFD can therefore be unnecessarily complex for the task at hand.

    In part 2 I will explore the possibilities of how we can streamline this process even further and make the experience of working with related parental table data almost transparent to the user. We’ll be leveraging the brand new Form Component Control to essentially combine the features from the earlier Quick View Forms and Main Form Dialogs.

  • Make your Power Apps search experience more Relevant

    Make your Power Apps search experience more Relevant

    Microsoft recently launched a brand new search experience for Model-driven Power Apps and therefore also first-party Dynamics 365 apps operating on top of CDS. This is a significant step forward in the “non-structured” search capabilities in Power Apps. The structured queries one can construct via Advanced Find were always one of the most powerful features that the XRM platform could offer on top of relational data (and remain one of my most read posts on this blog). Now also the free text based search experience is catching up nicely:

    Being a low-code application platform, there are several configuration options related to how the search features in Power Apps behave. This can also result in people missing out on how they could ensure that the search really works the way that the users would expect. In this blog post I’ll go through some common challenges that the Dynamics 365 professionals may have already learned to overcome but which can be surprising to new Power Apps makers.

    Challenge 1: Relevance Search is not enabled

    If you’re not seeing anything even remotely like the MS blog posts when performing a search in a Model-driven app, then you may well be using the limited Categorized Search instead of the fancier Relevance Search. When attempting to change the search type, you might discover that the dropdown actually doesn’t give you any choices, i.e. it’s a dead end with Categorized Search as the only option:

    Why does this Categorized Search option even exist, and why do we need to specifically enable Relevance Search? It all comes down to the on-premises legacy of the platform, where the single CRM server had to be capable of offering a standalone search option. In the cloud era we can leverage Azure Search as the external search index database to where CDS data is syncrhonized to, thus offering a far richer search experience.

    Now, Azure Search being a separate service and possibly having different types of SLAs and other legal variables than the core Power Apps or Dynamics 365 services follow, it’s not on by default even in the MS cloud. An administrator will need to navigate to the Power Platform Admin Center, choose the environment, then go under Settings / Features / Search to flip on the swith that turns on Relevance Search.

    Once it’s enabled, only then will you see the option to also turn on the new search experience (which probably will become the default option in the future). It won’t show up there immediately, so give it a lil’ time.

    Challenge 2: Relevance Seach doesn’t search my entities

    Cool, we’ve now got the new UI up & running. When we do a search from the new prominent search bar always visible at the top, the results are returned for some of the entites. But why aren’t we getting any hits for Widgets, for example? In this scenario we know there are records in there that contain matches to our search string.

    Even though Azure Search provides a richer search index for your Model-driven Power Apps, it doesn’t directly copy each and every table from CDS into it’s database automatically. When working with a Dynamics 365 environment there are some default entites covered (like accounts, contacts, opportunities). For any custom entities and especially with custom apps, you’re gonna have to explicitly tell which entities should be enabled for Relevance Search.

    To access this configuration option you’ll need to leave behind the modern Power Platform Admin Center and venture into the land of the legacy web client and Dynamics CRM era customization UI. You can either add “/main.aspx?settingsonly=true” to your environment URL or find another path into the land of more advanced options. Once there, find Settings / Customizations / Customize The System and open up the Entities menu in the Default Solution window. Now you’ll see what entities are included in your Relevance Search Index and which are not, i.e. they are in the Available Entities list:

    Select the entities you want, click OK, then Publish All Customizations and now they are enabled for the modern Relevance Search experience.

    Challenge 3: Relevance Search doesn’t search the right fields

    Hmm, why aren’t we still getting the full search results for our Widgets entity, even though we added it into Relevance Search? Well, technically you didn’t add the whole entity into the search index. By default a custom entity seems to pick up only the primary field (usually “name”) into the search scope, but it’s likely that you’ll have plenty of other important field that should also get indexed. The same goes for default entities: only a subset of the standard fields are included, and none of the custom ones are, unless you configure them to be included in Relevance Search.

    If finding the menu from where the entities list for Relevance Search is maintained was a bit tricky, then figuring out the place for specifying the field level search settings ain’t that obvious either. You see, it’s not a property of the field in the entity itself. It’s the inclusion of that field in the entity’s specific view called Quick Find View that determines what gets pushed to Azure Search database and back to Power Apps UI.

    Even though the entity view editor can already be found in the modern Maker Portal for Power Apps, these settings aren’t there yet, so I hope you didn’t close that legacy customization UI just yet!

    From the legacy Solution Explorer, open the Quick Find View for your entity, select Add Find Columns from the right and check the boxes for the fields you consider to be potentially useful for Relevance Search. Save & publish your changes, then verify that the search results match with your expectations.

    Challenge 4: Relevance Search doesn’t cover inactive records

    Sometimes the information you’re looking for isn’t found on records that are actively edited anymore, as you may be digging further into the history of your business data to check up on past transactions. In the typical CRM scenarios where Model-driven apps are leveraged this could mean searching through historical sales opportunities that are either won or lost, to find examples of what offers have been made to which clients on what specific terms.

    With the out-of-the-box configuration of Dynamics 365 or Power Apps, you won’t find them via Relevance Seach. Yes, the vast majority of records that you’re storing in CDS may well be excluded from the search index by default. This is because of the same Quick Find View we visited earlier. Not only does it control the fields being indexed, as well as the column layout of the search results page. It also controls the static filters which are applied to the search results before they are shown.

    Using the OoB opportunity entity as an example, you’ll find a system view called “Quick Find Open Opportunities” under the entity. Click on Edit Filter Criteria to reveal the fact that it indeed does only include open opportunities. While we can’t create additional Quick Find Views for entities, luckily we have the freedom to modify or delete the existing filters. So, just remove that status field filter criteria, save & publish. Now your Relevance Search will also return results from the inactive records for this entity.

    Challenge 5: Relevance Search suggestions aren’t found in the search results page

    The new search experience has a nice UX for suggesting matching records immediately as you type the letters in your the search term. Let’s say that we’re interested in the search term “relevance”. By the time we’ve entered “relev” into the search bar there’s already a number of matches in the suggestions box:

    Looks great, but I think I want to see more details, so I’ll click on “show more results” at the end of the search suggestions. Hey, where did all those matching records go?!?

    Unfortunately this is a challenge where you can’t configure way around it (at least yet). For the time being, this actually is by design. Taken from the documentation, Microsoft lists the suggestion feature separately from the actual search requests:

    Suggestions provide a list of matches to the specified search parameter value, based on an entity record’s primary field. This is different from a regular search request because a suggestion search only searches through an entity record’s primary field, while search requests search through all relevance search-enabled entity fields.

    So, the search box and the search results page follow different logic, which is why it is expected that they will show different matches. This may be seem quite complex to explain to the app end users on a detailed technical level, so it’s better to just instruct them to always apply the wildcard character * at the end of their search term. The results are likely to be closer to what they expected to see:

    Hopefully these 5 tips will help you in setting up the basis for more relevant search results and a better user experience in your Model-driven apps. For more comprehensive guidance, check out these three different levels of documentation that Microsoft provides on the Power Apps seach features:

  • Unified Interface Form Design Notes

    Unified Interface Form Design Notes

    It’s been around a year since Microsoft announced that Dynamics 365 Customer Engagement would be moving from the world of separate web, mobile and Outlook clients into a single Unified Interface (or UCI, as in “Unified Client Infrastructure”). At that time I made a prediction that this level of shift in the client technology would be a long road, and to date that still pretty much holds true.

    Although V9 has been available for quite some time for new cloud instances and also existing customers have been upgrading as the version has become available for them a bit later, the majority of current Dynamics 365 CE users won’t yet be on UCI – at least for the desktop usage. MoCA was already replaced with UCI in V9, so the mobile UI is now on the new infrastructure, no choices there. For the web, there’s still a fair bit of capabilities not yet on Unified Interface, which makes it hard for customers to move over to it.

    Eventually everyone will need to migrate to UCI, though. It’s best to start exploring the scenarios where Unified Interface can fulfill the core needs and to gain the skills needed for designing great user experiences on this new client type. Even though the majority of the customizations will be rendered the same in UCI as on the current web client, there are still details that you should pay attention to. This is a collection of a few observations I’ve made when building a Dynamics 365 Customer Engagement App on UCI. Specifically, I’ll focus on the entity form rendering here, as a continuation of the previous post where I covered the new Card Form type.

    The Header

    Let’s start from the top. Form headers are where you would have previously placed up to 4 fields that you wanted to be always visible to the user when opening the form and scrolling down along it. Great for highlighting properties of the record that users needed to be aware of.

    In UCI there can still be just as many fields on the form header, but unfortunately they won’t always be shown. Even on a 1920*1080 screen resolution you may only see the first 2 fields on the form. The rest are hidden behind a small downward arrow icon that the user would have to discover and the click on to see the remaining header fields. I’m pretty sure most will never even realize the fields’ existence.

    When using a smaller mobile device screen the rendering changes quite significantly. Since on a vertical screen there’s no space for showing a header next to the record primary field (the name), in this form factor the header actually becomes the very first form section to be shown to the user. The nice thing is that it’s really “in your face” for the user. The downside is that this may not be the most logical information to be shown at the start of the form – or at least it will differ from what the user might expect to find there. Especially when creating new records these header fields rarely are the ones where you’d start the data entry process.

    For now, I don’t really have a good guidelince on how to consistently leverage the form header with UCI. You probably want to minimize the number of fields shown there, instead of capitalizing on the full 4 field opportunity, and stick to 1-2 fields max.

    The Footer

    Like the header fields, also the form footer has enjoyed a persistent presence on the XRM entity form. Now with UCI and Dynamics 365 CE, this is no longer the case. On a PC screen the fields do get shown, though, but not in a very nice way.

    As an example, a fairly common use case for the footer has been to present a few entity default fields that were hidden in CRM 2013 upgrade when the record properties dialog was removed from the UI. I’m referring to the created/modified on/by information, which can be very useful in determining the validity of the CRM data and persons responsible of the updates. You can still put them there, but currently the rendering looks so messy that I’d prefer not to show that to customers:

    The icons of these fields are often overlapping, even in full screen. This also highlights one of the current issues with UCI, meaning it doesn’t respect the user’s format settings and instead forces “AM” & “PM” upon users who live in a country where these concepts are never used. (Do also watch out for the date fields that sometimes reverse the order of day and month around, creating interesting results with things like appointment data entry.)

    The upside of the new design is that the footer fields don’t add up an extra row at the bottom, instead they are incorporated into the gray bar containing the record status and update indicators. This is very welcome, since in the old web client with especially entities using the BPF control, you’d sometimes have barely any vertical space left for working on the actual record fields, thanks to all the padding at the top & the bottom. Striking a balance with these responsive screen layouts surely isn’t an easy task for the engineers, with requirements for both information density and touch friendliness being presented to them.

    On a mobile screen you will not see the fields of the footer at all. It doesn’t appear to be rendered anywhere else on the form, so any information presented in this form section will be inaccessible in some scenarios. Much like the header, I would also advise not to put many fields in the footer if you plan on using Unified Interface (or if your users need them while out on the road).

    The Tabs

    The return of the visible tabs is certainly one of the big UX improvements compared to the old web client. Having these anchors visible right at the start of the form’s loading is a great help especially with information heavy forms like what accounts tend to have. Adding the “Related” menu to the end of the tab list to reveal the child entities is also much better than the mystery arrow in the middle of the old Nav Bar at the top of the screen. Left navigation and Proper Tabs, woo-hoo! Go UCI!

    Except that much like the header and footer, the tabs aren’t persistent either. The moment you start scrolling down the form, the tab labels get removed from the screen. Doh! Oh well, I guess we’ll just need to scroll down a bit further without the help of those anchors…

    Except we can’t. Once we reach the end of the tab, it’s a hard stop. No matter how much you spin your mouse wheel or swipe your finger on a touch screen, there will be no more of the form revealed to you. You see, in order to go further DOWN on the form you’ll need to scroll all the way UP, reveal the tab labels and then click/press on them. The longer your forms are, especially when reflown as a single column view on a smartphone screen, the longer it will take for your users to reach the next tab.

    Having the tabs as containers with hard boundaries might be an understandable design choice from a UX perspective. Getting lost on an endless list of scrolling fields and sections will not be fun for the users, so bringing some structure into this navigation experience is welcome. On the mobile form factor there’s also the Semantic Zoom option to help the user understand the form’s different tabs and sections. Just a shame that also the Semantic Zoom icon is hidden once move down an inch on the form…

    Here’s an idea to upvote: Ability to Dock “Tabs” on top of Unified Client Interface Tabs.

    We’re Getting There

    Despite of these few challenges, there is a lot to like about the way Unified Interface changes the user experience of entity forms:

    • Quick View Forms truly blend into the native form fields in UCI, whereas with the legacy web client the rendering was always quite clumsy.
    • Timeline is far better at exposing related activities, notes, posts than the earlier tabbed UI hiding most of the content.
    • Subgrids are actually actionable, with access to full grid features like sorting, select multiple.
    • Subgrid content rendering can be customized via custom control configuration options like Card Forms.
    • Business Process Flow consumes less vertical space (although BPF stage fields being hidden by default may cause challenges).
    • Visual hierarchy is much more obvious than even with the web client “refresh UI”.

    A big bonus is also the fact that by default you’ll get the same form customizations for desktop and for mobile users. It may or may not be suitable for real life mobile use cases, but at least you get the starting point for designing a mobile optimized UCI App to be targeted for specific scenarios that only need a subset of full form functionality.

    The key thing to keep in mind when considering the choice between the classic web client and UCI is this, though: UCI is the future. It will be continuously updated with more supported features and optimized for the end user experience with the latest browsers and devices. These updates don’t even require the customer to schedule their version upgrades via the CDU calendar, since from V9 onward all the Dynamics 365 online updates will be deployed automatically to customer environments. See the new continuous deployment policy that Microsoft just announced for more details.

    More and more areas of the classic XRM UI will be moved over to Unified Interface with every release. Although we don’t yet know any dates for end of support for the web client nor the target date for UCI’s full parity, the next wave of features in October 2018 release will be published as release notes on July 23rd at the Microsoft Business Application Summit. Better keep an eye on that one!

  • Card Forms and List Views in Unified Interface

    Card Forms and List Views in Unified Interface

    Since the beginning of time, meaning early days of MS CRM, we’ve grown accustomed to the fact that record fields in Dynamics 365 Customer Engagement can be presented either via entity forms or entity views. The entity form shows the editable fields of a single record, whereas the entity view gives us a list of many records from the same entity. Views used to be read only, but as Microsoft finally provided a first-party editable grid feature in December 2016 update for Dynamics 365, that blurred the lines between a view and a form to some extent.

    Showing views on a form has been possible since already 2011 when subgrids were introduced. Now with the expanding feature set of CDS for Apps and their Model-driven Apps (formerly XRM), it’s actually possible to also show forms within a view. No, not just any random form, as that wouldn’t really make all that much sense. After all, if you want to look at an actual entity form with several tabs and sections worth of data, you’re going to want to click away from the view and show the entity form in full screen mode. In Unified Interface there’s even a nice shortcut for you to keep browsing the other records in the source view without having to navigate away from the entity form you’ve opened:

    The scenario for showing form style content within a view is for a different type of a need: presenting several fields from one record in a view when there is no space available for showing columns side by side. This is of course related mostly to the vertical layout of a phone app that has more pixels available from top down than left to right. You could however encounter this type of a layout need when embedding views onto either forms or dashboards, with a narrow space available for any single record from the view to identify itself with its fields.

    The Unified Interface already has a built-in capability to address this scenario with its automatic reflow. If you take the “My Active Contacts” view as an example, when in the web client on a wider screen you’ll see the view columns in the traditional format. However, if you start making the screen (or “viewport” as the developers like to call it) more and more narrow, you’ll eventually reach a point where the presentation mode changes to remove all the columns & sideways scrolling bar, replaced with a card like UI. It will by default show the entity icon and the first three columns available in the original view definition.

    If you want to have more control over how the information would be presented in its compact, mobile friendly format, then the entity Card Form is a tool that you should take a look at. Available as one form type alongside the more familiar Main Form, Quick View Form and Quick Create Form, the Card Form was introduced originally with the Interactive Service Hub (ISH) client. Since this was a very limited client type that predated the Unified Interface, most customers and many consultants probably haven’t worked with it in the past. Now that Unified Interface is set to take over the world from the legacy web client sometime in the future, it’s about time to get familiar with these features.

    Unfortunately Microsoft doesn’t yet provide much documentation about the use of Card Forms. The references in the current documentation are also somewhat misleading, since the term “card form” is also used in reference to what is actually a Quick View Form. Many people will surely have an image in their minds about the Card Form being something like the example shown below. It is not.

    The customization UI in the application itself isn’t that helpful either. Out of the ~14 default forms that the contact entity currently has in a sales focused Dynamics 365 Customer Engagement instance, 4 forms contain the word “card” in their name, but only one is actually of the type Card Form!

    Ignore the false cards and head straight to either the default “Contact Card form”, or alternatively create a brand new one. You’ll land on the classic form editor experience that will present to you the fixed layout and available features of a Card Form:

    It looks like there are familiar elements from the Main Form available here: header, details, footer. What’s different is that there aren’t much properties you could play around with when it comes to the sections, meaning any labels or layout options that a traditional form would have. The maximum number of fields you can drag from the field explorer and drop onto the Card Form are:

    • Header: 3
    • Details: 4
    • Footer: 4

    Given that the intention is to provide just the key attributes of a record in a view, these numbers should be plenty. In fact, you might want to be cautious about not including too many fields onto the Card Form to keep it visually pleasing to the eye. As you’ll see from the example of how the form renders, there will be no form labels provided for any of the fields in the header or details sections, so be sure to only include the kind of fields that will be obvious to the user based on just the data of the field or the context in which the view is available (not just a bunch of date fields, for example). Also note that the footer currently appears to be expanded by default when the view renders, although there’s an upward arrow for you to collapse it for an individual record (you’d think this would be the other way around). You can control whether the footer is expanded by default or not by going to System Settings – General – Set the default card state for Interactive Dashboards.

    How will you then determine where this card form layout will appear? This is where the Custom Control Framework comes into play. We now have a control type in standard Dynamics 365 Customer Engagement called “Read Only Grid” that is different from the “Read-only Grid (default)” control. When you switch one of the clients (web, phone, tablet) to utilize this new control instead, you’ll get the option to link your default or custom Card Forms as the way how the view contents should be rendered. (more…)

  • From AppSource to Solutions to Dynamics 365 Apps

    From AppSource to Solutions to Dynamics 365 Apps

    In my previous blog post I presented the various different meanings that an App can have in Dynamics 365 Customer Engagement. Now that we’re aware of this jungle, let’s grab a machete and start making our way deeper into the heart of it, to understand how a system customizer can survive in there.

    Before there was Microsoft AppSource for Dynamics 365, the methods available for distributing apps in a generic sense were pretty basic: you downloaded a zip file (or several) from a location provided by some party, then navigated to the solutions menu in your XRM environment and started importing them. When there were updates to those apps, you needed to repeat the procedure. If there were some other configuration steps needed in getting the application properly set up, you had to read the friendly manual and complete those. In a more tech savvy environment the Package Deployer might have been used here, but that was hardly a task for the accidental CRM administrator.

    What AppSource aims to change in the Dynamics 365 app distribution process is similar to what the smartphone app stores did a decade ago, i.e. simplify the steps for the customer and also provide a better channel for app developers to deliver their updates. When you go to AppSource and choose to either install a free App or start a trial on a paid one, the next screen will provide an instance selector to determine where in your Office 365 tenant you want to put this App in. Also presented are the checkboxes for agreeing on both Microsoft’s as well as the ISV’s legal terms.

    From here you’ll be taken into Dynamics 365 Administration Center. This part of the process nor the UI of the admin center isn’t very intuitive, so let’s pause here for a moment. While you’ll land on the Solutions view of an Instance after clicking on “Agree”, on the logical level we should be paying attention to the Applications tab instead. The chosen ISV (or MS) App will have been added as a row in the applications list, which applies to the whole tenant. In this example we see that North52 Business Process Activities is now available in our tenant. It doesn’t have any configuration options in this UI, but the Microsoft apps like Portal Add-on or Voice of the Customer both have an additional “Configure” button that is accessed via this Manage Applications screen.

    If we click back to the Instances tab in the admin center, select one of our instances and click the Solutions icon on the right side, we’re now presented with the list of solutions available to this instance via the AppSource delivery channel. It is not the same as going to your XRM instance and clicking Settings – Solutions, as there can be more solutions within that instance. For example, the organization specific solutions that you’ve created as a container for your own customizations. Not even the managed/unmanaged status of those solution has anything to do with what’s shown in the admin center, because whatever zip files you imported directly into your XRM instance as a solution is only visible from within the XRM UI.

    The solutions list in the admin center is also different in the way that it shows also the solutions you haven’t installed in the instance. These are applications that someone, either MS or your D365 admin, has made available in your tenant and possibly installed them into some other instance (a test sandbox, for example). To get them installed you don’t have to go to AppSource, rather you can start the process from here.

    What makes this view so relevant for the Dynamics 365 instance administrator is that here’s where you’ll see what solutions have upgrades available. In the above example, Microsoft has released a new version of the Relationship Insights solution. Since they don’t want to accidentally break your dev/test/production orgs by changing the solutions on their own, they are rather giving you the controls to click on the “Update” icon for the particular instance when you’re ready for it. This same process is applied also for third party ISV solutions to deliver updated versions of their apps.

    Now when we have deployed the app from AppSource and the Solutions view in the Dynamics 365 Administration Center for our chosen instance shows the status as “installed”, let’s use the Office 365 app launched to navigate to our Dynamics 365 start page, meaning home.dynamics.com. And… there’s nothing new here. Even if we click the “Sync” button to refresh the My Apps view, our AppSource app doesn’t appear. What gives?

    At this point we need to take a step back from the UI and think about how these different components relate with one another. On the highest level we have AppSource, which is more of a marketing UI for products. From there we get Applications into our Dynamics 365 Administration Center. These manifest themselves as single solution rows for an instance when viewed via the admin center, but they can actually contain N separate solution files (look at Dynamics 365 Portals, for example). Finally, these solutions may or may not contain Apps – from 0 to N. This diagram illustrates these four conceptual levels and their relationships:

    In our example we’ve installed North52, which is an administrator/customizer tool designed for “building simple or complex business rules using point-click editor, eliminating C# and JavaScript coding”. In short, it’s an app for configuring apps, but it’s not a business app in itself. That doesn’t mean it wouldn’t need a UI, of course, but the Command Bar shortcuts and the dedicated home page web resource with navigation options quite frankly is much better suited for this type of a power user tool than the new Unified Interface apps that are supposed to work even on 4″ mobile phone screens.

    This brings us back to the App Module concept that was briefly mentioned in my earlier blog post. Before V9 and the Unified Interface there wasn’t so much benefit in building separate Apps for different functional areas of the XRM platform, as we had the one master UI for the instance available anyway. When the features are migrated over to the new Unified Interface, basically everything must be an App. In v9.0 we’ve yet to see how the more complex admin features will be implemented as Unified Interface versions, so currently it’s a somewhat jarring experience of 2011 meets 2018 for the system customizers.

    Even when all the actual business application functionality has moved over to Unified Interface, there will still be many scenarios in which presenting an AppSource app as a Dynamics 365 App Module App doesn’t necessarily make any sense. UI extensions like Checklists will not have much use outside the actual business entity in which they are used. Any app that connects to an external web service to enrich the contents of Dynamics 365 records mainly needs a configuration admin UI somewhere. Sure, there’s nothing stopping developers from using the App Designer to define an App for their solutions, since all you technically need is a single HTML web resource to publish an App with a single menu item. However, separating the tool from the XRM instance in which it lives isn’t going to make the UX of configuring features any easier, so I’m not really hoping for the app clutter to increase this way.

    Both the AppSource marketplace and the App Module in Dynamics 365 Customer Engagement provide significant improvement on how the business application features can be presented to business users and decision makers. What they don’t do is completely remove the need for Dynamics 365 system administrators to understand how the various layers and parts of the application platform are wired. XRM will likely remain an environment that’s just inherently more complex than an iPhone screen with its pretty app icons lined up just the way the single device user likes to see them.

  • Configuring Custom Controls for Views in Dynamics 365 CE V9

    Configuring Custom Controls for Views in Dynamics 365 CE V9

    The new Unified Interface that launched in v9.0 of Microsoft Dynamics 365 Customer Engagement gave us all the possibility to try out the next generation CRM user experience in new trial orgs or sandboxes. While the CDU process for upgrading existing customer environments to V9 has not yet been made available by Microsoft (which gives them some time to iron out the remaining wrinkles with a steady stream of Service Updates), now’s a good time to explore what’s new and what’s changing with the imminent arrival of Unified Interface.

    One of the most exciting platform enhancements from a developer perspective is surely the arrival of the Custom Control Framework. Known as CCF for short (no, not that Microsoft CCF you senior members of the community might recall), this is essentially the mechanism through which all of the data visualization in the XRM platform will be handled in the Unified Interface. Not just the custom developed UI components from partners but also everything that Microsoft builds. Take a look at the default solution of a V9 org and you’ll already see a wealth of these components listed in there:

    The bad news is that as of now there’s no documentation nor API available for developers to build new or extend existing controls via CCF. It’s coming, but it just ain’t ready quite yet. In the meantime, us system customizers can get familiar with the concept by tinkering with the configuration options that ship with V9.

    Custom Controls for Views

    Back when the Editable Grid first launched, the feature was rolled out in an “all or nothing” style. What this meant was that you were able to enable it on the entity level, but then it was the only view type that any user would see in the UI (at least in the specified client type). Sure, they were given the option to switch from editable to classic read-only grid if they spotted the option, but the system customizer wasn’t able to target the powers of Editable Grid to only views that actually benefited from this feature.

    V9 has taken this a step further and introduced a Custom Control setting for each individual entity view. This gives us the option to set that only a specific view like “Edit Account Details” would only present the grid in the editable format with all the pros and UX cons that this particular control introduces over a read-only view. This doesn’t apply in the classic web UI (or the “Refreshed UI” as the V9 release refers to it) but on the Unified Interface side we can now see the power that this granular control over controls has on the user experience.

    New View Controls in V9

    In addition to the Editable Grid, there are a number of other grid types that a V9 org presents as options for the system customizer. In the screenshot above you’ll see the Calendar Control having been chosen as the data visualization type for the view. This opens up a number of configuration options that can be set right in the UI, like the date field data sources, description label, colors and so on. What we see here is essentially an example of the point & click configurability that a CCF based control can offer when used in the Dynamics 365 CE solution.

    The Calendar Control is also responsive to the client type. When access via a browser app using the Unified Interface style (in this case a custom Subscription Management app), you’ll see a somewhat ugly legacy calendar with the week days presented horizontally. When viewed via the Dynamics 365 for Phones app it will render in a the above format of vertically stacked records per day. (Yes, those day of the week and month texts are presented in Finnish regardless of the app language setting being English, because that’s how Microsoft prefers things to be).

    There are also other control types available for views in V9 currently, such as Timeline Control. That specific control appears to require quite a specific format of source data that fits the scenario of the Company News Timeline solution, so you might not find it useful in your own customization work. What might be worth noticing is that there are in fact two separate read-only grids available in the current release: the default one and the Read Only Grid with settings to control the entity card form and data reflow behavior.

  • The Long Road to Unified Interface in Dynamics 365

    The Long Road to Unified Interface in Dynamics 365

    On June 20th Microsoft started taking the cover off its next major release of Dynamics 365 Customer Engagement (formerly known as CRM): v9.0. The biggest announcements in the first day of the Dynamics 365 Preview Executive Briefing were around the client story. With the new Unified Interface (sometimes also referred to as “UCI” for Unified Client Interface/Infrastructure) the plan is to bring a single client technology to cover all the different UI’s across devices. Web, Outlook, Mobile, Tablet.

    This is very exciting news, but there’s a lot of details and footnotes that people in the Dynamics ecosystem need to be aware of. Let’s dive right in!

    The Client Fragmentation of Dynamics CRM

    Most of you will have probably been around when the previous big UX refresh took place with CRM 2013. We then received the MoCA Framework based tablet app with Windows 8 style tile UI and later saw this framework being used in many other places. We even received a brand new client to be used on the (desktop) web, the Interactive Service Hub (ISH). In fact, one year ago it almost looked like MoCA would be eating the world:

    The only problem with this strategy seemed to be that all of these individual parts never formed a sensible whole. Instead, there were so many “seams” visible everywhere you looked in the Dynamics CRM client landscape that many times you just wanted to keep your focus on the traditional web client and wait for things to clear up in these newer areas of the platform. A few examples:

    • Knowledge Articles were introduced only on ISH, but at the same time ISH was too limited/buggy to be used in most of the existing customer service scenarios with customizations in place.
    • Visual Controls were introduced in the phone and tablet, but the main web app forms just kept getting more and more white with nothing but text fields.
    • Dashboards with filters were made available on ISH, but much of the entities (i.e. sales) that typically are analyzed with dashboards were not allowed on the ISH side.

    MoCA was born for the mobile first era of touch UI and understandably it didn’t have all of the traditional capabilities from the web client. However, there were plenty of gaps that didn’t make it ideal for mobile use either. One of the biggest issues I had with MoCA was the “configure once, deploy everywhere” principle, which tried to force the same full CRM configuration onto the mobile device screens. MoCA brought the CRM into your pocket, but most of the time what a user would need in their pocket is a simplified app focused on a limited set of tasks. The limitations with MoCA meant that Microsoft had to rely on a Resco based client for their Field Service app in which the use cases are primarily mobile only.

    This Time It’s Different

    The promise of Unified Interface is that the era of web vs. mobile is over and now we’ll see a UI that’ll both adapt to the device or screen in use, as well as offer the same customization options in each of them. Content will be presented in a way that will reflow into different states of the control as the space available to it changes.

    Unlike with MoCA, this time there can be multiple different apps also accessed on a mobile device. Also web-only features like form switching are now available on all devices which makes it far less challenging for the system customizer to design a solution when all the exceptions and limitations of specific client types are (in theory) no longer in the way. It’s important to set the expectations on a realistic level, though, since I’m quite sure we’ll need to make some more compromises on the web side of the house with this new Unified Interface, but hopefully it’ll be a price worth paying for true mobility of Dynamics 365 business apps.

    For an even more customized experience, the Custom Control Framework that has been gradually introduced as part of the application (like the Editable Grid, for example) is going to introduce a design surface for developers to extend Dynamics 365 Customer Engagement apps in exciting new ways. Not only that, the existing ASPX based UI controls that have been in the core CRM application since forever are now also being transformed into Custom Controls. This is a part of the larger application/platform separation initiative that’s a whole topic of its own. On a high level, the developers should soon have access to basically the same tools for building new UI controls as what Microsoft is using to build their business apps.

    All of this should help in removing many of the gaps that have currently stopped the rolling out of the individual application features in earlier releases for real life business scenarios. There are plenty of promises that MS is making on performance improvements of this new client technology, too. That’s an important aspect to keep in mind and realistically evaluate as the Unified Interface becomes available, since all of the eye candy in the world won’t be of much value if the actual user experience of working with the application isn’t meeting the ever growing expectations of fluid interaction with the data stored in and managed via Dynamics 365.

    Are We There Yet?

    So, all of this looks great – now can we have it by tomorrow, please? The short answer is “no” and the expanded one is “it depends”. As mentioned in my earlier blog post, much of the new features in Dynamics 365 will now be rolled out via Private Previews and Preview programs before general availability. Hopping on to the preview train will shorten the time it takes for gaining hands on experience with the new UI. However, there’s more to it.

    Earlier I mentioned the previous UI refresh of CRM 2013 release (“Orion”), but some of you might still remember the intermediate release of “Polaris” (whereas the official name December 2012 Service Update isn’t something even I remembered anymore). That was perhaps the first Online-only release that Microsoft developed, with a target of not even trying to upgrade all of the application features into the new UI concept but instead just a selected few entities (“COLAC”) received the refreshed forms and Business Process Flow. You could build a simple CRM demo for a new customer with it, but trying to upgrade existing systems into Polaris or building anything with more customization requirements was a no-no. They had to wait until the full CRM 2013 release became available.

    The reason I’m bringing up this is that initially the Unified Interface is likely to be a bit like Polaris. It’s going to be made available only to brand new instances with the Business Edition licensing, or for new Apps that are either built by Microsoft (Customer Service Hub, a.k.a. ISH v2) or by the customer. It will also be available on the Phone and Tablet apps as well as in the lightweight Dynamics 365 App for Outlook (which officially replaces Outlook Client that’s now deprecated). Everywhere else, though, it’s not going to be the time for Unified Interface yet, but instead a refresh of the web client that’ll look something like this:

    Starting to get confused? I don’t blame you! There’s a hint of irony in the fact that the “Unified” Interface will initially be yet another interface variation for the Dynamics 365 application. I’m sure it’s not the way Microsoft would prefer to have these things introduced but reality is usually a bit more messy than PowerPoint presentations. The new client technology simply represents such a major shift in how Dynamics 365 works that upgrading all the complex customizations of existing Enterprise customers into it in one go would not be a smart move. Remember that “everyone’s an enterprise customer” until the Business Edition finally is out the door.

    To truly understand the client strategy that Microsoft is pursuing, you simply have to look at the Business Edition now, regardless of your deployment’s size. It is the dreamy wonderland in which MS can cut back on unnecessary complexity of application features and not worry about breaking any existing deployments, since there is hardly any legacy there. A fresh start that doesn’t need to carry all of the overlapping functionality (like Contracts vs. Entitlements) or provide all the admin options necessary for hybrid environments. It’s not all pure bliss in the sense that all of this will eventually have to live in harmony with the more complex custom UI’s and business logic of big corporations with “non-simplified” CRM systems running on the Dynamics platform. Still, right now we’re seeing a move from “cloud first” to “Business Edition first” when it comes to client innovation.

    Just because the Business Edition is targeting the lower end of the product licensing fees doesn’t mean you should dismiss the functionality that is being introduced in it. If the Sales app mainly streamlines many of the unnecessary complexities of current opportunity management in Dynamics 365 Enterprise, then the Marketing app will bring advanced logic like Customer Journey management that many existing larger customers would surely love to get their hands on. Unified Interface is the big story here that’s driving the release policy. I suspect that it’s the primary reason why the new XRM based Marketing app is only available for Business Edition customers initially, since features like integration with Customer Insights based segmentation and scoring mechanisms are not a feature anyone would build solely with the SMB segment in mind.

    It will all make sense in the end (hopefully), but in the near future both the customers as well as Microsoft will have some work ahead of them before the new promised land of Unification is reached. This is of course not all that different from what other business application platforms with a long market presence must go through every once in a while. Some may claim that Microsoft is following the Salesforce Lightning UI concept here with their Unified Interface and the similarities are surely there to be found. In fact, what I wrote about this the last time when Salesforce was following Microsoft’s lead is still pretty relevant when it comes to user experience evolution, so why not revisit that blog post for some perspective: The Irresistible Force of Great User Experience in CRM Applications.

  • A Million Voices: VoC Survey Results Analysis

    A Million Voices: VoC Survey Results Analysis

    A few weeks ago I launched a demo survey built on Voice of the Customer, the brand new survey tool from Microsoft. The goals I had for this exercise were twofold: 1) see how these type of interactive tools could be used in live events like eXtremeCRM 2016 Warsaw, and 2) gain some experience on what it is actually like to work with incoming survey response data inside Dynamics CRM. In this post I’ll mainly be focusing on the latter one, although the example data we’ll be looking at are the live answers you & other readers of this blog submitted via the eXtreme MVP Survey.

    VoC_survey_page

    As you may know, Voice of the Customer (or VoC as we’ll refer to it from now on) is a pure XRM solution. Although the actual customer facing survey forms are of course not presented via the Dynamics CRM client UI, everything that you use for configuring the survey questions and logic, as well as the incoming survey responses, is managed with CRM entities and stored into the CRM database. The reason this is such a big deal is that most of you will already possess the skills needed for leveraging such data via views, charts and dashboards as it’s just XRM all the way. Furthermore, you’re free to design business processes around the survey functionality with tools like real-time workflows or business rules. Naturally you’re also able to interact with the survey entities and records via the latest CRM Web API, should you come across some integration scenarios where data needs to either flow in or out to another system.

    The flip side of this coin is that VoC is unfortunately very XRM-ish to work with. If you compared it to dedicated survey apps that do nothing but questionnaire design (like SurveyMonkey, Surveypal and the likes), survey publishing and response data analysis, then there’s still quite a big gap for Microsoft to work on bridging when it comes to the end user experience of this tool. In a way this is quite understandable since the value proposition of VoC really is all about the tight integration with your customer data and the ability to send survey invitations automatically as a part of your customer facing processes; such as a survey link being emailed to a customer after a support case is closed in CRM, to gather quick ratings and design automatic escalation paths if the KPI’s are not met. Nevertheless, since VoC does also support creating pretty advanced surveys for collecting quantitative data from a broad target group in more traditional campaign style satisfaction surveys, as well as anonymous survey links presented on website, it’s good to understand what it’s like analyzing such data inside Dynamics CRM.

    VoC_Survey_Summary_report

    There are a lot of components in the VoC solution right out of the box. First off, there are four SSRS reports: Survey Summary, Question Summary, Net Promoter Score and Survey Export. The first two are general purpose reports with tables and charts summarizing the data either across a single survey or a specific question, as illustrated in the screenshots shown here. The NPS report is naturally aimed for this particular survey type, whereas the export one is a single huge matrix for dumping out the raw survey response data into Excel for further manipulation.

    VoC_Question_Summary_report

    For more interactive data analysis there are eight dashboards in the VoC solution. However, these may not be all that useful for many real life scenarios, since they suffer from the same limitation as all Dynamics CRM dashboards: there are no global filters you can apply for all the dashboard components. Meaning, unlike with an SSRS report launched from CRM, you can’t set the context of the dashboard to be a specific survey. Yes, with the new “interactive experience dashboards” introduced in CRM 2016 you do get this type of filters, but since right now those features are limited to the Interactive Service Hub only (which in turn has a fair number of limitations for general use), it’s not exactly the kind of solution we’d need right here.

    That doesn’t mean we couldn’t build pretty dashboards to summarize our survey responses, though. I had a go at this with the eXtreme MVP Survey and it turned out pretty well. Have a look (click for a larger image):

    VoC_eXtremeMVP_dashboard_page_1_small

    In the survey form I had three pages full of questions and I constructed the corresponding pages as personal CRM dashboards. This allowed me to both monitor the incoming responses during the survey data collection period as well as present the results to the audience at the MVP Showcase session in eXtremeCRM. It looks good, it appears very familiar to existing CRM users and it gets the job done without having to resort to any complex report development. (more…)

  • My CRM User Experience Presentation at eXtremeCRM 2016 Warsaw

    My CRM User Experience Presentation at eXtremeCRM 2016 Warsaw

    If you’re a Microsoft Dynamics CRM partner in EMEA then eXtremeCRM is definitely an event you don’t want to miss. This spring the event was arranged in Warsaw, Poland, and I had the pleasure of not only attending but also contributing to some of the content at the conference. Together with 8 other CRM MVPs, we all presented in our own sessions, did a joint “ask the MVPs” showcase and also got the chance to talk with many of the awesome Dynamics CRM community members at our Team eXtreme Pitcrew booth. Thanks to everyone who came around to compete in a lap of Forza 6 with the MVPs!

    eXtremeCRM2016Warsaw_Team_eXtreme_Pitcrew

    It was the first eXtremeCRM event where I was not only attending the breakout sessions but also speaking at one session of my own. The topic that I ended up covering was something that has been touched upon also in this blog a few times: user experience of CRM systems. In addition, the focus of my presentation was specifically on the no-code configuration possibilities and how they can impact the solution UX, in good and bad. (It seems to be a common misconception among the MVP’s that I would know something about writing custom code, when in fact I’m almost illiterate when it comes to the CRM SDK. But anyway…). You can find my presentation slides below, or access them via this direct link to Docs.com.

    In my session I covered quite a wide variety of topics. To start with, I wanted to address the business impact of CRM system UX and provide some tools for demonstrating why user experience not just about application usability but really about the organization’s ability to deliver great customer experiences. Then I reviewed some of the basic CRM customization best practices that we all should keep in mind when configuring our solutions (but which are all too easy to forget when dealing with schedule constraints in CRM deployment projects). I then explored the concept of how Dynamics CRM could be made to feel more responsive to the end user’s actions via tools like Business Rules, Quick View Forms and Real-time Workflows. Finally I highlighted the importance of continuously maintaining the UX of a CRM environment when both the platform, the usage patterns as well as the ecosystem around it keep on evolving at an ever increasing pace in the cloud.

    At eXtremeCRM there’s never a shortage of interesting sessions to attend, nor the amount of great new CRM roadmap insights that Jujhar Singh and the other members of Microsoft’s organization are there to share with the community. In an attempt to capture some of the highlights from the event, I compiled them into the following Sway presentation that includes content shared on Twitter via the #eXtremeCRM hashtag.

    That’s all for today, but do check back for the next blog post where I’ll be sharing some of the results from the Voice of the Customer survey that we did for the MVP session at eXtremeCRM.

  • The Irresistible Force of Great User Experience in CRM Applications

    The Irresistible Force of Great User Experience in CRM Applications

    Those who have worked with Dynamics CRM for a longer period of time will remember how the user experience delivered by the platform has evolved over time: from an Office style, data entry focused, Internet Explorer popup window application into the clean and modern Dynamics CRM 2015 application that works on any device and aims to present the maximum amount of relevant information to the user with the minimum amount of clicks. There was a time when CRM didn’t exactly seem like something that was designed with the needs of the end user in mind, but this direction changed quite drastically from the CRM Online December 2012 Service Update onwards, as Microsoft started to redesign the experiences they wanted to deliver for the users of their business applications in the new era where mobile, social and cloud were quickly becoming the most dominating forces in the world of enterprise software. Not forgetting the consumerization of IT, which had shown people that not every app used in a work context needed to look like a 90’s ERP system.

    I have covered this transition in quite a bit of detail in my four part article series titled “Dynamics CRM Platform Evolution”, which I’d recommend you to read through for understanding the practical impact of moving from the “first era” of MS CRM v1-v5 onto the current era of largely CRM Online focused rapid product iterations. One of the points I raised in the article was that not all the CRM software providers in the market had chosen to follow a similar path of introducing a big bang revolution to their application. Unlike Microsoft, Salesforce.com had instead opted for an evolutionary path that had seen their application UI remain almost unchanged for the main components and layout, as depicted in the image below.

    CRM_Platform_Evolution_2_small

    While being wildly successful in becoming the “next CRM application” after the 90’s generation of Siebel style, on-premises enterprise CRM suites had began to slide out of the limelight, Salesforce also began to receive a growing amount of criticism over the legacy that its user interface had accumulated over its history. The question of “Why doesn’t Salesforce upgrade the UI/UX of its core CRM web app?” did seem more and more valid, especially when competing products like Dynamics CRM were transforming the user experience that one could expect from a customer relationship management application. Well, finally in late August 2015, Salesforce announced that their next era of CRM UX would arrive in the form of the new Salesforce Lightning UI.

    Welcome to the Future of CRM, Salesforce!

    First of all, congratulations to the product team behind the Lightning UI on the launch! Pulling off a major redesign like this is bound to be a massive task and I’m sure in many ways the work has only begun now, but it’s still definitely an achievement worth celebrating. As many of you may have noticed, in my day job I work exclusively with Microsoft Dynamics CRM, so whatever I write here about a competing CRM solution is not going to be 100% objective. For that I apologize, but the point of my post isn’t to bash Salesforce but rather to analyze some of the trends in CRM software in general and also reflect back a bit on what has taken place in the world of Dynamics CRM during the past few years.

    But first, I need to just get something out of the way. Damn how these two apps look alike! Here’s the brand new opportunity form on Salesforce Lightning UI, a.k.a. Opportunity Workspace:

    Salesforce_Lightning_Opportunity_small

    …And here’s how the opportunity form on Dynamics CRM has looked like pretty much since the 2013 version:

    Dynamics_CRM_2015_Opportunity_small

    Notice any resemblance? Let me help you out a bit by listing the first five things that come to my mind from the Salesforce screenshot:

    • Sales Path for visualizing the sales process stages and related fields, known as Business Process Flow in Dynamics CRM
    • Tabs for switching between related activities and social posts, known as the Social Pane in Dynamics CRM
    • Composer for adding new tasks, phone calls and events to the opportunity, which simply is an inline activity quick create form in Dynamics CRM
    • Related information on Contact Roles, essentially the Stakeholders editable grid in Dynamics CRM
    • Persistent four header fields at the top of the form, ditto for Dynamics CRM

    Yeah, of course these both are applications for managing your typical sales opportunity information with activities and contacts, so its understandable that the concepts used in the default screens would be unlikely to radically differ from one another. Still, contrasting Lighting UI with the traditional Salesforce UI and looking at how close to the now familiar Dynamics CRM form layout, UI controls and especially the Business Process Flow feature the Salesforce product team has ended up with their design is, well… Quite remarkable in my opinion. Not a bad choice by any means, and also serves in validating the direction that Microsoft’s team took when overhauling their application’s UI a couple of years ago.

    Aside from the similarity to Dynamics CRM, there are plenty of nice looking designs and features included in the Salesforce Winter ’16 release notes. Some of them are about filling the functional gaps to Dynamics CRM (list view charts known from CRM 2011 make an appearance here), others are borrowing concepts from the more recent CRM apps out there (Kanban style opportunity board used in Pipedrive, Pipeliner et al., as well as SalesFlow for Dynamics CRM), but many of the release items seem to be focused on fine tuning the application usability and removing unnecessary friction from common tasks that sales people need to perform on a daily basis. Rather than just slapping on a new field layout and updating the icons, it does seem like the user experience of Salesforce will change quite dramatically with Lightning. Of course the true UX can only be evaluated once a live version of the application is available for testing how it truly feels like to use the app, but at this point it looks like a major step forward.

    The Price of Revolution

    Introducing a new application user experience to new users who don’t have prior experience of the product will always be far easier than forcing it upon the existing user base. While few people would say that they don’t want a nice & easy UI, the reality is that resistance to change is always a factor when dealing with human beings. When it comes to business software especially, disruptive changes are at the very bottom of the want list for the majority of people who are responsible for ensuring that information systems deployed for managing the core business processes of their organization keep on churning out the expected results. What’s going to happen when a CRM system jumps from evolutionary releases to revolutionary changes instead?

    The one important thing to keep in mind is that changes like this never take place overnight. Migrating over all the functionality that vast application platforms like Salesforce of Dynamics CRM have accumulated over time isn’t something you can get away with a single big bang release. With Microsoft there was a preview version of the new UX introduced with the Online only Polaris release, launched almost one year ahead of the actual major release of CRM 2013 (v6.0). Initially only five core entities were updated to the new “refreshed” forms, and even today the latest v7.1 still contains lots and lots of entities and menus that follow the old Ribbon based user experience. So, three years later the work isn’t even done for the Dynamics CRM product team in renewing the platform, which means that the end users and system customizers need to cope with a somewhat mixed application environment. The platform legacy becomes most apparent with the new mobile client applications that don’t support the old product architecture, resulting in features like marketing lists or connections not being available on the modern client versions. Sure, life is much, much better with the new UX, but it has also introduced some new complexities into the product.

    In the case of Salesforce, the story sounds to be somewhat similar, as not every area of their platform will be Lightning enabled right from the start. The Service Cloud will not yet be updated, nor will features like forecasting, orders or person accounts. In moments like these it’s always interesting to see how companies prioritize their development efforts, as they are likely to indicate either the observed level of usage for certain features of their products, or alternatively possible future plans to scrap something old and rebuild it from the ground up. If you’re working as a consultant that advises customers on what features they should take into use or invest in developing for their CRM systems, the messages conveyed by the application vendors via the frequency of updates to certain functional areas of their products are signals you’ll most certainly take into consideration when deciding on what strategy to recommend to your client base.

    With 150k customers and millions of users, it’s going to take a while before Salesforce will have safely moved each and every one into the Lightning world. In fact, based on the statement by Sara Varni, senior VP of marketing for SFDC Sales Cloud,  this milestone may never even be reached, since Salesforce will support the classic experience “indefinitely”. In the oldskool settings of on-premises servers, the way this could have been handled would be for the customers just sticking to an older version of the software and not deploying any updates. When you’re the grandaddy of SaaS platforms, things are obviously a bit different and supporting older versions will require more than just accepting support tickets for ancients releases of your software. With CRM Online, Microsoft has previously been pretty strict on getting every customer to move on to the latest version via the CDU (Customer Driven Update) program, but lately they’ve also changed their update policy to allow skipping the bi-annual releases and updating only once per year. As SaaS products become a more mature market, I bet we’ll be seeing a growing number of options for customers to choose which versions to use, which features to activate and when to schedule these changes to take place.

    Universal Experiences

    The way Salesforce chose to build their next generation UI is different from the path that Microsoft took. While Dynamics CRM 2013 introduced both the new web client experience as well as the “MoCA” tablet client application as separate experiences (followed by the refreshed mobile app in CRM 2015 Update 1), Salesforce decided to first build the Lightning framework for their Salesforce1 mobile app and then scale it out to the PC screens. As a result, the screenshots that we see in the Winter ’16 release notes look very much like a mobile app placed onto the screen of an iMac. While you could in theory also use the Dynamics CRM for Tablets app on a Windows 8/10 laptop, the users will certainly almost always end up choosing the Dynamics CRM web client designed for interaction with mouse & keyboard rather than touch optimized “Metro” experience.

    Salesforce_Dynamics_clients

    I think this will be one of the most interesting design choices to keep an eye on when it comes to user reactions to the new Salesforce Lightning UI. Regardless of all the recent Universal Apps hype that Microsoft has been building up alongside the Windows 10 release, I’m personally not quite convinced yet that you can deliver a great UX with a single app that needs to scale from 5″ touch screens to 27″ desktop monitors. As a result, I’m also not a big proponent of the “configure once, deploy everywhere” slogan used in reference to the Dynamics CRM mobile apps, since I’d rather see CRM applications truly optimized for the device and use case in question. However, if Salesforce can pull this off with Lightning, then perhaps Microsoft has been right all along with their OS strategy and the application teams should now move faster towards unifying the client side of things.

    Applification of Platforms?

    When it comes to products like Dynamics CRM or Salesforce, one of the key reasons why they are being so widely deployed across enterprises today is the ability to customize them to align with the business processes specific to the customer organization. They are not only replacing legacy CRM suites but also capturing an ever larger share of the market that used to belong to custom developed business software, since using a customizable application platform delivered from the public cloud can really drive down the TCO quite significantly. But if the CRM applications are now reaching towards an even more polished user experience in performing common tasks with sales, marketing and service records, what will happen to supporting the business specific scenarios that are more unique than what pre-built application features can cover?

    When Microsoft launched the Dynamics CRM 2013 version with the refreshed UI, they didn’t only add more features into the already crammed product, but rather they took away some configuration options that had been previously expected from the platform. As the saying goes about the goal of design work, “perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.” That may very well be true when designing a product to serve a specific set of tasks, but it may not resonate so well with a toolkit used for crafting these end products. Limiting the options shown to an end users is different from limiting the options available to the designer of the final solution that the user will be exposed to.

    How do such limitations show up in everyday life with the latest Dynamics CRM version? Today we have inline quick create forms for effortlessly adding activities for records, but we can no longer choose if we want to record a future phone call activity instead of a completed one. We can use an editable grid for adding line items into opportunities, quotes and orders, but we can’t configure these grids to contain those fields that the business logic would require to be recorded onto these line items. The price of added convenience for some is therefore resulting in the reduced usefulness to others. Looking at the Salesforce Winter ’16 release, it’s apparent that also here the polished UX will be come at the cost of reduced options. For example, there will be a brand new, great looking Home screen offered for sales users, but the components shown in it cannot be customized at this time.

    Salesforce_Lightning_Home

    Is there an inherent conflict between the needs of the application end user and the platform customizer? I don’t believe this is necessarily the case, but it is obvious that there are trade offs in building something that works great and building something configurable when it comes to the allocation of development resources for these software products. As the release cycles get faster and faster, the pressure for getting a new feature out there can mean there’s no time to perfect the first version into something that will meet the needs of all user groups and align with the rest of the platform functionality. The real question is, will the features be made more customizable in the subsequent releases, or will the requirements be pushed down in the backlog when the demand for more new features arises?

    When discussing the user experience of applications that are not commodity services like email but highly business specific process management tools (at least when properly deployed), it’s very important to understand what the final UX really consists of. It’s not only about having the slickest UI controls for working with the data, the flashiest graphics for visualizing the sales pipeline or most creative layouts for presenting different data sources on one screen. At the end of the day, the users need to feel like they can easily accomplish the tasks they are responsible for, with the help of the application – not despite of it. Understanding what exactly those tasks are and what pieces of information are relevant to the process of their completion is something that requires careful analysis conducted at the organization deploying a new CRM solution. Failure to do this will quickly wash away any value that the software features could have potentially delivered to the organization.

    As today’s CRM platforms become more and more sophisticated with the functionality and data presentation options available, the design work of those who configure the customer specific solutions also needs to be aligned with the increasing expectation levels for application usability. It’s still not rocket science, but it does require a greater attention to detail than the earlier, more primitive business applications where the UI was essentially a reflection of the data model. I’ve illustrated some of these design aspects in my 10 Tips for Designing A Great User Experience presentation, which hopefully can give an idea of how the system customizers can do their part in building CRM systems that the business users will find great value in – a Useful Experience, if you will.