The following steps occurred in my resolution process with Microsoft:
1. Microsoft Support ran some backend script against my tenancy that removed the dependency on msdynce_ActivitiesPatch
2. Attempt to remove FieldService solution lead to another non descript error. Microsoft engineers interrogated the back end and advised me to delete the setting msdyn_knowledgemanagement using a direct url reference
https://YOUR ENVIRONMENT.crmREGION.dynamics.com/main.aspx?appid=YOUR APP ID&forceUCI=1&pagetype=entityrecord&etn=msdyn_knowledgemanagementsetting&id=YOUR COMP ID
3. Then successfully removed the solution FieldService
The appid (YOUR APP ID) is the unique id of any Power Platform application that is active within the specified environment. In our case the id for the component (YOUR COMP ID) was the identity of the dynamics entity msdyn_incidenttype. Microsoft provided me with this guid during the investigation from their own diagnostic views. I found a way to lookup this id using an API call as follows:
https://YOUR ENVIRONMENT URL/api/data/v9.0/msdyn_knowledgemanagementsettings
This yields a fragment of JSON from which you can find the guid in the value pair msdyn_knowledgemanagementsettingid for the relevant knowledge based entity (in this case "msdyn_entityname": "msdyn_incidenttype").
Some further investigation reveals that you can use the following url to see the entities on which knowledge management has been activated:
https://YOUR ENVIRONMENT URL/main.aspx?pagetype=inlinedialog&name=KnowledgeSettings&forceUCI=1
The URL above shows a screen where there are options to de-activate knowledge management for specific entity types. The incident type msdyn_incidenttype is part of the field services solution. So switching off knowledge management dependencies on this entity type might help.
