Support Portal ContactGet in touch

Controlling Entity Events in DocMan

   Words by Paul McQuillan

   on 21/01/2019 09:00:00

DocMan for Dynamics manages events in CRM to integrate these into SharePoint.

The most notably event is when a new Record is created in CRM, this then creates a new Area in SharePoint and connects the two together.


This ensures that we have a Document Location in SharePoint for each Record created in CRM, with the DocMan Panel Web Resource then allowing us to view and use this SharePoint Location.

However DocMan also uses 3 other significant events from CRM to SharePoint:

  • When a Record is updated in CRM, this renames the corresponding Site, Library or Folder in SharePoint
  • When a Record is updated in CRM, this refreshes any applicable Metadata from CRM into the Documents held in SharePoint
  • When a Record is deleted in CRM, this deletes the corresponding SharePoint Location

Each of these Events can be activated or deactivated for an individual Entity in CRM.

To control these events, we can browse to the DocMan Configuration Area in our CRM Settings:


Opening this area will then show us the Settings for how our instance of DocMan is configured.

Within this screen is the List of Entities that DocMan is configured for within Dynamics:


This List defines which Entities are working in conjunction with SharePoint through the DocMan App Logic.

We can then drill down into that particular Entity to view the settings specific to that Entity in Dynamics.


The area for Core Actions then specifies these 4 Events – and we can activate or deactivate each Event within that Entity as required.

This allows us to control the Rename and Delete events in particular as we may not want these Events in operation for how we use SharePoint alongside Dynamics.

In the particular Scenarios that we have worked with:

  • On Create in CRM – Create in SharePoint, whilst normally best activated, could be deactivated so that a SharePoint Location is not created by default until the Record is first used or a first document is uploaded – this prevents excess locations being created in SharePoint if the Records of the Entity only occasionally need Documents.
  • On Update in CRM – Rename in SharePoint, this is a handy feature in keeping the records in synch between Dynamics and SharePoint but if we have distributed links to a particular SharePoint Location and do not want these links to break after the Record in CRM has been renamed then we may want this deactivated.
  • On Update – Publish Metadata, this can be excellent for ensuring changes in CRM are then published down to each of the Documents – but if we want to say track the Sales Stage of an Opportunity or Quote *when* the Document was uploaded, then we may want this deactivated; as then the Document Metadata will remain a record of when the Document was uploaded instead of being refreshed when the Sales Stage changes.
  • On Delete in CRM – Delete in SharePoint, this helps tidy SharePoint and remove Documents that are linked to a Record that has now been deleted – but we may have rules or policies in our organisation that insist we should keep Documents long after a Record has been deleted and so want this deactivated so the Documents connected with a CRM Record are retained beyond the record itself.

This flexibility can be useful in how we want Dynamics and SharePoint to work together.

What Updates in CRM would prompt the SharePoint Location to be renamed?

This is driven by the Dynamics Map Rule for how the Location was created from CRM – this Map defines what Fields in CRM should be used to name the Site, Library or Folder in SharePoint that will store Documents for this Record.

DocMan will trigger only when any of these defined Fields being updated and rename the SharePoint Area accordingly.

In the example below, the Folder for a Quote record would only be renamed if the ‘quotenumber’ or ‘customerid’ fields were updated:


What Updates in CRM would prompt Metadata to be refreshed from CRM to SharePoint?

This works in a similar way in only registering Updates in CRM when a Field is being changed that is recorded in the list of Metadata Maps from CRM to SharePoint.

this list of Metadata Maps is available within the Configuration of that Entity:


In the above example, the ‘QuoteNumber’ Metadata in SharePoint will be set with the corresponding ‘quotenumber’ field in CRM – this will be initially set whenever a Document is uploaded to the SharePoint area for a Quote, and then refreshed into SharePoint whenever the ‘quotenumber’ field in updated in Dynamics. (if this particular setting is set to YES)

  • "Paul has made a real difference to how my team of 24 people record and store valuable customer data and sales opportunities. Highly recommended."

    James, Operations Director

  • "Understanding your business allows us to advise when to implement aspects of CRM and, likewise, when not to."

    Paul McQuillan, Managing Director

  • "Dynamics 365 and CRMCS have made a real lasting difference to our business, allowing us to replace older systems that were holding back our performance."

    Grahame, Chief Operating Officer

  • "James worked well with us to help connect CRM with Outlook and relate how this might benefit our team using CRM for Property Care."

    Natalie, Property Care Supervisor

  • "Matt was really good with helping us run User Testing on the new Compliance Module of our CRM System."

    Tom, Compliance Administrator

Prefer to go old-school?

Write to us using the below addresses.

Head Office
CRM Consultancy
61 Oxford Street
M1 6EQ

London Office
CRM Consultancy London
Grosvenor Avenue

Content © CRM Consultancy.