Tip #1182: The Tool Every Developer Needs (Even The Ones Who Don’t Use Code)

Whether your weapons are JavaScript and Plugins, or Processes and Flows,  there is a tool you should pick up before going anywhere near the keyboard. That is, of course, the pen.

This is a lesson I learned while at university with my computing lecturer insisting we write out our code before committing it to the screen. Our major assignment was to code a token ring network controller. It might have been tough to write out every line of Pascal to make it work but when I finally entered it into the computer, the entire thing was bug free. The time taken to write it out and think it through calmly and carefully paid dividends in not having to debug my otherwise incoherent, spaghetti code.

While I do not write every Workflow out in full before logging in to Dynamics, for the more complex ones there is a lot to be said for organising your thoughts on paper first. My general rule of thumb is if I cannot contain whatever it is I am developing on the screen (almost impossible for all but the most simple Flows), I write it out first. By going to a high level pseudo-version, I can see the algorithm on one page and usually improve my vision or discover issues which may not have been as visible in the weeds.

Often coders will lament that their non-coding associates do not have good habits when developing. For me this is the first good habit of any developer. The pen is mightier than the DWORD.

Tip #1181: Filtered lookups on editable grids

Today’s tip is from Nick “Benchpress” Doelman. Technically it’s from his wife which proves that all of us, MVPs, are mere mortals and the real knowledge still belongs to the users.

She only wanted to see contacts that belonged to an account on the record but the lookup view was showing all the contacts. Turns out, the editable grid lookup will only filter if the ‘filter by’ field is also on the view. For instance:

  1. Without the “Account” being visible on the editable grid view:
    clip_image001
  2. Now with the “Account” being added to the editable grid view:
    clip_image002

Don’t have a tip but your spouse works with Dynamics? Ask them and send the tip to jar@crmtipoftheday.com!

(Facebook and Twitter cover photo by Tyler Nix on Unsplash)

Tip #1180: Rejiggering the Outlook App

I dedicate today’s tip to Steve Mordue, who asked me how to do this.

Let’s say you have the Dynamics 365 App for Outlook configured against D365 instance A, but you are moving instances and want to use it with instance B.

  1. Log in to https://outlook.office365.com/owa/
  2. Click the settings gear in the upper right corner
  3. Select Manage Add-Ins
  4. Select “My Add-Ins”
  5. Tap the … on the Dynamics 365 Custom Add-In tile
  6. Select “Remove” 
  7. Install the Outlook app from Dynamics 365 instance B

 

Tip #1179: Add a dash of dash to your autonumbering

&tl;dr

Jonas “The Shuffler” Rapp reports: when modifying autonumbering for built-in entities like case, always include a dash in the pattern to stop Dynamics 365 from self-combusting.

Long story

One of the awesome users of the Auto Number Manager for XrmToolBox managed to break the system settings for Auto Numbers in Dynamics 365, so he called me up to see if I could find the problem.

clip_image001

The Auto Number Format of the Case Number (ticketnumber) attribute on the Case (incident) entity had been changed from the default value:

CAS-{SEQNUM:5}-{RANDSTRING:6}

To a custom format:

CASE{SEQNUM:7}

And now it was no longer possible to open the Auto-Numbering dialog in Dynamics 365.

I see four potential problems here:

  1. The prefix is four characters – will that fit?
  2. There is no dash between prefix and number
  3. The number is seven digits long
  4. There is no random string at the end

After some investigation using the number one troubleshooting methodology –  some simple trial-and-error – I came to some conclusions:

  1. Prefix may be even longer than that, I tried with CASENUMBER and that worked fine too
  2. Skipping the dash makes the dialog explode like above
  3. Seven digits works fine, even though the UI in the dialog will only show 6, there is no 7 available
  4. Works fine without random string, but in the dialog it still looks like it has the random suffix

clip_image002

So make sure you keep a DASH between your prefix and number when you are changing Auto Number Format for out of the box number attributes!

