Sonoma Partners Microsoft CRM and Salesforce Blog

9 Wins for Manufacturers Using Mobile CRM - 1. Surface Info that Matters

Today’s blog post was written by Kayla Silverstein, Marketing Specialist at Sonoma Partners.

To keep up with today’s rapidly paced market, manufacturers must push their products at the right moment, in the right place, at the right time. Your field sellers are doing the best they can to stay on-the-move and in the field, talking to and meeting with potential customers. You need a customer relationship management (CRM) system that’s just as mobile as they are to track activities, pipeline, and progress to capitalize on your team in the field.

Over the next few weeks, we’ll share nine key wins for manufacturing companies using mobile CRM solutions.

Are you a manufacturing company with a field sales team? These nine wins should have you considering an investment in a mobile application sooner than later.

1. Surface the information that matters.

The old days of field selling are gone. No more printed excel sheets, spiral bound notebooks, or  wrinkled pages of contact information. With today’s technology you can access information on-the-go, anytime, anywhere.

Mobile_CRM_app_Linkedin_img520x272

Tracking quality, inventory, quotes, and individual client information… there’s a lot that a field sales rep is responsible for when meeting with customers on the road. When time is of the essence (as it always is), you need to be able to access all of this in one place. Don’t waste time working in disparate systems and spending minutes (and energy) navigating between windows. A mobile application that surfaces the information you need – when you need it – can leave you, and your team, with more time and resources to turn a greater profit.

Consider an Integration

An application designed for the field can help you surface critical data from a variety of systems, such as historical sales data, product catalogs, pricing information, and more. For example, you can utilize an integration with a back-end content database to surface product catalogs when meeting with potential clients onsite.

Consider an integration with your ERP system to display critical financial data within CRM. Without a clear CRM and ERP integration strategy, your organization might not be realizing its full potential in the marketplace. With an integration, you will reduce the amount of process steps, increase efficiencies, reduce errors when inputting data, all while providing your key stakeholders with a true 360-degree view of your customers in a single solution.

With complete visibility into each and every opportunity, you can save time clicking and updating your disparate systems and spend more time selling. If your customer information is stored in a variety of email systems and spreadsheets across your different offices, your customer service efforts also become inconsistent, translating to lost sales and unhappy customers. Enable your sales staff to deliver exactly what the customer needs exactly when it’s needed.

Customer Example: New Belgium Brewery

New Belgium Brewery worked with Sonoma Partners to help their field sales team (also known as “Beer Rangers”) provide the best service to their customers in the field. We created a touch-based mobile application to provide them with easy-to-access customer data when they needed it most.

Functionality on the Road

In today’s highly mobile and data-centric world, access to information on-the-go is not only necessary, but expected. A consulting partner can help you access your CRM data via a mobile application, while supporting a range of mobile devices and dashboards tailored for ease-of-use in remote locations.

Stay tuned for more wins for manufacturers who invest in a CRM mobile application. If you’re interested in learning what might be possible at your organization, contact us.

Topics: CRM for Manufacturing Enterprise Mobility

PowerApps with Dynamics 365 Update

Back in October 2016 I posted a step by step instruction for creating a basic contact application using the PowerApps preview designer with the new Dynamics 365 connector.

Today, I provided an encore presentation for the CRMUG. So, in preparation for the webinar, I went back through the steps using the new production version of the PowerApps studio. As I guessed, some fantastic updates to application were deployed, which prompted changes and new screenshots for our original application. Our original post was updated reflecting the changes as of today.

I am sure there is a more comprehensive list somewhere, but listed below are a few the differences & improvements I found useful for updating my contact application.

  • The default Dynamics 365 contact app now includes a refresh icon/functionality.
    image
  • The 'Theme' functionality is no longer on its own Design tab. It is on the Main tab, but isn't readily discoverable if your window is too small.
    image
    image
  • The PowerApps team added support for multi-environments. Learn more at https://powerapps.microsoft.com/en-us/blog/powerapps-environments/.
  • You can now search for advanced properties. Super nice!
    image
  • More properties are exposed in the ribbon, making it easier to change them without having to go and search in the Advanced tab.
  • Added an application description field. Doesn't sound like much, but when you start creating a lot of applications, it is nice to have more context about them. Smile
  • The default icon size appears to be larger than the preview. We still recommend using the search icon and sizing it the same as the text box height, but added some padding to make it look better.
    image
  • Overall performance of the client was improved. I am sure they are still making further improvements, but the latest version was noticeably faster than the preview.

Support

Should you need to submit ideas or help with your apps, please use the following forum link: https://powerusers.microsoft.com/t5/PowerApps-Community/ct-p/PowerApps1

There two forums for you, support and ideas.

clip_image002

The PowerApps team uses these sites for feedback and will forward any Dynamics 365 connector questions to the Dynamics team where appropriate.

