Tip #965: Pass Parameters to Quick Create Form

If additional initialization logic is required when a form is opened, Dynamics 365 offers a choice between setting default field values (easy) and configuring custom parameters (not as easy but straightforward).

Quick forms also take parameters when opened. But, as Daryl “Always Raising” LaBar has discovered, sometimes it just does not work.

Short version: If you’re adding form parameters to a quick create form, always remember to add them to the default form as well, even if it “works” on your machine.

Long version: Go and read Daryl’s adventures in the local storage, if you feel like reading about a good lesson in investigative development.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #964: Use latest language features

I often find that developers like comfort zones. They tend to use the constructs that they already know and are comfortable with. That includes language features as well. However, programming languages are evolving all the time and new features are introduced with every new release. Those features aren’t just cool, they make developer’s life much easier in a lot of cases.

One of my favorites is interpolated strings, introduced almost 3 years ago in C# 6.0. Instead of:

Trace.WriteLine(string.Format(
  "Name is {0} {1}", c.firstname, c.lastname));

you can now write:

Trace.WriteLine(
  $"Name is {c.firstname} {c.lastname}");

(Did I also tell you to stop using Console.WriteLine and start using Trace.WriteLine instead? No? That’d be the tip for another day then)

The way I see it, not only this new syntax allows for cleaner and more concise code, it implictly adds value to everything you create by sprinkling your code with dollar signs.

Of course, there are a lot more goodies in version 6.0 than just interpolated strings. There are null-conditional operators, exception filters, index initializers, to name but a few.

And don’t forget C# version 7 either, with out parameters, pattern matching, is-expressions, tuple types and literals, deconstruction, and many others. Like, how cool is this:

(string, string) LookupName(Guid id)
{
  // ... get those names
    return (first, last);
}

Languages evolve and so should your knowledge of them. So, what’s your favorite feature?

Share on FacebookTweet about this on TwitterShare on Google+

Tip #963: Minimum portal licensing requirements

Only someone as thorough as Feridun “Best Twitter Handle for CRM MVP” Kadir would spend their time analysing changes in the new (July 2017) edition of Dynamics 365 Enterprise edition Licensing Guide. As it turned out, it was a very good idea.

Until now, one could purchase just a single Team Member license, and get themselves a Dynamics 365 instance, a sandbox, and a portal merely for $10. Well, not anymore. Straight from the document, broken down to the separate bullet points:

  • Starting August 1st, 2017, access to the first included portal for the tenant, customers will be required to purchase a minimum of 5 Full User licenses of Dynamics 365 Customer Engagement Plan, standalone Dynamics 365 Applications (Sales, Customer Service, Field Service or Project Service Automation) or a combination.
  • Existing customers will not be impacted with this change until renewal.
  • New customers who need to purchase less than 5 users, may purchase the Portal “Add-on”.
  • Team Member Licenses will not contribute to the minimum user requirement

In other words: if you were legitimately using single team member license to get the portal, you are good until the next renewal, at which time you’d have to buy either portal add-on, of 5 full user licenses.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #962: Microsoft Portals Source Code Is Available

After a very short private preview program, Microsoft has just made the source code for the Dynamics 365 Portals available on the Microsoft Download Center. We’ve already reviewed the topic on the podcast but this milestone is quite significant to deserve another discussion.

tl;dr

One-off release of portal source code is available for download. If you’d like to contribute, head off to the community edition. If you crave some official training, Dynamics Learning Portal is the place.

What

It’s the full source code of the Microsoft Portals version 8.3 as of July 2017, released under MIT license. The downloads contains:

  • Microsoft Portals solutions. Portals run entirely “off” the Dynamics 365 Customer Engagement deployment and will need a number of solutions installed in your organization instance.
  • The source code. Visual Studio solution, some libraries that couldn’t be added via nuget, some docs and samples.
  • The deployment instructions for the source code.

The drop comes with some strings attached:

  • It’s unsupported. Do not call Microsoft if your code does not compile or if it’s just wiped out your entire Dynamics 365 instance.
  • It’s a one time release. Do not expect Microsoft to maintain this code or release any future versions of it.
  • Portal solutions distributed as part of the release are managed. The solutions are not just web resources and schema changes, there are also plugins and workflow custom actions that do not have the source code included. I’m not quite sure what to make out of it yet and how does it impact future compatibility.

Who

