Tip #1371: i18n of the links

Today’s tip has nothing to do with Power <insert noun here>. Not because I have nothing to talk about but because I feel strongly about today’s subject.

tl;dr

When sharing a link, remove en-us from the URL.

What are you talking about?

We all consume and produce a fair amount of the computer-related material. Being good netizens, we link to the works of others. Sometimes that work of others live on multilingual sites, like Microsoft.

If your audience read you in English because that’s the language you write in, that’s not the reason not to refer to the documentation, if available, in the reader’s preferred linqua. Consider, for example, Power Apps pricing page. You searched for it, you found it, copied and pasted URL, done. Hold on for just one second. The URL you just copied would be something like https://powerapps.microsoft.com/en-us/pricing/. Just remove the en-us part, will you? Make it https://powerapps.microsoft.com/pricing/.

What’s the difference? If I set my browser’s language preference to Spanish then, instead of US pricing, the second link will redirect me to:

Russian is close to my heart? Нет проблем!

Be a good netizen and craft your URLs. Your readers will appreciate the effort.

Cover image by Transparent 6lue / Public domain.

Tip #1370: Handle RemoteExecutionObject in Power Automate

When we talked about triggering Power Automate on Associate/Disassociate, I did set aside the task of “dealing with horrendous serialization”. Short version: it’s a RemoteExecutionObject that is serialized in the message and every DataCollection property is serialized as an array of objects with the key and value properties. 

"InputParameters": [
{
  "key": "Target",
  "value": { 
    ...
    "LogicalName": "adx_webrole"
  }
},
{
  "key": "Relationship",
  "value": { 
    ...
    "SchemaName": "adx_webrole_contact"
  }
}

Fair enough. But in the jsonified world of Power Automate, it would’ve been nice to see it as { “key”:”value” } object instead:

"InputParameters": {
  "Target": {
    ...
    "LogicalName": "adx_webrole"
  },
  "Relationship": {
    ...
    "SchemaName": "adx_webrole_contact"
  }
}

Let’s say we want to extract SchemaName of the relationship. What are our options?

Someone suggested iterating over the InputParameters array until Relationship key is found and then extract the value and the property. It will work and will be very readable but bleugh! Here is not one but two methods to achieve the same.

Continue reading →

Tip #1369: New user cannot see environment

I recently saw the following scenario in several environments:

  • New user added and license for Dynamics 365 or Power Apps assigned
  • User granted security role in an environment
  • User can only see default environment when going to make.powerapps.com or power platform admin center, but they see all environments at Power Automate.

The reason for this that I heard from multiple people is “it’s some kind of caching.” It isn’t browser caching, because trying different computers and browsers, the experience is the same. So it may be some caching in the maker portal.

The solution we discovered was that if you have someone with access to the environment share a canvas app in the environment with the user and have the user run the app one time.

After that the user will now see the environment, both in maker portal and the admin portal.

The Camouflage of an Eastern Bearded Dragon (Pogona barbata) blends almost perfectly with its environment in our cover photo courtesy Andrew Mercer / CC BY-SA

Tip #1368: Missing a flow?

Today’s tip is from Rilsina Pegado. Got a tip of your own? Send it to jar@crmtipoftheday.com.

If you happen to face a situation where your flows are not visible after signing into https://flow.microsoft.com/ > My Flows or by checking default solution with global admin login. Or if you removed flow from the solution and need to find it later…

Go to Admin center > Select your environment > Resources > Flows.

Cover photo by Humphrey Bolton / Invisible stream, Cracoe

Tip #1367: Tell apart create, update, and delete events

It’s not every day one gets to chime in on a post from Jerry, the lifetime tipster and Power Automate connoisseur. In this post Jerry talks about When a record is created, updated, or deleted trigger in CDS (current environment) connector and how to tell the event that triggered the flow using a clever combination of checks on Modified On and Created On attributes.

I think there is a not necessarily better but certainly a simpler way to achieve the same.

Continue reading →

Tip #1366: Make file type field required

We recently got a great new field type in CDS called the file type field. This allows creation of fields that contain files, and it is very useful for scenarios like the following:

  • Order needs to have a copy of the purchase order before the order can proceed
  • application must include a copy of applicant’s driver’s license

In the past our only options were to put the file in attachments or Sharepoint, both of which are 1:N file storage mechanisms. So while we could handle files, we couldn’t dependably verify that a specific file had been supplied.

With the file field I can tell that a file has been added if the “purchase order” or “driver’s license” field contains data. Super.

But how do I make the field required? None of the normal requirement tools can work with file fields. This is likely due to the file being stored in Azure Blob. You can’t require it at the field level, and you cannot require it with a business rule, and you cannot check if it contains data via workflow.

Use business process flow

In most cases like I listed above, the file is required before reaching a specific stage in the process. Use business process flow and make the field required in the process flow. This makes the field required before changing stages or completing the process, but doesn’t make the field required to create or update the form.

Cover photo Nora Belrose / CC BY-SA

Tip #1365: Dynamics 365 App for Outlook checker

Checkers are everywhere. It used to be a game immortalized for me by Segura and Wormold in Our Man in Havana. Nowadays it’s ubiquitous software that just keeps poking their nose into the intricate world of citizenmanship. We have Power Apps checker, Flow checker, Solution checker, Portal checker, Power BI checker (phew, got carried away a bit).

If that wasn’t enough, Amey Holden reports from the field there is a new kid on the block. (While we’re at it, send your tips to jar@crmtipoftheday.com).

Troubleshooting issues with Dynamics 365 App for Outlook just got a little easier. Fire up the app in your outlook and hit Ctrl+Alt+Y to fire up the App for Outlook Checker which gives you a head of useful diagnostic information, handy links for errors plus the ability to export error logs and also clear the apps local cache.

Cover image is a scene from Our Man in Havana adaptation of the Greene’s novel.

Tip #1364: Customizing opportunity close status reasons

So you followed tip 1290 and you customized your opportunity close form. Great! But now that you did that, users don’t see all of the win/lose status reasons to select when closing the opportunity. What’s up with that?

First thing to remember is that the custom opportunity close is a quick create form for a different entity called Opportunity Close. If you make changes to the status reasons of opportunity, opportunity close doesn’t automatically know about them.

The way to inform opportunity close of your customized status reasons is to add them (including the same option set value) to the opportunitystatuscode field on opportunity close. If the values of status reason from opportunity are in the opportunity close opportunitystatuscode field, users closing an opportunity using the custom opportunity close field will see the correct options.

Cover image Pye Records / Public domain

Tip #1362: Trigger Power Automate on Associate / Disassociate

Many to many relationships are everywhere, from good old marketing lists to web roles in Power Apps portals. The secret sauce is in the little hidden intersect entity holding the relationship together, those of you who used FetchXml Builder from XrmToolBox to craft a query, are very familiar with. The messages to control the relationship are appropriately named Tweedledum and Tweedledee Associate and Disassociate.

Wouldn’t that be nice to be able to automate some business processes when records are associated and disassociated? For example, when someone is added to a marketing list we might want to say hello or, when someone is no longer a portal administrator, we’d like to say “Nyah nyah nyah nyah nyah nyah”?

These little messages have been tormenting us for as long as I can remember. Power Automate has given me a glimpse of hope by accepting [manually entered] intersect entity name but refusing to fire when the records were added or removed. Currently there is no other way to intercept those messages except writing a plugin. Or is there?

Well, plugin is still required but we don’t have to write anything because we can use webhooks.

Continue reading →