Topics: Enterprise Mobility Microsoft Dynamics 365

New Dynamics 365 Apps for iOS and Android Authentication Issues

Today's blog post was written by Neil Erickson, Development Principal at Sonoma Partners.

Our team at Sonoma Partners have been using Microsoft’s mobile applications for a few years, including the native phone and tablet clients. Over this past weekend we received reports from a few users that they were now unable to sign in properly. After investigating, we determined that Microsoft recently updated their apps to reflect the most recent version, Dynamics 365. After these updates made their way to user’s phones, the follow error was shown.

image

Looking closer, when the new apps try to authenticate the following error is logged on the ADFS server.

Microsoft.IdentityServer.RequestFailedException: MSIS9236: The OAuth authorization request contains invalid client or redirect URI. Failed to process the request. ---> Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthInvalidClientRedirectUriException: MSIS9224: Received invalid OAuth authorization request. The received 'redirect_uri' parameter is not a valid registered redirect URI for the client identifier: 'ce9f9f18-dd0c-473e-b9b2-47812435e20d'. Received redirect_uri: 'ms-auth-dynamicsxrm://com.microsoft.dynamics.iphone.moca'.

This error tells us that the new version includes some RedirectUri's that were not present in previous versions, and are now required for proper authentication.

So, you will need to add these RedirectUri's to the ADFS client even if your Dynamics CRM / Dynamics 365 server version has not changed. This can be accomplished by removing the existing ADFS Client and adding it back with the cmdlet currently on this TechNet article.

Topics: Enterprise Mobility Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

Creating a PowerApps Mobile Application with Dynamics 365 in 1 Hour

Today's blog post was co-written by Brad Bosak, Vice President of Development at Sonoma Partners.

Note: This article was updated on January 23, 2017 to reflect the latest update to the Dynamics 365 connector. Specifically with the lookup approach.

Note: This article was updated on December 14, 2016 to reflect the latest updates to Dynamics 365 and PowerApps.

I recently presented at the CRMUG Summit on how to use the new PowerApps Studio to quickly create mobile applications using the Dynamics 365 connector. As I prepped for this session, my colleague, Brad, and I discovered that native Dynamics 365 connector can quickly get you to a working functional application in minutes. However, since the connector is still in preview, some adjustments need to be made to use these applications in practice.

We are going to provide the steps we went through to create an application that will show active contacts in a list, allow you to drill into the contact record for additional details, and finally update the contact records. All of this will begin by using the default template provided by PowerApps through the Dynamics 365 connector. The application you will create is shown below:

imageimageimage

You are also encouraged to download the completed application, but please review the install note after you extract the file.

Before You Begin

Before trying out this application, you will need to have some prerequisites completed.

  • A PowerApps account using your organization email address
  • A valid Dynamics 365 (Online) instance which must reside in the same organization
  • Download the latest Windows PowerApps Studio application & PowerApps mobile clients for the mobile devices you wish to distribute

Contact App Demo Setup

  • Open the PowerApps Studio and create a new connection to Dynamics 365 
    image
  • Note that this will take you to the PowerApps web page where you can configure a connection 
    image
  • Back in the PowerApps Studio, create a new Phone Application using that connection and by selecting the contacts entity. Note, you can search to filter the table list.

    image 
    image
      
    image

You will see the application is created and ready for use (in theory at least Smile). The newly created app has a live copy of your contact data and 3 screens (a list screen, contact detail screen, and an edit contact screen). Unfortunately, the default list, detail, and edit screens do not provide the fields or format we desire. To address this, we'll use the rest of this article to simply “clean up” our app. 

image

Add Data Sources

Since we want to also display and edit company information in our application, we will also add the Accounts entity as a data source. This will be necessary as we demonstrate a work around for the lack of lookup support in the current Dynamics 365 connector.

image

Important: The current Dynamics 365 connector does not support lookup or option set data types. This application will need to use a lookup field (Company), so we'll demonstrate how we worked around the lookup limitation.

  • Add Accounts so we can display names in our lists and lookup fields

Change Theme

For variety, let's change the overall app theme. You find the theme selection in the main Home tab. It will be the down arrow if your screen size of the application is small. Otherwise, it will be listed as "Theme" in the ribbon. Select the theme of your choice. We went with Light.

image

Update Icon & App Name & Save Locally

We want to encourage you to save often as you work on your application. There are two save options, one saves to the cloud and the other locally. We prefer to save locally as we work on our application as it is a bit faster with how often we save. This approach also allows us to put our app file in source control. However, in order to distribute the application, you will eventually need to save to the cloud.

You can also change your application name, icon, icon background color, app description, and screen orientation from the App Settings menu. Select File - App settings and then name your app, change the icon, icon background color, and provide a short description. Finally click Save and save locally.

image

image

