Community Spring Cleaning week is here! Join your fellow Maveryx in digging through your old posts and marking comments on them as solved. Learn more here!

Alteryx Server Discussions

Find answers, ask questions, and share expertise about Alteryx Server.
SOLVED

Change workflow ownership in Gallery

smysnbrg
8 - Asteroid

Is there a preferred way to change ownership of a workflow in Gallery?  

 

As the server administrator of our organization, I would like to reassign workflows of users who have moved on.  I can make it so the new user can download the workflow and republish it, but it seems like that's a very cubersome process involving permission and role changes.

 

I'm looking to see if Alteryx has a documented process to do this that's not so tedious.

 

Thanks,

S

16 REPLIES 16
Luke_C
17 - Castor

Hi @smysnbrg 

 

This idea was raised and was sadly marked as 'revisit'. Some comments note maybe something is possible with the APIs to update the mongoDB, but I'm not sure if anyone's had any success doing so.

 

https://community.alteryx.com/t5/Alteryx-Server-Ideas/Allow-Transfer-of-Owner-from-one-Workflow-to-A...

 

ramesh_neel
11 - Bolide
11 - Bolide

@smysnbrg  - I had the same issue as well and reached out to Alteryx support who provided me an application that updates the MONGODB and changes the ownership . Apparently that's the only way to change ownership currently .

Alteryx ACE | Sydney Alteryx User Group Lead | SparkED Contributor and Mentor
smysnbrg
8 - Asteroid

I will contact support - I appreciate it.

cjayachandran
5 - Atom

I am also facing the same issue. It would be nice to have this feature added to the application for the administrator role if not to other roles.

Ariharan
11 - Bolide

Hi @smysnbrg

 

The Shared Studios approach is being followed by our team in order to eliminate this problem. We added the group of people to shared studio subscriptions and they can publish the schedule and workflows via shared studios.

 

Let me know if this helps and please mark it as the solution if so.

 

Regards, 

Ariharan R

RodLight
8 - Asteroid

The thing is that Alteryx has been stating for some time that studios will be going away and that companies should shift to using Collections for the sharing. Which still leaves the problem...

PanPP
Alteryx Alumni (Retired)

Hi @smysnbrg @Ariharan @cjayachandran @ramesh_neel @RodLight 

 

With the recent release of updated APIs, you can change the ownership of workflows via the APIs shown in the image below.

 

 API - Workflow.png

 

 

Hope this helps, if it does please like this post and if it helps resolve your problem, mark it as a solution. If you have any other questions, please let us know.

RodLight
8 - Asteroid

@PanPP , 

Thanks for the response. However...

This API functionality doesn't really address the issue as in order for this to work (as noted in your screenshot), both owners must be in the SAME subscription. And having shared subscriptions is going opposite of the recommended Alteryx best practice that has been noted in various places for some time...and that is...do NOT used shared studios as these are eventually going away...use collections instead. 

 

What is needed is the ability to move a workflow from one subscription to another. Or I guess in the new vernacular of recent versions of the gallery, move from one "workspace" to another.

 

1737280
8 - Asteroid

This API method does not work, as it keeps throwing an error about a parameter that's not on the interface:

 

{ "message": "The request is invalid.", "modelState": { "updateWorkflowContract.RevisionId": [ "The provided revision ID is invalid." ] } }

 

However, the JSON example does not contain such a parameter.  I tried adding "RevisionId": "1" to the JSON input parameter no effect.

 

It's frustrating that such a common need is continuingly ignored.

 

Furthermore, this API has EVERY parameter set to required.  The team that implemented these APIs don't understand the needs.  If I'm modifying certain attributes of a workflow, why should every other attributes be required???  The design pattern for such an API should be all attributes are optional, you update whatever the attributes are passed in, and don't touch any other attributes not mentioned in the call.