Please note: The additional “Managed Disks” and “Storage Transactions” options are not required. No additional software should be needed:
1. Managed Disks:
2. Storage Transactions:
Virtual Machine Pre-Requisites if Building Your Own Virtual Machine
If building your own Virtual Machine vs. purchasing a new Azure Virtual Machine and given the option, we recommend installing Windows Server 2019.
Other compatible server operating systems include: Windows Server 2016 and Windows Server 2012
It is recommended for best performance that the Virtual Machine for your DocumentsCorePack Service be located in the same datacenter your Dynamics 365-instance itself is located (i.e., inside the same network and physically close as possible).
No other software is required (For Server 2012 .Net 4.6.2 installation is required)
The DocumentsCorePack Installation consists of two main parts:
Server Install: Installation of DocumentsCorePack Service and import of DocumentsCorePack Managed Solutions into the Dynamics 365 environment
Template Designer Cient Install: Client executable only installed on workstations of designated Template Designers – Nothing Installed on Virtual Machine
DocumentsCorePack Installation and configuration is covered in our Installation Guide:
Please note: The use of the DocumentsCorePack connector for PowerAutomate and PowerApps is not supported for self-hosted deployments of DocumentsCorePack. Automation is still supported using the native CDS connector or through Microsoft Dynamics 365 Workflow.
Virtual Machine Architecture and Security for DocumentsCorePack
When installing DocumentsCorePack on your own hosted Virtual Machine, mscrm-addons.com does not have any direct access to your hosted Virtual Machine or other systems (i.e., Dynamics 365, SharePoint, etc.).
Scheme Diagram and Process Flow
This article outlines how the Cloud service structure for DocumentsCorePack works. Once a customer sends a document generation request the service will grab the request from Dynamics 365, retrieve the data, generate the document, and push it back to Dynamics 365. Afterwards, the document can be accessed by customers.
As you can see in the figure below, the sequence of the document generation is as follows:
Figure 1: DocumentsCorePack Online Scheme
Document Generation Request:
Once a document generation request is triggered, a Dynamics 365 record called “AutoMergeWorkingItem” gets generated in Dynamics 365. Document requests can be triggered manually by a user using pre-configured “One-Click-Actions” or automated through Dynamics 365 Workflow. (PowerAutomate (Flow) is not supported for self-hosted installations).
Push Request to Document generation service in the Cloud:
As soon as the AutoMergeWorkingItem is saved, a web URL (Azure Function) is called. This URL tells the Cloud-service that there is a new document to generate in the Dynamics 365 environment. There is no data transfer at this point.
The Cloud-service connects to Dynamics 365 using Dynamics 365 web services (secure communication via https) and loads both the document to generate (template) and the Dynamics 365 data needed inside the document. There is no information stored on the Virtual Machine that hosts the cloud service except when debugging is activated – in that case, the data fetched from Dynamics 365 will show up in debug-files.
Send document back to Dynamics 365:
The generated document is sent back to Dynamics 365 using web services (secured communications via https). The document itself is never stored on the Virtual Machine.
Please note: To communicate from the cloud-service to Dynamics 365 we use Server2Server authentication without the need to store login credentials locally on the Virtual Machine.
That’s it! We appreciate your feedback! Please share your thoughts by sending an email to email@example.com.