Browse Screen

Now that we have saved our progress, we'll update the Browse screen first, using the default screen/list layout provided.

Our first step updates the list filter to only show active contacts and search on the last name field. You accomplish this by selecting the list of records and replacing the Items property with the following line of text:

SortByColumns(Search(Filter(Contacts,statuscode=1), TextSearchBox1.Text, "lastname"), "lastname", If(SortDescending1, Descending, Ascending))

The Filter function trims the dataset based on the criteria entered, in this case only showing active contacts.

image

Next, we will remove the fields we don't wish to display.

Note: You need to select the first cell of the list to access the individual elements of the list.

  • Remove all fields by selecting each control and clicking delete, except the entity image. We'll add back the ones we want to display. 
    image
  • Make the entity image smaller, so it takes up less room in the cell
  • Insert a Text box control to show contact full name
    Note: The Dynamics 365 connector doesn't return full name in the field list, so we'll need to manually concatenate it.
    • Text = ThisItem.firstname & " " & ThisItem.lastname
    • Vertical align to top of image 
      image
  • Copy and paste the previous Text box control to to show the contact's job title
    • Text = ThisItem.jobtitle
    • Change font Size to 16
      image
  • Repeat this process for the Parent Customer (company) field.
    • Text = LookUp(Accounts, Text(accountid)= ThisItem._parentcustomerid_value).name

Note that lookup fields display the id (GUID), not the label. We'll fix that by using the LookUp function. The LookUp function takes our newly added Accounts collection and matches the parentcustomerid with the accountid. We then use the result to return the name field from the account.

  • Tighten up row height by selecting the bottom of the first cell and dragging to the desired height
  • Change font size as desired by updating the Size property to whatever value you wish

image

  • SAVE!

Detail Screen

Next, select the DetailScreen1 page from the screen list. We'll also make this screen more presentable to the user. Similar to the Browse screen, we'll remove the fields we don't wish to display and add the ones we do. But for this screen, we'll also take advantage of PowerApps custom card option.

  • Remove all fields but Company Name card
    image
  • Add Custom card and move the card to top of screen by dragging the card to the top 
    image
  • Make sure you keep the the custom card cell selected and insert Image from the Media button
    image
    • Set Image property to ThisItem.entityimage
    • Drag the size to something that fits in the left corner
  • Insert Text box
    • Set Text property to ThisItem.firstname & " " & ThisItem.lastname
  • Insert Text box
    • Set Text property to ThisItem.jobtitle
    • Change font size. Select Size in the dropdown and set it to 16
  • Select the custom card and change card fill to a different color
    • Set Fill to RGBA(227, 233, 241, 1)
    • Note you can use a web converter tool such as http://www.hexcolortool.com/ to help with the correct RGB color

      image
  • Select Company Name card and then select the Advanced Properties
    image

    • Unlock the card, so we can edit the individual properties image
    • Update Company Name to display name to LookUp(Accounts, Text(accountid) = ThisItem._parentcustomerid_value).name 
      image
    • Close the Advanced Properties dialog
  • Add EmailAddress1 and Telephone1 fields by simply enabling eyeball indicator from the Options tab.
  • Select the EmailAddress1 field and change the display to launch the native email client with the email address prepopulated. 
    image
  • Similarly update the telephone1 field to display as a phone number. This will launch the native phone client when the application is used. 
  • SAVE!

Account Lookup View

In order to work around the lookup field limitation on the edit form, we will create our own lookup dialog for Accounts. Remember, we have already created (and used) the Accounts data source. We'll create a new screen (page) and populate it with the active account list. This will allow us to call this page from our custom lookup field on the edit page.

  • Click the New Screen button in the upper left of the designer
  • Name this new screen Account Lookup
    image
  • Click Layout in the right pane and select the 'Browse items, one line description' template
    image
  • Rename header textbox to "AccountLookupTitle"
  • Select the text label control and change the text to "Accounts"
    image
  • Update the Items property of the list by replacing the sample gallery text with the Accounts data source and change the search property
    • SortByColumns(Search(Filter(Accounts,statuscode=1), TextSearchBox2.Text, "name"), "name", If(SortDescending1, SortOrder.Descending, SortOrder.Ascending))
      image
  • Click the first cell in the list. Select the text box control and update the Text property to show the account name and change the font Size to 20.
    image
  • Rename the list to "AccountList"
  • Update the Arrow icon's OnSelect property to: 
    ClearCollect( SelectedAccount, { Account: AccountList.Selected } ); Back()

    • This clears previous values and creates (if not already created) an in-memory collection that we can reference from the other views, I haven't found another good way to have a 'global variable' in PowerApps
      image
  • Let's hide the new accounts button, as we don't want to create new accounts. For simplicity, we'll just hide the field, by setting the Visible property to false. You can do this from the Icon tab and unselecting the Visible button.
    image
  • SAVE!

