Tag: address

  • Account address capture & mapping with Power Apps

    Account address capture & mapping with Power Apps

    In the Power Apps team blog there was an announcement of the GA availability of Geospatial Features for Canvas apps. In short, we now have a preview of two new controls powered by Azure Maps:

    • Address Input control which suggests the correct address based on partial street names and autocompletes attributes like city, postal code, country, latitude/longitude.
    • Interactive Map control to show one or more records from a dataset as pins or cards on a visual map .

    I decided to do a quick test of how to leverage these new capabilities in a simple scenario where we are managing account address information via a Canvas app running on a phone screen. Here is the end result:

    Simple yet effective! Let’s explore the steps I needed to perform to achieve this functionality.

    Source data

    As a starting point, I’m using a pure Dataverse environment with no Dynamics 365 components. Instead, I’ve installed the free RapidStartCRM solution to give me a simplified CRM data model, plus a fully working Model-driven Power App. I could embed this inside Microsoft Teams and use it via a channel tab, for example:

    In our scenario I want to offer the users a simplified UI to be used on a phone screen, with only a small subset of the full features found in the Model-driven app. I’ll focus just on the account data, which means I can simply start by going to make.powerapps.com and choose to generate the mobile app based on a data source. In this case I’ll select the account table in the Dataverse environment where RapidStartCRM is deployed. This gives me the basic 3-screen UI for browsing, viewing and editing records (yeah, I know, “rows” – but I refuse to adopt this part of the latest MS BizApps naming bingo results just yet).

    I want to create a custom data entry UX for this demo scenario, so I’ve added a “+” button at the bottom of the gallery screen to launch a new screen where I’ll be leveraging the geospatial features.

    Address Input control

    It’s never a fun task to enter the address details when creating new account records, especially when on a mobile device. Instead of asking the user to fill the various fields included in an address, we’ll add the new Address input control from the Input menu onto our “Add new account” screen. From the control’s documentation page we can see there are a number of input properties we could use, but it works quite well just by dropping it as a field onto the form and starting to enter text:

    In my case, I did limit the country set to “FI” to give me just Finnish streets for my demo app. It looks like you need to enter the street name and number before anything is suggested by the Azure Maps API, but you’re allowed to have small typos in the street name, so there’s some fuzzy matching logic applied here.

    The real benefit of the Address input control is in the 19 output properties you get from it. Ultimately I’ll want to use them to A) show the map control based on lat/lon and B) store the data onto the new account record the app will create. But first, it’s nice to see the control’s output on the screen while updating values, so I’ve added a few labels where I display the results from the selected address. To do this, I’ll reference properties like AddressInput1.PostalCode and AddressInput1.Municipality to construct a nice looking string for the text property of the label:

    This exercise will also help me in identifying how I’ll need to concatenate properties like StreetName and StreetNumber to create a valid value for the Dataverse account table’s Street 1 field eventually.

    Map control

    Seeing a map view where the address we’ve inputted is physically located is a big factor in the app’s user experience. We’ll want to give visual confirmation to the user that the address is actually at a location where they expected it to be, plus the ability to zoom in/out on the map to explore the surroundings. So, while in the Power Apps maker studio, let’s click on the Media dropdown and add the Map control onto our screen.

    Hmm, how do we then tell the Map control to zoom in to the address we’ve selected in the Address input control? I had to browse the Interactive map component documentation for quite a while to figure out a way to do this, as it wasn’t entirely obvious how to visualize an individual address rather than a table of records. What I ended up doing was to go into the OnChange property of the Address input control and create a SelectedAddress variable to be set to the chosen address whenever the field’s value changes:

    Set(SelectedAddress, Table({Label:tiAccountName.Text, Longitude:AddressInput1.SelectedLongitude, Latitude:AddressInput1.SelectedLatitude}))

    Note that in my app I’ve got a Text input control tiAccountName into which the user is requested to type in the name of the new account being created, before proceeding to work with the Address input control. I’m picking that name as the label to be shown on the map pin.

    Then in the properties of the Map control I’m setting the values of ItemsLabels, ItemsLatitudes and ItemsLongitudes properties to reference my SelectedAddress variable’s respective properties:

    There’s a variety of other input properties for the Map control, many of which I didn’t yet tweak in my demo app. For example, setting the default location to be that of the current location of the user’s device might be a good idea, but a quick test in the browser didn’t yet tell me how exactly I’d then replace that with my custom location from the variable. I’m sure the will be plenty of ways to optimize these map parameters when connecting them with your app’s business logic and data.

    Saving the account + address

    Finally we need to store the account name and address details onto a new Dataverse record in the account table. As we aren’t working with the form control here, it’s time to use the Patch function. I always need to check the Docs page for the exact syntax, but when working with simple text fields in the target table, the formula isn’t all that complex. On my Save button of the “Add new account” screen I’m running this:

    I’m storing the results of the Patch function also inside a NewAccount variable, so that I could reference the values further in the UI if needed (confirmation dialogs, for example). No error handling or anything else fancy here in the demo app, instead I’m just navigating the user to a “Success!” screen after the record has (hopefully) been saved in Dataverse:

    The “Success!” screen has an invisible timer control set to auto start and a duration of 3000 milliseconds. In the OnTimerEnd I’m doing housekeeping like setting the SelectedAddress variable to Blank(), resetting the Account name text input, then navigating the user onto the account browse screen that will show our newly created account somewhere in the gallery. Another option would of course be to take the user onto the full Edit Screen of the record, to enter further details via the standard form control if needed:

    That’s all there is to it! All in all, my first impression from these new geospatial features is quite a positive one. It’s important to note that since they are using Azure Maps service behind the scenes, these controls have the “premium diamond” next to them in the UI. This means you’ll need to have a premium license like Power Apps Per App or Power Apps Per User for users who are taking advantage of these address mapping features. Also keep in mind that the Power Platform environment where your app lives in must be enabled for geospatial features by the admin.

  • Country lists and multi-language lookup fields

    Country lists and multi-language lookup fields

    One of the most common customizations almost any organization working with customers from multiple countries will want to have in their Microsoft Dynamics CRM data model is the addition of a structured list of country names, to ensure they are stored in a consistent format. Yes, by default the Country/Region fields on the account, contact and lead entities are free text fields that a user must manually fill every time. This can result in some serious issues with data quality that make it difficult to perform a common task such as searching for accounts from specific countries. The field may contain values like “United States of America”, “United States”, “USA”, “Estados Unidos de América”, not to mention different conventions for upper/lowercase letters, hyphens etc.

    Why doesn’t Dynamics CRM come with a pre-configured list of countries? There are probably several reasons for the choice of this design, some of them which date back to the early days when CRM wasn’t a multi-language platform (before version 4.0 came along). Anyway, there’s absolutely nothing stopping us from fixing this gap by using the basic customization tools, so let’s get right to it!

    Picking the right Country field option

    There are two alternative approaches to implementing a controlled list of values for country names. You can either create a new option set (preferably a global one) or a new entity to hold the country name values. There are pros and cons to each method, which means the right choice depends on the use cases of the organization in question. In a simple scenario the option set may well be sufficient, if there are no other requirements for country data in CRM. For implementation guidance, look no further than this excellent post by Pedro Innecco: Dynamics CRM: Adding a Country/Region option set using ISO 3166-1.

    Sometimes the country data management requirements may be somewhat more complex, which may lead you into choosing to create a custom Country entity. This approach has the benefit of allowing you to store other variables than just the name of the country on the same record. For example, there may be parameters related to reporting that are country specific and would therefore be logically placed on the same record as the official name of the country. Other regional variables such as states or languages spoken are also a natural fit to be stored on the country entity.

    One interesting scenario to explore is the possibility of using the Country records as a central location for posting updates specific to a particular region, by using Activity Feeds on the Country record’s wall. Let’s say you have a multi-region Dynamics CRM implementation and you want to target auto-posts to users working with customers from specific countries. By generating posts like “New campaign Big Fair 2012 launched in @Finland” or “Major opportunity closed in @Sweden for account Contoso” that mention the country record you can easily push updates to any user who’s following that particular country. For a more detailed explanation please see my earlier post on how to make CRM Activity Feeds easier to follow by creating custom groups.

    There’s a catch with the custom entity approach, though, and that is the lack of native support for multiple languages. While the option set labels are a part of Dynamics CRM solution files and support translations just like your regular form fields, a custom entity is just data stored into the CRM database, no matter if you use it in a metadata like manner. As a result, if your CRM organization has different languages enabled and the user switches from English to Spanish, the value on the Country field on the account form won’t change from “United States of America” to “Estados Unidos de América”. If you had used an option set, all you’d need to do is export the labels for translation, enter values for the Spanish language column for the option set values, import it back and publish the results. However, with the custom Country entity we’ve ended up choosing, the value stored in the name field of the Country record will display the same way, regardless of the UI language of the logged in user.

    Nothing a little Jscript can’t fix

    Lucky for us, Pedro has come up with a solution that can also handle the multi-language support requirement when using a custom entity to hold the country labels. In the image below, you can see an account record viewed first in English, then in Finnish. Even though we’re using a lookup field to the Country entity on the account form, the label of the selected Country record has magically been translated from one language to another. As if that wasn’t enough, also the Look Up Record dialog window shows a list of values that has been tailored to the language of the user. Well, that looks like the best of both worlds, doesn’t it?

    How can you switch the label in the lookup field then? All you need to do is to download the Country/Region for Dynamics CRM solution created by Pedro Innecco and configure your CRM organization to take advantage of the scripts included. The solution also provides the ability to add more languages, so I’ll list out the steps I followed to add the Finnish language support for this Country lookup field.

    (more…)