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.
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:
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!
6 thoughts on “Power Apps Portal: deactivate account, no workflow please, thank you”
Good solution Olena! I Think the new WEB API for portal will play a role here as well by letting a button make an API call to update the status
Thank you very much for pointing to it! Personally, I am so excited about Web API for portals. That will change a lot how we build a portal logic in many ways.
Also, I find challenging not just getting developers to adopt new technologies but also merging two worlds of “old” and “new” in one system. We don’t always have the unlimited power to change/replace old stuff in one day. Making sure it will be easy to do it tomorrow is something I keep in my mind while building these days.
LikeLiked by 1 person
You are welcome, thank you for spreading knowledge. You know, what I find hard with all the new stuff is the illusion of being able to do X fully with the new technology but then will face a stopper that will force me to go back to the old world. I think both worlds will coexist for some good time and we should really consider them as the “current state ” and not separate them as old and new.
Agree, 100% THis is what I call real-life scenarios. It’s very different from the demo world.