When performing an integration between an ERP system and Microsoft Dynamics CRM, if the data only flows from ERP to CRM, the integrated fields in CRM are typically set to be read-only. This is usually done to prevent users from changing data in an integrated field and having that data be overwritten the next time the integration runs. This can be a problem because users in the CRM system, typically sales, marketing and customer service personnel, may have access to the most updated information (phone number, address, name, etc.) as they are dealing with customers on a daily basis. The solution for this issue is to create a change request in CRM, and that process is the focus of today’s blog!
Assuming that users don’t have access to the back-end master data system and that the integration is not configured to be bi-directional, this approach works well in assisting with change requests. This process is simply configured and can be customized to be extremely robust in functionality. The level of depth you apply is totally up to you and also depends on how configurable your ERP system is with respect to updates.
If you need to update a read-only integrated field in Microsoft Dynamics CRM, simply follow the process outlined below:
Create Change Request
CRM users can create a change request record in CRM, which is directly related to the entity in question. The change request record can pre-fill all read only fields approved for edits with the current value in CRM via either custom development or through 1:N field mapping (out-of-the-box).
Users can make the appropriate changes and submit the record, locking the request. The request record will (by default in CRM) be date/time/user stamped so users will know who made the change and when for auditing purposes.
Notify Data Team
You can build a workflow in CRM that automatically assigns the request record to the person or team who will be responsible for approving and making the change in the ERP system. Routing rules may be leveraged within the workflow to assign based on territory, country, etc.
The workflow will then send an email to the assigned person or team, notifying them of a pending change and providing a link to that change request record in CRM.
Approval / Change Process
This step is where the process really shines. The person in charge of approving the change identified above will log into CRM, review the change, and either approve or reject the change.
- Approval Process – Simple (No access to write to ERP system via integration middleware)
- The user will make the changes in the ERP system and then mark the change request as approved.
- An email will notify the user who submitted the request that the changes have been approved and will sync back during the next integration
- Approval Process – Complex (Edit access to write to ERP system via integration middleware)
- The user will mark the change as approved in CRM.
- ETL middleware (SSIS, Scribe, BizTalk, etc.) will read the changes and write the updates to the ERP system directly.
- ETL will then change the status of the change request record to complete.
- An email will notify the user who submitted the request that the changes have been approved and will sync back during the next integration.
- Rejection Process (Applies to either option above)
- The user will reject the changes and provide a rejection reason.
- An email will notify the user who submitted the request that the changes have been rejected, along with a reason for the rejection.
Updates to CRM
Once the changes have been made in the ERP system, the changes will automatically sync to CRM during the next integration cycle, depending on the frequency of the integration.
This process works well with varying levels of customization. At its most basic, it can be configured out-of-the-box and used as a manual queue to get users to centralize their changes for ERP systems, reducing the amount of emails that a data administrator would have to make in the system. For more complex implementations, it’s definitely an option to build upon this concept with custom development, integration middleware, and automatic updates to data with an approval process in the middle.
Hopefully this sparks some creativity in your mind about how to handle one-way integrations between ERP and CRM with read only data! If you would like to read more about integrations, check out some of our customer success stories!
Happy CRM’ing!