Happy numbering!

Tip #1178: Pure Unified Interface trials

I guess it was only the matter of time until Unified Interface started to take over. And so it begins with the changes coming to the trial experience that will let the customers experience and evaluate their workloads purely on Unified Interface.

Summary of experience enhancements are as follows. For more details, please refer to the original blog article.

  • Users will now land on the app selection page when they sign in instead of the legacy web client application and this page will showcase applicable app modules to the user.
  • When creating a new app module, you will only have the option to do so based on the Unified Interface. You will no longer be able to create new app module based on legacy experience.
  • If you have an existing legacy web app module, you will be able to run, edit and convert it to Unified Interface. Note: App modules converted to Unified Interface cannot be rolled back to the legacy web client experience.
  • The “Dynamics 365 – Custom” app that provided access to the full legacy web client sitemap will no longer be available to users or admins. The runtime will only be available through app experiences.
  • Admin sitemap and experience is still exposed in the legacy web client and can be accessed from the gear icon on the apps selection page or from within an app module by clicking on Advanced Settings. This will open another browser tab and direct you to the settings page.

These changes will be available in all regions in the next 2-3 weeks. Please note that this will not impact any existing customers.

(Facebook and Twitter cover photo by rawpixel on Unsplash)

Tip #1177: Use the CDS connector when you go with the flow

MVP Elaiza Benitez gave me some very helpful advice when it comes to Microsoft Flow:

If you want to filter Dynamics 365 records to only records that you create in your flow, you should use the CDS when a record is created (preview) trigger, not the Dynamics 365 trigger. If you use the CDS trigger, you can set the scope to “User.” This way the Flow will only execute if you create the record. This makes flow more consistent with how Dynamics 365 Workflow works, and vastly simplifies Tip 835.

For more details on how to use scope in your flow, check out episode 1 of Elaiza’s fantastic vlog series WTF.

YouTube player

 

Tip #1176: Handling the Primary Field

Sometimes inspiration comes from unlikely sources. In this case it was not having written a tip for a few weeks and knowing George would meter out Spießrutenlaufen if I did not post soon. Thoughts of such things give one time to reflect and so I am going back to basics and addressing one of the great mysteries of Dynamics: the Primary Field.

Surprisingly, the TOTD crew have never tackled this one, other than as a step in Tip 646 but we are all familiar with its ways. If you are not familiar, the Primary Field is a text field created automatically whenever you create a new entity. Why it is necessary to create a default text field whenever we create a new entity? An excellent question and one that will not be answered as part of this Tip. No one knows. I can confirm that this behaviour has been there since the beginning, back when the product was known as Microsoft CRM. However, like decaffeinated coffee, the reason for its existence is a mystery.

By default the name of the Primary Field is ‘<prefix>_name’ with a display name of ‘Name’. If this name is not appropriate, as per Tip 646, change it, ideally before saving the entity, otherwise, like all saved fields, you are stuck with the system name. You can always edit the display name by finding the field in the entity’s field list and modifying it like any other field. However, you cannot modify it through the Primary Field tab of the entity’s Information screen. That would be too easy.

Where possible, try to work the Primary Field into your list of fields for the entity but make sure it is a field which will be populated each time a new record is created and is generally unique for each record. If there is no text field which fits the bill you are better off making it non-compulsory and hiding it/removing it from the form. To make it non-compulsory, edit it through the fields list. The next question is whether you should auto-populate this field if you have removed it from the form and made it optional.

In my opinion, the answer is “usually yes”. The problem we have is if another record has a lookup to this entity, the value displayed in the lookup field is the Primary Field. We cannot change this so if we leave it blank, even if our lookup is pointing to a valid record, if the Primary Field is blank we will not readily know it. I am pretty old school in populating it and just use a workflow but there are so many ways to populate a field with a default value these days, take your pick. If there is no obvious role for the Primary Field for the entity, create a short description field for the record by concatenating key field values. Your lookups will thank you for it.

 