I can think of quite a few audiences who would benefit from the code release:

  • Existing customers who use Adxstudio 7.0 or prior versions. These were left in limbo when Microsoft cut off all future developments of that “branch” and imposed some restrictions on Adxstudio portals support.
  • Dynamics 365 customers with unique portal requirements that cannot be satisfied by the Microsoft version. Think integrations with third-parties, payment gateways, micro services.
  • Customers in the restricted environments with the stern security demands making it impossible to go with either Dynamics 365 Online or Microsoft portals.
  • ISVs who can offer additional value with custom components.
  • VARs who can no longer feel restrained when discussing solution architectures and portal opportunities with their prospects and customers.
  • Consultants who can now offer migration, support, and training services around rejuvenated portal community.
  • Microsoft Azure accounting team raking in fees from the cloud deployments of the private portals.
  • Curious developers who would like to peek “under the hood”. Portal source code is a great research resource to see how things should be done. And how they shouldn’t be done.
  • Curious developers who graduated from “peeking” to contributing to the open source. Great opportunity to take part in the community efforts.
  • Commercial water cooler suppliers, soft drinks vendors, and local pizza joints who would benefit from the increased consumption by the developers engaged in the heated discussions while consuming obscene quantities of the said beverages and pepperoni slices.

Why

First of all, kudos to the portal team because it’s hard to underestimate the skills required to navigate both the technical and legal complexities of the public source code release at Microsoft, even for the company routinely releasing the entire .NET as an open source. Heck, we are still waiting for the open source version of the Microsoft Dynamics 365 Developer Toolkit so that we can make it work with the latest two releases of Visual Studio.

We probably will never know the full story behind this one-off release but I couldn’t resist the opportunity to speculate.

Hosted-only shared portal model comes with some incredible challenges to provide a solid extensibility model, both flexible and safe. There are many obstacles and challenges including technical – what extensibility model to offer and how to package the extensions, devops – how to provide the private deployment facilities while maintaining SLAs for everyone, security – how to guarantee safety in the shared environment, support – how to provide for generic baseline support with tons of custom code deployed, and legal – how to address concerns of corporate customers around arbitrary code deployment and execution without opting for the revenue killing “one customer – one enviroment” model?

Add to that the exciting but turbulent times for Dynamics 365 platform with so many new features, capabilities, and requirements. The last thing we’d want is a solution rushed through just to appease some customers and then deprecated and killed couple years later because it was poorely thought through, turned out to be utterly uncompetitive, useless, and generally dead on arrival. Dynamics-cough-Marketing.

The entire Dynamics 365 ecosystem has been evolving as a rapid release environment which routinely takes away one of the most precious resources – time.

With the source code release, the portal team bought some time to properly design a sustainable extensibility model

Microsoft was also risking a revolt in the existing customer base of Adxstudio 7.0 portals, who has just until recently paid over $10K for the portal license. These customers havw invested a lot of money and resources into extending and developing their portals and wanted some clear upgrade path that would see them moving forward. With the source code release Microsoft has shifted the responsibility of upgrading and maintaining the existing Adxstudio portals to the customers.

Did Microsoft just wash their hands on Adxstudio customers with the source code release?

First of all, Adxstudio version 7.0.0018 or higher is still supported (read the article to understand the preconditions and the channels). And let’s be honest, customers and consultants who heavily customised the portals have always had sufficient skills and resources to deliver those customizations and, by proxy, to maintain the code base. Calling support in the environments with the mix of Microsoft and proprietary source code has always been a challenging exercise with volatile results.

Larger organizations have always been more or less self-sufficient when it comes to the portal extensions. Code release simply extends these capabilities without placing Microsoft in awkward position of eternally supporting legacy products by the virtue of sitting on the compiled code base without a suitable license model.

As I mentioned before, the situations is less clear about the extensions that are part of managed portal solutions, how complex is the functionality delivered by the plugins, is it critical or not, and whether it’d be feasible and permissible to replicate it [in the open source] – I’m sure these questions will be answered in due course.

Licensing

Source code itself and a number of accompanying libraries is released under MIT license which is arguably one of the most permissive open source licenses. Do what you want with it, in other words.

Some of the included packages use different licenses, BSD, Apache, and Microsoft’s own Public License (Ms-PL). Pay attention to those, especially if you are in the corporate land or if you plan to release commercial products based on or around the released source code.

Call to action

Download, read instructions, play with it, and send your tips to jar@crmtipoftheday.com.

As far as source code is concerned, Adoxio, the phoenix business after the Microsoft’s acquisition of Adxstudio, has already put their hand up as a custodian of the publicly available source code, a.k.a. xRM Portals Community Edition.

