Tip #1372: Synchronous Power Automate Flow on create/update of a record

Today’s tip is indirectly from Alex Shlega. Alex is very thorough in his writing so I was a bit surprised that his answer to running a synchronous flow from a webhook was a ‘no’. The reason cited was that

CDS “execution pipeline” won’t wait for the Flow completion.

Well, it will indeed not, but only because we need tell it that we are going to return something. The moment you add a Response action, the webhook becomes synchronous.

There is a catch, of course. If you update the same record in your flow, you will enter a loop. And you will enter it from a separate process whilst blocking your original request. It means you can’t break that loop if you update the same record. The original update waits for the flow to complete but the flow can’t complete because it waits for the original update to release the record so that the flow can update it. Which is a classic deadlock.

In short, if you update the same record then no matter what you do, the original update will fail.

However, if you update does not touch the same record or entity then it will work. To illustrate, I added a calculated field to the account entity that displays main telephone of the primary contact. Registered the flow as a webhook and included pre-image with the primarycontactid:

Inside the flow I update the primary contact record with the +1 <company main number>:

The end result? Primary contact record is updated very much synchronously:

Synchronous update of the primary contact

Is synchronous flow possible? Yes, it is. Is a good idea? With the deadlock and infinite loop on the cards, it is probably not.

Cover photo: Waiting for Godot, text by Samuel Beckett, staging by Otomar Krejca. Avignon Festival, 1978. Rufus (Estragon) and Georges Wilson (Vladimir) / photographs by Fernand Michaud / CC0

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