CODEWITHSUNDEEP
workflowdynamics-crm-2011
Peter
Peter

Reputation: 7804

CRM 2011 RU13 The workflow cannot be published or unpublished by someone who is not it's owner

I have created and added some workflows to CRM 2011 RU13, through the UI

Through not fault of my own my development environment is completely air gapped from my production environment.

I added these workflows to my solution and exported the solution as managed and given the solution to the production admin.

When he deploys it fails with this message.

The workflow cannot be published or unpublished by someone who is not it's owner

How do I fix this. There is no way to not give workflows an owner. or say that the owner is the solution.

Upvotes: 1

Views: 2483

Answers (2)

AdamV
AdamV

Reputation: 1467

A couple of additional points for clarity for the OP:

The owner of the workflows in your dev environment is not relevant, the importing user in prod will become the owner (this does not contradict Guido, I'm just making sure you don't follow a red herring). It is quite right for their to be an "air gap" between dev and prod.

If you know which workflows are in your solution, assign those in prod to yourself, then import, then if and only if you need to, reassign them to the original owner(s). You may not need to if that owner is just an equivalent system admin user, but if it is a special user (eg "Workflow daemon" so users can see why it updated their records) you will want to re-assign.

Note that after re-assigning them, that user has to activate the workflows. You cannot activate a workflow in someone else's name (or users could write workflows to run as admins and elevate their priviledges).

If the workflows have not actually been changed in this version of your solution, take them out of the solution and ignore them - often I find that a workflow has been written, carried across to production in the original "go live" and is then working perfectly fine, but is left in the solution which is constantly updated and re-published (ie export / imported).

Personally I often have a "go live" solution (or more than one, but that's a different thread...) and then we start all over again with a new solution which only contains incremental changes thereafter. This means that all your working workflows, plugins, web resources etc do not appear in that solution so this avoids confusion as to versions, reduces solution bloat, and avoids this problem of workflow ownership. If a workflow is actually updated, then you need to deal with the import, but don't make this a daily occurrence for unrelated changes.

Upvotes: 2

Guido Preite
Guido Preite

Reputation: 15128

The production admin gets that message because he is not the owner (inside the target CRM environment) of one or more active workflows included in your solution.

This happens in these situations:

  • First time you give your solution to be imported, is USER_A to perform the operation and all the workflows are assigned automatically to him. If later USER_B try to import an updated version of the solution he gets the error message because is not the owner of the workflow(s).

  • First time you give your solution to be imported, is USER_A to perform the operation and all the workflows are assigned automatically to him. Meanwhile one or more workflows are assigned to USER_C. If later USER_A try to import an updated version of the solution he gets the error message because is not the owner of the workflow(s).

Before a workflow can be updated must be first deactivated, and only the owner can deactivate a workflow. This is by design.

In your case the production admin must be the owner of the processes (he can assign temporarily the workflows to himself, import the solution and after assign back to the right user) or needs to be the owner of the workflows to import the solution (if he has the rights)

Upvotes: 6

Related Questions