Some may object but let’s be honest, with their expertise Adoxio is in a unique position to both ensure reasonable quality of the code and provide ongoing enhancements contributed by the community and Adoxio themselves. I do hope that one of the first developments will be a clear migration path for Adxstudio 7.0 owners to the whatever version we now have as open source. If you would like to contribute, go ahead, fork the project, do you craft and then submit a pull request.

Last but not least, if you would like to get up to speed with the portal extensibility using that source code (and portals in general), check out Dynamics Learning Portal for the upcoming Develop Dynamics 365 Portals courses. The curriculum is currently being updated to include self-deployment and extensibility scenarios, with new coding exercises to keep your brains busy and your hands dirty. First in-person class will be in New Zealand in October. If you cannot make it down under or prefer to get some portal wisdom in your pyjamas, virtual deliveries will start in November in PDT and HKT timezones.

If you can’t wait that long, teach yourself, listen to the community, organize your private training, or attend one of the portal training classes during D365UG Summit or eXtreme365 (details TBD for that one).

Share on FacebookTweet about this on TwitterShare on Google+

Tip #961: When you want Resco

I’m a big fan of the Dynamics 365 mobile apps. I’ve written a book about it, I present CRMUG summit sessions about it, and I fight the misguided app reviewers about it. However, there are several scenarios where it may not be the best fit, and a good third party mobile app (like Resco) is a better choice.

The following are some of the primary scenarios where Resco may be a better fit than the standard Dynamics 365 mobile app:

  • You want a different form for mobile. Dynamics 365 mobile is based on the strategy “design once, deploy anywhere.” This means that users on mobile see the same form that users in the web client see. There is not a “mobile only” form (the one you see that says “mobile” is for the old Mobile Express). For many users, this works great, but in some scenarios, having a form that is radically different on mobile makes sense.
  • You are on premises but don’t want to turn on ADFS. Dynamics 365 mobile assumes that you are running claims based authentication with IFD. If you can’t get your information security team to approve ADFS, Resco is an option to have mobile CRM without IFD.
  • You want to use entities that are not available on Dynamics 365 mobile. As we have covered in numerous tips, the list of system entities that are not available on mobile has shrunk in recent years, but if you have to have campaigns, campaign responses, letters, or some of the other entities that don’t work on Dynamics 365 mobile, Resco is a great option. It can even send email activities directly from the app.
  • You want document integration from mobile but don’t yet have server-side SharePoint. As we have covered here, the client-side SharePoint grid control is deprecated in version 9, but say you still have SharePoint 2010 integrated with CRM 2016? The only option to see documents in Dynamics 365 mobile is server-side SharePoint integration, which requires SharePoint 2013 or later. Instead of waiting until SharePoint is upgraded to see documents on mobile, Resco can work with the grid control based SharePoint document integration and display CRM documents in mobile.
  • Mobile mapping: Bing maps are available with the Windows version of Dynamics 365 mobile; however, you do not have maps with the iOS or Android versions of the standard Dynamics 365 mobile apps. Resco includes mapping on all versions, and it integrates with the device GPS and geocoding (lat/long) on records to not only display the address of a record, but also show the location of the user/device. So it not only can show you where a customer is, but also help you get there.

What’s the point?

The point is not Dynamics mobile bad, Resco good. Dynamics 365 mobile provides a very fully featured experience that will meet the needs of many Dynamics users. But my motto is “use the right tool for the job.” Keep in mind that it’s not either/or. You can easily have some users using standard Dynamics 365 mobile while others are using Resco.

What do you think? Leave a comment letting us know what you use, and why.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #960: If your FetchXML-based report preview is not working

You are writing a FetchXML based custom SSRS report . When you click the “preview” tab in SQL data tools, the report runs without error, but does not display correctly. Maybe there are records missing, or you enter a parameter value that should return data, and it does not display any results. Is your report wrong? Are you crazy?

Report

The answer is maybe, but probably not. You are likely running into what almost every FetchXML report author has experienced from time to time–when you preview a report in SQL data tools, the Report Authoring Extensions only retrieve the first 250 records. So if you select a parameter value that doesn’t have any results in the first 250 rows, your report will not display any data.

That’s why the first rule of FetchXML SSRS Report test club is

Test the report in CRM, not in Visual Studio

(Rule number two is move to a more powerful reporting platform like Power BI).

Share on FacebookTweet about this on TwitterShare on Google+

Tip #959: Getting ready for D365 v9: Learn Microsoft Flow

So you have probably heard the news that Microsoft Flow is going to be integrated in Dynamics 365 v.9, allowing Flow to be managed and run directly from the Dynamics 365 menu.

