Pushing Onward and Upward

Like anything in life, we should constantly try to move forward and not allow unpleasant events in the past get us down. That is not to say however that we just forget everything in the past– rather we take with us all the lessons from those instances and use them to propel us forward. 🙂

But how do I apply this thing in Dynamics 365? Well, I bet you are well-aware of business process flows. It’s that set of chevrons (previously, but now represented by big dots) across the top of the page when opening up a record (say, an opportunity or a lead). It is meant to provide a visual guide to users so that data are consistently captured.

Some question popped up weeks ago about whether I can stop somebody from moving the active stage one step back, just because I do not want to. It sure is possible I thought. I then took the plunge and worked on it.

(Before getting into the details of it, I’d just like to say that in learning a skill, it’s most effective for me when there is a scenario I set myself to work on, rather than just purely reading through materials. If my approach is the latter, I’d surely just doze off. 😴)

Here are snippets of the code and what they represent.

1. Validate that the plugin was registered correctly.

When I came across this part while going through the documentation on plug-in creation, I wondered why this is necessary. I just came to realize that it is a “first line of defense” in case the plug-in was registered incorrectly (e.g. a different entity was selected).

2. Get the execution data available from the operation

The plug-in takes advantage of the data available in an update operation. Also, since what I want is to stop moving the process flow backwards, I also need the data before it is moved, which is provided by the PreEntityImage property. These are the data I’d be using to control whether I would allow the change in the active stage of the process.

Also, I invoked the ToEntity method of the Entity class to cast the object from type Entity to an early-bound type, which I find easier to manage. This is something I’ve been trying to look up, but could not, for a long time, find a way to do it. Luckily, I stumbled upon a blog post that exactly does that.

3. Retrieve the stagename attribute using FetchXML expression.

This needs some further fine-tuning as this may not be a sustainable solution — that is, using the stagename attribute to compare the pre-update data to the would-be data for the reason that is fluid; business decision-makers may just decide to change the names for one reason or another.

4. Compare the stagename values before and the proposed after values.

This is the last block of code of the plug-in, in which I just compared the stagename values. To be perfectly honest, using try-and-catch is still something that is not crystal-clear to me. But I guess it should suffice for now for me to know the gist of it which is that for unhandled cases, there has to be a way for the code to catch them so that both users and the developers are aware what exactly it is and to prevent the system from crashing. 🙂

As I have stated in #3, this I think is not a totally robust solution as I am comparing string values from the attribute stagename. Maybe making it into a variable would be best, but that’s something for another day. 🙂

This is how it works in action. I recorded my laptop screen rather crudely using my phone (with matching background music for inspiration). 🙂

 

This is what the configuration looks like when registering the plugin.

To cap this off, it is not onward-looking when we employ an old approach to an old problem, would you not agree? Enter Power Platform into the picture. It broadens the array of tools that we could tap into to solve old and new business problems alike — in a low-code to no-code way, making it more accessible to a wider audience (citizen and pro-developers alike).  That is what I intend to leverage next for this very same scenario.

Have a good day! ⛅

P.S. Code and Dynamics 365 solution are stored here.