Alteryx Analytics Hub Knowledge Base

Definitive answers from Alteryx Analytics Hub experts.

Analytics Hub Sandbox Strategy


NOTE: The following article applies to Analytics Hub 20.4 only.  Version 21.1 and newer includes a set of Sandbox licenses for a separate Sandbox environment. For questions, please reach out to your Alteryx representative. 


A sandbox is a development and testing environment isolated from a production environment or repository.  Sandboxing protects an organization’s production data, programs, and other content from changes that could be damaging to mission-critical systems.  But, sandboxes can be difficult to manage … until now.  A recommended best practice from Alteryx is to leverage a “Sandbox” environment for developing and testing Workflows, data connections, user configurations, and other settings before publishing to a production environment. 

This article walks through a Sandbox strategy for Alteryx Analytics Hub, and applies to Analytics Hub version 2020.4. Alteryx Analytics Hub 2020.4 has added functionality that provides for a sandbox development environment while streamlining user administration, ultimately providing easy workflow promotion from the sandbox to production.

Sandbox Strategy

This sandbox strategy for Analytics Hub is based on two key concepts, Sites and Job Tags.  Sites were introduced in Alteryx Analytics Hub at inception, Job Tags are introduced in the 2020.4 version.
  • Sites are separate and secure areas to store data files, run workflows, and collaborate with other users. All content in a Site is completely walled off from other Sites. 
  • Job Tags allow users to direct the execution of a particular workflow run or schedule to a specific Worker (Alteryx computing engine).
This example Sandbox Strategy for Analytics Hub is to creates two Sites:
  • Sandbox – where all development and testing work takes place. Here users can define new data connections, upload, and collaborate on new workflows and analytic apps.
  • Production – where all curated data assets and workflows are uploaded and scheduled.

The Analytics Hub environment should include at least two Workers.  One tagged for “Sandbox” jobs and the other tagged for “Production” jobs.  Additionally, the Sandbox worker should also be configured to run untagged jobs.  An architectural diagram of the environment is depicted above.
This approach provides a dedicated Worker for production jobs, which prevents development and debugging jobs from tying up the job queue, which could block production jobs from being able to run.  Additionally, if a user submits a job and does not specify a job tag, the workflow execution would occur on the Sandbox worker where untagged jobs are allowed, and not the Production worker.

  • An example Production Worker configuration with a “Production” Job Tag, and configured not to execute untagged jobs.
  • An example Sandbox Worker configuration with a “Sandbox” Job Tag, and configured to execute untagged jobs.
  • A user specifying a job tag before running a workflow. 

Important Points
  1. The ability to specify a Job Tag at workflow execution time is restricted to Contributors, Data Stewards, and Site Admins.  Users with the “Consumer” role cannot select a Job Tag.
  2. The Job Tag must be specified when the Schedule is created, or when an on-demand job is being submitted, under the Advanced Settings panel.  Otherwise the job will be “untagged” and be directed to the Sandbox Worker in the above scenario.
  3. A group of users need to be members of both the Sandbox and Production Sites to promote content from the Sandbox site to the Production site.  To promote content from the Sandbox site to the Production site, a user would need to open the Workflow assets in Designer from the Sandbox site, then republish the assets to the Production site. 
  4. To ease content promotion from the Sandbox site to the Production site, data connections with the same names should be created on both sites – the only difference should be in the connections themselves, Production pointing to Production data, while Sandbox pointing to development data.
  5. The above strategy does not provide for a separate Analytics Hub environment to test new Alteryx Analytic Hub versions and upgrade procedures.  To test product upgrade procedures, it is recommended to stand up a separate Analytics Hub environment and configure with SSL certificates, LDAP integration, and SMTP notifications.  Users will not be able to access this environment, nor will jobs be able to run.  This will allow the Alteryx administrator the ability to test product upgrades before upgrading the production environment.


The strategy outlined here provides an organization the ability to separate business critical production job execution from developers who are building and testing new applications while simplifying administration and license management into one Alteryx Analytics Hub environment.
If you have any questions about this approach, please reach out to your Alteryx representative.
No ratings