- fortnightly business review
- reviewing linked sources to Stop blaming the tools when Collaboration fails
- working with a team member on date culture issues in Azure Webjobs
- working with HR on recruitment for a senior role in my team
- improve our integration code that posts web form data to service bus for downstream integrations
- blog post “The machines may eat your job, but that might not be a bad thing – are any politicians acknowledging this?“
- minor development tweaks on our website
- some planning work around GDPR compliance
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
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:
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.
Updating the invoice status – the old way
Updating the invoice status – the new way
However as that call has been deprecated, we took the opportunity of some other refactorings to migrate to using Update requests.
Using C# and IOrganizationService.Update
First attempt in C# was:
However we found that the workflow was being triggered twice!
The only way we found to stop this happening was to adjust the code so we only update the statuscode attribute:
However we found that although this appears to change the entity fields correctly:
… the workflow is just not being triggered
Changing the process trigger
We changed the process trigger for the workflow to be “When record fields change” (i.e. update), and filtered only on statuscode
I half expected that this might fire initially but that later steps where the workflow calls itself recursively by changing status of the invoice would fail.
Second experiment was triggered from C# code based on other system actions. That too ran correctly all the way through, with the process only triggered once.
UPDATE – later in testing we started seeing random double triggers on this when the invoice status was changed using Update. Reverting to legacy SetStateRequest (but with the process still triggered on Update) corrected this behaviour. As none of this fits with documentation we assume it is an obscure bug in the platform
Microsoft have made changes to the way entity status interacts with processes.
The Microsoft recommendation is that all code which changes record status should do using updates, not the deprecated SetStateRequest
UPDATE: however from our later tests we consider SetStateREquest to be the safer option on the IOrganizationService
For workflows which are set to trigger on “Record status changes” there appears to be inconsistent behaviour depending on the source of the update (SOAP via the IOrganizationService, or directly to the newer REST API )
From our tests, any workflows which are triggered from “Record status changes” should be modified to fire on “Record fields change”, filtered down to just the status field.
Worflow steps created in the Workflow Designer which call “Set record status” still work, and will still fire triggers that have been modifed as above
It’s different from Windsor – jsut working out exactly how
Getting back on the blog wagon
Now playing with Federated Wiki here
Today was rebuilding a solution that had been updated to xunit2, and kept getting random test failures, usually with some kind of conflict with Rhino Mocks. The fix seemed to be to turn off the parallel testing. A little googling turned up this which suggests Rhino Mocks does indeed have a problem in a multi-threaded test environment