Building an SFD in Dynamics 365 and the Power Platform

There’s a lot of talk about software delivery methodologies these days. To those not constantly reading the latest 400+ page textbooks on methodologies, it can be quite hard to keep up.

Agile methodologies such as Scrum can be great, but to work optimally they require a fair amount of education for all stakeholders involved, which is not always practical. Waterfall is considered by many as old hat, but lots of successful projects are still delivered this way. Hybrid methodologies can also work and can work practically and commercially. What is more important, across whatever methodology you use, are the techniques you use as part of these methodologies to define solutions and deliver real business outcomes.

There is a technique that I like to use which is ideally suited to Dynamics 365 and the Power Platform. It’s a great technique because:

  • It helps you gather real requirements aligned to the technology. We shouldn’t pretend to understand what someone else is imagining about a technology they have never seen before and try to make it fit.
  • It starts you thinking about the end-game very early in the process.
  • It helps you learn new technologies and capabilities as they are released.
  • By virtue of this techniques name, you are setting the bar quite low, so risk of embarrassing yourself is minimal (although conversely, partial failure here may be a very good thing).
  • It can provide valuable insight into estimates for future tasks.

It’s called the Shitty First Draft, hereby referred as an SFD.

Continue reading “Building an SFD in Dynamics 365 and the Power Platform”

Building a Power Platform Dream Team

As Microsoft Practice Lead for Codec in UK and Northern Ireland, I’m regularly thinking how Codec has grown a Microsoft Dynamics practice from a small team of 2 people to over 100 Microsoft ‘Power Platform‘ Consultants, in little over four years. In the past two years, our Belfast team has experienced rapid growth with exciting plans to grow further. Building teams at such a rate can challenge any company of any size, but Codec’s success has not come around by accident or luck.

To gain an insight into some of the factors that have helped Codec become both Microsoft Ireland partner of the year and Microsoft Dynamics partner of the year in successive years, here are some of the principles we’ve adopted in Belfast, and across the Codec group, to ensure that we stay the best at what we do. Continue reading “Building a Power Platform Dream Team”

PowerApps is dead. Long live XRMPowerApps.

In April 2017 I attended SummitEMEA in Amsterdam and listened intently when Matt Barbour told us that a true Microsoft Dynamics XRM image – i.e. a CRM organisation instance with only accounts, contacts, activities and nothing else – existed internally within Microsoft. This interested me as partners have been calling out for this since the old CRM 4.0 on-premise days. At that time it seemed there were no immediate plans to do anything with it.

Fast forward one year, and this time closer to home in SummitEMEA in Dublin, April 2018 and Matt Barbour again moved the conversation on a country mile or three. I discovered that XRM no longer officially exists in name, but does exist in practice and has been renamed PowerApps. So, how does this work? Continue reading “PowerApps is dead. Long live XRMPowerApps.”

Segmenting your Contact records with Dynamics 365 Apps

I’ve been using apps with Dynamics 365 for some time now and they are a great way of simplifying the user interface in a way that doesn’t require you to cross reference low level security permissions with Site Map XML.

One problem that has come up time and time again is the fact that different organisations often have different types of contact because of the nature of their business. There are a lot of benefits you get from using the system contact entity, which means that creating a new custom entity for a new contact type does not always make sense.

For example, consider an organisation with multiple types of service and therefore multiple different types of customers. They have contacts which may encompass the following types, and contacts may often be one or more types of these.

  • Staff Member
  • Applicant
  • Student
  • Citizen
  • Farmers

Ultimately, these people are, and should be, contacts in the CRM data model – if we model them as standalone custom entities they are no longer activity parties, they can’t be associated with the customer lookup fields – for example the dedicated customer field on the case record. Additionally, we want to have a single view of the customers contact with the organisation which can be viewed on the activity pane or activity associated view on the contact record.

For this reason, it often seems natural when designing a solution to apply a type field to the contact record. This could be a single option set on the contact record if the contact types are mutually exclusive, or a set of Boolean fields so that a contact can be of multiple types. For example, a staff member could also be a student who works as a part-time farmer (not uncommon in Northern Ireland!).

