How to move from Subscriptions to Collections in Server

How-To

Move From Subscriptions to Collections.

This page is meant to help Alteryx Server users move their assets from a subscription model to a collections model. We recommend all customers move their assets from subscriptions sharing to collection sharing in preparation for the deprecation of subscriptions. Additionally, the collection structure gives curators and users increased visibility into the sharing of assets. Compared to studios, it’s much easier to update and monitor permissions to these assets as well. By sharing assets through collections, you can implement a secure, flexible, and easily maintainable sharing structure. In this document we will use the name subscription and studios interchangeably.

Subscriptions Structure

To help you understand how to best share assets through subscriptions instead of collections, we will start by outlining how subscriptions are structured. For this outline we will be assuming the customer is only using studios at this time and not collections.

Subscriptions are private spaces that hold workflows. Users can be added to subscriptions to gain access to the workflows in the subscription. Each user/workflow can only belong to one studio at a time and curators can create new studios and move users between studios using the UI or via API.

While users can move between studios, workflows are tied to the subscription they were created in and can not be individually moved between studios. Once a workflow is created in a studio, it must remain in that studio regardless of the studio the workflow owner is in. There is one exception for this which will be outlined below. Therefore, the user who created the workflow will be listed as the “owner”, but the creator’s studio owns the workflow. As a result, when a user moves to another studio, the user’s workflows remain in their original studio because they are owned by that studio. If a user owns a workflow in studio A and then moves to studio B, the workflow will remain in studio A and even though the user is the workflow owner, they will no longer have access to that workflow. The workflow will still show up under “My Files” for the user, but they will be unable to run the workflow.

Unlike workflows, schedules are actually owned by users. Therefore, if a user moves between studios, their schedules will move with them. To run a schedule the schedule owner must have access to the scheduled workflow, so if a user moves out of a studio without the scheduled workflow, that user will need to have the workflow shared with them via a collection or transfer the schedule ownership to a user in the workflow’s studio. Schedules can be shared within a studio if the studio permission has ‘Shared Schedules Enabled’ selected.

This diagram below demonstrates that workflows and schedules can be shared with users using studios. The studio and workflows are red to represent that the studio owns the workflows and the users and schedules are blue to represent that users own schedules. The dotted lines show the workflows that the user is the creator of. One workflow exists without a line to a user because that user was deactivated or has moved to another studio, but the workflow remains in the studio.

image.jpeg

Assets:
Users, workflows, and schedules
Structure:
One studio per user and workflow
Multiple users per studio
Permissions:
Curators can create studios and move users between them

Move Users Between Studios

Let’s run through an example to explain how users move between studios. Say Alice and Tom start out in studio A together, and then Tom moves to studio B

image.jpeg

If Tom moves to studio B, you will notice that the workflow he created did not move with him. Because the workflow is still in studio A, Tom no longer has access to that workflow. Also note that when Tom moved to studio B, unlike workflows, Tom's schedules did not remain tied to studio A. Additionally, if the schedule Tom created is connected to the workflow he left in studio A, that workflow will automatically become disabled because Tom does not have access to the workflow, therefore the schedule can not run. In this scenario, an admin can use the Server V3 APIs to transfer the schedule ownership to Alice, or Alice can create a new schedule for that workflow. Schedule transfer is not studio dependent, so schedules can be transferred to any user with access to the scheduled workflow. You will also notice that if Tom creates a new workflow while in studio B, the workflow will now belong to studio B.

Move Workflows Between Studios

Now let’s review the one exception to the rule that workflows can not move between studios. There is one way for workflows to move between studios. If there is only one active user in a studio, an admin can change the user’s “private studio subscription key” under the user’s profile, and the user and all workflows from that studio will be moved to the new studio.

These criteria that must be met for to move workflows between studios.

There must be only one active user in the studio you wish to move workflows from.
The user and the workflows in the studio must transfer to the same new studio. It is not possible to only transfer some of the workflows to the new studio or to transfer the workflows to the new studio without also moving the user.
The user’s private studio subscription key must be updated in their user profile (Admin homepage → users → select user you wish to move between studios → update private studio subscription key). If the user’s subscription key is updated via the admin view subscription page, the user will move between studios, but the workflows will not.

image.png

To transfer assets with a user from one studio to another, update the user’s private studio subscription key in their user profile.