Edit Screen

Finally, select the EditScreen1 page from the screen list. Using the native Dynamics 365 connector for PowerApps, automatically wires up the edit page. We don't want to interrupt this process, but we'll need to use a workaround for the lack of lookup support. For the other fields, it is as simple as adding the fields to the form.

  • Remove all fields except the Company fields and Last Name
    image
  • Add emailaddress1, firstname, jobtitle, telephone1 and order them as shown in the image below. 
    image

We will now show you our workaround for managing lookup fields. First, we relabel and hide the existing type and id fields. Then we'll create our own lookup field that will talk to the Account list we previously created and populate the fields we just hid, which will allow the native wiring to work as expected.

    • Update the parent customer field to show our lookup control instead of the GUID
      • Click the ellipsis on _parentcustomerid_type field in the right pane and select Advanced Options
      • Unlock the card to change properties 
        • Click more options in the Data section and change Default field to "accounts"
          image
        • Click more options in the Design section and change Visibility field to false 
          image
      • Click the _parentcustomerid_value field and should see the Advanced pane change
      • Unlock the field by clicking the lock at the top of the options pane
        • Select the Text box in the parent customer card on the form
          • Rename the Text box to AccountGuid
          • Set the Visible property to false 
            image
        • Change Company Name card Default value
          • This is saying the if we have a selected account in our custom collection, use that value.  If nothing is in our custom collection, use whatever is currently set on the record from CRM
          • If( IsBlank( First( SelectedAccount ).Account.accountid ), ThisItem._parentcustomerid_value, First( SelectedAccount ).Account.accountid )
            image
    • We have completed the setup for the card and original field bindings for the form to use. What is left is for us to create a field to select the account.

      • Insert a TextBox control to the card - Make sure you are focused in the Company Name card 
        • Rename the TextBox to "AccountName"
        • Update the BorderStyle property to Solid
        • Update the BorderThickness property to 2
        • Update the X property to 30
        • Update the Y property to AccountGuid.Y
        • Update the Width property to Parent.Width - 60  (to match the other input fields)
        • Update the Height property to 52
        • Update the Text property to LookUp( Accounts, Text(accountid) = Parent.Default ).name
          image
      • Insert a magnifying glass icon control to the card to have the input better resemble a lookup control
         image
        • Update the X property to Parent.Width - 82  (Note: 82 is the right padding of 30 between the textbox and the edge of the screen plus the width of the icon)
        • Update the Y property to AccountName.Y
        • Update the Height and Width properties of the icon to 52 
        • Update the four Padding properties to 5. This will shrink the icon a little and make it look better
        • Update the OnSelect property to Navigate('Account Lookup', ScreenTransition.None)
          image
    • Select the form and update the OnSuccess property to Clear( SelectedAccount );Back() 
      image
    • Select the Cancel button and update its OnSelect property to:
      Clear(SelectedAccount);ResetForm(EditForm1);Back() 

      image

That's it! Click the Play icon in the top right menu and test your application. If everything is working as it should, save to the cloud to test on your mobile phone and then share with your team.

Topics: Enterprise Mobility Microsoft Dynamics 365 Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

My Experience with Mobile CRM 2016 and Making It Work

Today's blog was written by Argyris Anargyros, Development Principal at Sonoma Partners.

Recently I had the pleasure of upgrading a CRM 2015 On Prem org to 2016 On Prem. The main reason for the upgrade was to take advantage of the latest CRM mobile applications for phone and tablet. Based on what I read and had experienced with implementing CRM Online using mobile apps, I expected this to go pretty smooth. This client was originally on CRM 4.0, upgrade to 2011, then 2015, and now 2016. I was a part of the 2015 upgrade, so some of these challenges were a surprise because I was unaware of all the changes that have happened over the years. Here is a list of all the "fun" stuff we ran into once we upgraded and tried out the phone and tablet apps for iOS and Android. 

Bad Assumption

Let's start off simple and talk about Microsoft's documented limitations for Mobile apps.

"Forms in CRM for tablets are limited to 5 tabs (or 75 fields and 10 lists). This limit includes hidden fields."

What I got tripped up on was the definition of a list. I assumed a list was a view or sub-grid, but that was wrong. The simplest way I defined Lists are screens you can swipe to on your phone. Below is a screenshot of the visual indicator of which the list you are currently on. The underscores in light grey and black show the 10 "lists," or screens, you can swipe to while on an entity. Make sure you watch out for this limitation if your form is on the large side. You may run out of space and sections of your form may not appear as expected. For this project, we were able to trim down the needed sections. This was missed, though, until we went to UAT and someone tried to get to a section that was not available on Mobile.

Argy mobile 1

Where are my connections?

According to the documentation on MSDN, connection were not available for 2013, but for 2016 the disclaimer provided by Microsoft was removed.

