Dynamics 365 Error – cannot Delete Field “can not be deleted because it is associated with another object”

You may wonder while you are engaged in Dynamics 365 training (which sometimes happens by just using it day-to-day) about why you receive this error when Deleting Entity or a field associated with it in Dynamics 365 CRM, including all versions – 2016, if there’s a Dynamics 365 2018 in the future it might probably apply to it, and this error is as follows: “can not be deleted because it is associated with another object.”

Well you may be familiar with the difference between unmanaged and managed, in which a small refresher is included later in this post.

However there is a separate category within managed fields and entities called System and also some of them are called Out Of The Box entities. In general with regards to the System entities and Out Of The Box entities that come with Dynamics 365, these entities and any related fields cannot be deleted, even if there is a 1:N relationship between them. These entities and fields cannot be deleted even if no other object references it, and you may still get this error “can not be deleted because it is associated with another object.” or another error.

How do you know if it is a System entity or System field? Well, this and many other questions, can be answered through our Microsoft Dynamics 365 Training Courses, and we also offer custom courses and custom services such as consulting.

Dynamics 365 Training 2018 can not be deleted because it is associated with another object
Dynamics 365 Training – Customization Error When Deleting Entity: “can not be deleted because it is associated with another object”



Managed Versus Unmanaged

(source: here)

Unmanaged Solutions

  • All Solutions must begin as Unmanaged, allows the customer to directly control their intellectual property and customisations
  • Unmanaged Solution customisation are made at the Unmanaged Layer which is also part of the Default Solution
  • Allows us to make customisations, register plugin steps etc, before we can export as Managed
  • Deleting the Unmanaged Solution only deletes the reference to the solution, not the customisation components
  • Ensures customer business customisations & data are always part of the default solution
  • Rolling back requires manually deleting the customisation components from either the solution or Default Solution, or restoring the last Backup of the CRM
  • Less risk of losing customisations and data as more difficult to remove
  • Depends on how the solution is being delivered. ie internally or externally
  • Risks associated to how well IT infrastructure / TFS / Version control is maintained
  • If the business has procedures in place to disable direct customisation to live / security
  • Unmanaged Solutions are easier to maintain for customers who are responsible for their own deployment
  • Allows to snapshot production and resolve a blocking issue due to the use of unmanaged solutions
  • Merging behaviour for customisation updates is simpler, less complex than managed
  • The unmanaged solution can be exported as unmanaged, but not vice versa


Managed Solutions

  • Manged Solutions need to be exported as Managed from an Unmanaged Solution
  • The whole point of Managed is locking down the Component states so they cannot be edited
  • This secures the solution in the Target / Production so it keeps the solution feature working and prevents end users from breaking it. Therefore it is maintainable.
  • Managed Solutions are installed at the Managed Layer
  • Deleting the Managed Solution will remove all its customisations as well as data contained
  • Solutions are additive, no build in feature to removing managed customisation without losing your data unless a holding solution is used.
  • Any Managed components that are customisable will be done at the Unmanaged Layer
  • Managed Solutions become read only once deployed so they cannot be manipulated

<![if !supportLists]>·        <![endif]>Roll Back / removing a Managed Solution after deploying to production is simple

<![if !supportLists]>·        <![endif]>Preparing managed solutions for deployment requires more considerations for dependencies & merge behaviour

<![if !supportLists]>·        <![endif]>Once you deploy as Managed in production you cannot change back to unmanaged once the solution has been deployed