In this article, we want to describe which minimum privileges are necessary for the user defined in the DocumentsCorePack Service Online Configuration.
DocumentsCorePack Service with Server2Server or AppAccess connection:
AppAccess and S2S connections are based on the “act on behalf of another user” privilege management. The user used for the connection requires as many privileges as any user requires for the use of the product. Security for “act on behalf of” is determined by matching privileges present on BOTH the impersonated user and the “act on behalf of user”. Privileges only present on one user are ignored by Dynamics.
While creating the DocumentsCorePack Service this user must have at least
- SystemCustomizer privileges and
- mscrm-addons.com security roles(LINK)
For running the DocumentsCorePack Service this user must have
- as many privileges as any user require for the use of the product.
This means that you have to ensure that the service user has all privileges necessary for the document generation and processing functionality of DocumentsCorePack, like:- access to all Dataverse data you have referenced in your templates
- rights to read, create, modify records ( emails, activities, notes,..)
- …
After the installation, you can remove the SystemCustomizer role from the user, but it is not recommended, as you need to re-add it, whenever an update of the DocumentsCorePack solutions is required.
Granting system administrator privileges to the Application user ensures, that no user interaction is accidentally limited.
DocumentsCorePack Service SharePoint Integration
If you have enabled the SharePoint Integration for the DocumentsCorePack Service we recommend using Server2Server connection.
The SharePoint user must always be able to log in to the root site of SharePoint. (Not see any data, but be able to logon without any error)
The user must have modify rights to the target folder. If the product is configured to create SharePoint folder information, the same rights are required for every existing library and folder in any possible target path.
If templates are used that set attribute-values on your SharePoint locations then the SharePoint user must be able to read the attribute metadata on the library level.