Sonoma Partners Microsoft CRM and Salesforce Blog

I’ve Got 99 Problems, And CustomControlDefaultConfig Is One

Today's blog post was written by Mike Dearing, Principal Developer at Sonoma Partners.

When attempting to import a CRM 2016 SP1 solution the other day, I was greeted with an error that I hadn’t seen in a while: “cannot insert duplicate key.” Typically, this means that someone created a new field in the target environment and the source environment with the same name but different casing such as “new_test” in the source and “new_Test” in the target. SQL ignores casing, but CRM detects the difference and assumes these are 2 separate fields, so it attempts to create the new column, causing the duplicate error message. When checking a trace though, the following was logged:

The dependent component Entity (Id=XXXXX) does not exist.  Failure trying to associate it with CustomControlDefaultConfig (Id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) as a dependency. Missing dependency lookup type = EntityObjectTypeCodeLookup.

So, I began my Google journey. It turns out I was not alone here, and that many others had already documented their struggles and their progress. Everything pointed back to the customcontroldefaultconfig entity, as the trace suggested. There appear to be a few possible cases of bad data that can occur:

  1. There can be multiple instances of one customcontroldefaultconfigid occurring in this table.
  2. There can be multiple instances of a primaryentitytypecode occurring in this table.
  3. There can be instances of primaryentitytypecode in this table that don’t exist in this environment.

#1 and #2 may be closely related, but I at least confirmed that #2 was an issue for me. I also noticed #3 in my environment. For #3, it looks like Microsoft is bringing over the entity type code of an entity from a source environment and using it in a target environment, which is not a reliable practice for custom entities since you can’t ensure the type code will be the same between environments. For #1 & #2, I’m not certain how these come to exist, but it may be through the usage of segmented/partial solutions.

Each thread I found online suggested direct SQL detection and deletion. I didn’t immediately see a reason why, since this entity is queryable through the API, so I wrote a LINQpad script and checked it out. I queried the target environment’s metadata for all custom entity type codes to try to fix #3 from above. This returned one record, and the primaryentitytypecode in the result set actually said "none" since it was trying to convert a type code into an entity name but failing to find the entity in this organization. I went ahead and tried to delete the record, and no errors occurred. Looking in the database though, the record was still there. While frustrating to hit this dead end, at least now I understand why every thread suggested direct SQL cleanup, since API deletions appear to be ignored for this entity type. Here is the code for reference:

var connection = CrmConnection.Parse(connectionString);
var orgService = new OrganizationService(connection);

var entityFilter = new MetadataFilterExpression();
entityFilter.Conditions.Add(new MetadataConditionExpression("objecttypecode", MetadataConditionOperator.GreaterThan, 9999));

var attributeExpression = new AttributeQueryExpression();
attributeExpression.Properties = new MetadataPropertiesExpression("logicalname");
attributeExpression.Criteria.Conditions.Add(new MetadataConditionExpression("logicalname", MetadataConditionOperator.Equals, "donotreturn"));

var relationshipExpression = new RelationshipQueryExpression();
relationshipExpression.Properties = new MetadataPropertiesExpression("schemaname");
relationshipExpression.Criteria.Conditions.Add(new MetadataConditionExpression("schemaname", MetadataConditionOperator.Equals, "donotreturn"));

var entityQueryExpression = new EntityQueryExpression()

{

                Criteria = entityFilter,
                AttributeQuery = attributeExpression,
                RelationshipQuery = relationshipExpression

};

var retrieveMetadataChangesRequest = new RetrieveMetadataChangesRequest()

{

                Query = entityQueryExpression

};

var metadataResponse = (RetrieveMetadataChangesResponse)orgService.Execute(retrieveMetadataChangesRequest);

var entityTypeCodes = metadataResponse.EntityMetadata.Select(x=>x.ObjectTypeCode).ToList();
entityTypeCodes.Sort();