Here is an example. Say Alice, Tom, and Emma are all in their own studios. Alice gets promoted and no longer needs access to server, so Emma is going to take over managing all of Alice’s assets.. Since Alice is the only user in studio A, a curator can go to Alice’s user profile and update the private studio subscription key to be studio C.
To do this, an admin should first get Emma’s private studio subscription key from the subscription details page (Admin → subscriptions → select subscription name). Then, the admin should update Alice’s private studio subscription key from her user profile and replace it with Emma’s key (Admin → users → select Alice → scroll down to ‘Keys’ and click ‘Edit’ → input Emma’s key → ‘Save’.
When the curator saves Alice’s profile, Alice and all of the assets in studio A will be moved to studio C. Because Alice was the only user left in her studio, Alice and all of her assets will be transferred to Emma’s studio. The admin can then deactivate Alice as a user.
To transfer the assets along with Alice to the new studio, the private studio subscription key must be updated from Alice’s user profile (NOT the subscription details page). Please note, once a user and their assets have been moved to a new studio, this action cannot be undone.

You will notice that all the workflows from studio A including the workflows with no active owner and the workflow that Tom created are moved to studio C. Tom still does not have access to his workflow in studio C because he is in studio B, but now Emma has access to all of the workflows Alice brought with her as well as Alice’s schedules if schedule sharing is turned on for that studio. At this point, Alice can be deactivated from server and studio A can be deleted. Please note that if Alice is deactivated, her schedules will no longer work, so they will need to be transferred to Emma using the v3 APIs before Alice is deactivated.

image.jpeg

The Benefits of Collections

Collections are permission restricted spaces where users can easily share assets. Only authorized users will have access to one or more collections. Collections are ideal for work groups that share a common goal but are not public (e.g., controlling, human resources, project x or y...). We recommend you create collections that reflect your team’s organization structure. For example, you can create as many collections as there are teams (Finance, HR, Marketing, Risk, ...). This approach allows you to structure and secure the content that each team will produce.

Users can create collections as long as the permission has been granted in their user profile by a curator. Workflows, insights, schedules, users, and groups can be added to a collection. For users and groups added to a collection, there are a series of collection permissions that dictate how the user can interact with the collection and assets within it. Based on these chosen permissions, users can use and update assets inside the collections. The owner of the workflow can update these permissions at any time. Additionally, curators can change collection owners and update user and group permissions for all collections. Curators can also create and edit collections using the Server APIs.

Unlike studios, collection assets and users can be updated as needed. The collection owner can move assets and users in and out of the collection as needed, and curators can change the owner of a collection at any time. This makes it easy to keep collections up to date with your sharing needs. Moving assets or users into a collection does not change ownership, and allows assets to be shared with users regardless of ownership.

image.jpeg

Assets:
Users, groups, workflows, schedules, and insights
Structure:
Multiple users per collection
Multiple collections per user
Permissions:
Users can create collections with permission granted by a curator

image.png
Example of the permission types available to users in collections.

Studios to Collections: Alteryx Recommendation

Now that we understand how both studios and collections work, we can outline what the transfer structure will look like. Since we are doing this move in preparation for the deprecation of studios, It’s important to think outside the limitations that currently exist with studios. Collections allow users to manage workflows very similarly compared to studio sharing, but assets are still functionally owned by the studio at this time. We will take these conditions into consideration as we find a structure that works with the existing architecture, while simultaneously preparing for a future state where studios no longer exist.
The primary change that will occur with the deprecation of studios is that the studio will no longer be the functional “owner” of a workflow. This will be immensely helpful because it will make it much easier to track data lineage, clarify sharing structures, and most importantly, transfer ownership of an asset from one user to another. For example, after studios are deprecated, if a Server user leaves the company, a curator will be able to easily transfer all of that user’s assets to other users without disrupting existing sharing structures.

Create Collections to Match Studios

The high level structure of the move is relatively simple. The main goal is to create collections that match your existing studio structure. This means creating a collection for each of your existing shared studios and then adding the users and assets from that studio into the new collection. If there is only one user in a studio, a separate collection for that studio does not need to be created. By copying shared studio structures in collections, you can ensure that your users still have access to all of their shared assets. Functionally they should notice little change moving from having assets shared with them via a collection rather than a studio.

image.jpeg

This diagram visualizes how a collection can be structured to provide the same sharing that existing studios do. Comparing the studio and collection above, you can see that the same workflows, schedules, and users from the studio are added to a new collection, creating an equal sharing structure without ownership boundaries.

Let’s review this concept with a simplified example: Alice was a new Server user with curator permissions. Upon her account creation, a studio was automatically created for her called Alice’s Studio. When Alice added workflows to Server via designer, an API, or an upload, the workflow was added to Alice’s studio and she was listed as the owner. Alice could not view the workflows from anyone else’s studio, and no one else could view the workflows in Alice’s studio.
Tom joined Alice’s team a few months later and a Server account was created for him. Alice wanted to share all of the workflows she created with Tom and have access to all the workflows Tom creates, so Alice added Tom to her studio and re-named the studio “Finance Team.” Over the years Emma was added to the “Finance Team” studio as well.

Now, Alice needs to move from studios to collections, so she creates a collection called “Finance Team” and adds all of the users and assets from the “Finance Team” studio into the “Finance Team” collection. Moving forward, Alice, Tom, and Emma should all share assets with each other using the “Finance Team” collection or any other collections they create.

image.jpeg

You will notice that Alice, Tom, and Emma are all in the same studio, that the workflows they add to the Finance Team collection are still owned by the studio. This isn’t a problem because Alice, Tom, and Emma still have the workflows shared with them via collection, so even after studios are deprecated, all three users will still have access to the workflows in the Finance Team collection. Additionally, since schedules are not owned by the studio, they retain ownership by their creator even when added to the collection.

Move Users to Private Studios

The second goal, which is optional, is to move users back to their own private studios. Moving users back to their own studios clarifies ownership of assets and forces users to share assets using the collection structure. This will help ensure that sharing remains unchanged for existing users once studios are deprecated. At the very least, we recommend that when new users are added to Server, that they remain in their own private studio and are not added to any shared studios unless they are taking over full ownership of that studio.

To continue with our example, Alice can move all of the users (Tom and Emma) from the “Finance Team” studio back into their own private studios so that Alice is the only remaining user in the “Finance Team” studio. Since Tom and Emma are both in the “Finance Team” collection, they will still have access to those workflows and schedules. However, if a user is not in the same studio as a workflow, that user can not add that workflow to a collection. So if Tom and Emma were separated back into their own private studios, Alice would be the only user able to add any workflows from studio A into collections.

After the deprecation of studios workflows will no longer be tied to a studio, so studio membership will not dictate which workflows can be added to a schedule.

The benefit of moving Alice, Tom, Emma to their own studios is that the assets can now be shared between them in any combination to accommodate their sharing needs. With collections, Alice, Tom, and Emma can share assets in various combinations and there is more oversight and permission granularity when sharing assets. This will make it easier for curators to audit what assets are being shared with whom and with what permissions. Curators can also edit these collections as needed to maintain data security.

image.jpeg

How to Share Assets If a User is Deactivated

If you choose to move users back to individual studios and a user leaves a company, or no longer needs access to Server, we recommend that you share the user's assets with their team using collections. We recommend this approach because even if a user is deactivated, the workflows and schedules they shared via collections will remain in those collections and the other users in the collection will still have access to them. If you deactivate the user, a curator will need to transfer their schedules to someone else in the collection with access to the scheduled workflow, and this can be done using the V3 APIs. Once the workflows and schedules are added to a collection, other users and assets can be added or removed from the collection as needed into the future. This makes it easier to update sharing access to assets into the future.

We recommend this method over trying to change ownership of a workflow for a few reasons. First, as we outlined earlier, workflows aren’t really “owned” by their creators. Since the the studio owns the workflow, the only real way to transfer ownership is to join the studio the workflow is in. Since users are limited to belonging to one studio at a time and since workflows for the most part can’t move between studios, sharing the assets through collections is currently the more flexible route to sharing those assets. With collection permissions, users in a collection can edit a workflow, schedule the workflow, run the workflow manually, and update workflow versions giving users the power they need to use those shared assets. Additionally, curators who have the workflow shared with them via a collection can also update the workflow settings as well.

For example, say Alice is promoted and no longer needs access to Server in her new department. To share her assets with Tom and Emma, we recommend you create a collection and add all of Alice’s workflows and schedules to it as well as Tom and Emma. Tom and Emma will now have access to all of Alice’s assets even if she is deactivated as a user. Please note though, that either Tom or Emma will need to take ownership of Alice’s schedules once she is deactivated (represented by the grey dotted lines).

image.jpeg

If Alice loses access to Server before she can move her assets into a shared collection, a curator will need to move the assets to collections. To do this, a curator (Tom) can join the deprecated user’s studio (studio A). Then, Tom can add the assets from studio A to collections as needed, and then return to his original studio (studio

after he has added the assets to collections. Please note: Our recommendation is to add the curator (Tom) to Alice’s studio via the Admin-Subscriptions page as opposed to updating their studio subscription key from their profile. Changing Tom’s studio via the Admin-Subscriptions page guarantees that there’s no risk of Tom’s assets moving to Alice’s studio if he’s the sole member of his studio.

3 Ways to Transfer Ownership of Assets

If you do need to transfer ownership of assets, there are three ways to do so.

Move studios
1. Moving into a studio will give the user ownership of the workflows inside it, so a user can either be moved into a studio with the assets or you can use the move workflows between studios method mentioned above to move a user and all of their assets into someone else’s studio.
Download and reupload workflows
1. If a user’s assets need to be owned by separate individuals, as long as the assets are shared in Collections or made public and the ‘Others can download this workflow’ setting in the workflow settings is turned on, then Artisans and Curators can download and re-publish the workflow as the owner. If not, Admins can download the assets via API and send them to the new owners so they can upload them to Server.
3V3 APIs
1. Curators can use the V3 APIs to update the workflow owner. However, the original owner, new owner, and workflow must be in the same studio.
2. Curators can use the V3 APIs to update a schedule owner. However, the new owner must have the scheduled workflow shared with them via collections or studio.

Step By Step Instructions to Move From Studios to Collections

It’s possible to move your organizational structure from studios to collections either using the Server UI and limited API use, or entirely via Server APIs. If you have a large number of shared studios and users, we recommend you use the Server APIs for a speedier process. Only users with Curator permissions will be able to view all of the necessary details to complete the move.

As a reminder, only studios with multiple users where users are sharing assets through studio sharing will need new collections created. If users are in individual studios, new collections do not need to be created for those studios.

Via Server APIs

Create a new collection for each existing shared studio
1. Generate a list of all studios in Server and retrieve the ‘name’ and ‘studio Id’.
  1. GET /admin/v2/subscriptions
2. Get a list of all users and their studio IDs. You can combine this list with the subscription list to identify which studios are shared, meaning the studio has multiple users in it.
  1. GET /admin/v2/users
3. Create a collection for each shared studio. When creating a new collection, you can choose to either re-name the collection or keep the name the same as the studio. We recommend you name the collection the same as the studio until the move is complete to reduce confusion. Please note that studios and collections can have duplicate names, so we recommend keeping track of which studio id corresponds to each collection id.
  1. POST /v3/collections
Add the studio users to the new collections
1. Add active users to the new collection that corresponds with their studio
  1. PUT /v3/collections/{collectionId}/users/{userId}/permissions
    1. These are the collection permissions that would match studio permissions for non curator users. Adding an expiration date is optional.
      1. "isAdmin": false
      2. "canAddAssets": true
      3. "canRemoveAssets": false
      4. "canUpdateAssets": true
      5. "canAddUsers": false
      6. "canRemoveUsers": false
    2. If the user is a Server curator, all of their collection permissions can be set to “true”. You can do this by selecting “true” for all permissions, or just select “true” to isadmin and leave the rest blank.
Add the studio assets to the new collections
1. Use the studio Id to generate a list of all workflows in each studio. When using the API, input the subscription Id into the GET parameter to retrieve the workflows associated with just that studio. If you leave all parameters blank, you will get all workflows in Server.
  1. GET /admin/v2/workflows/all
2. Add workflows to the new collection that corresponds to the studio they are in. You must add workflows using their workflow ids.
  1. POST /v3/collections/{collectionId}/workflows
3. If the studio has ‘Shared Schedules Enabled’ turned on, those schedules will need to be added to the new collection as well. You can find this setting by viewing the Admin-Subscriptions details page for the studio. Schedule ownership is tied to users, not studios, so schedules will be matched to collections based on the users in that collection.
  1. Get all existing schedule information. You can choose to add ‘active’, ‘inactive’, or both types of schedules to the collection.
    1. GET /v3/schedules
  2. Match the schedule information to the user ID and identify what collection they belong to. This is the same process you did in step 2-B.
  3. Add the schedules to the collection the schedule owner is in.
    1. POST /v3/collections/{collectionId}/schedules
Optional:
1. Update the collection owner once the move is complete.
  1. PUT /v3/collections/{collectionId}
2. Turn off the 'Shared Schedules Enabled’ setting for all studios. This will ensure that users can only share schedules via collections. This will also ensure users share schedules via collections so that when studios are deprecated, they experience no change in schedule sharing. This must be done via the server UI.
  1. Admin → subscriptions → choose subscription → Details Tab → deselect 'Shared Schedules Enabled’ → Save

Via Server UI & Server APIs

Gather existing studio information
1. Create a list of all studios in Server with more than two users and retrieve the ‘name’, ‘studio Id’, 'Shared Schedules Enabled’ setting, and list of users for each studio. If any studios have duplicate names, we recommend re-naming them before you begin to ensure each studio has a unique name.
  1. Admin → subscriptions → choose subscription → Details Tab → Users Tab
Create a new collection for each existing shared studio.
1. When creating a new collection, you can choose to either re-name the collection or keep the name the same as the studio. We recommend you name the collection the same as the studio until the move is complete to reduce confusion.
  1. Home → collections → ‘+ New’ → Add collection name → 'Create’
Add the studio users to the new collections.
1. Once you have a collection created, you can add active users to the new collection that corresponds with their studio.
  1. Home → collections → choose collection → users tab → ‘+ Add’
2. When adding users, these are the collection permissions that would match studio permissions for non curator users. If the user is a Server curator, you can set their Admin collection permission to ‘Yes’ and all of their collection permissions can be set to ‘Yes’. Adding an expiration date is optional.
  1. Admin: no
  2. Add Assets: yes
  3. Remove Assets: no
  4. Update Assets: yes
  5. Add Users: no
  6. Remove Users: no
Add the studio assets to the new collections.
1. This is the only portion of the move that needs to be done using APIs. The APIs are necessary to know which workflows belong to each studio. If you choose not to use the APIs, you can ask your users to add all of their workflows and schedules to the new collections manually.
2. Use the studio Id you collected from the subscription details page to generate a list of all workflows in each studio. When using the API, input the subscription Id into the GET parameter to retrieve the workflows associated with just that studio. If you leave all parameters blank, you will get all workflows in Server. Collect the Workflow Id associated with each workflow in a studio.
  1. GET /admin/v2/workflows/all
3. Add workflows to the new collection that corresponds to the studio they are in. When you go to add a new workflow in the ‘Add Workflow’ modal, type in the workflow Id, select the workflow that appears, and click add. We recommend you use the workflow Id instead of the workflow name, because there may be multiple workflows with the same name, but workflow ids are unique to each workflow. The workflow Id is also located on the workflow details page of a workflow in the Server UI.
  1. Home → collections → choose collection → workflows tab → ‘+ Add’ → type workflow Id into drop down → select workflow → Save
4. If the studio has ‘Shared Schedules Enabled’ turned on, those schedules will need to be added to the new collection as well. Schedule ownership is tied to users, not studios, so schedules will be matched to collections based on the users in that collection.
  1. Find the schedules owned by each user. Go to the schedules table and search the user’s name in the search bar. For each recurring schedule, owned by that user, collect the schedule name.
    1. Admin → schedules → search user name → identify recurring schedules by sorting by next run.
  2. Add the schedules to the collection the schedule owner is in.
    1. Home → collections → choose collection → schedules tab → ‘+ Add’ → type schedule name into drop down → select schedule → Save
Optional:
1. Update the collection owner once the move is complete.
  1. Admin → collections → choose collection → ‘Change Owner’
2. Turn off the 'Shared Schedules Enabled’ setting for all studios. This will ensure that users can only share schedules via collections. This will also ensure users share schedules via collections so that when studios are deprecated, they experience no change in schedule sharing.
  1. Admin → subscriptions → choose subscription → Details Tab → deselect 'Shared Schedules Enabled’ → Save
3. Create new studios to move users into their own private studios. This will require creating a new studio for each user moving out of a shared studio.
  1. Admin → Subscriptions → New → Name the studio the user’s name and match the default workflow credentials from their old shared studio. Don’t enable shared schedules. → Create.
4. Add the user to their new studio.
  1. Admin → Subscriptions → Choose the new studio you created → Users Tab → Type the name of the user you want to add to the studio in the search bar → Select the user → ‘+ Add’ .
  2. Optionally, you can also update the user’s studio by going to Admin → Users → Select the user → update ‘private studio subscription key’, however, if the user is the only active user left in the studio, the workflows in that studio will transfer to the new studio along with the user when you update the studio using this method.

Q&A

Will there be any changes after I move all sharing to collections and move users to individual studios?
1. If a schedule is not shared via a collection, other users will not be able to view that schedule. Previously if ‘Shared Schedules Enabled’ was turned on for a studio, all studio users could see schedules in a studio. However, once you move to collection, a schedule and the workflow it is scheduled for must be shared in a collection for other users to view that schedule.
2. Only curators with whom a schedule is shared via collections will have access to update workflow settings if users are in separate studios.
If I add a workflow to a collection and then leave the studio that workflow is in, will the workflow still be shared in the collection?
1. Yes
If I share a workflow to a collection and then I leave that collection, can others in the collection still access it?
1. Yes, even if users aren’t in the same collection, if a workflow owner leaves a collection, the users in that collection can still view and run the workflow. This applies to all users with permission to run workflows.
What happens if you delete a studio with assets inside it?
1. Deleting a studio also deletes the workflows in it and they will be removed from any collections they were in. Studios can't be deleted if a user is still assigned to it.
What happens to a user’s workflows when they are deactivated
1. The workflows remain in the studio and other users in the studio will have access to them. Additionally the workflow will remain in any collections it is shared in and users will be able to manage the workflow as usual.
How do I transfer ownership of a schedule?
1. A curator can transfer ownership of the schedule using the V3 APIs, but the new schedule owner must have access to the scheduled workflow via collections or a studio. Schedule transfer is not studio dependent, so schedules can be transferred to any user with access to the scheduled workflow.
What happens to a user’s schedules when they are deactivated?
1. The schedule still exists, but it will be disabled by the validation check since the creator has been deactivated and no longer has access to the workflow. To reactivate the schedule, a curator can transfer ownership of the schedule using the V3 APIs. See “How do I transfer ownership of a schedule?” above for more details
Can users in a shared studio access a schedule shared via that studio if the schedule creator is deactivated?
1. As long as the studio permission has ‘Shared Schedules Enabled’ selected, users can access the schedule if the workflow and schedule are both in their shared studio. If the owner is disabled, ownership of the schedule must be transferred for the schedule to run. See “How do I transfer ownership of a schedule?” above for more details.
Can users in a collection access a schedule shared via the collection if the schedule creator is deactivated?
1. Users can access the schedule if the workflow and schedule have been shared with them via a collection. If the owner is disabled, ownership of the schedule must be transferred for the schedule to run. See “How do I transfer ownership of a schedule?” above for more details.
Can workflows from a deactivated user be added to a collection?
1. Yes, however, the schedule will remain inactive because the workflow owner has been deactivated. If the owner is disabled, ownership of the schedule must be transferred for the schedule to run. See “How do I transfer ownership of a schedule?” above for more details.
Which users can create collections?
1. Create collections is a user level permission, not a role based one. As such, any user that has the "Create New Collections" permission activated can create a collection. Curators can update this permission in the user’s profile details page. Admin → Users → select user → User details page → update "Create New Collections" permission.
If a user has been deactivated, can an admin who is not in the user’s studio, add the user’s workflow to a collection?
1. No. If a user loses access to Server before they can move their assets into a shared collection, a curator must join their studio and move the assets. To do this a curator can join the deactivated user’s studio, add those assets to collections as needed, and then return to their original studio after they have added the assets to collections. If you do this and the curator is the only user in a studio, do NOT update their studio subscription key from their profile, or else all of the curator’s assets will also move to the deactivated user’s studio.
Who can add workflows to a collection?
1. Users in the same studio as a workflow can add that workflow to a collection. To add a workflow to a collection via API, the user must have access to the workflow from the studio. Unless you are in the same studio as the workflow, you can not add the workflow to a collection.

Additional Resources

Example Alteryx Designer Help

Tips and Tricks

Collections

Accepted answers

All comments

There are no accepted answers yet

Quick Links

This months top contributors

atcodedog05 19598

Qiu 15880

binu_acs 15708

MarqueeCrew 13708

apathetichell 13703