Handling Role Transfers

[raychase]

Hi all,

I'm curious how other Alteryx Server customers are handling role transfers.  Knowing that all workflows are tied to a user's private studio, what happens when a user transitions to a new role (using their same AD account), and you no longer want them to have access to their existing workflows/schedules?

We are in the process of developing detailed documentation for onboarding/offboarding/transfers and despite my experience with Alteryx Server, I still struggle to identify easy methods for handling user changes.

I would love to hear how other companies are handling this.

Thanks.

[fmvizcaino]

Hey @raychase ,

You have a few options there. 

1. Include another user in the private studio, this will work if you have a new user coming to the other user's place.
2. Manually download the workflows and save them in another studio.
3. Use gallery APIs to migrate the workflow from one studio to another. (This one is tricky but is the best one in my opinion)
   
   1. https://community.alteryx.com/t5/Alteryx-Server-Knowledge-Base/Migrating-Workflows/ta-p/335774
      1. It is not all built, but with a few tweaks, you will be able to do everything dynamically
   2. https://help.alteryx.com/developer-help/gallery-api-overview
      1. If you want, there are C# and Javascript samples built to help you leverage the APIs
   3. https://www.youtube.com/watch?v=TFYf0cxS85s
      1. Example showing how to use APIs to download workflows

Best,

Fernando Vizcaino

[raychase]

Thanks for the response, @fmvizcaino.  I have some follow-up comments:

Option 1. Adding a new user to the private studio works, but the idea is that we want the original user to be removed, so they lose access to their original content.  Doing so breaks their existing schedules, which brings us to Option 2.

Option 2. This is what we tell our users to do today, but it is painstaking for a new user to download > republish hundreds of workflows, especially if there is minimal overlap (if any) with the existing user for support/guidance.

Option 3. would be fantastic, if it works.  The goal would be to download all workflows owned by X (existing user) and republish under authorship of Y (new user).  My understanding is that there have been issues with migration via API for workflows that contain Gallery connections (aka nearly all of our workflows).  Can you confirm whether or not this continues to be the case?

We would also prefer to migrate all existing schedules to the new user.  From my understanding, this is completely manual, and a huge ordeal for a user with hundreds of schedules.

[fmvizcaino]

Hey @raychase ,

Here I talk about that issue, there are 2 workarounds for that.

https://community.alteryx.com/t5/Alteryx-Server-Discussions/Migrating-Workflow-handling-Alias-Betwee...

I have never tested or checked, but maybe it is possible to start messing with the MongoDB and change the workflow ownership to another user and move the schedules together.

When uploading the workflow back to the gallery with the Gallery API, the only information needed to save that to a studio is the new owner's email, maybe it is easy as that in mongoDB.

Here is a tutorial showing how to use Robo 3T to connect to mongoDB.

https://community.alteryx.com/t5/Alteryx-Server-Knowledge-Base/How-to-Identify-and-Fix-Null-Incorrec...

Best,

Fernando Vizcaino

[raychase]

I'm very familiar with the MongoDB and Robo3T, and I'm quite certain that modifying schedule ownership isn't straight forward.  Much of the schedule data is contained within the ServiceData BLOB field, and modifying that would involve re-creating its checksum, which hasn't been done successfully, from what I'm told.

In terms of the identified workarounds for posting workflows via API, we do not use a dedicated service account, so Alteryx' recommendation isn't particularly relevant.  Your advice to include the TemporaryAlias is ingenious; however, seems cumbersome.  Publishing via the API endpoint should involve similar functionality as publishing from Designer.

In hindsight, I wish we had avoided Gallery connections altogether, in favor of local connections created identically on the Server and locally in Designer installations (ie. the same mechanism used for in-db connections).  At least then there's no dependency on embedded alias files.