Argy mobile 2

This note was provided in the 2013 version of the "Entities displayed in CRM for tablets" section of this article, but not in the 2015 or 2016 version. This note is still valid for 2016.

Error - This view is unavailable.

While swiping around the app, we would occasionally see this message: "Error - This view is unavailable." I attempted to use the mobile app logging to help identify which view or which entity was causing the issue, but nothing there. I ended up identifying the next screen which was the activities entity. After reviewing all the available views, some of the system views were disabled as a part of a previous deployment. It looks like the mobile apps are looking for specific views to be available. Once we activated the "All Open Activities" and "My Activities" views, the errors disappeared.

Default Sales Dashboard

The mobile app home screen is defaulted to the default Sales Dashboard. If  you want to change this default for the browser, all you have to do is make a small change to the site map and set default dashboard for each area, Sales, Marketing, etc. Mobile ignores this and uses one specific OOB sales dashboard. To get around this, we recreated the default sales dashboard as a new dashboard and then edited the OOB sales dashboard to include the data we wanted to see. This way the mobile and web applications showed the same dashboard and the users still have the option to switch to the native dashboard.

White Relationship Tiles

This was a fun one. While on an entity we would see blank tile spaces intermixed with the tiles for related entities. When you tap on those spaces they would take you to a related entity. I ended up finding this helpful article on CRM Tip of the Day which resolved this issue for most entities, but we ended up with a few that this did not work. Luckily we did not need those related entities as related entities, so we removed them from the navigation.

Order of Operation

Intermittently we would see an issue with the mobile app executing JavaScript out of order. This was something we did not see on the browser, but to resolve this we ended up consolidate all of our scripts to one file. Enforce libraries were in place before events are fired helped remove these issues. This might be a practice you are already following, but as this was an upgrade we had a handful of web resources being referenced by the form without issue until Mobile was introduced.

Fields Need To Be On The Form

While taking a look at Opportunities, we started to see this error.

Argy mobile 3

We did not find any of our code that referenced this field, so assuming the mobile app needs this field, we added it as a hidden field on the form and the error went away. We also saw this for the stage field and the same solution worked. Both of these fields are not in use for this implementation, so adding them was not needed for the browser.

Related Lookup Filter

The native filters on related lookups do not work on Mobile, but you can add some JavaScript to fix this. Using the addPreSearch and addCustomFilter XRM commands, you can mimic the same behavior as the native filters. Up to you if you would like to add a check so your code runs for mobile only, but probably a good idea.

I hope this list helps you resolve some of your challenges with the Native CRM Mobile app. The most helpful tip I can provide (taken again from the CRM Tip of the Day) is to make sure you start looking at mobile as early as possible and for developers, use your browser to test/debug mobile issues.

Learn how to use Voice of the Customer in this guide

Topics: Enterprise Mobility Microsoft Dynamics CRM 2016

Ins and Outs of App Deployment Using Microsoft Intune

Today’s blog post was written by Marty Diamond, Senior System Administrator at Sonoma Partners.

Here at Sonoma, we promote a highly mobile workforce. Like other businesses, this means distributing internal apps to phones and tablets not owned by the company. Many mobile device management solutions have risen to assist with this challenge. We’ve used a handful of these with varying degrees of success. Recently, we have been piloting Microsoft’s Intune system, a part of Microsoft’s Enterprise Mobility Suite. Intune is interesting as a significant portion of it is dedicated not just to device management and compliance but application management, which offers many benefits to us.

Before delving too far into it, I should say that while Intune is a very flexible platform for managing a fleet of mobile devices, Sonoma’s use case is almost entirely dedicated to application distribution and updating. We have few company-owned mobile devices that are used by our QA team, and thee have very few requirements placed on them. This makes Intune very appealing: we can use it to simplify management of our mobile applications and scale up if needed.

We began testing with a simple task: log into the management portal and add a device. Getting there is simple enough. Once you’ve started the trial and assigned a license, Intune becomes another administrative portal launched from your Office365 portal. You are greeted with a set of startup prompts to help you navigate the portal from creating a policy to setting up your “Company Portal” to get devices into management. Once this is complete, the dashboard begins to fill with data about any devices it is managing.

Marty post 1 v2

The first real step within Intune is to define a policy. This is where we ran into our first “gotcha.” While the wizard takes you through defining a policy and creating other policies, it does not mention anything about deploying those policies. Nor does it mention that, by default, the existing Default Security Policy is not deployed. Missing this deployment step freezes the whole process: no device can be added unless a default policy is deployed.

Marty post 2 v2

