Get Started with SDLC
Promoting a package from one environment to another is a key part of the Software Development Lifecycle (SDLC). During the SDLC promotion process, users can validate key metadata across workspaces, verify dependency completeness, and review the logic for a specific workflow version. You can then request promotion, obtain approval, and materialize an immutable package in the target workspace.
Throughout the promotion process, users can review package metadata, validate dependencies, test the workflow, and maintain an auditable promotion history. Each step supports a controlled, secure, and compliant deployment process.
Step 1: Save Workflow as a Package
Save a workflow as a package to deliberately mark a tested change as release-ready, rather than promoting work-in-progress by default. When you save a package, you assign it a version and description—giving reviewers clear context about what changed and why, before they approve it for promotion.
This also preserves a traceable release history: each saved package becomes a distinct, identifiable point in the workflow's evolution, making it easy to look back and understand what was released, when, and for what reason.
To save a workflow…
Sign in to Alteryx One.
Select Library from the left panel. A list of all the workflows owned or shared with you is displayed.
Select the three dots menu icon for the Workflow you want to save as a package.
Select Save as Package.
Once you select Save as Package, a modal is displayed with the following fields:
Create New or Select Existing Package: Enter a custom name to create a new package or select an existing package from the dropdown menu.
Note
If you enter a unique package name, a new package is created starting at version 1. If you select an existing package from the dropdown, a new version of that package is created.
Description: Provide a description or other relevant information about the package to provide context.
Note
The Description field appears only when you create a new custom package.
Version Name: Add metadata to a specific version of an asset. This metadata can help identify asset versions through APIs or include additional version-specific details.
Select Save.
If you create a new package, then a snackbar displays a confirmation message indicating that the package was created, with a link to its asset details page.
If you select an existing package and a package with the entered name already exists, a pop-up is displayed with two options. Select Create New Package to create a new version of the package. Select Overwrite to replace the existing package.
Step 2: Request Package Promotion
Users can request promotion of a package to another workspace representing an destination workspace from the asset details page or from the three-dot menu in the packages page. This action creates a promotion request linked to a specific package and workflow version, enabling promotion of the asset across workspaces.
To start a promotion request…
Select SDLC Manager, Library, or Overview > Recent Assets from the left menu to view the list of workflows. Use the available filters to narrow the list as needed.
Select the workflow that you want to promote. The asset details page is displayed.
Select Request Promotion.
A pop-up appears, prompting you to select the destination (upstream) workspace. Select the radio button labeled Select from list to choose a workspace from the list of available workspaces in your account. Or select the radio button labeled Enter Workspace ID manually.
Note
The user who submits the promotion request is not required to be a member of the destination (upstream) workspace.
Select Promote to promote the package to the destination (upstream) workspace.
You can initiate a promotion request directly from the places where you already find and manage your assets. There is no need to manually recreate, re-upload, or export the asset to move it forward. Whether you're viewing a package's asset details page or browsing your assets list, the promotion action is right where you're already working, so moving a workflow to the next workspace fits naturally into your existing workflow management process.
Step 3: View Outgoing Requests
After a promotion request is submitted, all users with the appropriate approver capability in the destination (upstream) workspace receive email and in-app notifications.
For more details about the notification, go to Notifications.
A confirmation snackbar appears at the bottom of the page, indicating that the promotion request was created. The message includes a link to the Outgoing Request details page. Select View to go to the package details page of the outgoing request.
To view and track the status outgoing requests…
Select SDLC Manager from the left navigation panel.
Select Outgoing Requests.
Track the status of the promotion requests within the current workspace, especially if you don’t have access to the destination (upstream) workspace.
Incoming Requests
User persona: Approver
Step 1: View Incoming Requests
Requests initiated from a downstream workspace that require review or action in the destination (upstream) workspace are listed under Incoming Requests. Review the promotion request metadata, justification, and package content before approving or rejecting the request.
To view incoming promotion requests...
Select Incoming Requests.
Select the promotion request that you want to view and take action on.
Note
The statuses of both outgoing and incoming promotion requests are dynamically updated across workspaces as they change.
Step 2: Dependency Mapping
If the package contains unresolved dependencies, map each dependency to its equivalent in the target workspace before you approve the promotion request.
For Designer Cloud workflows, map each dataset to the corresponding dataset in the target workspace.
For Desktop and Workspace Execution workflows, map each Workspace Execution connection to the corresponding connection in the target workspace.
You can't approve the promotion request until all required dependency mappings are resolved.
Dependency mapping allows the workflow to run in the target workspace without copying workspace-specific datasets, connections, or credentials. Each workspace can continue using its own datasets, connections, permissions, governance policies, and storage configuration.
Note
Datasets and connections referenced by a package are not migrated or promoted across workspaces. Only their references (IDs) are retained to preserve asset provenance and to display dependency metadata during review and approval. This helps ensure workflows are reviewed accurately and run correctly in each workspace without unintentionally copying or overwriting data.
To map and fix the dependencies before approving a promotion request…
Select Fix Mappings in the package details page. The Create a Connection Mapping modal appears. Use this modal to map Workspace Execution connections referenced by a package to the corresponding connections in the target workspace.
Note
Before you begin, create a connection in the target workspace with the same configuration as the source connection. This target connection must already exist before you can select it in the mapping.
Source Connection: This is the connection used in the source workspace, including its name and connection ID. Review the Source Connection to identify the connection referenced by the package.
Target Connection: The connection you're mapping to in the target workspace. Select an existing connection from the dropdown, or view the pre-filled mapping if one already exists.
Repeat this process for each unmapped connection.
Note
Some connections may already be mapped and appear as non-editable. This means the mapping was already configured at the workspace level and applies across all workflows and packages in that workspace. Select Review connections to view or manage these mappings.
Select Save Changes to apply the mapping after you've selected a target connection for each unmapped source connection. This mapping persists even if the package is overridden in the future, so you won't need to remap the same connection again on subsequent promotions.
Select Close to exit without saving.
A snackbar confirms that the dataset mapping is fixed.
Step 3: Test Run the Promotion Request
Select Run in the promotion request details page to execute the promotion request before approving it. You can run the asset using the final dependency mappings or other data available in the target workspace, such as sample or test data.
Note
Run button remain disabled until all dataset mappings are resolved.
The test run is validated against your roles and permissions, allowing you to inspect the outputs, identify failures, and verify the asset before it is approved and materialized in the destination workspace.
Each test run creates a Job that records the execution status and outputs for review and traceability.
Note
A test run is an actual workflow execution, not a preview. Depending on how the workflow outputs are configured, it can create or write data in the target workspace. Before running a test, verify that you are using the appropriate datasets or connections and confirm the workflow's output behavior.
Step 4: Approve/Reject the Promotion Request
To take action on a promotion request…
Select SDLC Manager from the left navigation.
Select Incoming Requests.
Select the promotion request that you want to approve or reject. Approving the request creates an immutable package in the target workspace. If the request is rejected, no package is created in the target workspace. The approval is recorded in Job History.
Select Approve & Merge to approve the request.
Select Reject to reject the request. In the Reject Package modal, enter a reason for rejecting the promotion request in the Comment field.
Note
Approve & Merge button remain disabled until all dataset mappings are resolved.
After you approve or reject the promotion request, the requester receives an email and in-app notification with the promotion request decision and any included comments.
Note
If you don't have promotion approval permission, the Approve, Reject, and Fix Mappings buttons are disabled. Hovering over a disabled action shows a tooltip explaining which permission is missing.
If you don't have promotion request permission, the Cancel Request and Request Promotion buttons are disabled, with a tooltip explaining the missing permission.
If you have the relevant permission, you can perform the corresponding action as usual.
Approved Packages
Once an incoming promotion request is approved, the package becomes an immutable, executable asset that you can run, share, and use. The approved package becomes available in the destination workspace through its asset views. Package runs are recorded in Job History.
Sharing a package doesn't grant access to its datasets or Workspace Execution connections. Users must have the required permissions to access the dependencies referenced by the package.
Note
If a promotion request is rejected, a package is not created in the destination workspace.
Once a package is created, it can't be edited directly. Any change that updates the metadata, content, or configuration creates a new version of the package instead of modifying the existing one. This ensures every version remains a stable, auditable point in the release history.
Each package version is uniquely identified and timestamped, providing a traceable record as the package moves through the promotion lifecycle. Previous package versions remain available in the Library and can be restored for re-promotion when needed. For more information, go to Manage Package Versions.
Notifications
When a promotion request is created, approvers in the target workspace receive a notification to review the request. After the request is approved or rejected, the requester receives a notification with the result. The rejection notification includes the reviewer’s comment or reason for rejecting the promotion request. Notifications are sent through email and in-app notifications. For more information about notifications and how to manage them, go to Notifications and Notification Settings.