Processtrigger error messages and the holding solution approach

The holding solution approach, sometimes referred to as a shadow solution or the shared publisher technique, is the recommended approach for removing solution components from a CRM organization. Generally this works ok, however we have been facing some challenges lately. Some errors that you might encounter:

- Crm Exception: Message: processtrigger With Id = 3922b595-8637-e511-80d3-b13ac3e6ed07 Does Not Exist, ErrorCode: -2147220969

- 0x80040203 Could not retrieve parent object id for label with id 1f26a158-cf40-e511-80d6-f0b8a7508109 and label type code 19

- Cannot find a top solution for ProcessTrigger:3922b595-8637-e511-80d3-b13ac3e6ed07

My analysis has shown that there is a challenge with Business Rules when using the holding solution approach. The option that I found to get this working is to temporarily remove the business rules from the holding solution. Here's how you can get this to work on a supported approach:

- Export solution as managed
- Export solution as unmanaged
- Remove troubling business rules [1]
- Export the solution as managedHolding
- Import the unmanaged solution in your dev environment.

For the unsupported approach, but just as effective,
- Copy the managed solution to a temporary managed solution
- Export solution.xml & customizations.xml from the managed solution
- Modify the unique name & save the solution.xml
- Remove the troubling business rules in the customizations.xml
- Replace the solution.xml & customizations.xml in the temporary managed solution
- In the zip file, remove the business rules from the workflows folder

You now have a managed solution export which does have the business rules, but a managedHolding solution which doesn't have the business rules. Make sure to change the unique name of the solution and you're set to go. In your target environment:

- Import the managedHolding solution
- Remove the previous solution
- Import the managed solution
- Remove the managedHolding solution

And that should do the trick! Now let's hope that this will be fixed soon.

[1] To find out which business rule is the cause of the problems, copy and paste the processtriggerid into the following query and run this on your database. For CRM online it'll be a bit more challenging to find out which business rule is causing the issue.

select
processid, (select workflow.Name from workflow where workflow.WorkflowId = ptb.processid),
solutionid, (select FriendlyName from solution where solutionid= ptb.solutionid),
ptb.overwritetime
from
ProcessTriggerBase ptb
where
ProcessTriggerId = '3922b595-8637-e511-80d3-b13ac3e6ed07'

Alternatively, you could create a temporary holding solution (managed) by:
- copying the original
- modify the solution unique name
- remove the business rule(s) from the customizations file

For more information about the technique, have a look at Microsoft's document: ALM for Microsoft Dynamics CRM 2011: CRM Solution Lifecycle Management.

4 comments:

Greg Owens said...

For CRM Online, run this FetchXML statement, using a combination of Tanguy's awesome XrmToolBox and Jonas Rapp's FetchXml Builder plugin for the same (gives you click-though access to CRM to open the offending record):

<fetch>
<entity name="workflow" >
<link-entity name="processtrigger" from="processid" to="workflowid" >
<filter>
<condition attribute="processtriggerid" operator="eq" value="{***PROCESS TRIGGER GUID ***}" />
</filter>
</link-entity>
</entity>
</fetch>

Kushum Nayak said...

http://ivrguru.com/crm-project-management.html

George Joseph said...

Finding the time and actual effort to create a superb article like this is great thing. I’ll learn many new stuff right here! Good luck for the next post buddy.

I will bookmark your site and check again here often. I’m quite sure :)

Thanks
ERP Software Dubai

Hammed said...

Grateful to check out your website, I seem to be ahead to more excellent sites and I wish that you wrote more informative post for us. Well done work.......

SEO Company in Chennai