Once we got past that, we continued testing with device onboarding. This process is critical as the easier we can make it for our staff to access apps they need, the less IT overhead we need. This where Intune scores some more victories—as a part of Office365, it works with our existing SSO. We simply needed to grant users licenses. From there, they are free to download the Company Portal app and sign in. The device add process is similar to other MDM solutions. It will ask the user for permissions to perform the functions it needs (management certificates for iOS, device administrator for Android, etc).

Notice that the Company portal app allows for easy app discovery and management. As long as they meet deployment criteria, users can find easily find apps by category. They can also see what other devices they have enrolled and if those devices are compliant. Each licensed Intune user is entitled to up to 5 devices (admins can limit this further).

For us, the star of the show was in app deployment. The Apps section does exactly what we need it to: deploy apps and keep them updated on our schedule.  The first step is to add an app. Much like policies, the process here is to add it and then deploy it. 

Marty post 4 v2

The Add App function launches a ClickOnce application that allows you to upload an app directly to Intune, hosted an external link, or—for iOS only—managed from the App Store. This same application is used to manage existing deployments. From this ClickOnce application you can change what types of devices can run the app (in the case of iOS universal apps), rename the apps, and keep apps updated. This was critical for us. Once a user has downloaded an app from Intune, they will then always have the latest version of that app on their device. The same is true for any apps we require the install for. One note here is that apps deployed to device groups that are required installs can take several hours after being upload to be deployed. The same is true with app updates. This delay does not appear to exist for apps deployed to users that are requested through the company portal.

In a lot of respects, Intune has more in common with System Center than other established MDM products. For example, when you want to deploy an app to groups of devices, you only have the options to Install or Uninstall. You can only make an app available to people via the portal by deploying to a group of users. While not immediately clear, this methodology makes a lot of sense: you might have groups for tablets and phones but deploying a universal app to a user allows someone with an iPhone and an iPad to get the app as needed without the need for two separate deployments.

Some other notes to keep in mind when considering Intune:

  • Intune supports direct connections to Exchange and SCCM. While we don’t employ these at Sonoma, leveraging them can give you more centralized control over devices.
  • Intune is smart about app deployments. For example, f you deploy an APK file to the “All Mobile Devices” group and mark it a required install, it won’t try and deploy to iOS devices or Windows machines. Keep this in mind when deciding how best to deploy your various mobile applications.
  • In our testing, sign-ins timed out very frequently, even in the Company Portal app (though the login itself is cached). This is a nice security measure but may cause confusion and you will want to communicate that to your users. 

Learn how to use Voice of the Customer in this guide

Topics: Enterprise Mobility Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

How Mark Anthony Brands Revitalized Sales Culture with CRM and Mobility

Meet MABI

Mark Anthony Brands (MABI), the United States division of Mark Anthony Group (MAG), imports and distributes fine wine, premium beer, and specialty beverages. Due to alcohol distribution regulations, MABI can’t sell directly into accounts (e.g. bars/restaurants/stores). Instead, they rely on a network of distributors to facilitate these transactions. Field sales representatives (FSR) coordinate these operations and are crucial to how MABI does business. Overtime, business practices grew inconsistent and their sales tools outdated. The FSRs needed a mobile application to enhance the way they did business.

Mabi750x375

Time for a Change

Prior to this project, sales processes varied from region to region and from FSR to FSR. Practices for collecting/storing account information were piloted by single regions or teams, only to be abandoned shortly thereafter.

Their Leadership team aimed to provide the FSRs with a better means of doing their jobs, in order to secure better data and reporting capabilities. This shift in process would not only revitalize their sales culture but also spur enthusiasm from the FSRs by providing them with a new and unique means to reach their sales goals.

Objectives

The use cases for this project revolved around the tasks of the FSRs, which included:

  • Maintaining relationships with the account (bar/restaurant)
  • Quality assurance and evaluation of distributor performance via site surveys
  • Up-selling/cross-selling Mark Anthony Brands products

The plan?  A two-phased program including a Mobile Test Drive and mobile app development.

Download our free eBook: 5 Fundamental Features of Custom Mobile CRM Applications.

Post-Launch Life

The new mobile application – named, Mability (MABI + Mobility) – completely transformed the way the FSR team functions. With the new mobile CRM tool, they have better access to customer information in the field and an easier method for entering that transactional and account information. FSRs work more consistently than before with an implemented and defined sales process. Bonus: Mability features cross-device flexibility, providing endless opportunity taking the application to a tablet, an iPad, and beyond.

If you’d like to read more about the project, check out their customer success story here.

If you’d like to learn more about Sonoma Partners’ mobile applications, visit here.

New Call-to-action

 

Topics: CRM for Manufacturing Enterprise Mobility Microsoft Dynamics CRM Online

How to Plan Test Data for Testing Mobile Applications, Part 2

Today's post is written by Jen Ford, Principal QA at Sonoma Partners.

The last blog post I wrote about this topic covered the “Who” and the “What” of planning out test data for mobile apps.  Now, I will focus on the “Where”.

