By Alexandra Tucker
July 24th, 2018

Andre’s Blog

Troubleshooting: “There is no active transaction” Error

Today I encountered a very weird error when I’m working with my team to create a very simple workflow, on a status update, if the status is equal to a specific status, create a task that is assigned to a specific team. However, we can’t proceed due to a very strange reason:


This is the error message:

“There is no active transaction. This error is usually caused by custom plug-ins that ignore errors from service calls and continue processing.”

So, I googled it to find the similar error. Based on a past post by Aileen:

We have tried checking the suggested approach by her:

What to Check

So, if you find this error, please check:

– Whether you have custom plugin/custom workflow active triggered
– Whether you put skipping the error that will have impact to the CRM process, it is not possible
– Actually you better to log the error
– Because you won’t know what it is
– This is not your logic wrong in your custom plugin
– This just you need to fix why CRM cannot proceed?
– Is that because your user/team does not have privilege or you missed some parameters required
– This error might happen like for Assignment, Lead Qualification, Quote creation, etc

However, no luck 😦

And we also come across this forum discussion:

where some people are mentioning about an issue with ActivityFeeds plugins, again no luck, as we can’t find the specific ActivityFeeds plugins registered.

So, as the usual troubleshooting technique of elimination process, we tried to remove 1-by-1 the workflow mapping, and we found the culprit. Apparently, it’s on the mapping of record owner in the Create Task step. For some reason, if we set the owner on the creation of the task, it keeps throwing the error. So, we split the owner assignment to a separate step to assign the record to the team. Something like:


And it solves our misleading “Custom Plugin” issue.

By Alexandra Tucker
February 8th, 2018

Andre Margono, Solution Architect @ Barhead Solutions posts with more tips and tricks when using Dynamics 365.

The feature of Security Group in the Dynamics 365 Online deployment has been there for a while. However, I often find either people do not understand it correctly or this feature is not being considered as an important “checklist item” for a smooth deployment. So, in this post I will share some reasons on why we need to plan setting up the security group.

To support the example, I’ve set up the following scenario:

In my instance I have 4 users:

Users List.png

And 2 Security Groups for Production and Sandbox

Security Group.png

Where in Production, everyone is the member of the group:

Prod Membership.png

While in Sandbox, Test User 3 should not access the environment

Sandbox Membership.png

Now, let’s begin with the reasons why we need to implement Security Group.

#1 For Authorisation Purpose

In typical Dynamics 365 implementation, there will be multiple instances, such as DEV, TEST, UAT and PROD. When the instance has been associated with the security group, only users that are member of the security group can access the environment. The traditional way to restrict access by not assigning the security role to the users is still viable, but this leads to the reason #2 below.

The difference on the error message would be as follow:

  • Not assigned with the security role


  • Not part of the Security Group

Not Part of Group.png

#2 To Keep Users in the Instance Clean

On top of the first point, to prevent the users to access the environment, having security group configured for the environment will also prevent the users that are not part of the security group to be synchronised with the environment.

A thought come into my mind: it won’t harm right to have the users synced. As long as, we are not assigning the security role to them. Yes, it’s true from the authorisation perspective. However, having them in the environment that they are not supposed to be, also means they will be under the list of “Enabled User” that can be used in selection when assigning records. In multi-organisations deployment, it also means the user from different organisations are visible to the environment. These situations could cause confusion to the users.

The list from Production environment:


The list from the Sandbox environment:


#3 To Hide Unnecessary Items at the Apps List/Instance Picker

With the “App” concept in Dynamics 365 Online, the will contain all kind of “Apps”. This includes the Apps that deployed within the instances. When a user have the privilege to access multiple instances, they also will see the “Apps” that are deployed in those instances. IMHO, it is always the best approach to hide anything that users should not see, so that they could focus on what they need to do with the system.

For example, my user that has full access to all environments, could see the following:


Meanwhile, the Test User 3, can only see 1 “App” that is associated to the instance that this user has access (controlled via the Security Group).


The same thing with the Instance Picker (this has been superseded by the However, if users might have bookmarked this page.

The following is the list from my user:


Meanwhile, this is from the view of Test User 3.



Implementing Security Group for Dynamics 365 implementation should be considered in the design and planning to ensure proper and robust security and user experience.

Hope this helps!



Next step

Contact us for more information or for a free quote:  1300 DYN 365