var ccdcsToDelete = orgServiceBCG.RetrieveMultiple(new FetchExpression(String.Format(@"
                <fetch>
                                <entity name='customcontroldefaultconfig'>
                                                <attribute name='primaryentitytypecode'/>
                                                <filter>
                                                                <condition attribute='primaryentitytypecode' operator='not-in'>
                                                                                <value>{0}</value>
                                                                </condition>
                                                                <condition attribute='primaryentitytypecode' operator='ge' value='10000'/>
                                                </filter>
                                </entity>
                </fetch>", String.Join("</value><value>", entityTypeCodes))));

foreach (var ccdcToDelete in ccdcsToDelete.Entities)

{

                orgService.Delete("customcontroldefaultconfig", ccdcToDelete.Id);

}

When discussing with Microsoft, they suggested manually removing the "CustomControlDefaultConfig" xml elements from each entity node in the solution import every time, which does appear to prevent the error from occurring since it isn’t attempting to insert the duplicate row any longer. This is pretty time consuming though, so if you are on CRM Online, see if you can get your support representative to clean up your customcontroldefaultconfigbase table for you. For On-Prem, you can go the direct SQL route and delete duplicate rows or rows that have no matching entity in the environment. Be extremely careful and take a database backup before doing any direct SQL deletion since this is unsupported and may have unexpected results. The following SQL should allow you to detect the rows for the three cases discussed above:

-- #1 Detect duplicate CustomControlDefaultConfigid
select count(CustomControlDefaultConfigid), CustomControlDefaultConfigid
from CustomControlDefaultConfigBase
group by CustomControlDefaultConfigid
having count(CustomControlDefaultConfigid) > 1

-- #2 Detect duplicate PrimaryEntityTypeCode
select count(PrimaryEntityTypeCode), PrimaryEntityTypeCode
from CustomControlDefaultConfigBase
group by PrimaryEntityTypeCode
having count(PrimaryEntityTypeCode) > 1

-- #3 Detect PrimaryEntityTypeCode that doesn't exist in this environment
select CustomControlDefaultConfigId, primaryentitytypecode
from CustomControlDefaultConfigBase
where PrimaryEntityTypeCode >= 10000 AND
PrimaryEntityTypeCode not in
(
                select objecttypecode
                from entity
                where objecttypecode >= 10000
)

Microsoft said that this is in their product backlog and being worked on, but had no ETA for a fix. They also unfortunately didn’t have any details on what the cause is for these issues. If you’re encountering these as well, please consider opening a support ticket to help escalate a fix. Here’s to hoping for a new year with one less solution import error on each of our plates!

Topics: Microsoft Dynamics CRM 2016

Enabling Configurable Plugin Trace Levels

As we mentioned last spring, Dynamics 365 now supports tracing messages from plugins without requiring an error to be thrown.  However as plugins become more complex, we often find ourselves wishing for more granular control over the level of detail traced without requiring code recompilation.  With these requirements in mind, we will build an elegant solution that has minimal impact on performance.

First, we'll define an enum that introduces the different levels of tracing we want to support.

This should start to look familiar if you use log4net or similar logging frameworks.  The different levels (Debug, Info, Warn, Error, and Fatal) provide the granularity we are looking for when configuring how much detail we want in our Plugin Trace Logs.  The other two values (All and Off) provide a more explicit way of completely enabling or disabling tracing.

Next we’ll add an internal class to our plugin assembly to wrap all of our trace calls.

The main constructor starts by getting the ITracingService from the passed in IServiceProvider and storing it in a field for later use.  It then goes on to look for a shared variable on the IPluginExecutionContext which will define the minimum tracing level to trace.  If that shared variable doesn’t exist, it defaults to the minimum level passed in to the constructor.

Now we’ll add a method that will actually perform the tracing.

The Trace method takes a level, a format, and an array of arguments.  If the level is at or above the minimum, the format and arguments are combined and then passed to the previously saved _tracingService.  We prefix the message with the trace level, to provide extra detail.  This could be further enhanced to provide timestamps if you are investigating performance concerns.

Finally, we’ll add a few convenience properties and methods to our Tracer class just to make it easier to use.

The properties provide a quick way to check and see which trace levels are enabled.  For simple messages there isn’t a need to check these properties, but some more detailed traces have to build up a complex messages.  In these cases, it is worth it to check and see if the targeted level is enabled before building the message.  The methods here are simple shortcuts for Trace with the level specified as the method name.

Now we’re ready to write a plugin that takes advantage of our new class.

While this plugin’s logic is very contrived, it demonstrates how to use the Tracer class.  There are examples of tracing at different levels and checking which levels are enabled before composing a more complex message. 

We can register this plugin to run during the Create of a contact using the following configuration:

BusinessLogicPluginStep

If the plugin is left registered by itself, it will always be configured to run at the “Info” trace level (The simpler Tracer constructor it uses defaults to TraceLevel.Info for the defaultMinimumLevel).  If we want to change the level without making code changes, we’ll need to introduce another plugin.

The TraceConfigurationPlugin uses the Unsecure Configuration value to set the TracingLevel shared variable on the execution context.  As long as we register this plugin to run before any of our other plugins, it can specify the level the plugins following it should use.  We could even register multiple steps for the same message with different Execution Order values if we wanted to have different trace levels for different plugins.

Here is an example of how we could register this plugin to run before the BusinessLogicPlugin and set the trace level to “Debug”:

TraceConfigurerPluginStep

Now we can use the Tracer in all of our plugins and feel comfortable adjusting the trace level as more details are needed during troubleshooting.  No additional API calls are made to read the tracing configuration values, so this will have a minimal impact on performance.

To see how to enable tracing and where to read the logs, please reference our earlier blog post.

Topics: CRM Best Practices Microsoft Dynamics CRM Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

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

Amazon Alexa and Dynamics CRM

Here at Sonoma Partners we’re always looking for ways to use the latest and greatest technologies with CRM.  With voice dictation services becoming more and more prominent, we decided to put Amazon’s Alexa service to the test.  Using an Echo device, we were able to develop and test an Alexa Skill that can interact with Dynamics CRM using node.js.  The process was surprisingly easy as Amazon provides native OAuth configuration so we were able to connect to CRM’s Web API with little effort.

We recorded the whole process of building an Alexa Skill, check it out below!

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

Offload Processing with Azure Functions

Earlier this year, Microsoft announced Azure Functions which provide the ability to run code that can be triggered by events from within Azure or from third party systems or even scheduled at certain intervals.  There are many ways Azure Functions can be used to benefit your CRM system.  In this article, I will walk through how an Azure Function can be built and triggered from a plugin in CRM for asynchronous processing outside of the native CRM async service.

Note: Azure Functions are still in preview state and therefore provided “as-is” and may not be covered by customer support.

First, head to your Azure org and add a new resource.  Search for “Function App” in the filter.

image

Select Function App and click Create and then specify a unique name for your Function App and which resource group and plan to add it to.

In our scenario, we are going to trigger the function from a CRM plugin so we want to choose the “Webhook + API” scenario and I’ll be using C# for this example but JavaScript could be used as well if desired.

image

Now the Function App is created and a sample function is already setup with a Url that can be used to trigger the Function.  The sample Function looks for a “name” property in the request and returns a message back to the client application using the “name” property that was passed in.

image

With this basic sample, you could be good-to-go already, if you don’t need to interact back to CRM.  You could have your CRM plugin pass in the necessary data and let your Function do with what it needs, such as processing that data and then sending it off to a third-party system.

But what if you need to query CRM for more data or make some updates within CRM?  In order to do so, we need to do a little bit more work.

First, we’ll need to add some NuGet packages that our Function can reference to connect to the CRM API.  In order to do so, we need to add a project.json file to the Functions folder where it is hosted in Azure.

  • Click “Function app settings” at the bottom left of the Function app screen

image

  • Click “Go to App Service Settings” in the Advanced Settings at the very bottom of the screen

image

  • Under the “DEVELOPMENT TOOLS” section, click “App Service Editor”

image

  • Click “Go” on the next screen and it will open a new browser window
  • Expand your Function app node under the WWWROOT node then right-click and select “New File”

image

  • Type project.json for the file name
  • Update the project.json file with the following:

{
  "frameworks": {
    "net46":{
      "dependencies": {
        "Microsoft.CrmSdk.CoreAssemblies": "8.1.0.2",       
        "Microsoft.CrmSdk.XrmTooling.CoreAssembly": "8.1.0.2",
        "Microsoft.IdentityModel": "6.1.7600.16394",
        "Microsoft.IdentityModel.Clients.ActiveDirectory": "2.18.00"
      }
    }
   }
}

The necessary NuGet references for the CRM SDK are now added.  You can now either go back to the main Function app screen in Azure or just use the App Service Editor to edit the Function code in the run.csx file.  We will want to add the following namespaces to the top of the Function:

using System.Net;
using Microsoft.Crm.Sdk.Messages;
using Microsoft.Xrm.Tooling.Connector;

Now we can utilize the CRM SDK to connect to our CRM environment with a connection string like so:

var orgUrl = "https://org.crm.dynamics.com";
var username = user@domain.com;
var password = "password";
var authType = Microsoft.Xrm.Tooling.Connector.AuthenticationType.Office365;

var crmSvc = new CrmServiceClient($@"ServiceUri={orgUrl};AuthType={authType};UserName={username};Password={password}");

Now we can use the org service to do whatever we need within CRM.  For this basic sample, we’ll just do a simple WhoAmIRequest and log the result to the Function app console to make sure everything is working correctly.

var request = new WhoAmIRequest();
var response = (WhoAmIResponse)orgService.Execute(request);
log.Info(response.UserId.ToString());

The final Function should look like so:

using System.Net;
using Microsoft.Crm.Sdk.Messages;
using Microsoft.Xrm.Tooling.Connector;

public static void Run(HttpRequestMessage req, TraceWriter log)
{
    var orgUrl = "https://org.crm.dynamics.com";
    var username = "user@domain.com";
    var password = "password";
    var authType = Microsoft.Xrm.Tooling.Connector.AuthenticationType.Office365;

    var crmSvc = new CrmServiceClient($@"ServiceUri={orgUrl};AuthType={authType};UserName={username};Password={password}");

    var request = new WhoAmIRequest();
    var response = (WhoAmIResponse)crmSvc.Execute(request);
    log.Info(response.UserId.ToString());
}

 

Now click Run and in the Logs section you should see a Guid of your System User ID in between the Function started and Function completed statements.

image

You can then use a simple app like Postman to test submitting a request to the unique Url that Azure gave you for your Function app.  Once you submit the request, check your Logs in the Function app and you should see your System User ID logged again.

The last step would then be to build a standard CRM Plugin on the desired event and have it submit a request to your Function app Url to kick off the process.  Microsoft Flow could also be used to trigger an event from CRM and call your Function app without building any custom code at all.

There you have it, we can now utilize Azure Functions to free up some CRM processing but of course there are some caveats.

  • If you are on the “Dynamic” service plan, Azure Functions will currently only run for 5 minutes before timing out.  This still gives us 3 more minutes than an asynchronous plugin in CRM but be cautious of long running processes.
  • If an error occurs, there won’t be any ability to reprocess like there is with an asynchronous plugin in CRM.  You will need to build that into your Azure Function.
  • Lastly, Azure Functions aren’t free (they are cheap however).  If you have long running, memory intensive processes that will trigger often then you should consider the pricing.  Pricing details can be found here.  Microsoft gives 400,000 GB-s for free each month so if you have 1GB of memory allocated to your Function, it can run for 400,000 seconds per month without having to pay a single dime!
Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

CRMUG Summit 2016 Recap

Earlier this year, Microsoft announced that it’s Convergence conference would be replaced by Microsoft Envision.  Envision would be meant for business leaders looking for a more strategic vision, while  Microsoft Ignite would be intended to be the conference that provided more hands-on and deeper technical content.

CRMUG Summit, on the other hand, is a conference not run by Microsoft, and instead run by users for users.  However, what we’ve seen this year is that the Microsoft presence at the Summit was greatly increased from years past.  The Summit actually is meant for more than just Dynamics CRM as there are user groups for all of the Dynamics Products (AX, GP, NAV).

Image result for crmug summit

All In for Summit!

After attending both Ignite (in Atlanta) and CRMUG Summit (in Tampa) this year, it’s clear that Summit is getting more and more focus as the years go on, and seems to be the conference to attend if you’re a Dynamics CRM customer or prospect.  There were 1550 CRM attendees this year - triple the amount from last year.  At Ignite there weren’t as many Dynamics sessions, whereas CRMUG Summit was chock full of sessions led by end users, MVP’s, and Microsoft employees.  You could feel more than ever this year Microsoft’s increased presence and Tampa Florida skyline stock image for Tampa Uber promo code postcommitment to the event.  Jujhar Singh, Corporate Vice President at Microsoft, brought most of the product team along to the conference and was also a main presenter at the CRMUG Keynote.  Scott Guthrie, Executive Vice President at Microsoft, was also in attendance and led the overall Summit Keynote.  Scott’s keynote showed Microsoft’s large push for PowerApps, Flow, and their Azure framework.  He also talked about Dynamics 365, and the tighter and enhanced integration coming between Dynamics 365 and Office 365 such as Outlook.  Jujhar went deeper into discussions around Dynamics 365, and he also announced the integration between Dynamics 365 for Sales, and Predict by Versium (discussed in more details below).

It definitely seems like Microsoft is increasing their presence at Summit (as they did this year), and our hope is that this continues.  If so, we definitely recommend users attend Summit 2017 in Nashville.

Dynamics 365

Of course the big topic at CRMUG Summit 2016 was all around Dynamics 365, Microsoft’s suite of Dynamics products.  No more are the days of Dynamics CRM, but instead users will need to get used to the new moniker Dynamics 365 for Sales.  The different products that will be available with the upcoming release (slated to be released to the cloud in the next month) include:

  • Dynamics 365 for Sales
  • Dynamics 365 for Customer Service
  • Dynamics 365 for Field Service
  • Dynamics 365 for Project Service Automation
  • Dynamics 365 for Marketing
  • Dynamics 365 for Operations
  • Dynamics 365 for Financials
  • Dynamics 365 for Customer Insights

These products currently exist but are being entirely rebranded (e.g., “Dynamics CRM” becomes “Dynamics 365 for Sales” and “Dynamics AX” becomes “Dynamics 365 for Operations” and so on).  However, Dynamics 365 will allow users to quickly jump from one application to another within the same session, further unifying CRM and ERP capabilities.

Along with the new naming of the products and unification of Microsoft’s flagship CRM, ERP, and Office suites, the upcoming release also introduces other new features.  Stay tuned for future blog posts detailing more of these newly released features for Dynamics 365.  Until then, know that you can expect to see more around the user interface, configurability, built in intelligence, proactive insights, enhanced visualizations, enhanced Outlook integration, enhanced navigation, and much more.  Sounds pretty exciting, right?

Predict by Versium

During the conference, Microsoft announced a new integration with Versium Predict, an automated predictive analytics solution that brings lead scoring and lead matching directly to Dynamics 365 for Sales. 

With Predict, users can build a predictive model directly from CRM that will allow them to add insights to enrich current data in the system with thousands of new attributes (e.g., hobbies, SIC Code, revenue, social handles, number of employees, demographics, etc.) from Versium’s extensive data warehouse.  Versium has trillions of data points in their data set, and users will be able to build a customer-based model or a business-based model directly from Dynamics 365 for Sales.

After your predictive model is built, with Predict by Versium and Dynamics 365, users will also be able to build a new list of leads and add them to a new marketing list.  Note:  Microsoft strongly enforces the importance of having data already in Dynamics 365 (500 records for a business list model and 1000 for a customer list model) in order to build a successful predictive model.

Thanks Tampa – Hello Nashville!

Once again Tampa was a great host city for Summit (the 2013 Summit was also in Tampa).  The weather was great - even though the east coast had previously experienced some extreme weather the week before - and the conference content didn’t disappoint.  It would be an understatement to say all of us at Sonoma are excited about Dynamics 365 and the announcements from Summit, as well as new features that are coming with the latest release of the product.  We can’t wait.

Image result for nashville tennesseeIf you’ve never been to a CRMUG Summit, we definitely recommend you register for next year’s summit in Nashville.  If this year’s was any reflection of where the conference is headed, next year’s should be much bigger with more product announcements and roadmap discussions.  Each year, Summit has grown at exponential rates, and the involvement seen from Microsoft this year is certainly encouraging.  We’re hoping that they return in full force next year as well.

Stay tuned for more announcements about Dynamics 365 and the new features that will soon be released.

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

Dynamics CRM Performance Considerations

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

While working on a 2016 org upgrade from 2015, I was tasked with looking into a few performance issues that affected specific parts of the system, such as Connections and Activities. For Connections, the lookup to select the Connect To field took a very long time to load and would sometimes return a SQL time out error. For Activities, we were seeing long waits for quick find search results. While looking into these issues, we used both CRM and SQL Tracing, and we were able to identify a few problems that were easily fixed through native changes. These changes produced a dramatic improvement to the specific issue and the system as a whole. Some of these might seem obvious, but these can be good things to look for when you first come to an existing implementation.

Connections and Quick Find Views

First thing we noticed was that there were a bunch of Quick Find Query requests to pull in each entity listed as available to Connections. Microsoft does not provide a way to uncheck this availability, but we were able to identify a few unneeded custom entities, delete those entities, recreate them, and avoid the unneeded call to request for that data. The next piece we tackled was some of these Quick Find queries were taking a long time. After reviewing the Quick Find views, we found a lot of fields included as a part of the Quick Find. Each field that is selected can poetically create an index which should help searching, but what we found was that there were many fields of the same type being search on, like Owner, Regarding, and Modified By. This combination of fields to search on created a SQL statement that union 3 select statements to consolidate the results from the entity we were searching on, the users entity to cover the Modified By, Contact, and Accounts for the Regarding field. This union was not needed since we really did not need to have Modify By and Owner set to searchable by the Quick Find view. Once we removed all the unnecessary Quick Find fields, we had to wait a day or two for the indexes to clean themselves up, but we saw these long running queries go away. 

To edit the quick find view >>  

Permissions and Business Units

Next we found SQL statements that were joining to the POA table and looking at Business Units to identify whether the user querying this data has permission to the individual records. Once I saw this I found it odd since the client I was working with has a single Business Unit. After reviewing there custom roles, we found that a lot of their permissions were set to BU instead of Org level, but with the single BU they are in essence giving folks Org level access. Once we changed all the permissions from Business Unit to Org access, the union to the POA and BU tables were eliminated and the response time of those queries became very small. 

View security roles and privileges>>

New Call-to-action

Topics: 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

Learning Path - Dynamics CRM 2016 Guided Help

With the Spring 2016 release of Dynamics CRM came a guided user experience that provides context-sensitive and interactive tasks for end users to more easily become familiar with Dynamics CRM.  Remember, you can always review the features on the roadmap from this link.

What is it?

Learning Path, adds a new icon to the main navigation bar of CRM.  This conversation bubble with a question mark icon will appear in the top right corner of the CRM window if you have Learning Path enabled (see below for more information about turning this feature on or off).

Clicking on this Learning Path icon will slide out a pane on the right side of the CRM window that will allow users to do the following:

  • Learning Paths:  These are content areas where videos, text, guided tasks, and more.
  • Guided Tasks: These are step by step instructions that guide users through specific CRM tasks (see below)
  • Videos:  Learning path has full support for inline video within the pane that appears on the right
  • Navigation:  There’s the ability to navigate between pages of the Learning Path module using left / right arrows.  The user can also navigate to the home page by clicking the icon of the home.  And they can also “Send a Smile” or “Send a Frown” on any particular page of the Learning Path module

As users progress through Guided Tasks, their progression is saved and they’re able to see this in the learning path pane with a checkmark next to that specific task.

image

Guided Tasks

Guided Tasks are a way for users to learn an aspect of the CRM system, by doing it as areas of CRM are pointed out along the way.  As a user completes a guided task, a checkmark appears next to the task.  However the user can complete the task as many times as they’d like in case they’d want a refresher on how to complete something in CRM.

For example, if you clicked on the “Let’s go! Sales basic tour” you’d see the following set of steps in your guided task as it takes you around the basic aspects of sales within Dynamics CRM.

image

image

image

image

image

Enable or Disable Learning Path

Each user has the ability to disable Learning Path for themselves by clicking on the Options icon, and selecting Opt out of Learning Path or Opt in for Learning Path.

image

Alternatively, your system administrator can turn Learning Path on or off at an organization level by going to Settings –> Administration –> System Settings.  On the General tab, Set custom Help URL section, you can toggle the setting for Enable Learning Path.

image

Limitations

Since this is the first release of Learning Path, there are obviously some limitations.  First off, this is only available for CRM Online.  Like most features with Dynamics, features are released to the cloud first, and then as it makes sense, are released for CRM OnPremise.

Another limitation is that the usage metrics (who’s completed what guided task, when, and how many times) is currently not available.  This could be very useful for companies that are trying to gage user adoption, as well as training opportunities for loud users who complain they don’t know how to complete a specific task, but at the same time haven’t completed the guided task that shows them exactly how to do what they’re looking for.

Finally, Learning Path isn’t currently configurable.  This one probably hurts the most currently.  What you’ll get out of the box is predefined learning paths for onboarding, and for those who have spun up a CRM Trial instance, they’ll get learning paths around the trial and how to convert the trial into a purchase.  I see the first thing our clients will ask us as we show them this is how can we configure it, and unfortunately at the moment, the answer is you cannot.  Configuration and usage metrics are two areas that Microsoft will most likely be investing in as they build out this feature in the near future.

Topics: Microsoft Dynamics CRM 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