The “Where” – Where are your test users, and where are you?

As a tester, where you are located and where your test users are located, are integral components of mobile app testing. Like data security I mentioned in my previous post, this is another great place to look for defects. First let’s look at where your test users are.  If you have a global implementation, differences such as language, currency, and time zones can cause instability in the app if not tested properly. While difference in language and currency are fairly noticeable in a mobile app, how data syncs to a back-end system in different time zones is more subtle.

The first step is to make sure the following questions get answered:

  • What languages will this app support?
  • What currencies will this app support?
  • What time zones will the users be in?

When considering test cases for language, we will want to review the app in multiple languages. But there’s more to it than just that. Some test cases that are important to check include the following:

  • Make sure that when entering special characters in a language other than English, they display properly in the app, and in the back-end system when data is synced.
  • Make sure any text (field labels, instructions, demo modes) in the app display their special characters properly.
  • Field and label length. In some languages, the translation of a word is significantly longer than its English counterpart, or the word can translate into a multiple word phrase.  You will want to make sure these labels take up proper screen real estate in other languages, and don’t overlap other text on the app.

We have similar potential pitfalls with currency as we do language. Consider the following when writing test cases:

  • Make sure that when entering currencies other than USD, they display properly in the app, and in the back-end system when data is synced.
  • If the currency symbol is to be stored in the back-end system, make sure the correct one is associated to the value.
  • Make sure any text (field labels, instructions, and demo modes, for example) in the app displays the proper currency symbol, and the proper punctuation. For example: in USD, we’d expect to see an amount like this: $1,000.00.  In Japanese Yen, we should see it as this: ¥109,416.48.
  • Field length. Similar to language, make sure that when you enter a currency amount, that you can enter a large number. Going back to the amount in Yen, that number gets large very quick, so ensuring that those large amounts (both positive and negative) can be entered and properly stored in the back-end system is crucial to the success of a mobile app implementation.

Time Zones can be tricky if you are only dealing with a few that are close, like just the continental United States. Not taking into account time zones when testing can cause various issues with display and with actual data. Birthdates can be off by a day, policy effective and cancellation dates can be incorrect, and the ramifications of these issues are significant.  The good news is that you won’t need someone from every time zone to test if dates work across multiple time zones. You only need two: the one that you are currently in, and one additional time zone. If the test fails for the one additional time zone, it’s going to fail for all of them. Conversely, if it passes for one, it should pass in most scenarios (edge cases notwithstanding).  Here are some examples of what should be tested with time zones:

  • If someone is born on 1/1/1980, and this is logged into the app while in GMT, it should display as 1/1/1980, regardless of where the app is being accessed from in the world.  A user accessing this data from a different time zone should not impact this date whatsoever.
  • Effective and/or Cancellations dates. If you start an insurance policy, for example, your policy will have an effective date and time.  If you start your policy on 5/1/2016 at 12:00 AM GMT, then this should display in CST as 4/30/2016 at 7:00 PM, since this is the exact same time.

Regardless of the time zones that the app will be distributed to, testing with two time zones that are far apart from each other is the easiest way to spot defects, because the dates could then show as being off by one day.  I recommend whatever time zone you are currently in, and another one that has a 12 hour time difference.

The next important “Where” question, is where are you?  Where are you physically located, and where are you going with this app? This deals with how your app connects to the internet, and how it should behave when you are offline. It is important that your app is able to handle changes in internet connectivity. If this is an app that people will be taking into areas with little to no connectivity (hospitals airplanes, etc.), gracefully handling the app being online vs. offline is important. 

Here are some ways to test connectivity:

  • Test app functions (browsing, entering data, map functionality), while connected to a wireless network.
  • Test app functions (browsing, entering data, map functionality), while connected to a cellular network.
  • Test app functions while offline.

So, those seem pretty obvious, but the interesting stuff happens when you transition between each of these connection methods. To do this correctly, I recommend taking a walk (yes, a physical walk) with the app. When testing an app at work, this is a typical process that I go through:

  • Start in the office, connected to a wireless network.
  • Start walking around the office, making sure functionality continues to work, and any syncing or storing of data to a back-end system functions properly. I’d also make sure that maps are showing as I expect them to, based on my location and what other data points should be showing.
  • I’d walk out into the hallway, and wander around a bit. My wireless connection will drop and connect to a cellular network.  I want to make sure the app gracefully handles the switch, and that data entry, data display, and data retrieval are not interrupted with an unnecessary error or alert.
  • Then, I’d get into the elevator and watch my connection drop completely. Now I want to make sure that the app handles the switch to being offline. Does it display proper messaging, so that, as a user, I can visibly see that I’m offline? Does the app continue to work without crashing when submitting requests? Does any map functionality stop working and gracefully displays proper messaging to let the user know the map is not accessible (or display a stock image)? Does the app queue up requests that need to be synced to the back-end system, so that there is no data loss while working offline?
  • After my elevator ride, I’d get off and resume my connection to the cellular network. Is the switch handled well? Does my app now indicate that I’m online? If data is expected to sync automatically, does this happen now that I’m back online?
  • Then I return to my office, automatically reconnect to the wireless network, and resume testing. If I did not see any connection issues going from Wi-Fi to cellular, I wouldn’t expect to see any going from cellular to Wi-Fi, but if you’re walking that way, you might as well get some extra tests in.

