Dynamics – Plugin Assembly Habits to Avoid during Development and Maintenance

Just wanted to share some of the habits while development / maintenance of Dynamics plugin projects which i feel are not correct and i feel they should be avoided

a) Registering different versions of the same assembly – Although having different versions of the plugin / workflow assembly is acceptable till dev / test, however one must make sure that before the solutions are deployed to UAT / Production, they must be combined.

If not, we just end up having multiple assemblies in production which can be a nightmare for maintenance.

b) Disabling / Enabling steps from the solution – This is another point one must keep into consideration while maintaining the different environments.

It just adds unnecessary complexity / effort to analyse what could be the root of the issue.

c) Maintaining Unmanaged Assembly in Production – Just in the case with all the other components present in a solution, its not a best practice to have unmanaged assembly instead of a managed one in production.

d) Running Workflows / Plugin Impersonation  – In the scenario’s when a plugin is being impersonated to run under the context of a particular user or when an out of box workflow is running under the ownership of a particular user, we must ensure that the user set should be the service account user.

This is because in many cases, the license for the developer user is revoked. In such cases, the functionality will start breaking and could be difficult to trace.

e) Update plugins filter attribute  – If we are having any update plugin, we must give some thought on the attributes on which the plugin step is triggering. This is because if we randomly choose any attribute, it could impact the performance of the system.

For further reading please refer to the Microsoft official site for best practices on Plugin development






Azure – Managing Resources Using Resource Groups

In this blog, I just wanted to share some tips which people can use to manage resources in Azure via Resource Groups. Resource Groups in Azure users can help users in organizing the resources in a much better way. It can help them not only in development but also helps them in better monitoring of the resources, there maintenance and the associated cost.
Mentioned below are some of the points which people can use to organize their resources better

a) Always create resource groups in Azure to manage the different environments of dev, test, uat and production. Also do not create unnecessary resource groups.

This ensures that there is a good level of segregation between the components in azure and people can easily develop and deploy resources in dev without impacting the other components in test, uat and production.

With this approach, if developers needs to flush out the entire resources in a particular environment, they can just do it by deleting the respective resource group

b) Provide access to only relevant people in each resource groups. This can be managed by either providing them access as a standalone user or as a team.

This segregation can help avoid unauthorized access and update of components by mistake.

c) While deploying the resources, it’s always beneficial to tag resources. This can enable better monitoring of the environment. For example using tags we can monitor the usage and costing of respective resources.

Please read the mentioned below Microsoft blog for better understanding on resource groups

Microsoft Dynamics Portals – Setting Value in a Lookup Attribute

In Dynamics Portal’s we can use the mentioned below syntax to set value in a lookup attribute

In the code example below, attribute needs to be replaced with the schema name of the attribute.
txtName , txtID and txtEntityName needs to be replaced with the name, guid and entityname of the record which you are setting in the lookup attribute.

$(“#attribute_name”).attr(“value”, txtName);
$(“#attribute”).attr(“value”, txtID);
$(“#attribute_entityname”).attr(“value”, txtEntityName);