Tip #1379: App People vs. Flow People

The wand picks the wizard

Nick Doelman

Too tired to read? Why wouldn’t you listen instead – t.j.

It’s been my observation that with a few notable exceptions, people in the Power Platform community primarily focus on Power Apps or on Power Automate. Lots of people will use both, but generally people are more “app people” or “flow people.”

I don’t have a strong preference between the two, and I regularly use and enjoy both platforms, but I’ve had conversations with people in the community that say something along the following lines:

Flow Person: “I love Power Automate, but Power Apps (canvas apps) are confusing.”

Apps Person: “I can write canvas apps all day long but you need to be a developer to use Power Automate.”

I’ve also noticed that if you suggest a flow solution in the Power Apps forum or an app solution in the Power Automate forum at powerusers.microsoft.com, people will give you funny looks.

Intrigued by this phenomenon, I interviewed some of my friends in the Business Applications community to see what they thought was behind this divide. Why does one tool seem accessible and easy to some while difficult to others?

Continue reading

Tip #1378: Update Common Data Service user photo from Office 365 profile

I had things stolen from me, I gave things away on many occasions. But I never ever lost anything. What’s the secret? Time perception.

I do not lose things, I only temporarily misplace them

The Enabler

Consider this. Last year I created a folder for all the good tips coming in from the fellow tipsters, users, developers. (Your email can land in that folder too if you send it to jar@crmtipoftheday.com). Then I lost misplaced that folder. Then I found it again (SEE?). For the next few days I’m going to be bringing these tips to life. Today’s tip is from Michael Aarvik.

Continue reading

Tip #1377: Open Advanced Find in tab

I truly hope that one of the traits that differentiate me from, say, an ungrateful baboon, is ability to recognise when I’m wrong and apologise to Jeff Klosinski who sent not one but two tips an EFFING YEAR AGO and I haven’t published it.

In my defense I couldn’t reproduce either. But you know how can you tell a good tip? It stands the test of time. Today I went back, played a bit and discovered that when combined, those two tips just like sodium and water produce kapow! of one powerful trick.

Continue reading

Tip #1376: Antivirus for portal attachments

One taketh one giveth (or other way around). Returning a favor to AK who asked:

How does the portals handle uploading of virus?

(Want your favor returned? Send your awesome tip to jar@crmtipoftheday.com!)

There are multiple mechanisms you can put in place to protect your users from the viruses (no, not that virus, unfortunately).

Continue reading

Tip #1375: Get record count for entities

I need to perform some data… uhm… “augmentation”. Easy as using Power Automate – get all the records, loop through, fudge I mean augment the data. Right? Except there could be more than 100,000 records. Why 100K? That’s the maximum you can get with the List Records action. (Wanted to insert a reference here but that limit does not seem to be documented at all… Oh, well, save it for another tip). In short: I need quickly to find out the total number of records in couple entities. On top of that, those were the entities not exposed outside of their parent entities, like Order Product or Invoice Product.

Even if you are not a developer there are couple Web API methods you can add to your toolbox and RetrieveTotalRecordCount function is one of them.

https://orgname.crmN.dynamics.com/api/data/v9.1/RetrieveTotalRecordCount(EntityNames=['logical_name_1','logical_name_2', ...])

for example:

https://foobar.crm.dynamics.com/api/data/v9.1/RetrieveTotalRecordCount(EntityNames=['salesorder','salesorderdetail','invoice','invoicedetail'])

This is what comes back:

{
  "@odata.context": "https://foobar.crm.dynamics.com/api/data/v9.1/$metadata#Microsoft.Dynamics.CRM.RetrieveTotalRecordCountResponse",
  "EntityRecordCountCollection": {
    "Count": 4,
    "IsReadOnly": false,
    "Keys": [
      "salesorder",
      "salesorderdetail",
      "invoice",
      "invoicedetail"
    ],
    "Values": [
      6679,
      10547,
      17568,
      59618
    ]
  }
}

Nice and easy, right?

Cover photo by Amornthep Srina from Pexels.

Tip #1374: Safely remove search box from subgrid

Today’s tip is from AK. (Be like AK, and send your next awesome tip to jar@crmtipoftheday.com).

Adding a subgrid to model-driven form in the maker portal brings the search box which takes an extra row. If you want to hide it, you may tempt to switch to classic and clear the Display search box.

Don’t do it.

AK

You will lose the jump bar and record/page counter if the subgrid has only one page. Instead:

  • export the solution
  • extract customizations.xml
  • find the grid and add EnableQuickFind node to the subgrid
  • repack the solution
  • import back and publish
Continue reading

Tip #1373: Dynamics 365 Mobile, Quick Create, and form issues

You create a model-driven app and open it in the Dynamics 365 mobile app or the Power Apps app (now supports model-driven). But when you click new record, you get a form but you cannot enter in data correctly — maybe there are some missing fields or something else is wrong.

Dynamics 365 mobile uses Quick Create to create records. If you don’t have quick create enabled or a quick create form created for the entity, Dynamics 365 will generate one for you based on the main form.

To quote the official documentation:

Dynamics 365 mobile apps use quick create forms for creating new records. If an entity already has a quick create form configured for it, the mobile apps use that form. If an entity doesn’t have a configured quick create form, Power Apps generates a quick create form for creating records in the mobile apps based on the main form definition.

https://docs.microsoft.com/powerapps/maker/model-driven-apps/create-edit-quick-create-forms

So if you don’t get the expected results, enable quick create on the entity and create a quick create form that contains the desired fields.

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