Adding the “When” scenarios to your tests will start to broaden your scenarios and show you how this app will be working in real world scenarios. Enjoy the walkabout and prevent defects from entering your app once it’s live.

Happy Testing!

Topics: Enterprise Mobility

Could Siri Power Your CRM App?

Today's post was written by Kyle Gerstner, Principal Consultant at Sonoma Partners.

The WWDC script has been the same for the past few years; go through Mac, iOS, Watch, Apple TV, and show off some cool new features that have been developed. 

Usually, these features are consumer focused and don't have a huge impact on enterprise mobility. That being said, something was announced this year that could greatly improve the user experience of enterprise applications.

We don't have a lot of information yet, but Apple has opened up the Siri API to developers.  This will be accomplished through a new API called Intents. This allows a developer to enable their application to respond to a request the user has asked Siri to complete. The demo during the WWDC keynote focused on consumer use cases, including examples such as hailing an Uber or sending a text message through a 3rd party application. We're excited to get more details as they come out and see if there are opportunities to trigger actions in our applications.

Let’s look at how this could impact one of our applications: Activity Tracker.

Our Activity Tracker application is built for iOS and allows you to search across CRM contacts and accounts, view basic information, record activities, and create new contacts.  While we have made every effort to make the user experience very streamlined, it would be much better to be able to ask Siri to look up John Smith's phone number, or even start a phone call to him.  Could we ask Siri to add a note to the Sonoma Partners account and dictate the text of the note?

We don't know what will be possible with this new API, but we are very excited about the prospect of it.  It also shows that Apple is becoming more willing to open up their APIs to 3rd party developers.  Apple announced developer access to a few other APIs that aren't relevant to the enterprise market, but shows their willingness to allow 3rd party applications to feel like they are built into the OS.  We hope there is more good news on the horizon.

Are you interested in learning more about enterprise mobility? Contact us to get the conversation started.

Topics: Enterprise Mobility

The Best Method to Demo Mobile Applications

Today's post is written by Brian Kasic, Principal Consultant at Sonoma Partners.

Mobile applications are becoming more and more prevalent within CRM projects.

Seeing how they function is critical to the success of any mobile deployment. However, in my experience, screen prints seem to be the standard way of showing functionality or training end users on how a mobile CRM application works. Typically users learn how to use mobile apps by interacting with them. They should be intuitive and straight forward. Demoing an app or training end users on how to use an app should be just as intuitive. However, getting started can sometimes be challenging, especially when there is a process involved or if end users are seeing the app for the first time.  

At Sonoma Partners, we utilize a product called Reflector 2 to mirror your phone via Bluetooth on your computer. The set-up and steps to reflect your app to your computer are simple. The Reflector license pricing is reasonable and worth the corporate license fee. By mirroring the app on your computer, you can quickly create re-usable videos to assist end users when they are first starting to work with their new mobile CRM applications.

Here are the steps for getting started on an iPhone:

  1. Download a trial of Reflector 2 to your computer. If you end up liking it the pricing and licensing can also be found on the website.
  2. Launch Reflector 2 on your computer.
    1

  3. Next make sure your computer Wi-Fi and your phone Wi-Fi are on the same network. This is important and can be where you run into trouble. Also be aware that if you get bounced off of Wi-Fi, you need to start over again. I’ve seen Reflector need to be completely closed and restarted to begin a new session when bounced off of Wi-Fi.

  4. From your phone find your Bluetooth button. This is can be done by swiping up from the bottom of an iPhone. Then Click “AirPlay”.
    2

  5. Within Airplay find your laptop and swipe the mirroring button.
    3

  6. This will Mirror your content from your phone screen to your computer screen without wires.

  7. You can move the phone on your computer with your mouse by hovering over it and dragging it to another part of your screen.

From here, customers and end users can see the actions on your phone directly on your computer. I’ve given demos showing data being entered into the phone then immediately refreshed my CRM online environment showing the data being updated. You can also demonstrate voice activation on the phone and the time savings it can provide to enter notes or activities. Both of these demo tricks of showing the mobile app in action have fostered very positive feedback from the audience.

Android installation instructions can be found here.

Have a question about mobile CRM applications? We're here to help.

Topics: Enterprise Mobility