However, if we model these as contacts in CRM, it is important to consider the user experience when navigating through CRM screens. When a user clicks on the contact menu item on the site map, they could be presented with a list of views where they can view a list of contacts by type – For example, all active Applicants, All Active students etc.

But to improve this, what if we could add multiple entries in the site map to take you directly to a view of each type of contact. This would make the users life easier.

Consider this use case, which demonstrates a non-streamlined user experience with minimal customisations.

  1. User wants to view a list of all Students
  2. User Clicks on Sitemap
  3. User Clicks on Contacts
  4. A list of contacts is displayed, but the view is not the Students one.
  5. User changes view to Student
  6. User clicks into a record
  7. User realises that form being displayed does not show Student specific information
  8. User browses forms for that contact entity and selects (perhaps guesses) the most appropriate one.
  9. Student form is displayed.

The best user experience here is (arguably):

  1. User wants to view a list of all Students
  2. User Clicks on sitemap
  3. User Clicks on Students
  4. User clicks into a record
  5. The most appropriate form for that student is displayed.

However, even if we know what the most appropriate form is for a particular record, we are limited technically in setting the form based on the value of a field on a record. The default form displayed for a record is the one that was last saved by the user. It can be changed using JavaScript when the form is loaded, but that would involve a page refresh straight after the record is opened (ugh), and that is quite confusing to the user.

So, what is the optimal, supported way of navigating this scenario at using Dynamics 365? (I am using v8.2 here, am hopeful of v9.0 SDK improvements)

Consider this flow:

  1. User wants to view a list of all Students
  2. User clicks on sitemap
  3. User clicks on Students
  4. A list of students is displayed
  5. User Clicks into a record
  6. If form is not optimal for that record, the system prompts the user that record is a student, and suggests the most appropriate form(s).
  7. User clicks single button to bring the user to the suggested form.

This scenario can be achieved relatively easily using Dynamics 365 Apps, URL Addressable forms and some supported JavaScript on the contact form. Configuring this pattern will look something like this:

Configure the Site Map and App

  • Create appropriate fields on the contact record to segment your contact into different types.
  • Create a new system view filtering for each type as required.
  • Get the GUIDs for each of the views you have just created. One way of doing this is to navigate to the view and select ‘Email a Link of Current View’. The viewid will be at the end of the URL between the escaped %7b indicator and %7d curly bracket tags.
  • Create a new Dynamics app and add the contact record to it. Select all the views you have created that you want to display in your app.
  • Open the Site Map within your app and add the Contact record first.
  • Now add a subarea of type URL for each of the other types of contact you want to display on the site map in their own right.
    • The URL should be in the format /_root/homepage.aspx?etc=2&viewid={VIEWGUIDGOESHERE}
    • Note : When adding this link in the app designer, it is not escaped as indicated in the MSDN documentation. Paste it in exactly as above or it won’t work.
    • As a side note – you cannot change the sitemap icons for these contact types, even though you have added it as a URL. CRM still appears to parse the entity type code (ETC) or entity type name (ETN) provided in the URL which unfortunately means that the default contact icon will still display.
  • Save and publish your app once you have added all your views.

Streamline the form experience.

At this point, you have a set of entries on your sitemap which link directly to the views for each contact type. However, what happens when you click on the record – it will take you into whatever form you last looked at. To improve this experience, you will need to add some JavaScript to each form onLoad event to display an appropriate recommendation to the user. My library of choice to do this is Notify.js, which will give you a nice notification as shown below when you are opening a form.

If you think this type of scenario should be handled better within Dynamics 365 natively, please vote for the submissions below on for a) this to be handled within the app designer and b) for better URL addressable forms. I’m sure Microsoft can come up with a better way of doing this.

I should mention, this approach flies in the face of what a ‘Contact’ is the CRM Community Schema project which is a great initiative that takes a different approach to modelling entities. The question is, are you a pragmatist or a purist?