But maybe you haven’t paid much attention to Flow (not even Tip 880), but now that it is going to be “in” CRM, you want to start learning more about it and how you might use it. But where do you start?

  • Start with this post from the Microsoft Flow team. It does a good job of succinctly describing the primary Dynamics 365 triggers and actions, and shows examples.
  • Sign up for Microsoft Flow at flow.microsoft.com.  If you don’t already have a license, you can sign up for the free version (which has limitations) or you can sign up for a 90-day trial.
  • Once you sign in to Flow, click “connectors” and scroll down to “all connectors” and click on Dynamics 365. Under the description of Dynamics 365, you will see a link to see documentation. This will give you documentation for the triggers and actions available for the Dynamics 365 connector.

  • Look at the templates. There are dozens of great templates for common Dynamics Flows that you can use as a starting point. Things like synchronizing records between Dynamics 365 Customer Engagement and operations, creating records like cases based on social media posts, adding records to Dynamics from a spreadhseet, and more. Even if these aren’t exactly what you are looking for, they can give you great examples of how to build Dynamics Flows, and you may be able to find one that is close and make some minor modifications rather than starting from scratch.
  • Learn the plans. There are several different Flow plans, and pricing differs based on number of executions per month, frequency of execution, and connectors needed. As you think through how Flow will be used in your Dynamics 365 deployment, consider what the expected volume will be to determine the associated cost.

Bonus tip: When you get deep into Flow, you will likely want to filter a list of Dynamics records to be updated or deleted by a Flow, and you will want to use an odata query. But if you are not a developer that speaks odata, the good news is there is a tool for that (actually several).

One such tool is Jason Lattimer’s Rest Builder.

 

*note the original post suggested the XRM Toolbox FetchXML Builder, however, Daryl LaBar reminded me that tool is now deprecated.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #958: Segmented solutions and lookup fields

Dynamics CRM 2016 or later allows configurators to build segmented solutions that only include the fields, views, and entity components necessary, rather than adding the entire entity to the solution.

Be aware that if you add a lookup field to your solution that references an entity that is not already part of the solution, Dynamics will automatically add the entire lookup entity to the solution. This will make your solution not so skinny.

The recommended best practice to avoid this from happening is to first add the lookup entity to your solution, without all of its baggage, then create your lookup field.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #957: Configurator’s Dilemma Revisited

Last week I was in a discussion with a colleague and the topic of whether or not he should re purpose the opportunity entity came up. He had a scenario that was somewhat similar to opportunities, but was not a sales opportunity. This lead me to rediscover a blog post I wrote 8 years ago for the Dynamics team blog called The CRM Configurator’s Dilemma to answer the question “should you re-purpose system entities or create new entities?”

My advice from the post, with updated comments:

  1. Consider the future

Still valid, even more so. The future of Dynamics is moving much faster than it was back then, using entities in non standard ways can cause problems if Microsoft makes changes to the entity that you are using. Also, if you choose to re-purpose a little uses system entity like contracts, there is a good chance that Microsoft will elect to deprecate that entity in the future. Custom entities don’t get deprecated.

2. Consider the overhead

When I wrote the original post, there were a number of system entities that had certain fields that could not be removed from the forms. This has changed somewhat as system entities have been refreshed and modernized, but there are still fields on entities like opportunity, case, and campaign that cannot be removed from the form. 

3. Consider the user experience

This still applies–if your use case is less that 50% in line with the standard entity functionality, a custom entity will typically give users a more simple user experience than scaling down a more complex system entity. Plus we now have the ability to add business process flows to any entity, including custom entities, which can easily make a custom entity use experience as good or better than re-purposing a system entity.

Final thoughts

The advice 8 years later is still the same–don’t re-purpose system entities. There is even less reason to do so now–one of the biggest reasons that configurators 10 years ago would re-purpose system entities was activities–users wanted an activity type that wasn’t a fax, email, appointment, or task, so the configurator would grab one that wasn’t being used and re-purpose it. Now we have custom activity entities, this is no longer necessary.

 

Share on FacebookTweet about this on TwitterShare on Google+

Tip #956: Encryption error when configuring Dynamics 365 for Outlook

You try to configure Dynamics 365 for Outlook (legacy Outlook Client) against a sandbox organization that has been copied from production, but when you do, you get an encryption error.

This error can be caused by restoring a copy of a production environment that has data encryption enabled and not restoring the encryption key. If your production environment still exists, in Production go to Settings | Data Management | Data Encryption and show the key.  Copy it.

Then in the sandbox organization, go to the same location and paste that key into the activate box.

In case you no longer have the original organization, follow the instructions in Tip 243 to wipe out the encrypted fields.

Share on FacebookTweet about this on TwitterShare on Google+