Tip #1175: CDS and data object prefix

Recently we interviewed Evan Chaki, Principal Program Manager for PowerApp and D365 maker experience on CRM Audio. In the conversation, we discussed the dual maker experiences–configuring model-driven apps via web.powerapps.com or via D365 solutions and App Designer. To the question of which maker experience that D365 configurators should use, Evan said that there wasn’t a wrong answer, and that if you are used to the D365 configuration experience or use solutions, you should continue to design your model driven apps that way.

In a comment on the episode, Rob Dawson mentioned:

If you care about the prefix of the model-driven app you need to still create it from the classic solution though. How long before we get to create from within web.powerapps and pick the solution to add it to, not just it being added by to the CDS Default Solution by default?

You actually can change the prefix used by CDS/PowerApps when creating new database objects. In Dynamics 365, go to Settings>Customizations>Publishers and open the CDS Default Publisher record.

Update the prefix to the desired prefix. Now entities and fields added via CDS/PowerApps will have the desired prefix.

Regarding Rob’s point about model driven apps being added to a solution, it is a valid point, and we expect the maker experiences to become more unified in the future. For now, if you want to create your apps via web.powerapps.com and still use solutions, the recommendation is to create a new solution and add the app module to the solution in D365.

(Facebook and Twitter cover photo by Antonio Barroro on Unsplash)

Tip #1174: Create dead souls

After a short unplanned break we are back! For the past three weeks we’ve been travelling and taking part in Ignite, crafting and teaching BAD Masterclass, and preparing for CRMUG Summit which did leave us with a choice to either breathe or publish CRM Tip of the Day. Good news is that we survived and stashed some juicy tips waiting to be shared. Now, to the tip.

Frequently during the data import we need to preserve historical ownership of the data. Dynamics 365 Online does not allow creating user records in UI. Adding users in Office 365 portal, assigning Dynamics license, and then deleting the users is the only interactive way to create disabled user accounts.

It is possible to create disabled users by importing CSV file, but on odd occasion programmatic creation is required. Challenge is/was to come up with an absolute minimal set of fields required to create a “dead soul”. Here we go:

var user = new Entity("systemuser");
user["firstname"] = "test";
user["lastname"] = "testroni";
user["internalemailaddress"] = "test@samples.com";
user["businessunitid"] = 
    new EntityReference("businessunit", 
    new Guid("deadbeef-0aad-e711-a96d-000d3bb10143"));
user["windowsliveid"] = "test@sample.com";
var userid = service.Create(user);

Similar code can be used in PowerShell, JavaScript or any other language of your choice.

(Facebook and Twitter cover photo by NeONBRAND on Unsplash)

Tip #1173: Who needs VBA? Skype for Business, that’s who!

This post has soooo nothing to do with Dynamics, it’s not even funny. You know what else is less funny than not funny? When you have 20 minutes before an important Skype for Business session where you’re presenting but any attempt to upload the presentation is met with this:

image

In case the picture is too small or you’re not allowed to look at the pictures at your workplace:

Skype for business pptx couldn’t be converted for sharing because Visual Basic for Applications is not installed on this computer

Visual Basic for Applications?! Why?!

Oh well, I’ll just rerun the installer, check the box for VBA and be…. wait a minute, I installed Office 365 using click-to-run from www.office.com. When you do that (as opposed to msi-based installers), you don’t get a choice of, well, anything.

Here is the good news: VBA is actually installed. Here’s the bad news: Skype for Business does not believe you. And here’s the workaround:

  1. Start PowerPoint
  2. Click File > Options > Customize Ribbon
  3. Scroll down in the right-hand window and check Developer tab
  4. Ok
  5. Exit PowerPoint
  6. Upload your deck to Skype for Business.

In your face, S4B! Still angry though. It’s 2018, people, who the heck uses VBA?

(Facebook and Twitter cover photo by mwangi gatheca on Unsplash)