A bit out of order1 but capturing this week’s work to migrate one of our legacy Dynamics solutions into our new architecture.
The solution in question contained only business logic - about half a dozen plugins, and similar numbers of workflow steps and a similar number of workflows (including custom actions),
Removing ILMerge Having already moved a few plugins I knew there were some challenges in getting away from the use of ILMerge (one of our goals).
Quick notes jotted down while listening to this podcast originally published 26/09/2018.
Podcast guest Merwan Hade, at that time Senior Program Manager for MS Flow (now Director of Product Management at Salesforce).
Q: Flows inside Dynamics 365 solutions - why? Solution as a way of packaging dependencies and moving between environments. Parameterised solutions - e.g. have a generic flow that can be parameterised in different environments Q: How will connectors be handled when deploying solutions across environments?
This week I made my first visit as a new member to the Dynamics 365 User Group UK chapter meeting.
I’d been invited to speak about our experiences in using Dynamics 365 and Thunderhead ONE together – my slides embedded below.
Overall I found the day valuable and enjoyable, especially the review of new features in Dynamics Version 9 from Sarah Critchley, and Ben Walker detailing his experience with setting up a CI/CD environment for Dynamics.
Some useful notes and links here from Steve Mordue , CEO of ForceWorks on Account-Based Marketing, and ways to adapt the native behaviour of Dynamics 365 to support it.
Beyond his suggestions I think the following are key in terms of building and information base about your target accounts:
acquire as much contextual information about accounts as possible, via both automated and human sources whilst acquiring as much data as possible about individual customer interactions on touchpoints, put significant effort into linking those individuals to an account when customising the touchpoint experiecne for an individual, take into consideration their account context, including other recognised individuals
Background Since upgrade of CRM Online to 8.2, we have noticed some strange issues around workflow triggers that are supposed to be fired by the change of a record status.
We have a workflow associated with the Invoice entity that is set to trigger on change of record status:Workflow trigger settings
The workflow is responsible for setting up various bits of data when we issue an invoice, then flagging to an external integration that the invoice is ready to send to Finance.
If you need to use ILMerge, you must use an unencrypted strong name key for your assembly
If you change the strong name key for your assembly, CRM thinks it’s a whole new assembly, so it might pay to create new ones explicitly
If you are now including the generated CRM early-bound classes through ILMerge instead of as a source include, remember to add [assembly: Microsoft.Xrm.Sdk.Client.ProxyTypesAssemblyAttribute()] to all deployed assemblies