Power Apps Portal: deactivate account, no workflow please, thank you

The real-life scenario: a portal user (agency) indicates that they don’t manage a particular property anymore. The action is performed via self-service portal. From a user experience perspective, the property has to “disappear” from the list of active properties immediately after “no manage” action is performed.

If we choose to use Deactivate as an action we’ve got two documented choices available for an entitylist(https://docs.microsoft.com/en-us/powerapps/maker/portals/configure/entity-lists):

Again, from the user experience perspective, Items Actions aren’t very “visual” with the items are hiding in the context menu.

So we go custom.

On click of the checkbox we open a modal dialog confirming the additional details then we run workflow(you can always look up the page source code to see how it’s done) or perform deactivate.

BUT…

With the OOB Deactivate Item action you can’t choose a status reason.

You’ve got more flexibility with Workflow option. But what happens if you don’t want to use workflow?

Workflows are deprecated and has to be replaced at some point anyways. We try to develop new functionality with Power Automate.

So how do we do this?

We can use a form metadata to deactivate record on save.

It’s not better than Deactivate but it’s arguably better than workflow.

I want my status reason to be set to a non-default value. I can’t do it in any “natural” way. Un-natural way is to set the correct status reason with Power Automate after setting it to default from the portal first. So you will set status reason twice.

Happy days? Not exactly.

We had the workflow running on a status reason change which performed a certain logic. The worst bit, it was running synchronously. Changing workflow to accommodate portal double-running logic was the wrongest possible way to solve the problem (not because it was already big enough to easily break if you touch it or because it had if…then…else… runs for all existing statuses and reasons in combinations…)

At the moment we discovered that record deactivation was working differently for CRM side and a portal side I started thinking of the way to set status on a portal but save the correct status reason once, not twice.

Something had to run before the synchronise workflow and change the reason to a correct one. This “something” is a PreOperation plugin running on pre-update synchronously.

There is a trick here: Execution Order has to be set to 0. This is to get it running before the sync workflow.

Thanks to these guys below:

https://carldesouza.com/dynamics-365-pre-operation-plugin/

https://community.dynamics.com/crm/b/nunoscrmblog/posts/real-time-workflow-vs-plugin-execution-order

I don’t have the best memory and probably forget more than learn, because it’s more to forget due to changing every second technologies.

Summary: sometimes we need to override something before it saved to CRM. Sometimes we need a place to run some logic before sync workflow is triggered. Pre-operation plugin could be a better option than introducing a branched complex logic to workaround. No-code doesn’t always solve problems. Sometimes you need an old world and a new world co-exist and you have to use a bit of coding to get things working together.

Happy days this time!