Just came across an interesting post in the Dynamics Team blog:
Set default Business Process on a form while creating new record
It is interesting in two different ways. First, it is offering a nice example of how to implement a useful feature. When there are multiple business processes per entity, we can order those processes using the configuration-only approach, but that’s just about as much as we can do.
If we wanted to select default business process based on some conditions, we would have to start customizing (aka doing scripts/plugins development), and that’s where a code samples like that one in the post above can be very useful.
However, this is where it becomes interesting in yet another way.
1. How do we normally check if we are on the “Create” form or on some other form?
We use Xrm.Page.ui.getFormType, right?
Here is how it’s done in that code sample above, though:
(Xrm.Page.data.entity.getId() == null || Xrm.Page.data.entity.getId() == ‘undefined’ || Xrm.Page.data.entity.getId() == ”)
Remember this is a Dynamics Team blog, so.. it’s interesting they are not using getFormType there.
2. What parameters can we pass to the form? More specifically, can we use process parameter?
parameters[“process”] = procesGuid;
According to this:
https://msdn.microsoft.com/en-us/library/jj602956.aspx#BKMK_OpenEntityForm
We can pass Form Id and Default fields ids.. Would it be too much to say that script is using.. shhh.. unsupported parameter?
It does not make that code sample less useful at all, but it does bring up the question of whether it’s so important to use supported customizations only(although, there are, probably, different degrees of “unsupported”) when, it seems, even the Dynamics Team itself is suggesting some customizations which are not, necessarily, fully supported.
I don’t really have the answer..
If you are more on the development side, then you probably don’t care that much since, after all, if this saves you a few days of work and you know how to maintain it.. then why not?
If you are more on the project management and/or project maintenance side, you may want to make sure your Dynamics implementation is not using some tricky/unique/unusual customizations which will be difficult to maintain and/or to even recognize.
Apparently, it depends on how you are looking at it. But what do you think?